Agile 개발 방법론

Theme , Initiative 개념도 추가됨. Story 는 애자일팀에서  보통 작은단위이슈를 이렇게 칭하고 Ticket 이라고 칭하기도 한다.

https://jellyfish.co/blog/jira-structure/

https://jellyfish.co/blog/jira-best-practices-project-organization/

 

 

스크럼 프로세스의 이해 (애자일에는 대표적으로 스크럼, 칸반이 있으며 스크럼은 신규 SW개발시 많이 사용된다)

• 먼저 팀에 의해 구현되어야 할 필요가 있는 일차적인 기능과 요구사항의 리스트인 백로그(backlog)를 가진다. 
• 항목의 백로그는 위에서 아래로 우선순위에 따라 나열된다.
• 제품 책임자는 백로그에 대한 담당자로 그의 비전에 따라 우선순위를 정의하지만 팀의 모든 사람은 백로그에 새로운 항목을 추가하고 우선순위에 대해 논의하고 구현에 필요한 공수를 추정함으로써 백로그에 대한 기여가 가능하다.
• 팀은 그들의 다음 스프린트 계획을 시작한다. 스프린트 계획 미팅(sprint planning meeting) 동안에 팀은 스프린트의 범위(scope)를 결정할 것이다. 일반적으로 백로그로부터 가장 높은 우선순위 항목이 포함된다. 스프린트가 진행되는 동안에 일일 스크럼 미팅(daily scrum meeting)을 진행하여 내용 공유를 하기도 한다. 회의는 짧고 간결해야 한다.
• 스프린트의 마지막에 팀은 팀원들이 참석해 그들이 이해당사자를 위해 어떤 것을 만들었는지 보여주는 스프린트 리뷰 회의를 해야 한다. 회의 동안 새로운 백로그가 추가되기도 한다. 백로그는 새로운 스프린트가 시작하기 전에 우선순위를 다시 정하게 된다.
• 스프린트의 마지막에 수행되는 또 다른 회의는 스프린트 회고 미팅(sprint retrospective meeting)이라 불린다. 회고에서 팀은 잘한 것, 잘못한 것, 개선할 것에 대해 토론한다.
• 이 과정동안 스크럼 마스터는 모든 활동이 제대로 완료되었는지 확인하기 위해 심판처럼 행동할 것이다. 스크럼 마스터는 항목들에 대해 올바르게 범위가 지정되고 기술되도록 백로그의 작성과 스프린트 계획 미팅 동안에 제품 책임자와 팀을 가이드할 것이다. 스크럼 마스터는 회의가 초점을 맞춘 상태로 유지되고 생산적이면서 시간을 넘지 않게 해야 하며 팀원들이 서로 이해하지 못하는 말을 하지 않고 존중하게 해야 한다.

스크럼에서의 역할(Role) 종류

• 제품 책임자(Product owner): 전체적인 비전과 팀이 작업하는 제품의 방향을 담당하는 책임을 가진 제품관리자나 프로젝트 관리자이다. 백로그 리스트에 기능을 추가하고 이러한 기능들을 스프린트를 통해 출시하는 데 대한 계획을 담당한다. 기본적으로 제품 책임자는 팀이 스프린트마다 이해당사자에게 가장 많은 가치를 전달하는 것을 보장하는 사람이다.
• 스크럼 마스터(Scrum master): 팀이 효과적이고 효율적으로 스크럼을 사용하고 수행하는 것을 보장하는 역할. 팀원 모두가 스크럼을 이해하도록 가르치고 돕는다. 여기에는 팀과 상호작용하는 외부의 사람들은 물론, 제품 책임자, 전달 팀(delivery team) 도 포함한다. 코치 역할로서 스크럼 마스터는 전달 팀에게 수행하는 프로세스에 대한 설명과 더불어 제품 책임자가 백로그와 스프린트에 대한 계획을 이해하고 더 잘 관리하게 도와야 한다. 팀의 스크럼 프로세스를 개선하기 위해 진행 중에 있는 장애물을 제거한다. 방해물에는 잘 조직화되지 않은 백로그나 다른 팀/관리자로부터의 지원 부족과 같은 것들이 포함될 수 있다. 전반적으로 스크럼 마스터는 스크럼에 대한 옹호자로 교육, 실행 촉진, 그리고 스크럼을 적용하고 사용하는 장점에 대해 사람들을 이해시키는 책임을 진다.
• 전달 팀(Delivery team): 최종 제품을 실행하고 전달하는 것이다. 그러나 팀은 작업에 대한 추정치를 제공하고, 제품 책임자가 스프린트 계획과 전달을 더 잘하게 지원하는 책임도 있다. 이상적으로 팀은 개발자, 테스터, 그리고 비즈니스 분석가와 같은 프로젝트에서 필요한 교차 기능 팀원으로 구성되어야 한다. 각 스프린트는 자체로 작은 프로젝트로 볼 수 있기 때문에 워크플로우에 따라 작업이 수행되고 전달하는 기능에 따라 필요한 모든 자원을 항상 사용할 수 있게 하는 것이 중요하다. 마지막으로 팀은 각 스프린트의 마지막에 제품 책임자, 스크럼 마스터와 함께 그들의 성과를 검토하는 회고를 수행해야할 책임이 있다. 회고는 팀이 완료한 것이 무엇인지 검토하고, 다가오는 스프린트에서 팀이 어떻게 개선을 할 수 있는지를 알려준다.

용어 설명

• 스크럼(Scrum): 프로젝트를 완료하기 위해 개발 팀이 반복적으로 작업하는 애자일 방법론이다.
• 칸반(Kanban): 워크플로우와 진행 중인 작업을 시각화해 JIT(Just-In-Time, 즉시) 전달을 강조하는 애자일 방법론이다.
• 애자일보드: 포스트잇을 붙이는 화이트보드와 같다. (스크럼보드, 칸반보드) 
• 카드: 포스트잇이라고 볼 수 있다. (사용자 스토리를 기술, 구현되어야 하는 요구사항이나 기능을 나타낸다. 각 카드는 이슈이다.)
• 스프린트(Sprints): 반복적인 개발주기(회사에서 정하는 이터레이션이 개발 주기가 된다. 계획회의 부터 제품리뷰가 진행되는 날짜 기간이 1스프린트이다. 개발시에는 보통 약 2주정도) 
• 이슈와 이슈타입: 스토리, 에픽 같은 모든 작업 단위는 이슈이다.
  • 백로그(Backlog): 아직 스프린트에 포함되지 않는 모든 이슈를 포함한다. 백로그는 아직 완료에 대한 일정이 잡히지 않은 이슈들을 포함하고 있다. 보드를 새로 생성하면 기존 이슈들은 모두 백로그에 위치하게 될 것이다.
  • 에픽(Epic): 세분화된 요구사항, 나눠지지 않은 대규모 사용자 스토리. 대규모 개발 프로젝트에서의 모듈이나 주요 컴포넌트뿐 아니라, 여러 스토리들의 테마를 정의하는데 사용된다. 에픽은 중요한 애플리케이션 기능에 대한 큰 규모의 사용자 스토리이다. 에픽은 더 작고 관리 가능한 사용자 스토리로 분할된다. 지라 애자일에서 에픽은 유사한 사용자 스토리들을 함께 그룹화하기 위한 편리한 방법이다. 에픽은 스프린트나 백로그에서의 카드처럼 보이지 않는다. 에픽을 생성하고 난 후 에픽에 이슈를 추가할 수 있는데 이는 동일한 기능이나 관련된 기능 이슈들의 조직화를 돕는다.
  • 스토리(Story): 구현되어야 하는 단일 기능을 나타낸다. 최종 사용자 측의 요구사항을 기술. 기능의 바람직한 결과에 초점을 두고 비기술적인 언어로 작성된다.
  • 기술작업(Technical task): 서브태스크 이슈 타입. 스토리를 구현하기 위해 완료되어야 할 필요가 있는 실제 기술 작업을 나타낸다.
• 필터와 JQL: 여러 프로젝트에 대해 작업을 원할 때 포함되어야 하는 이슈를 정의하기 위해서는 필터를 사용해야 한다.
• 워크플로우: ToDo, InProgress, Done 의 칼럼과 에픽을 통해 이슈들을 조직화하여 swimlane 행으로 그룹화된 플로우. swimlane 은 할당자, 스토리, 에픽 같은 기준에 따라 이슈들을 그룹화한다. 기본적으로 swimlane 은 스토리에 의해 그룹회되며, 같은 스토리에 대한 서브 태스크는 한 swimlane 안에 위치하게 될 것이다.

지라 스크럼 보드의 이해

• 백로그(Backlog) 모드: 백로그 모드는 스프린트에 대한 계획을 하고, 백로그를 조직화하고, 이슈를 생성하는 모드이다.
• 활성 스프린트(Active sprints) 모드: 활성 스프린트 모드는 팀이 스프린트 동안 작업하는 모드이다.
• 보고(Reports) 모드: 보고 모드는 스프린트의 진행 상태를 추적할 수 있는 모드이다.

스크럼 보드가 처음 생성되면 모든 이슈(사용자 스토리 또는 짧게 스토리라 부른다)는 백로그 안에 위치하게 된다. 스프린트 계획 미팅 동안에 요구사항이 사용자 스토리로 변환되면서 더 많은 이슈가 생성되고 백로그에 추가될 수 있다. 이후 이슈에 에픽이나 버전을 할당할 수 있고, 스프린트에 추가해서 완료되는 일정을 예약할 수 있다.

---

각 스토리들은 팀이 추정치를 제공하기 쉽도록 Bill Wake 가 정의한 INVEST 특성을 사용하여 가능한 만큼 분할하는 것이 좋다.

• 독립적이다(Independent): 각 스토리들은 독립적으로 완료되는 것이 바람직하다. 항상 가능하지는 않지만 독립적인 작업은 구현을 더 쉽게 만든다.
• 협상 가능하다(Negotiable): 개발자와 제품 책임자들은 양쪽 모두 스토리의 세부 사항에 대해 완전히 알기 위해 함께 작업할 필요가 있다.
• 가치가 있다(Valuable): 스토리는 고객에게 가치를 제공해야 할 필요가 있다.
• 추정 가능하다(Estimable): 개발 팀이 추정치를 제공하기에 스토리가 너무 크거나 복잡하다면 스토리는 더 분할해야 할 필요가 있다.
• 작다(Small): 각 스토리는 작아야 할 필요가 있다. 때때로 단일 기능은 하나의 스프린트(약 2주)에 처리가 가능해야 한다.
• 테스트 가능하다(Testable): 스토리는 구현이 끝난 후 예상되는 최종 결과를 설명해야 할 필요가 있고 이것은 검증이 가능하다.

---

작업추정(Estimation):

과거 사람/시간(man hours) 로 추정하는 전통적인 방식과 다르다. 

스토리 포인트(story points)를 사용하여 스토리를 완료하는 데 얼마나 오래 걸리는지가 아니라 완료하는 데 요구되는 복잡도나 노력의 정도를 측정하기 위해 사용된다. 예를 들어 복잡한 스토리는 8 스토리 포인트를 가질 수 있다. 반면 간단한 스토리는 2 스토리 포인트만 가질 것이다. 8 스토리 포인트는 8시간을 의미하지 않는다. 다른 스토리와 비교해 복잡도를 측정하는 단순한 방법일 뿐이다. 

모든 이슈에 대한 스토리 포인트 추정이 끝나면 스프린트 동안에 팀이 얼마나 많은 스토리 포인트를 전달할 수 있는지 알아내야 할 필요가 있다. 첫 스프린트에서 이러한 사항을 알 수는 없다. 팀이 일주일 기간의 스프린트에서 10 스토리 포인트 가치의 작업을 전달하는 것이 가능하다고 하면 10 스토리 포인트가지 더해지는 임의 갯수의 이슈를 갖는 스프린트를 만들 수 있다. 이 10 스토리 포인트의 추정치가 너무 많거나 충분하지 않음을 발견하게 되면 이를 다시 조정하면서 작업에 대한 같은 크기의 스토리 포인트(팀의 속도)에 대한 추정치를 계속해서 개선할 수 있다. 

백로그의 각 스토리는 Estimate 라는 필드를 가지고 있다. 해당 필드에 스토리 포인트를 입력하면 된다. 일단 이슈가 개발 상태가 되면 추정치를 설정할 수 없다. 이슈가 개발 상태라는 것은 이슈가 속해 있는 스프린트가 활성화 상태라는 것을 의미한다.

 

 

 

Backlog

To Do

In Progress

In Review

Complete

Archived

Icebox