충남대학교 컴퓨터공학과의 "실전코딩" 강의를 필기한 내용입니다.
이 문서는 보관이 목적이고, 관리되지 않습니다. 따라서 잘못된 정보가 포함되어 있거나 순서가 뒤죽박죽일 수 있습니다.
People
- Developer : 실 개발자 - 디자이너도 포함됨
- Customer / End user : 고객
- Skateholder : 돈시간 등의 자원을 지원해주거나 아이디어 등의 제공을 하는 사람 - 개발자들을 지휘하고 관리하는 사람 (총 책임자CEO같은 사람들이것제)
Time
모든 개발에는 때가 있고 때를 놓치면 쓸모없는 프로그램이 되기도 한다
시간관리 예시
- skateholder의 요구 → 개발 → 유지 → 서비스 종료
- 지속적으로 버전업데이트를 하면서 성장하는 것(MS의 오피스)
- MSA : 전체의 개발 틀을 깨지 않으며 소규모 업데이트를 지속적으로 하는 것(주로 클라우드 서비스들이 이렇게 함)
Waterfall 개발 방법론
- 다음단계로 넘어가면 이전단계를 고치지 못하는 방식 - 컨베이어밸트같은 과정이다
- 건축쪽의 경우 이런식으로 진행된다
- 소프트웨어 개발쪽에는 효율적이지 않은 경우가 많다
- skateholder의 요구 → 디자인 → 개발 → 테스트 → 배포
- 각 단계가 완성될때까지 다음 단계로 넘어가지 않는다
- 각 단계마다 결과물이 문서로 나오게 된다 + 팀 사이즈가 크다(크기 때문에 관리를 위해 문서가 필요한 부분도 있다) + 코드 작성 가이드가 엄격하게 존재한다
- 결과물이 나오고 나면 유지보수 없이 프로젝트가 끝이 난다
Agile 개발 방법론
- Waterfall 방식의 문제점을 해결하고자 나온 방법론
- Skateholder가 요구사항을 쭉 나열하고 개발하는 방식이 아닌 skateholder가 한팀으로 묶여서 skateholder가 요구사항을 하나 던지고 그걸 만들고 자체적으로 테스트를 하는 과정을 skateholder가 만족할때까지 계속 반복한다
- 즉, 작은 waterfall을 무수히 반복하는것과 비슷하다
- 팀 사이즈가 작다 + 코드 작성 가이드가 그렇게 엄격하지 않다(팀 규모가 작기때문에 코드에서 이해되지 않는 부분은 바로바로 당사자에게 물어볼 수 있으므로) + 유동적으로 피드백이 오고간다
- 실행 가능한 결과물이 나오는데 중요하다 - waterfall의 경우 프로젝트가 마무리 되어야 결과물이 나오는 반면에 agile의 경우 완벽한 결과물을 원하는게 아닌 미흡하더라도 빠르게 결과물을 내놓고 이것을 점진적으로 보완해나가는 방식으로 진행된다
- 결과물이 나오고 나서도 지속적인 업데이트를 하며 유지보수를 한다
- 한국에서는 수직문화가 상당히 강하기 때문에 agile이 제대로 시행되지 않는다
- 이렇듯 agile이 제대로 작동하기 위해서는 문화에도 많은 영향을 받게 된다
Agile Manifesto
- Waterfall의 양식이나 절차에 얽매이는게 아니라 skateholder, developer, end user 즉, 이 서비스와 관련된 사람들간의 소통에 집중하자
- 절차나 문서가 중요한게 아니라 실제로 돌아가는 소프트웨어가 중요한거다 - 별기능 없어도 만드는게 중요하다
- 소비자와 상호작용을 하며 계속 피드백을 받으며 지속적으로 업데이트
- 이렇게 계속 업데이트를 할때 원활하게 하기 위해 변화에 유연하게 코드를 짜는게 중요하다
PO
- agile 팀 내에서 결정권을 가지고 리드하는 역할
- 그렇다고 해서 이사람이 다른 팀원들보다 우위에 있는 것은 아니다. agile팀은 모두 균등한 권위를 가지지만 프로젝트를 행할때 어느정도 결정을 내려야 할 사람도 필요하기 때문에 존재하는 것
Agile이 집중하는 것
- 빠른 전개(agility)
- 빠른 피드백과 인정(resilient)
- 실질적으로 작동하는 소프트웨어
- 연속적인 배포
- 사용자 입장(user story)에서 사용하기 쉬운 소프트웨어
User story
- As a : 나는 누구이고
- I want : 내가 원하는 것은 이것이고
- So that : 이것을 원하는 이유는 ~이다
MVP
- Minimum Viable Product
- 모든걸 다 제공하는 것을 소프트웨어를 만드는게 아닌 다른건 아니더라고 이것때문에라도 사용자들은 이것을 쓸 것이다
- 모든 기능을 다 제공하는게 아니고 핵심적인 몇가지 기능에만 집중해라
- 소프트웨어의 제일 핵심적인 기능, 이것을 제일 먼저 개발하게 된다
Agile method(종류)
- Scrum : sprint를 통해 프로젝트를 진행하는 것 - 이 수업에서 체험해 볼 놈이다
- Kanban : 뭐 도요타에서 처음 시도해 대박을 쳤다는데 뭔지는 몰라
- XD : 짧은 주기로 결과물을 계속 내놓으면서 계발하는거
- TDD : agile manifesto의 네번째랑 관련이 있다??
- 얘네들이 뭔차이인지는 잘 모름 - 몰라도 된다
실제 Agile의 작동 과정
- Sprint : Agile의 짧은 요구-계발-테스트 사이클 - 보통 1~4주 정도 걸린다
- Milestone(M) : 실제 현실에서는 매번 사이클이 돌때마다 배포되지는 않는다 - 어느 시점까지는 우리가 이것을 해야겠다라는 목표지점
Planning
- Product backlog : skateholder의 요구사항을 정리
- Sprint planning meeting : 요구사항을 가지고 각 요구사항을 구현하는데 며칠정도 걸릴지/어떤것들이 필요한지 등을 검토
- Sprint backlog : 실제로 sprint를 진행할 요구사항들을 정리
- 이런것들을 티켓화해서 관리(결정사항을 티켓이라 부른다?)
Sprint
- Grooming : 본격적으로 스트린트에 들어가기 전에 요구사항들을 다시 한번 리뷰하는 것
- Daily scrum(meeting) : 매일 같이 일하는 사람들과 진행상황, 문제점 등등을 의무적으로라도 소통을 하는 것
- 우리가 원하는 기능이 구현되었다고 생각되는 시점에 Demo로 넘어간다
Demo
- Skateholder 나 end user들의 피드백을 받고 반영/최종 테스트 등을 하며 결과물을 내놓음
Retro
- 이번 사이클을 회고하며 이번 사이클에 어떤점이 좋았고 어떤점이 문제였는지 등을 검토하는 것