이전편에 이어서 애자일 프로세스에 대해서 알아보도록 하겠습니다.
애자일 프로세스
[Product Backlog]
Product Backlog는 앞으로 처리해야할 여러개의 유저 스토리로 구성되어 있습니다. 여기서 중요한 것은 사용자 스토리는 사용자의 관점에서 작성이 되어야한다는 것입니다. 이 스토리들은 PO가 정의한 순위대로 정렬되어 있으며 이 우선 순위에 대한 권한은 PO의 직권입니다. 애자일 팀원들은 PO가 내린 결정을 신뢰해야한다는게 기본 전제 조건입니다. 또한 백로그는 계속 스토리가 쌓이는데 PO는 주기적으로 이 스토리들의 실행 여부를 판단하여 정리해주는 작업을 해줘야합니다.
[Sprint Planning Meeting]
Product Backlog가 나왔다면 해당 스크럼 팀에서 수행할 스프린트 기간에 개발할 백로그를 선정하고, 각 백로그에 들어갈 공수를 산정합니다(Estimation). 중요한 것은 스크럼 팀원 전체가 모여서 함께 계획을 수립하는 것입니다. 그리고 바로 전에 수행한 스프린트의 경험을 바탕으로 학습한 내용이 반영이 되어야합니다.
스프린트 플래닝 미팅을 통해 팀원들이 해야할 일들을 정하고 그 태스크를 일하는곳 벽에 볼 수 있도록 포스트잇을 붙이는 방법을 많이 사용합니다. 저의 경우에는 Notion 앱을 사용하여 TO-DO, In Progresss, QA, Completed를 체크합니다.
[Estimation]
에스트메이션은 PO가 만들어놓은 여러가지 스토리를 가져와서 실제 그 스토리를 해결할 팀원들이 이슈가 어느 정도의 크기를 가진 이슈인지 스토리 포인트를 매기는 것입니다. 이때 많이 사용하는 방법이 1점은 1시간으로 생각해서 절대값을 매깁니다. 하지만 이 방법은 대부분 예상이 빗나갑니다. 다른 방법으로는 과거의 스토리 중에 기준이 될만한 것을 가지고와서 그때의 경험을 토대로 에스티메이션을 합니다. 스프린트를 여러번 반복하면 한번의 스프린트에서 어느 정도의 스토리 포인트를 쳐낼 수 있는지 알 수 있습니다.
[Sprint Review]
스프린트가 종료하는 시점에 팀원 전체가 모여서 각자가 한 일을 리뷰합니다. 개발자의 경우 소스 코드 리뷰까지 하면 더 좋을꺼 같습니다. 자신이 한 일을 공유하는 것은 굉장히 좋은 일입니다. 또한 팀원으로부터 피드백을 받을 수 있기 때문에 좀 더 발전할 수 있는 기회가 됩니다.
[Sprint Retrospective]
히ㅗ고는 스프린트를 마무리하는 단계에서 하는 것으로 이 회고가 상당히 중요합니다. 회고를 통해 팀이 발전하기 위해서 어떤 방향으로 가야할지 논의하는 가벼운 회의입니다. 이렇게 회고를 통해서 다음 스프린트에 시행할 액션 아이템을 정한 다음 각 액션 아이템마다 담당자를 붙여줍니다. 개발자의 경우 소스 코드 리뷰까지 하면 더 좋을꺼 같습니다. 자신이 한 일을 공유하는 것은 굉장히 좋은 일입니다.
애자일 포스팅을 마치며
저도 이제 팀으로 활동하며 애자일 프로세스를 적용중입니다. 매 스프린트가 끝나면 배포 후 사용자들의 반응을 보고 다음 스프린트에 이것을 어떻게 반영할지, 프로젝트가 올바른 방향으로 가고 있는지 체크하고 있습니다. 저는 스타트업에서 일을 하고 있지는 않지만 이런 문화를 좋아하기 때문에 팀으로 활동하면서 조금씩 적용을 해보고 있습니다. 다른 포스팅에서 노션을 통해 어떻게 적용하고 있는지로 돌아오도록하겠습니다.
REFERENCE
'개발방법론' 카테고리의 다른 글
| [Clean Code] 주석 작성 방법 (0) | 2020.04.14 |
|---|---|
| [Clean Code] 함수 작성 (0) | 2020.04.06 |
| [Clean Code] 깨끗한 코드란(클린코드)? (0) | 2020.04.02 |
| 객체지향프로그래밍(OOP) 설계 원칙 SOLID (0) | 2020.03.30 |
| 애자일(Agile) 프로세스란?(1/2) (0) | 2020.03.12 |
최근댓글