Agile Practices - Scrum/Kanban

Agile Practices - Scrum/Kanban

조직의 생산성을 향상시키기 위해서는 개인의 실력을 향상시켜야 한다. 하지만 개개인 사이의 협력하는 방법을 바꿈으로써 조직을 발전시킬 수도 있다.

스크럼의 개념 (반복개발)
1) 해야할 일, 하고있는 일, 끝마친 일로 우선 프로젝트를 나눈 후
2) 이번에 할 프로젝트의 긴 개발 기간을 잘게 쪼개서 (이 쪼갠 단위를 스프린트라고 한다) 개발하는 방법을 말한다.
3) 이때 스크럼 프로세스(스프린트, 미팅, 산출물)은 대체로 1~4주 단위의 반복 개발을 한다.

이슈 타입

큰틀 (Epic)

• 단기간 내에 해결할 수 없는 이슈나, 거대한 테스크를 Epic 이슈로 등록한다. 여러 Story들의 집합이다. ~으로서,를 반드시 명시한다.

       예-1 : 사용자로서, 새로운 플레이팅 어플리케이션이 필요하다고 생각합니다

스토리 (Story)

• Chore는 개발을 해야 하는 부분이지만 사용자와 직접적으로 관계되지 않는 개발 내용을 정의한다.
• Story Point라는 것을 입력할 수 있는데, Story Point는 개발에 걸리는 시간 또는 난이도 등으로 지정할 수 있다.
• 기능 추가, 개선점(리팩토링)과 같은 이슈를 Story Issue로 사용한다. ~으로서,를 반드시 명시한다.

       예-1 : 운영팀으로서, 조건에 맞는 여러명의 사용자에게 같은 쿠폰을 발급할 수 있는 시스템이 필요합니다.

Chore

• “as a {user}, I want to {do something}”에 해당하는 사용자 직접적으로 사용하는 기능이다.

       예-1 : “Server Logging 구현”, “데이타 베이스 분리”와 같은 작업등을 정의한다.

Task(Optional)

• Task는 해야하는 일이지만, 구현에 관련되지 않으며, 일정이 없는 경우에 해당한다.

       예-1 : 디자인 문서 작성, 기획과 업무 협의 등이 해당한다.

Issue

• Issue 는 말 그대로 Issue이다. 매니저들이 관리하는 Issue

       예-1 : 클라우드 계약, 서버 Hang up, 솔루션 결정 들과 같이 메니져들이 관리해야 하는 항목이다.

버그 (Bug)

• 현재 버전을 사용하는데 있어 문제가 되는 점들을 Bug Issue로 사용한다. ~으로서,를 반드시 명시한다.

       예-1 : 사용자로서, 안드로이드 어플리케이션을 사용하다보면 자꾸 튕깁니다.

부작업(Sub-task)

• Sub Task가 중요한 내용인데, Story나 Chore를 개발하기 위해서는 여러 가지의 실제적인 개발 작업이 필요하다.
• Story나 Chore가 가질 수 있는 하위 작업(Sub-task)들 이다. 하위 작업(Sub-task)들은 좀 더 구체적인 작업 단위가 된다.

       예-1 : 사용자로서, 안드로이드 어플리케이션을 사용하다보면 자꾸 튕깁니다.

스프린트 시작

1.Epic 등록

2.Issue 등록 및 맵핑

• Component

           해당 프로젝트를 구성하는 구성 요소(iOS, Android, Landing Web, Database)

• Priority(우선 순위 선정)

           Blocker의 경우 해결되지 않으면 프로젝트가 진행될 수 없는 경우

           Critical은 프로젝트 진행은 가능하나 해결하지 않으면 정상적인 서비스 개발이 어려운 경우

           Major 꼭 개발해야 하는 경우

           Minor 개발은 해야 하나 없어도 상관 없는 경우

           Trivial 있으나 없으나 크게 상관 없는 경우

• Issue 생성

          Summary : 제목입력

          Priority : 우선순위생성

          Issue Type : 보통은 Story

          Assignee : 개발 담당(또는 스크럼 마스터로 정해놓고, 나중에 ASSIGN하거나, 각 개발자가 알아서 당겨가는 PULLING 방식)

          Description : Issue에 대한 상세 내용

• 4.Epic 맵핑

         등록된 이슈들을 EPIC에 맵핑

3.Release Version 정의와 맵핑

• 릴리즈 버전을 정의해놓고, 버전에 스토리를 맵핑
• 어느 기능이 어느 버전에 들어 가는지 추적 가능
• 어느 버그가 어느 버전에서 발생해서 어느 버전에서 수정이 가능한지 추적 가능

      *릴리즈의 개념을 먼저 이해하자, 릴리즈는 작동 가능한 서비스 가능한 상태로 만드는 것이다. 정확하게 이야기 하면 Production 서비스로 올리는 것을 릴리즈라고 한다.

4.칸반 보드 세팅

• 진행중인 스크럼 태스크의 상태를 칠판에 표시 해놓는 방식(포스트잇)
• JIRA 애자일 보드로 사용가능

      *칸반 보드의 스타일은 팀과 개발 방식에 맞게 끊임없이 변화해야함

스프린트 진행(Issue 처리)

1.일일 스크럼 미팅

• 약속한 시간에 스탠드업 미팅
• 어제 한일, 오늘할일, 일처리에 장애요인 간단하게 이야기함
• 끼어들거나 질문 금지
• 추가 회의 필요시 스크럼 미팅 끝나고 진행
• 생각보다 잘 안됨 -> 될떄 까지

2.코드리뷰

• 리뷰기법 : http://bcho.tistory.com/276

3.DAILY COMMIT

• 매일 코드 커밋
• 코드 커밋시에 JIRA TICKET #를 적어 넣으면, 티켓에서 코드 변경 사항 추적이 용이함.

4.Issue의 상태 업데이트

• 지정된 담당자는 Issue에 대한 작업을 시작했으면, 작업의 상태를 “To Do”에서 “In Progress”로 변경한다.
• In Progress에서 작업이 끝나면 Done (또는 Close. 사용하는 워크플로우에 따라 다름)을 눌러서, 상태를 옮겨준다.

      *나한테 ASSIGN 된 티켓은 항상 업데이트

5.Comment를 이용한 진행 상태 추가

• comment를 자세히 적도록 팀의 문화를 바꾸는 것은 대단한 노력이 필요하다.

6.Resolve 처리

• 처리가 끝난 Issue를 “Done” 처리