'SW기술/SW공학'에 해당되는 글 2건

스크럼은



스크럼은 프로젝트 관리를 위한 애자일 방법론으로서 추정및 조정 기반의 경험적 관리기법의 대표적인 형태이다. 1986년 타케우지 & 노나카 교수가 HBR에 기고한 "The New Product Development Game"이라는 기사가 시작이며, 1995년 켄 슈와버와 제프 서덜랜드가 이방법을 소프트웨어 개발에 소개하면서 스크럼이라고 부르게 되었다.




스크럼의 특징



투명성(Transparency)

프로젝트가 현재 어떤 상태인지 계획대로 진행되고 있는지 어떤 문제점을 가지고 있는지 정확히 파악하는 것은 어려운일이다. 스크럼은 스크럼회의, 소멸차트, 스프린트 리뷰와 같은 기법을 이용하여 다른 방법론에 비해 프로젝트의 상태나 문제점을 잘 드러내 준다.


타임박싱(Time boxing)

스크러을 구성하는 모든 실천법에 있어 시간은 매우 중요하다. 일일 스크럼은 매일 15분 짧은 시간에 진행되어야 하며, 스프린트 리뷰는 매 이터레이션 마다 주기적으로 진행한다. 스크럼 자체를 진행하는데 들어가는 시간을 엄격하게 제한함으로써 프로젝트 진행에만 집중할 수 있게 한다.


커뮤니케이션(Communication)

스크럼은 팀원 간 커뮤니케이션을 원활하게 하기위해 많은 노력을 기울인다. 일일 스크럼에서 각 개발자들이 어떤 방해물로 인한 문제를 겪고 있는지를 공유하고 각 사용자 스토리의 구현 난이도/시간을 토론하는 절차는 프로젝트 내 커뮤니케이션을 원활하게 해 준다.


경험주의 모델(Inspect & Adapt model)

스크럼은 고유의 프로세스 모델을 가지고 있지만 많은 기법들이 프로젝트에 참여하고 있는 개개인의 경험에 기반한다. 프로젝트마다 고유한 상황과 특징을 가지고 있기때문에 기존의 정형화된 프로세스로는 이런 최근의 프로젝트 상황을 따라가기 어렵다. 그래서 스크럼은 기본적인 구조만 같을 뿐 실제로 일을 진행하게 되면 팀마다 달라지는것을 허용한다.





스크럼 역할



스크럼에는 크게 3가지 역할자가 있다.


제품책임자(Product Owner)

제품기능목록에 해당하는 제품 백로그(product backlog)를 만들고 우선순위를 조정하거나 새로운 항목을 추가하는 일을 관리한다. 스프린트에 대한 계획을 수립할때 까지 중요한 역할을 하지만 스프린트가 시작되면 최대한 팀 운영에 관여하지 않는것을 권장한다.


스크럼 마스터(Scrum Master)

스크럼의 원칙과 가치를 지키면서 스크럼팀이 개발을 진행할 수 있도록 지원한다. 스크럼팀의 업무를 방해하는 요소를 제거하기위해 노력한다.


스크럼 팀(Scrum Team)

보통 5~9명으로 구성되며 하나의 스프린트 기간동안 구현해야 할 기능을 사용자 스토리로 도출하고 이를 구현한다. 스프린트 동안 구현해야 하는 기능을 완료하기 위해 노력하며 이를 위한 권한을 가진다.





스크럼 프로세스


 

스크럼의 프로세스를 구성하는 것은 스프린트,3가지유형의 미팅, 산출물이다.


1. 스프린트(Sprint): 달격기준 1~4주 단위의 반복개발기간을 가리킨다.

2. 3가지미팅: 일일스크럼, 스프린트계획, 스프린트리뷰

3. 3가지 산출물: 제품백로그, 스프린트백로그, 소멸차트




       



3가지 미팅



스프린트 계획(Sprint Planning)

각 스프린트에 대한 목표를 세우고 제품 백로그로 부터 스프린트에서 진행할 항목을 선택한다. 각 항목에 대한 담당자를 배정하고 태스크 단위로 계획을 수립한다.


일일스크럼(Daily Scrum)

매일 진행하는 15분간의 프로젝트 진행상황을 공유하는 회의이다. 모든 팀원이 참석하고 매일매일 각자가 한일, 할일, 문제점등을 이야기 한다.


스프린트 리뷰(Sprint Review)

스프린트 목표를 달성했는지 작업 진행과 결과물을 확인하는 회의이다. 스크럼 팀은 스프린트 동안 작업한 결과를 참석자들에게 데모하고 피드백을 받는다. 가능하면 해당 스프린트 동안 진행된 모든 작업에 대한 데모를 진행하며 고객이 참여하는것이 좋다.  스크럼마스터는 스프린트 동안 잘된점, 아쉬웠던점, 개선할 사항등을 찾기위한 회고를 진행할 수 도 있다.





스크럼 산출물



제품백로그(Product Backlog)

제품에 담고자 하는 기능의 우선순위를 정리한 목록으로 고객을 대표하여 제품책임자가 주로 우선순위를 결정한다.  제품 백로그에 정의된 기능을 사용자 스토리라고 부르며 사용자 업무량에 대한 추정은 주로 스토리 포인트라고 불리는 기준을 이용한다.


스프린트 백로그(Sprint Backlog)

하나의 스프린트 동안 개발할 목록으로 사용자 스토리와 이를 완료하기 위한 작업을 태스크로 정의한다. 각각의 태스크의 크기는 시간 단위로 추정한다.


소멸차트(Burndown chart)

개발을 완료하기까지 남은 작업량을 보여주는 그래프, 각 이터레이션 별로 남아있는 작업량을 스토리 포인트라는 것으로 나타낸다.




'SW기술 > SW공학' 카테고리의 다른 글

[SWr공학] 스크럼  (0) 2013.05.28
[SW공학] 애자일 방법론  (0) 2013.05.28
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

애자일 선언문



우리는 소프트웨어를 개발하면서, 그리고 또한 다른 사람들의 개발을 도와주면서 소프트웨어를 개발하는 더 나은 방법들을 찾아나가고 있다. 이 작업을 통해 다음과 같은 가치를 추구하게 되었다.


프로세스나 도구 보다는 개인과 상호 작용을,

포괄적인 문서보다는 작동하는 소프트웨어를,

계약에 대한 협상보다는 고객과의 협력을,

계획을 고수하기 보다는 변화에 대응을


더욱 가치있게 여긴다. 이말은 전자도 가치가 있긴 하지만, 우리는 후자 쪽에 더 많은 가치를 둔다는 것이다.



애자일 선언문의 바탕에 깔려있는 원칙들



1. 우리의 최고 우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달함으로써 고객을 만족시키는 것이다.


2. 비록 개발 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.


3. 작동하는 소프트웨어를 자주 전달하라. 약 2주에서 2개월 정도의 간격으로 전달하되, 간격이 짧을 수록 좋다.


4. 비즈니스 영역 사람들과 개발자들은 프로젝트 전체에 걸쳐 매일 함께 일해야 한다.


5. 동기가 갖추어져 있는 개인들로 프로젝트를 구성하라. 그들에게 그들이 필요로 하는 환경과 지원을 제공하고 일을 끝낼수 있도록 신뢰하라


6. 어떤 다른 개발팀을 상대로 혹은 개발팀내에서 서로간의 정보를 전달하는 가장 효율적인 방법은 얼굴을 보고 하는 대화이다.


7. 작동하는 소프트웨어가 진척 측정의 주된 척도이다.


8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자들은 일정한 속도를 유지할 수 있어야 한다.


9. 기술적 탁월함과 좋은 설계에 대한 지속적 관심이 기민함을 향상시킨다.


10. 간결함(하지않아도 되는 일의 양을 최대화하는 기술)은 필수적이다.


11. 최상의 아키텍처, 요구사항, 그리고 설계는 자기조직화되어 있는 팀에서 나온다.


12. 정기적으로, 팀 차원에서 어떻게 하면 더 효과적일 수 있을지에 대해 되돌아보며 자신들의 행동을 이에 따라 조율하도록 조정한다.



애자일 역사





출처: 소프트웨어공학센터  애자일초심자를 위한 '애자일 SW개발 101'



애자일 방법론의 종류




 방법론

 정의한 사람

  스크럼

  (Scrum)

  켄 슈와버/ 제프 서덜랜드

  적응형 소프트웨어 개발 방법론

  (Adaptive Software Development, ASD)

  짐 하이스미스

  기능 주도 개발방법론

  (Feature Driven Development, FDD)

  피터 코드/제프 드루카

  동적 시스템 개발 방법론

  (Dynamic Systems Development Method, DSDM)

  데인 포크너 외

  크리스탈 패밀리

  (Crystal Family)

  앨빈스테어 코번

  익스트림 프로그래밍

  (eXtream Programming, XP)

  켄트 벡/에릭 감마

  린 소프트웨어 개발방법론

  (Lean)

  메릭 포펜딕/톰 포펜딕

  애자일UP

  (Agile Unified Process, AUP)

  스콧앰블러



애자일 방법론의 특징



애자일 소프트웨어 개발은 반복점진적(iterative and incremental)개발을 기본 스타일로 가진다. 이런 스타일의 개발 방식을 효과적으로 진행하기 위해 자기조직화(Self-organizing)나 교차기능팀(cross-functional teams)등의 기법들을 활용하고 있다.



폭포수 방법론과 애자일 방법론간 주요 차이점



계획중심 vs 고객중심

폭포수 방법론은 프로젝트를 시작하기전에 프로젝트 기간 전체에 대한 일정 계획을 수립하며, 이 계획에 따라 프로젝트를 진행한다.

애자일 방법론은 계획을 수립하되 불확실한 프로젝트 기간전체를 감안하여 무리하거나 현실성 없는 계획을 수립하는 것이 아니라 현재 시점에 고객에게 중요하거나 확정된 내용을 중심적으로 수립한다. 프로젝트 상황에 따라 프로젝트 계획은 변동될 수 있다는 사실을 인정하고 진행한다. 그래서 계획보다는 고객이 중요하게 생각하는 기능을 먼저 개발하는 것을 원칙으로 한다.


빅뱅 릴리즈 vs 작은 릴리즈

폭포수 방법론은 프로젝트가 종료되는 시점에 한꺼번에 모든 기능을 릴리즈한다.

애자일 방법론은 이터레이션이라는 일정 기간 단위로 작은 규모 크기의 릴리즈를 반복한다. 이렇게 하면 고객은 요구사항이 제대로 반영되고 있는지 조기에 확인 할 수 있어서 프로젝트 종료시 요구사항에 맞지 않아 재개발하는 경우를 방지할 수 있다.


산출물중심 vs 동작하는 소프트웨어 중심

폭포수 방법론에서는 계획된 단계별로 지정된 산출물이 작성되었는지 여부를 확인함으로써 프로젝트가 제대로 진행되고 있는지 확인한다.

애자일 방법론은 소프트웨어가 제대로 동작하는지, 얼마나 요구사항에 맞게 개발되었는지가 중요하다. 하지만 애자일을 적용해서 개발을 진행한다는것은 문서를 만들지 않는것이 아니라 상황에 맞는 다양한 산출물을 만들 수 있다는 좀 더 유연한 의미로 받아들여야 한다.



애자일 방법론을 도입하려는 이유



많은 기업들이 다음과 같은 이유로 애자일 방법론을 도입하려고 한다. 

1. 팀의 생산성을 높이고 제품을 적기에 출시하기 위해

2. 개발에 들어가는 비용을 줄이기 위해

3. 소프트웨어 품질을 향상 시키기 위해

4. 팀의 사기와 업무 만족도 향상을 위해








'SW기술 > SW공학' 카테고리의 다른 글

[SWr공학] 스크럼  (0) 2013.05.28
[SW공학] 애자일 방법론  (0) 2013.05.28
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

티스토리 툴바