블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 
기존의 개발 프로세스에서는 요구 사항을 받아서 개발하는 형태였는데, 이 요구 사항이 완벽하지 않다는 것은 누가나 알고 있고, 이를 전재로 해서, 변경 가능한 요구 사항을 기반으로 개발하는 프로세스가 애자일 프로세스 이다.
관리 관점 뿐만 아니라, 요구 사항을 수집하는 관점도 변화가 필요한데

요구 사항은 고객이 정해주는 것이 아니라, 스스로 정하는 것이다.
고객에게 요구 사항을 받은 것이 완벽하다고 판단하지 말고, 요구 사항이 부족한 부분은 Develop하고, 완벽하게 만들어 나갈것. 즉 고객이나 다른 사람에게 요구 사항 정의에 대해 의존하지 말고, 커뮤니케이션, 가정, 레퍼런스를 통하여 스스로 요구 사항을 정리할 수 있도록 해야 한다.
완벽하지 않은 요구 사항에 대해서는
1. 고객에게 요구 사항을 커뮤케이션을 통해서 물어볼 것.
2. 고객의 요구 사항이 확실하지 않다면, 유사 레퍼런스를 통해서 요구 사항을 정의하여, 고객과 협의한다.
3. 또는 요구 사항을 가정하되, 가정의 원칙을 고객의 비지니스 밸류(가치)를 우선으로 한다.

요구 사항은 변경이될 수 도, 바뀔 수 도 있다. 그러나 원칙이 되는 것은 고객이 얻고자 하는 비지니스 밸류가 되어야 하며, 개발팀 역시 고객의 비지니스를 이해하고 이를 통해서 요구 사항을 함께 정의해야 한다. 최고의 요구 사항은 "고객의 비지니스 가치이다."

요구 사항의 정의 기법은 Scrum UserStory나 다른 기법에서도 여러 방법으로 표현하고 있지만, 요약해보면
적절한 요구 사항 정의는,
"누가? 왜? 이 행위를 원하는 것이며" - Who & Why
"이 행위의 결과로 얻을 수 있는 비지니스 가치는 무엇인가" - What
그리고, "이 비지니스 가치를 얻기 위해 하는 행위가 무엇인가가 명확하게 정의되어야 한다" - How

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
어제 교육을 받으면서 애자일 기반의 방법론에서 개발 기간을 Estimation하는 기법을 배웠는데, 흥미로운 내용이 있어서 포스팅한다.

스크럼과 같은 Iterative 기반의 개발방법론을 사용할때, 각 Iteration이 약 4~6주라고 가정하자
이 경우에는

Interation의 10%는 Planning에 소요되고
25%는 Stabilization (Integration과 Bug 수정)
나머지 65%가 개발에 소요된다.

이 65%기간 동안 매일 25% 정도는 다른 잡무 (회의,코드리뷰등)에 소요되고 남는 시간인 75%만 개발 관련 작업에 사용되는데, 그중에서도 10%는 코딩전의 디자인에 소요된다.
그림으로 도식화 해보면 다음과 같다.

 
  • Design 시간 = Coding 시간 * 0.1
  • 실제 소요시간 (Clock Time) = (Coding 시간 + Design 시간) / 0.75 (Productivity Factor - 하루에 실제 개발에 소요하는 비중을 수치화 한것)
  • Productivity Factor = 코드리뷰,회의,커뮤니케이션 시간 등을 고려한 가중치.
  • Coding 시간 = Coding + Unit Test + XMLDoc Comment(주석)
     
예전 데이타를 기준으로 대충 검산해봤는데, 어느정도 맞는것 같다. 결국 오차 범위는 Productivity Factor (하루에 코딩에 집중하는 시간/전체 시간 또는 (전체시간 - 회의,ADMIN,지원 업무등)/전체시간)을 잘 뽑아내느냐가 관건인거 같고, Planning Time이 4주 기반이라면, 4주 * 5일 = 약 20일의 10%면 2일로 어느정도 타당하다.
 
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

JIRA 아이폰 앱이 무료랍니다.

ALM/Task Management | 2010.05.04 11:43 | Posted by 조대협

http://itunes.apple.com/us/app/jira-mate/id293904930?mt=8
원래 유료앱으로 알고 있는데, 무료로 바뀌어 있네요.
JIRA 사용하시는분들 유용할것 같습니다.
참고하세요
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

JIRA용 UI 디자인툴.

ALM/Task Management | 2009.10.07 17:46 | Posted by 조대협
JIRA를 Task Management 도구로 사용할때, UI Requirement를 만들때는 PPT등을 사용해야 합니다. Balsamiq Mockup이라는 도구가 있는데, 이 도구를 이용하면 JIRA상에서 간단한 UI를 쉽게 디자인해서 Task에 붙일 수 있습니다.


호주에서 ARAIN씨가 소개해주셨습니다. ㄳ :)

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

JIRA 4가 Releae되었습니다.

ALM/Task Management | 2009.10.07 11:17 | Posted by 조대협

Atlassian의 JIRA4가 릴리즈되었습니다.
대쉬보드 SNS와 연동등 사용성이 한층 강화되었습니다. 역시 Atlassian은 실망 시키지 않는군요.
혹시 사용해보고 사용기 올리시는 분 있으시면 알려주세요.
저는 프로젝트 들어가야지나 사용해볼 수 있겠네요.
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
현재 진행하고 있는 프로젝트에서 Trac을 도입해서 사용하고 있습니다.
Trac 뿐만 아니라 사실상 거의 모든 이슈 트랙킹 시스템을 이용하여 팀 일정 관리를 할때 공통적으로 생기는 문제 같은데,
팀관리에서 가장 중요한것은 어떤 TASK를 누가, 언제 하느냐 입니다.
이슈 트랙킹 시스템은, 어떤과 누가를 잘 추적할 수 있게 해줄뿐만 아니라 Comment등을 통한 History 기능으로 어떻게 하느냐까지 잘 관리할 수 있습니다.

그런데 문제는 "언제" 즉 시간에 대한 부분입니다.
이슈 트랙킹 시스템들은 대부분 Time Frame,Mile stone, Due date 식으로 대략 Task 단위의 시간을 제공합니다만, 프로젝트 관리에 있어서 간트 챠트만한것이 없습니다. 문제는 이 이슈 트랙킹 시스템들이 간트 챠트를 제대로 제공하지 않는 경우가 허다하다는 것입니다.

매일 아침 Scrum 미팅을 할때, 간트 챠트를 이용하면 팀원이 무엇을 하고 있는지, 어제와 그제 무었을했고, 이번주에 무엇을 하고 있는지를 비주얼하게 보여줘서 리소스를 할당하는데 편리한데
이슈 트랙킹 시스템은 각 태스크로 관점이 맞춰져 있어서 사실상 팀관리를 하는데 어려움이 많습니다. (사실상 이부분은 엑셀이 더 편할것 같습니다.) 몬가 방법을 더 찾아봐야할것 같습니다.
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

언제 어떤 코드 리뷰 기법을 사용해야 하는가?

 그러면 이런 많은 코드 리뷰 기법 중에서 어떤 기법을 사용해야할까?

 코드 인스펙션

코드 인스펙션의 전제는 전문성을 가지고 있는 인스펙션 팀이 일정한 프로세스와 패턴에 따라서 개선안을 찾는 작업이다.

, 고도로 훈련됨 팀과 기간이 필요하고, 어느정도 개발이 완료되어 있는 인스펙션 대상(시스템)이 있는 것을 전제로 한다.

인스펙션의 시기는 시스템이 개발되어 있는 시점인 Release이 유용하다.

 필자는 두번의 Inspection을 권장하는데, 개발 초기에 비기능적인 구현을 끝낸 경우 1 Inspection을 그리고, 개발이 끝난 후 시스템 테스트 (성능,확장성,안정성등)가 그것이다.

 1 Release는 주로 비기능적이고 Risk가 높은 부분을 구현하는 단계인데, 이 구현체는 전체 시스템 아키텍쳐의 큰 틀이 되며, 추후 개발에도 이 아키텍쳐는 크게 변경되지 않는다. (1 Release 다음에 변경하려면 후반으로 갈수록 많은 리소스가 소요된다.)  그래서 1 Release후에 정밀 Inspection을 해서 아키텍쳐의 안정성을 검증할 필요가 있다.

 개발 후반의 시스템 테스트는 주로 비기능적인 요건 (성능,안정성등..)에 대한 성능 테스트가 이루어지는 단계이기 때문에, 테스트 시나리오가 미리 잡혀져 있고 테스터와 테스트 시나리오가 명확하게 정의되어 있기 때문에, 인스펙션을 수행하기 용이하며 최종 점검이라는 관점에서 매우 유용하다.

 인스펙션을 수행하는 주체는 전문 SI Task Force를 운영하여 프로젝트를 돌아다니면서 인스펙션을 수행할 수 있고, 여러 개의 솔루션을 인하우스 개발하는 업체 (네이X)와 같은 업체는 QA 조직내에 자체적으로 인스펙션팀을 운영하는 것을 권장한다. 그외의 일반 업체 ()나 기업의 경우 인스펙션팀을 운영하기 보다는 인스펙션 프로세스를 전체 개발 프로세스와 프로젝트 비용 산정에 포함하고 SI나 벤더 컨설팅을 활용하는 것을 권장한다.

 인스펙션의 결정 주체는 주로 PMO(Project Management Office) AA (Application Architect) 되는 것이 바람직하다, 대체로 개발 주체 조직 외부에서 인력을 데리고 오고, 여러팀이 함께 인스펙션에 참여해야 하며 일정에 대한 조정과 인스펙션 결과에 대한 반영이 필요하기 때문에 프로젝트 관리 조직 측면에서 접근하는 것이 바람직하다.

 팀리뷰

팀 리뷰는 각 개발 유닛에서 활용하기 좋은 기법이다. PL (Project Leader)의 역량아래 수행할 수 있으며, 팀원이 리뷰어가 되기 때문에 팀 단위에서 활용하기가 매우 좋다.

일주일에 한번정도, 한시간 정도 리뷰를 정기적으로 수행하도록 하며, 시니어 개발자나 PL이 리뷰 대상 모듈을 선정하고 개발자에게 리뷰를 준비하도록 한다.

리뷰는 발표자가 리드를 하도록 하고, 리뷰에서 나온 의견을 Action Item으로 잡아서 PL이 발표자의 스케쥴로 조정을 해주는 작업이 필수적으로 따라야 한다.

팀 리뷰에서 권장하고 싶은 사항은 위에서도 잠깐 언급했지만 위키와 같은 문서 공유 시스템을 이용하여 반드시 리뷰의 결과를 남기도록 하고, 리뷰의 결과는 Task Management Task로 연결이 되어야 한다.

리뷰되고 반영된 내용은 그냥 넘어가지 않도록 하고, 재 테스트를 통해서 반영 내용을 반드시 검증하도록 한다.

 웍쓰루 (WalkThrough)

일종의 아이디어 회의 정도로 보면 되며, 비정기적으로 언제나 개최할 수 있다.

팀리뷰처럼 PL이나 시니어 개발자가 중재를 하지 않기 때문에 구성원들의 의욕이 낮을 경우 효과가 매우 낮다. 개발팀보다는 QA나 운영팀에서 장애 사례나 버그 수정 사례 등의 정보 교환 목적으로 사용하는 것이 좋다.

 Peer Review

신입 개발자 교육이나, 해당 제품이나 기술에 전문적인 지식이 없는 경우에 Knowledge Transfer(지식공유)와 품질 유지를 위해서 유용하다.. 대신 리뷰어의 Task 부담이 가중되기 때문에 (예상하는 것 보다 많이. 심하게는 50%에 육박할 경우도 있음) 리뷰어에 대한 스케쥴 배려가 필요하다.

 요약

 

시기

효과

변경에 대한 비용

수행 비용

주체

인스펙션

1 Release,
시스템 테스트

매우높음

매우 높음

높음

PMO,QA,AA

팀리뷰 ★

매주

높음

보통

보통

PL

웍쓰루

비정기적

낮음

보통

낮음

원하는 개발자

Peer Review

필요한 경우

경우에 따라 높음

낮음

보통

시니어 개발자

 본인의 경험상 팀리뷰가 가장 효과가 높다. Peer Review는 팀원간의 실력 편차가 클 때 탄력적으로 운영하였고, Enterprise System과 같이 난이도가 높은 시스템의 경우 인스펙션의 효과가 비교적 크다. 비록 비용이 소요되지만 잘못된 아키텍쳐로 인해서 전체 품질이 떨어져서 비즈니스에서 손해를 보거나 쓸떼 없이 하드웨어 증설을 통한 비용을 생각하면 훨씬 낮은 금액이 아닌가 싶다.

효과적인 코드 리뷰를 막는 요인들

코드 리뷰에서 가장 힘든 점은 한마디로 내가 만든 코드를 남이 잘못되었다고 이야기 한다.” 입니다.

리뷰의 주요 목적은 결함의 발견과 개선 방안입니다. 흔히 농담 삼아서 창던지기라고 이야기 하는데, 발표자는 리뷰어로부터 많은 질문과 공격을 당하게 됩니다. 그래서 실제로 인스펙션을 해보게 되면 개발자는 인터뷰를 당하는 것에 대해 취조 당하는 느낌을 가지게 될 수 도 있고 방어적으로 행동할 수 도 있게 됩니다.

 팀리뷰의 경우 감정싸움까지 가는 경우가 허다하지요.

 팀리뷰나 인스펙션의 경우 리뷰를 중재하는 사람이 있기 때문에, 리뷰어가 아이디어나 결함에 대한 의견을 자유롭게 개진할 수 있도록 해야 하며, 반대로 발표자가 인신 공격을 받지 않도록 중재하는 기능도 필요합니다. 이건 어떤 프로세스나 시스템으로 될 수 있는 일이 아니라 사람 사이의 관계에서 발생되는 일이기 때문에 문화의 변화가 필수적입니다.

 또한 위에 언급한 대부분의 리뷰 기법들은 리뷰와 그에 대한 후속 처리가 시간과 사람이 필요한 일이기 때문에 프로젝트 운영 관점에서 시간과 리소스에 대한 배려가 이루어져야 합니다.

 경험상으로 팀리뷰가 팀에 자리잡기 위해서는 좋은 리더가 있다하더라도 최소한 1달정도의 (통상 2) 기간이 필요합니다. 급하게 할일은 아니라는 겁니다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

들어가기에 앞서서.

소프트웨어의 품질을 보장하기 위한 활동은 테스팅, 일일 빌드, 프레임웍의 사용, 개발 패턴들 수 없이 많은 방법들이 있다. 그중에서 개인적으로 생각하건데, 코드리뷰 만큼 적은 투자로 큰 효과를 얻을 수 있는 기법은 없는 것 같다. 이 문서에서는 코드리뷰에 대한 몇가지 기법에 대한 정리와 함께 적용 방법에 대해서 간단하게 소개해보고자 한다

코드 리뷰의 시초는 Fagan에 의해서 소개된 코드 인스펙션에서 기인한다. 소프트웨어의 개발이 끝난후에, 전문 인스펙션팀이 정해진 프로세스와 패턴에 따라서 코드를 검증하고 Defect를 찾는 프로스를 코드 인스펙션이라고 한다

코드 리뷰란, “코드를 실행하지 않고 사람이 검토하는 과정을 통하여 코드상에 숨어있는 잠재적인 결함(Defect)를 찾아내고 이를 개선하는 일련의 과정을 정의한다. 테스팅의 범주에서는 정적인 분석에 속한다. Formal한 코드리뷰 기법일 수 록, Defect의 발견에 집중하고, 소프트웨어 개발 주기의 후반에 위치하지만, Lightweight한 코드 리뷰 기법은 Defect의 발견뿐만이 아니라, 같은 로직을 여러 관점에서 생각하는 아이디어 회의나, 주니어 개발자에게로의 지식 전달등의 부가적인 목적들도 함께 가지고 있다

코드 리뷰 스펙트럼

코드 리뷰의 기법을 나누는 방법은 크게, 얼마나 정석적이고 프로세스적(정형성)이냐에 따라서 Formal/Lightweight 방법으로 나눌 수 있고, Offline에서 직접 커뮤니케이션을 하느냐? 또는 메신져,Email 이나 기타 자동화된 코드리뷰 도구를 사용하느냐에 따라 온라인 리뷰와 오프라인 리뷰로 나눌 수 있다.

 먼저 정형성에 따라서 대표적인 리뷰 방법을 나열해보면 다음과 같다

) 코드리뷰 기법중에는 Pair Programming이 종종 언급되고는 하지만, 본인의 사견상 엔터프라이즈 애플리케이션 개발에서 Pair Programming을 실제로 적용한다는 것은 매우 어렵다고 판단하기 때문에, 코드 리뷰 스펙트럼에서는 제외한다. 


코드 인스펙션

코드리뷰 기법중에서 가장 정형화된 패턴의 기법이다.전문화된 코드리뷰팀이 시스템이 어느정도 구현된 단계에서 일정한 패턴을 가지고 코드를 분석한다.인스펙션팀은 크게 4가지 역할을 가지고 구성이 된다.

1.     Moderator

는 인스펙션팀의 실제적인 메니져로 생각하면 된다. 인스펙션팀과 그 대상이 되는 코드를 작성한 개발팀간의 인터페이스를 담당하고 필요한 리소스와 인프라를 확보하는 작업을 한다.

또한 인스펙션에 대한 프로세스 정의와 산출물의 정리를 담당한다.

예를 들면, 인스펙션팀이 계정 업무를 인스펙션을 하다가 업무에 대한 지식이나 코드가 왜 이렇게 짜여져 있는지에 대한 자료가 필요하다면 Moderator가 요청하여 담당 개발자를 섭외하거나 소프트웨어 설계 문서등을 받아다가 인스펙션팀에 전달한다.

또는 인스펙션된 결과에 대해서 테스트가 필요할 때, 테스팅 환경을 확보하고 인원 (DBA나 벤더 엔지니어)을 섭외하는 것도 Moderator의 역할이다. 필요하다면 고객이나 개발자와 함께 인스펙션 미팅을 주선하고 주최하는 역할도 갖는다.

가장 중요한 역할중의 하나는 인스펙션이 언제 끝날 것인지 (Exit Criteria)를 정의하는 역할을 갖는다.

2.     Reader

Reader는 각종 산출물들을 읽고, 인터뷰등을 통해서 전체 시스템을 이해하여 인스펙션팀이 어떤 흐름으로 인스펙션을 진행할지에 대한 방향을 지시하며, 시스템에 대해서 팀내에서 가장 많은 도메인 지식을 갖는 사람이다.

Reader는 시스템의 큰 흐름과 구조를 잘 이해하고 있어야 하고, 상황에 따라서 문제가 발생할 수 있는 지점을 미리 예측해낼 수 있어야 한다. 실제 인스펙션은 이 Reader의 방향성에 따라서 인스펙션을 진행하게 된다.

3.     Designer/Coder

Designer Coder Reader가 지시한 방향에 따라서 코드를 검증하고 잠재적인 Defect의 발견 및 권장 수정 방안을 만들어 낸다.

4.     Tester

Tester는 인스펙션이 진행중인 모듈에 대해서 테스트를 수행하고 Defect를 찾아내는 역할을 수행하며, 이외에 Designer Coder가 권장한 수정 코드안에 대한 검증과, 실제 업무 개발자가 수정해온 코드에 대한 검증 작업을 수행한다

4가지 역할을 가지고 인스펙션은 다음 6단계로 진행된다.

 

1.     Planning

전체 코드 인스펙션에 대한 계획을 수립한다. 기간, 대상, 종료 조건 (금액 기준, 목표 TPS를 성취하는지, 시간에 따른 종료 조건, 등등). 그리고 인스펙션 팀이 이때 SET UP이 된다.

2.     Overview

이 단계에서는 인스펙션 팀에 시스템과 구성 제품등에 대한 교육이 이루어지고, 팀원간의 역할이 정의된다.

3.     Preparation

Inspection을 하기 위한 사전 준비 단계로 각자의 역할별로 필요한 문서를 습득해서 이해하고 필요하다면 인터뷰도 진행한다. 또 이 단계에서는 필요에 따라서 Tool (테스팅 툴이나, profiler, Application Performance Monitoring 도구..)과 환경(독립된 테스트가 요구되는 경우 테스트 환경을 구축한다.)

4.     Meeting (Inspection)

각자의 역할에 따라서 Inspection을 수행한다. Inspection을 통해서 결함을 발견하고, 모든 결함은 기록된다. 기록된 결함은 실업무 개발자에게 전달되어 FIX되도록 하고, 필요에 따라서는 권장 수정안을 전달하기도 한다.

5.     Rework

보고된 Defect를 수정한다.

6.     Follow-up

보고된 모든 Defect가 수정되었는지 확인한다.

 팀리뷰

팀리뷰는 코드 인스펙션보다 좀 덜 정형화 되었지만 그래도 일정한 계획과 프로세스를 따른다.

코드 인스펙션 프로세스의 단계 (Planning ,Overview ,Preparation등의 사전 준비 단계는 생략된다.) 역할은 중복되거나 생략될 수 있는데, 발표자(Author) Moderator는 필수적으로 구성된다.

리뷰시간에는 발표자(코드를 만든 사람)가 코드에 대한 설명을 하고, 팀원은 결함이나 개선안을 찾는다.

Moderator는 리뷰의 주제를 선정하여 리뷰를 진행하고, 리뷰에서 나온 의견을 정리해서 Action Item으로 기록한다. Action Item들은 프로젝트 관리자가 실제 프로젝트 Task로 관리해야 한다. (일정에 반영되어야 한다.)

 Moderator는 프로젝트 관리자 (PM이나 PL)이 될 수도 있으나, 팀내에서 기술적인 실력이 가장 좋은 Senior 개발자가 그 역할을 맏는 것을 권장한다

 일주일에 한번정도 팀리뷰를 수행하는 것이 좋으며, 특정 모듈이나 기능이 완료되는 시점 (Short Release) 시점에 수행을 하거나, 테스트 결과를 가지고 리뷰를 하는것도 좋은 방법이 된다

 필자의 경우 프로젝트를 수행할 때, 일주일에 한번 정도 팀리뷰를 진행하였으며, Short Release에 의해 완성된 부분이나 Risk가 비교적 큰 부분이라고 판단하는 부분에 대해서 팀리뷰를 진행하도록 개발자에게 지시 하였다.

 리뷰 과정에서 나온 의견은 팀 Wiki 페이지에 코드 리뷰 결과라는 분류를 따로 만들어서 관리하였고, 각 의견은 TASK로 생성되어 스케쥴에 포함되었다.


<그림. 팀리뷰 리포트>

웍쓰루 (Walkthrough)

웍쓰루는 단체로 하는 코드 리뷰 기법중에서 가장 비정형적인 방법중에 하나이다. 발표자가 리뷰의 주제와 시간을 정해서 발표를 하고 동료들로부터 의견이나 아이디어를 듣는 시간을 갖는다.

주로 사례에 대한 정보 공유나, 아이디어 수집을 위해서 사용될 수 있다.

개발을 위한 프로세스에서 보다는 “Bug 사례에 대한 회의와 같은 정보 공유성격에 유리하다.

유일하게 발표자만이 리뷰를 주관하고 발표하는 역할을 가지며, 다른 참여인원들은 아무런 책임이나 역할을 가지지 않고 자유롭게 의견을 개진한다.

웍쓰루는 정기적으로 (주일에 한번) 진행할 수 도 있으며, 또는 정보공유나 아이디어 수집이 필요할 경우 비정기적으로도 진행할 수 있다. (정기적으로 진행하는 것이 참여율이나 집중도가 더 높다.) 

Peer Review or Over the shoulder review

피어리뷰나 Over the shoulder Review2~3 (주로 2)이 진행하는 코드 리뷰의 형태이다.

코드의 작성자가 모니터를 보면서 코드를 설명하고 다른 한사람이 설명을 들으면서 아이디어를 제안하거나 Defect를 발견하는 방법이다.

 사전 준비등이 거의 필요없고, 필요할때 마다 자주 사용할 수 있는 리뷰 방법이다.

주로 Senior 개발자(사수) Junior 개발자를 멘토링할 때 사용할 수 있으며, Junior 개발자에 대한 교육과 함께, Junior 개발자가 양산한 코드에 대한 품질을 관리할 수 있다.

 그러나 이 기법은 Senior 개발자의 리뷰 역량에 따라서 결과물의 품질이 달라질 수 있고, Senior 개발자의 시간 투여량이 많은 만큼. Senior 개발자의 참여도가 떨어질 수 있다. (형식적으로 될 수 있다. )그래서 프로젝트 관리 관점에서 Peer Review 에 대해서도 프로젝트 스케쥴상의 Task로 잡아주고, 하나의 독립된 업무로서 시간과 노력을 투자할 수 있도록 해야 한다

실제로 예전 프로젝트에서 신입 사원에게 비교적 난이도가 높은 모듈의 개발을 시켜야할 상황이 있었고, 그때 이 Peer Review를 진행하도록 하였다. 결과적으로 만족할만한 품질을 얻었지만, Senior 개발자에게 Review에 대해서 Task를 지정하고 스케쥴링을 하였음에도 불구하고, Senior 개발자에게는 결코 적지 않은 워크로드가 되었던 경험이 있기 때문에, 팀원간의 실력 편차와 난이도에 따른 시간 배분과 함께, 경험적 (3~4일 해보면 실제 작업량에 대한 예측이 좀 더 정교해진다. )인 작업량 측정이 필요하다

Passaround

코드리뷰 스펙트럼에는 포함시키지 않았지만 사용되는 경우가 있어서 소개한다.

Passaround는 번역하자면 돌려보기이다. 온라인 보다는 오프라인 위주로 진행되는 리뷰인데, 작성자가 리뷰를 할 부분을 메일이나 시스템을 통해서 등록하면, 참석자들이 메일을 통해서 각자의 의견을 개진하는 방식이다. 특정 장소에 모여서 같은 시간에 진행해야 하는 기존의 리뷰 방식과는 달리 시간과 장소에 구애를 받지 않는 방식으로, 리모트에서 작업하는 팀의 경우 유리한 리뷰 방식이지만 반대로 Ownership이 애매하여 원하는 결과가 나오지 않는 경우가 많다. 또한 실시간이 아닌 비동기적인 커뮤니케이션으로 인해서 커뮤니케이션 속도가 매우 느리다는 단점도 가지고 있다.

 이를 방지하기 위해서는 참석자들의 업무 역할에 코드 리뷰라는 역할이 명시적으로 지정되어야 한다

필자가 일했던 글로벌 회사의 경우에는 버그 수정이나 제품의 기능 개선의 경우 개발팀에서 버그 수정과 개선만을 맏는 개발자가 개발팀에 속해 있었기 때문에 원할한 Passaround 리뷰가 가능했고, 이슈(버그) 트랙킹 시스템 (AtlassianJIRA와 같은)과 소스 코드 Viewing system (AtlassianFisheye)이 많은 도움이 되었다

지금까지 간단하게나마 코드 리뷰의 기법에 대해서 살펴보았다. Formal한 리뷰 (코드 인스펙션..)등에 대한 설명이 많은 것은, Formal한 리뷰가 좋아서라기 보다는 정형화 되어 있기 때문에 그만큼 프로세스에 대한 설명이 많이 필요하기 때문이다

회사의 성격 (SI,게임,임베디드,인하우스개발, 오픈소스 등)이나 팀의 구조나 성숙도에 따라서 리뷰의 기법은 변형되어 적용되어야 한다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Code Review Article Bookmark

2009.03.10 23:48

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

요즘 모회사의 차세대 시스템의 오픈을 막바지에 두고, 성능 향상 컨설팅에 나와 있습니다.
주로 하는 작업이 Code Inspection을 통하여 구조 개선 및 성능 개선을 하는 작업입니다.

그런데, 코드를 보면서 이해가 안되는 아키텍쳐가 종종 있습니다. 이런 의도가 아닐텐데 라던지.. 아키텍쳐 구성이 잘못되었다던지. 그런데 이미 구현이 끝나가는 단계에서 이런 아키텍쳐를 변경하기는 거의 불가능합니다. 알면서도 당하는 케이스라고나 할까요? 이미 여러 코드들이 동일 패턴으로 구현이 되어 있기 때문에, 공통부라면 어떻게 변경을 시도해보겠지만, 아키텍쳐적인 문제나, 통신 전문 같은 경우는 변경이 불가능합니다.
결국 울며 겨자 먹기로 CPU를 늘리거나, 다른 부분의 코드를 튜닝해서 목표 성능치를 내야 겠지요.

그런데, 만약에 Short Release를 통해서 매번 회귀 테스트를 진행했더라면 어땠을까 하는 생각이 문득 집에 도착한후에 들더군요. 그러한 문제는 아주 조기에 발견이 되었을 것이고, 초반에 아키텍쳐 수정이 가해졌을 것이며, 이렇게 비용을 들여서 Code Inspection을 하거나 추가 비용을 들여서 하드웨어를 증설할 일도 없겠지요...

그리고 여러개의 시스템이 연결된 시스템이기 때문에, 이제서야 통합 작업을 수행합니다. 마찬가지로 Interative and ieration 전략을 사용했더라면 초반부터 통합을 해왔기 때문에 통합때문에 드는 작업이 거의 없었겠지요.

특히 통합이 일정대로 원할하지 못한 경우, 이번에 튜닝을 위해서 거의 5명의 벤더 엔지니어를 불러다 놓고 하루종일 거래 개통도 되지 않아 엔지니어들이 대기하다가 돌아갔습니다. 보통 벤더 엔지니어의 하루 몸값은 Charging을 하는 경우에는 100~120만원선이 됩니다. 5명이니 대략 아무것도 안하고 600만원을 날린셈이 되는 것입니다.

회귀 테스트나 Iteration 방법론, Short Release 를 실제 프로젝트에서는 시간이 없다. 예산이 없다는 이유로 잘 사용하지 않습니다. 기능 구현에 쫓겨서 일단 구현만 해놓고 보자는 건데, 그 안에 있는 Defect 에 대한 검증이 이루어지지 않은 폭탄 코드를 양산해 내는 거지요.

결국은 위의 사례와 같이 오픈 연기, 하드웨어 추가 구매, 튜닝 컨설팅등의 추가 비용이 발생하고, 끊임없는 야근과 누더기 코드로 이어집니다.

반대로 지난번 프로젝트를 진행했던 S사의 경우 제가 진행했던 파트는 2주 주기의 Short Release를 사용했고, Short Release 마다 어떤 형태로든 비기능 테스트를 통해서 끊임없이 아키텍쳐를 검증했기 때문에, 지금 프로젝트에서는 통합에 대한 이슈나 아키텍쳐를 통째로 흔드는 일이 없습니다.

항상 자연계 열역학 제 1의 법칙을 이야기 하지만, "에너지 불변의 법칙"은 사람이 일할때도 통하나 봅니다. 개발과정에 생략한 테스트와 검증은 프로젝트 말에 그만한 부담으로 다시 돌아옵니다. 아니 에너지 불변의 법칙이 아니라, Defect 증폭의 법칙이라고 해야할까요?
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

ALM / Polarion Review

ALM/Task Management | 2009.02.20 19:05 | Posted by 조대협
ALM에 대해서 정리하다가 오늘은 Polarion (http://www.polarion.com) 을 직접 인스톨해서 Evaluate해보았습니다.
Polarion이 개념상으로도 만족 스럽고 무엇보다 AJAX기반의 깔끔한 UI가 마음에 들어서 비싼 가격에도 불구하고 미련이 남아서 다시 테스트를 해보았습니다.

Polarion ALM은 Enterprise Version으로 많은 기능을 제공하고 자체적으로 CMMI Level까지 충족시키는 프로세스를 포함한다고 해서 복잡도가 높고 속도가 느린 것으로 알려져있습니다. 그리고 가격도 만만하지 않구요.
오늘 테스트 한 버전은 Polarion Track + Wiki 라는 버전으로 일종의 Light 버전으로 생각하면 됩니다.

테스트해보고 딱 드는 생각은 Trac의 Commercial Version이다. 입니다.

1. 가격
25 User를 기준으로 1250$ 입니다. 가격은 만만합니다.

2. 구성
Issue Tracking + Wiki + Subversion + 간단한 CI 입니다.

3. 장점
일단 UI가 미려하고, 쉬운 인스톨에 인스톨만 끝나면 Trac과 마찬가지로 All in on package이기 때문에, 처음에 진입하기가 수월합니다.
그리고 하나의 UI내에서 모든 인터페이스를 제공하기 때문에, Seamless integration이 이미 구현되어 있습니다.
Eclipse Plugin 을 제공하고 또한 Java platform만 아니라 make나 다른 빌드 스크립트를 제공하기 때문에, 플랫폼에 종속성이 낮습니다.
또한 JIRA와 마찬가지로 Workflow에 대한 정의가 가능합니다. 이건 꼭 필요하고 강력한 기능입니다.
멀티 프로젝트를 지원하는 것도 장점중의 하나라고 할 수 있겠습니다.
무엇보다 Task간의 Hierachy 정의가 가능하고 이를 리스트에서 트리형태로 보여주는 것은 아주 장점중의 하나입니다.

4. 단점
Issue Tracking의 경우, Iteration이나 Release Plan에 대한 개념이 없어서, Short release (개발 프로세스를 작은 단위로 쪼개서 프로젝트를 진행하는 개념, Scrum의 Sprint를 생각하면 됩니다.) 이게 약간 걸리기는 하지만 Time point라는 개념으로 충분히 커버라 가능합니다..
또한 Wiki의 경우는 어느정도 기능을 가지고는 있지만, Confluence Wiki에 비하면 많이 떨어지는 것은 사실입니다. Confluence Wiki의 경우 Export나 MS-WORD 기능이 강력하기 때문에, 문서를 밖으로 Export하여 산출물로 활용할 수 도 있는데,  Polarion도 Wiki에 PDF Export기능이 있기는 하지만, Confluence 대비해서 얼마나 경쟁이될지는 미지수 입니다.
CI 부분을 살펴보면, 역시 Hudson에 익숙해져 있는 저로써는 눈에 거슬리는 부분이 많습니다. Hudson의 강력한 플러그인으로 여러 리포트를 만들어낼 수 있는데 반해서, Triggering으로 Build를 돌려주고 결과를 로깅하는 정도입니다.
 그러나 빌드 #와 Task를 연결 시켜주는 기능은 마음에 드는 군요.

5. 총평
말 그대로 Trac의 Commercial Version이라고 보시면 될것 같습니다.
쉬운 인스톨과 통합된 환경, 미려한 UI, 낮은 가격으로 ALM의 성숙도를 아주 높게 끌고 가지 않을 것이라면 손쉽게 선택할 수 있는 대중적인 솔루션이 아닌가 싶습니다. 조금 더 유연한 환경을 원하는 사람들을 위해서라면 글쎄요.. 그 부분에 대해서는 의문이 듭니다만, 충분히 추천해볼만 한 솔루션이라고 봅니다.



저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Adapting JIRA For Scrum
Scrum을 JIRA로 구현하는 방법인데, 간단하지만 실용적인 가이드 입니다. 확장 여지는 있지만 기본 방향은 권장할만 합니다. 참고하세요.
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
TAG ALM, JIRA, Scrum
PDF 버전입니다.
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Overview

프로젝트에서 중요한 포인트중의 하나는 팀의 운영과 관리이다. 프로젝트에 Unified Process나 Waterfall model과 같은 기존의 방법론을 사용하더라도, 그 방법론에는 자세한 task 관리 프로세스에 대해서는 거의 정의가 되어 있지 않다. 

반대로 요즘 유행하는 Agile 방법론의 경우, task 관리에 대한 전략과 수행 방법을 기술하고 있지만, 실제 프로젝트를 관리하는 관점에서는 전체 스케쥴에 대한 예측과 관리가 어렵기 때문에(불확실성의 문제), SI 프로젝트등에서는 쉽게 적용할 수 없는 문제를 가지고 있다.

또한 실제 프로젝트에서는 이미 고객이나 주관사의 방법론을 표준으로 사용하고 있기 때문에 Agile 방법론을 적용하는 것이 쉽지 않다. 

이 문서의 목적은 위 두 가지 접근 방법의 문제점을 상호 보완하여, 전체 프로세스는 기존의 전통 방법론을 따르고, 전체 프로세스의 각 단계를 Agile 방법론으로 보완하여, 실질적인 task 관리 방법론을 구축하고자 하는데 목적이 있다. 

Agile 방법론은 요즘 들어 가장 인기 있고 가벼운 방법론 중에 하나이다. 이 방법론의 특징은 구성원간의 협업 (Collaboration)을 중요시 하는 사상을 가지고 있다. 본 문서에는 이 사상을 기반으로 하여, 일일 Task 관리를 하는 기법을 중심으로 설명하고자 한다. 

Agile 방법론에는 XP,AUP,Scrum,Lean 등 여러가지 구체적인 방법론 들이 있는데, 아래 도표를 보면 알 수 있듯이, 근래에 들어서는 Scrum이 가장 인기있고 많이 사용되는 방법론이다.


 출처 http://crankypm.com/2008/10/poll-results-software-development-methodologies-agile-vs-waterfall/

 Scrum

 Summary

그럼 먼저 Scrum 방법론에 대해서 살펴보도록 하자.


Scrum은 기본적으로 Iterative and incremental 개발 방법에 기초를 한다.

Scrum은 몇 개의 Iteration으로 구성되는데, 이 Iteration을 Sprint라고 부르며 각 Sprint는 1~4주 정도의 기간을 갖는다. 이 Sprint는 일종의 Timebox의 개념을 가지며 한번 정해진 Sprint의 기간은 변경될 수 없다는 것을 전제로 한다. 

다음으로 Scrum에는 고객의 요건으로부터 작성된 Product Backlog라는 것을 가지고 있다. 쉽게 이야기 하면 “대략적인 할일 목록”이다. 구현 단계에 Scrum을 적용할 경우에는 SRS (Software Requirement Specification)이나 TRS (Technical Requirement Specification)들의 목록이 Product Backlog의 항목으로 적절하다.

Product Backlog의 항목을 팀 미팅을 통해서 이번 Sprint에 구현할 항목을 선택한다. 항목의 선택은 Product Backlog 항목의 우선순위(Priority)를 통해서 선택이 되고, 이 선택된 항목들을 구체적으로 구현하기 위해서 TASK로 쪼게 진다. 이 task 목록은 이번 Sprint에서 구체적으로 해야 할 일을 정의하고 되고 이 목록 리스트를 Spring Backlog 라고 부른다.

 Sprint Backlog의 task 들은 스케쥴이 지정되어 팀의 담당자에게 Assign된다. 팀은 이 Sprint Backlog를 가지고 정해진 기간동안의 Sprint를 구현한다. 

Sprint중에 매일 아침 팀원들은 10~20분 정도의 Daily Scrum Meeting 이라는 회의 시간을 갖는데, 이 시간 동안, 팀원들은 어제 한일과 오늘 한일에 대해서 간략하게 보고하고, 기술적인 질의 사항에 대한 문의나 (팀원들의 도움을 받을 수 있는), RISK 사항등을 고융한다. 이 Daily Scrum Meeting을 통해서 팀은 현재 Sprint의 진행 상황을 공유할 수 있다.

 Sprint가 끝난 후에 팀은 프로젝트의 stakeholder (고객)과 간단한 Review 미팅을 갖는데, 주로 이번 Sprint 에서 구현한 내용을 간단한 형태의 DEMO로 소개를 하고 Feed back을 받아서 Product Backlog를 업데이트 하고 다음 Sprint를 준비한다.

 Review가 끝난 후에는 팀원끼리 Sprint에 대한 회고 (Restrospective)의 시간을 갖는데,

 이 시간에는 Sprint에서 Scrum 방법론을 적용했을 때의 잘되었던 점과 잘못되었던 점을 토론하여 Scrum 운영 프로세스에 반영하여 팀의 Scrum 운영 방식을 성숙화 시킨다.

Role in Scrum

Scrum에서는 이 프로세스를 적용하기 위해서 몇 가지 역할을 정의하고 있다.

Product Owner

Product Owner는 요구 사항을 정의하고, Product Backlog를 업데이트 하는 역할을 맏고 있다. 가장 중요한 역할은 Product Backlog내의 Item 에 대한 우선 순위를 정하고, 정해진 구현 기간 내에 프로젝트 팀의 ROI (Return Of Investment)를 극대화 하는 책임을 가지고 있다. Product Owner는 직접 Sprint에는 참여하지 않고, Sprint 전에 Backlog의 업데이트후, Spring review에 구현 내용이 요구 사항에 맞춰서 적절하게 구현되었는지 확인하는 작업에만 참여한다. 

Team

Team은 Product Backlog의 내용에 따라 Sprint에서 구현하는 역할을 맏는다. 

Scrum Master

Scrum Master는 Project Manager도 아니고, 3자의 입장에서 Team과 Product Owner가 Scrum 방법론을 제대로 수행할 수 있도록 돕는 역할을 수행한다. 예를 들어 Product Owner가 Sprint중에 요건을 추가하려고 할 때 이를 제지하거나, Team이 Scrum을 수행하는 데 어려움이 있을 때 이를 돕는 역할을 한다. 종종 Scrum Master의 역할과 Product Owner의 역할을 한 사람이 겸임하는 경우가 있는데, Scrum Master의 역할중의 하나가 Product Owner가 Sprint중에 영향을 줄 수 있는 요건 변경을 막아야 하는 역할이기 때문에, 겸임할 수 없다. 

지금까지 Scrum 방법론에 대해서 간략하게 설명하였다. 그러나 이 Scrum 방법론은 태생이 제품 개발을 위한 프로세스로 개발되었다. (Product Owner와 같은 용어에서 알 수 있듯이..) 그래서 Requirement나 기능의 추가/삭제가 비교적 자유로운 In house 개발이나 패키지 솔루션 개발에서는 사용될 수 있을지 몰라도, 구현해야 하는 Requirement의 범위가 고정적인 Enterprise 프로젝트에는 적용하기가 어렵다. 그래서 다음은 경험을 바탕으로 하여 Customize 한 Enterprise 프로젝트에서의 Scrum 프로세스에 대해서 설명하고자 한다.

 ALM / Task Management Process

Process Design Principals (프로세스 디자인 방향)

ALM / Task Management Process 의 기본 디자인 방향은 기존의 전통적인 개발 방법론을 대체하는 것이 아니라, 기존의 방법론은 전체 개발 프로세스를 커버하고, ALM / Task Management Process 는 Scrum 방법론에 기반 하여 각 단계에 대한 TASK 관리를 위해서 사용된다.


전체 프로젝트 관리로는 사용되지 않고, 각 수행 그룹에서 사용된다. (예를 들어 전체 프로젝트가, 고객 지원 업무, 빌링, 포탈 등으로 구성되어 있을 때 전체 프로젝트 관리는 전통적인 개발 프로세스에 기반하여 프로젝트가 관리되고, 빌링팀, 포탈팀 등 각 개발 단위팀에서는 ALM / Task Management Process 방법론을 이용하여 팀을 관리한다.)

Team Structure for ALM / Task Management Process

ALM/Task Management을 실제 팀에서 수행하기 위해서 팀 구조와 역할 정립이 필요하다.

l        Project Manager : 전체 프로젝트를 관리 하는 역할을 한다. 큰 프로젝트의 경우 PMO나 여러 개발 단위의 PM을 정의하며 주로 전통적인 개발 프로세스를 기준으로 프로젝트를 관리한다. 단 ALM / Task Management Process의 개념을 이해하고, ALM / Task Management Process와 기존의 개발 프로세스를 연계 시키는 역할을 맏는다.

l        Project Leader : 작은 조직이나 프로젝트에서는 PL이 없이 PM이 PL역할을 함께 하는 경우가 많으며, 실제 개발팀을 가지고 Implementation을 리드하는 사람이다. 실제로 ALM / Task Management process를 이용하여 팀의 Task를 관리한다.

l        ALM Process Coach : 특이한 Role일지도 모르겠는데, Scrum의 Scrum Master와 같은 역할로 생각하면 된다. Process가 팀에 완전히 정착되기 까지는 팀에 대한 교육과 프로세스에 대한 지속적인 Mentoring이 필요하다. ALM Process Coach는 팀의 프로세스를 set up하고, 팀이 프로세스를 준수하도록 도우며, 개선하는 역할을 진행한다.


실제로 모 금융 프로젝트에서 ALM / Task Management Process를 적용해본 적이 있는데, PM이 두개의 팀을 운영하고 있었다. 그중에 A팀에 본인이 투여되었고, ALM / Task Management Process와 System을 구축하여 A팀에서 적용하여 효과를 보자 PM이 다른팀(B팀)에도 본 프로세스를 적용해 주기를 요청하였다. 그래서 System을 공유해줬으나, B팀에는 별도의 코칭을 제공하지 않았다. 프로세스를 제대로 준수하는지, 상태 업데이트는 제대로 하는지에 대한 코칭이 없었는데, 1개월후 A팀은 Task Management Process에 어느정도 적응을 하여, 효율적으로 만족 스럽게 사용하고 있었으나, B팀의 경우 이 프로세스와 시스템 사용이 또 다른 Burden이 되서 실업무 따로, 시스템 운영 따로 되는 결과를 만들어 냈다. 그만큼 ALM / Task Management Process를 적용하기 위해서는 성숙단계까지 지속적인 관찰과 코칭이 필요하다.

 Step 1. Prepare Product Backlog

Product Back log는 실제로 구현되어야 하는 기능 목록을 나열한다.

목록은 고개의 요구 사항으로부터 도출 되는데, 일반적으로 SRS (Software Requirement Specification)이나 TRS (Technical Requirement Specification)로부터 도출이된다. 구체화 되고 정확하고 상세한 목록을 도출 해야 한다. 비즈니스 요건 같은 경우를 목록으로 도출하였을 경우에는 종료 조건이 모호해질 수 있고 그런 경우 종료에 대한 기준이 모호해 질 수 있다.

Product Back Log의 항목은 다음과 같다.

1) NO

ITEM에 대한 ID

2) Item

실제 구현 요건

3) Description

요건에 대한 간략한 설명

4) Estimated Resource

얼마나 많은 Resource가 소요되는 가에 대한 예측치를 기록한다. 이 값에 따라 추후 PLANNING에 반영한다. 이 값은 초기 예측 값으로 매번 Sprint가 종료될 때 마다 새롭게 업데이트 한다. 업데이트 기준은 기존에 수행한 Sprint의 Item의 실제 수행 시간을 기준으로 앞으로 수행할 Item의 상대적인 개발 난이도등을 측정하는 방법으로 예측할 수 있다.

5) WIKI URL

Back Log의 Item의 이름과 Description만 가지고는 정확한 요건을 알 수 없다. 그래서, 해당 Item에 대해서 정확한 요건 (Requirement description 또는 Use case)을 알기 위해서는 별도의 문서를 참조해야 한다. 문서는 MS-WORD와 같은 형태로 공유 파일 폴더에 들어가 있거나 Subversion과 같은 SCM에 저장이 되어 있거나 Wiki에 작성되어 있을 수 있다. 여기에는 Item과 요구 사항에 대한 추적성을 유지하기 위해서 해당 문서에 대한 위치 (파일 위치나, WIKI URL)을 기술한다.

6) Priority

Item에 대한 우선 순위를 지정한다. 이 우선 순위에 따라서 Sprint를 스케쥴링 하기 때문에 Product Back Log에서 매우 중요한 부분이다.

Priority의 설정은 비즈니스에 대한 영향이 큰 기능, 필수 기능, 그리고 난이도가 높은 기능, 비기능적 요건 등에 대해서 우선 순위를 높게 설정하는 것을 권장한다. 특히 비기능적 요건은 성능이나 안정성등에 관련되는 경우가 많고 이러한 요건들은 아키텍쳐에 많은 영향을 주고 아키텍쳐는 후반으로 갈수록 변경이 어렵기 때문에 초반에 구현 및 검증 작업을 수행해야 한다.

7) Status

Status는 해당 Item의 진행 상황을 의미한다. 이미 아직 진행전이지, 진행중인지 완료가 되었는지를 표현한다. 필드의 값은 프로젝트 상황이나 프로세스에 맞춰서 변화한다. (QA 검증중, 운영 서버에 반영됨 등)

8) Estimated Value of item (Optional)

이 항목은 Item의 비즈니스적인 가치에 대해서 점수를 메기는 방법으로 SI개발보다는 제품 개발이나 In House 개발등에 유용한 항목이다. 이 값의 조정을 통해서 Product Owner는 정해진 기간내에 최대의 ROI (Return Of Investment)를 낼 수 있도록 Back Log의 우선 순위를 지정할 수 있다. 

Step 2. Release Planning

해야할 일의 목록 (Product Back Log)가 정의 되었으면, 언제 어떤 일을 해야할 지를 정의해야 한다. 일반적으로 말하는 스케쥴링인데. Release Planning에서는 프로젝트의 큰 Mile stone을 정하는 작업을 한다. Release 시기 마다 작동 가능한 Product을 Release한다. (모든 기능이 완료되지 않았다 필 수 기능이 완성 되었으면 Release한다. ) Release된 시점에서 QA팀에게 Release version을 넘겨서 Testing을 수행하고 구현된 부분에 대한 품질을 보장 받는다. 이러한 활동은 모든 개발이 끝난 시점에서 Big bang 방식으로 통합하고 테스트 하는 기존에 방식에 비해서 위험을 조기에 발견할 수 있고, 그 위험을 해결하는 비용을 줄일 수 있다. (복잡한 문제일 수 록 나중에 발견되면, 더 고치기가 어렵다.)

그리고 이 Release version을 고객에게 DEMO를 통해서 요구사항과 부합하는 지 확인하고, 잘못된 부분에 대해서 수정할 수 있는 기회를 갖을 수 있다.

이 단계에서 해야하는 구체적인 작업은 다음과 같다.

1)       주요 릴리즈 일정 지정
2)       릴리즈 일정별 Product backlog 내의 Item 지정

이 단계에서 완성된 Release Plan은 Project 관리 입장 (Project Management Officer)에서 전체 스케쥴 WBS (Work breakdown structure)와 맵핑이 되서 관리팀 관점에서 스케쥴 관리를 용이하게할 수 있다.

Step 3. Sprint Planning

Release Planning이 끝난 후에는 각 Release를 달성하기 위해서 Release Planning을 Sprint로 나눈다.

전통적인 Scrum 방법론에서는 다음과 같은 절차로 Sprint를 계획한다.
l        팀원의 가용 시간
l        Product Back Log Item을 구체적인 Task로 분할
l        Task 에 대해서 수행 시간을 예측
그러나 이 전통적인 접근 방법은 몇가지 문제를 가지고 있다. 먼저 Task 에 대한 수행 시간 예측후에 가용 인력에 Assign하는 방식인데, 이는 각 팀원의 능력이 동일함을 전제로 하고 있다. 그래서 실제 프로젝트에서는 다음가 같은 방법을 권장한다.
l        Product Back Log Item을 Task 로 분할 
l        Task를 팀장이 적절한 사람에게 배분
l        배분된 사람이 Task의 수행 시간을 예측 하도록 함 

이 작업을 좀더 상세하게 설명해보면

 Sprint는 보통 1주~4주 정도로 정의된다. Sprint의 기간을 정의할 때 기준중의 하나는 고객의 요구 사항 변경이나 작업에 대한 변경도가 얼마나 많은가? 예측된 작업 일정이 충분한가? 와 같이 불확실성이 높을 수 록 Sprint 주기는 짧게 잡는 것이 좋고, 불확실성이 적고 스케쥴이 안정적으로 정의될 수 있는 경우에는 길게 잡는 것이 좋다.

 필자의 경우에는 보통 2주 정도를 Sprint주기로 관리를 한다.

Sprint를 정의할 때 먼저 Sprint 기간과, 가용 Resource를 바탕으로, Release Plan에 의해 정의된 Product Back log Item들의 예측 기간(Estimated Resource : Man/Day)를 기준으로 Sprint에 Product Back log Item 들을 할당한다. 

해당 Sprint의 기간과 수행할 Back Log Item을 정의하는 일은 PM/PL이 수행하는 것을 권장한다.

Scrum 방식이 유연 해도, 스케쥴 자체는 프로젝트 진행에 있어서 가장 중요한 RISK FACTOR중의 하나이며, 팀원간의 협의를 해서 진행한다 하더라도 고객 입장에서는 꼭 끝 맟춰야 하는 부분이기 때문에, 우선순위 지정과 스케쥴 조정은 그에 대한 책임을 지고 있는 프로젝트 관리자가 하는 것이 RISK 관리 측면에서 합리적이다.

 선별된 Product Back Log Item은 실제로 수행되기 위해서 구체적인 TASK로 나뉘어진다.

TASK는 어떤 사람이 무슨 일은 한다는 구체적인 정의로, 명확한 종결 조건을 가지고 있어야 한다. 예를 들어 “Logging 기능의 설계” 는 언뜻 보면 적절한 TASK로 생각될 수 있지만 설계에 대한 종료 조건이 명확하지 않다. 즉 “Logging 기능 설계 문서를 WIKI에 업데이트” 또는 “Logging 설계 REVIEW 회의”와 같이 산출물이나 회의와 같이 어느정도 정해진 종결 조건을 정의하게 되면 TASK를 관리하기가 용이하다. ( “Logging 기능의 설계” Task만 있다면 문제지 위에 예를 든 종료 조건이 다른 Task로 정의되어 있으면 괜찮다)

 실제 TASK관리를 해보면, “구현 TASK”가 끝났다고는 하는 경우 개발자 본인의 역량에 따라서 Coding만 되고 실제로 기능이 작동하지 않거나, 의도하지 않은 설계대로 구현되어 있는 경우가 생각보다 많기 때문에, 이런 경우 프로젝트를 관리하는 입장에서 “구현 보강” 이라는 새로운 TASK를 만들고 새롭게 RESOURCE와 시간을 할당해야 하는 부담을 가지게 되기 때문에, TASK에 대한 종료 조건을 명확히 하는 것은 매우 중요하다. 

1:1:1 법칙

 Task를 정의하는데 가이드를 제시하면, Product Back Log Item은 분석/설계, 구현, 테스트 이 3가지로 크게 분리될 수 있다. 어떤 구현 테스트를 하기 위해서 요건에 대한 분석 및 설계가 필요하다. 비록 미리 다 설계가 되어 있는 부분이라도, 실제 구현에 있어서는 국지적인 설계 변경이 필요하거나, Prototyping (설계 검증을 위한) 들이 필요하기 때문에 분석/설계에 대한 시간은 소요된다.

다음으로 테스트는 구현된 내용을 바탕으로 검증을 해야 하는데, 특히 비기능적인 요건은 시스템 테스트를 하지 않더라도 최소한 자기 PC에서 성능 테스트 (이를 Micro benchmark test라 한다.)를 하고 단위 테스트를 수행해야 하고, 구현이 아닐 경우라도 설계나 요건 분석등의 문서상 산출물은 REVIEW 시간을 필요로 하기 때문에, 일반적으로 분석/설계, 구현,테스트에 대한 시간 및 Resource 할당 비율은 1:1:1이 된다.

Task 수행의 위의 3단계가 종료될 때 마다 주요 Task에 대해서는  어떤 형식으로든지, 리뷰 회의를 갖는 것을 권장한다. (Peer Review, Team Walkthrough etc)

 20% 버퍼의 법칙

이렇게 Task list를 도출하고 나면 각 Task에 수행 시간과  담당자를 지정해야 한다.

Task list 도출과 이 과정은 팀원들과 함께 수행되어야 하는데, 팀원들의 능력과 근무 가능 시간이 각각 다르기 때문에 팀원의 의사가 매우 중요하다. 팀원과 미팅을 통해서 해당 Task를 수행 가능한 사람에게 Assign 하고, Assign을 받은 사람과 수행 시간을 논의하여 결정한다. 되도록이면 Assign 받은 사람의 수행 시간에 대한 결정과 의견을 존중하는 것을 권장한다. 실제 Task에 대한 시간을 Estimation해보면, 경험상으로 충분한 시간으로 Task 수행시간을 Assign 하게 하고 Buffer율을 20%를 두도록 해도, 실제 수행해보면 그보다 20~50%의 시간이 모자라는 경우가 태반이고, 이는 초반 프로젝트 스케쥴 관리에 Risk factor가 된다. 보통 1~2개월간의 Sprint 기간에는 이런 스케쥴 예측에 대한 오차 범위가 크게 나타나는데 이를 반영해서 일정을 잡고, 2개월 후에는 팀의 스케쥴 측정에 대한 경험이 쌓여서 점점 더 정확하고 세밀한 스케쥴 관리가 가능하게 된다. 

 이렇게 만든 Sprint의 Task 목록, 예측 시간, 담당자의 목록을 Sprint Back Log 라고 하고 다음과 같은 형태로 작성이 가능하다. 


위와 같이 엑셀을 사용해서 Sprint 스케쥴을 관리할 경우에는 Task의 스케쥴을 우측에 날짜 박스를 만들어놓고, 수행 기간을 칠해 놓는 방식으로 그래프 형태로 스케쥴을 관리할 수 있다. 

Release Planning과 Sprint Planning을 정리해보도록 하자.

기본 원리는 큰 스케쥴을 작은 단위의 스케쥴로 나누어서 관리하는 방법으로, 기존의 전통적인 방법론이 가지고 있는 스케쥴 단계를 Release Plan으로 나누어서 관리한다.

Release Plan은 PMO에서 관리될 수 있는 단위의 프로젝트 주요 Mile stone이 되며, 각 Release Plan은 실제 개발팀이 수행할 하루 단위의 개인 스케쥴로 정의되는 Sprint Plan으로 나뉘어서 관리 된다.


Step 4. Sprint Tracking

Sprint 계획이 끝났으면, 계획에 따라서 프로젝트를 수행한다.Sprint의 Task 진행 상황을 추적하기 위해서 몇 가지 기법을 지원하는데 다음과 같다.

Daily Scrum

Daily Scrum은 일일 오전 업무 공유(보고가 아닌) 회의이다., Scrum에서 가장 유용하고 중요한 기법 중의 하나이다.

Scrum 팀은 매일 오전에 같은 자리에 모여서 어제 자신이 한일과 오늘 자신이 해야할 일을 짧게 발표한다. 전체 회의 시간은 30분을 넘지 않도록 한다. 이와 함께 자신이 진행하고 있는 Task를 Close하는데 필요한 시간을 같이 이야기 한다.

이 과정에서 팀원은 다른 팀원의 Task 진행 상황을 Share할 수 있고, 만약 일의 진행에서 문제가 있는 부분이나 도움을 받고 싶은 부분은 이 회의 과정에서 이슈로 제기하여 다른 사람의 도움을 받거나 PM이 일정을 조정할 수 있도록 한다.

PM 관점에서는 Daily Scrum을 통해서 지정된 Task의 진행 상황을 매일 추적할 수 있다.

PM은 회의에서 공유된 일정을 바탕으로 Sprint Back Log 를 업데이트 하는데, 중요한 점은 각 Task의 종료시까지 남은 시간을 반드시 기록한다. 이 데이터는 처음 계획 대비 현재 상황이 어떻게 되고 있는지를 판단할 수 있게 해주는 중요한 지표가 된다.. 

이상적인 프로젝트 진행이라면 위의 Sprint Planning (칠해진 부분)이 끝나는 다음날 남은 작업 시간이 0 이 되어야 한다. 만약 연장 작업이 계속 되더라도 칠해진 블록의 범위는 변경하지 않고,  남은 날짜만 계속 업데이트 해간다. 그러면 추후에 결과가 계획 대비해서 얼마나 초과되어서 끝났는지를 확인할 수 있다. 

진행중에 고객 요건 변경이나 구현의 난이도에 의해서 스케쥴을 바꿔야 할 경우가 있는데, 전통적인 Scrum 방법론에서는 Sprint가 한번 계획된후에 Sprint 중간에는 바꾸지 못하도록 가이드 하고 있다. 변경이 생겼을 경우 Sprint를 중지하고 다시 Sprint 계획을 하도록 하는데, 국내 SI프로젝트와 같은 상황에서는 이를 매우 통제하기가 어렵기 때문에, 개인적으로는 융통성 있게 Task 를 추가하거나 일정을 변경하는 것을 반영하는 것을 권장한다. 단. Sprint 전체 스케쥴에 최소한의 impact를 줄 수 있는 범위내에서 변경을 하되, 새롭게 발생한 Task가 있을 때 그만큼 다른 Task에 대한 일정을 미루는 것을 전재로 해야 한다.

Burn down chart

Sprint Product Back Log를 위와 같은 방법으로 Update하면, 매일 남은 작업 일 수를 계산할 수 있는데, 이를 그래프로 표현한 것을 Burn down chart라고 한다.


이상적인 Burn down chart는

(remaining time)=(total work)/(current date)

의 형태를 띄어야 한다. 그리고 실제 프로젝트의 remaining time역시 이 이상적인 곡선에 근접해야 하는데, Burn down chart를 매일 업데이트 함으로써, 이상인 그래프에서 실제 프로젝트의 remaining time 그래프가 얼마나 벗어 나는가를 측정함으로써 프로젝트의 일정상 위기 요소를 파악하고 대비할 수 있다.

Burn down chart는 프로젝트 룸의 칠판이나 또는 시스템의 Dash board나, Daily Scrum 을 통해서 공유되는 것이 좋은데, 프로젝트 팀원 역시 사람이고, 사람은 Visual 한 개념을 통해서 현재 상태를 파악하고 프로젝트의 위험도를 좀더 체감할 수 있기 때문에, Risk 요소에 대해서 심각도를 서로 공유하는데 잘 사용될 수 있고 이는 실제 팀의 사기에 영향을 줄 수 있다. 

Task Status

다음으로 각 Task에 대해서 상태를 관리해야 한다. 위의 예시에서 보여준 Sprint Product Back Log의 Status 부분을 말하는데, 이 부분은 사실 매일 Daily Scrum 미팅을 하고 엑셀로 프로젝트를 관리하는 경우에는 크게 중요하지 않지만, 좀더 전문화되고 정교한 Task 관리 절차를 만들거나 시스템으로 구축하고자 할때는 제일 필수적인 부분이다.

시스템으로 구축할 경우에는 해당 TASK를 Daily Scrum 때 뿐만 아니라, 항상 상태를 업데이트 해서 팀원이나 운영 조직간에 자주 의사 소통을 할 수 있고, 저장된 상태나 값을 기반으로 여러가지 지표를 뽑아 낼 수 있다.

Task Status는 Task의 상태 흐름에 따라 정의 되는데 이를 Task Workflow라고 한다. Task Workflow는 최대한 단순해야 하며, 관리 지향적이기 보다는 실무 중심적이어야 한다.

 또한 Workflow가 적용되는 업무의 특성별로 잘 정의되어야 한다. (개발의 Task workflow와 Bug의 Task workflow는 분명히 달라야 한다.) 

다음은 Task workflow의 예이다.


l       
Open (생성됨) 새롭게 생성되고 정의된 TASK로, 담당자가 지정되지 않은 TASK이다.
l        Assigned (할당됨) TASK가 담당자와 협의를 거쳐 지정되게 되고, 수행 시간이 ASSIGN되고 스케쥴링 된 상태이다. 이때 반드시 담당자가 TASK의 내용을 이해하고 자신에게 ASSIGN되었다는 것을 인지해야 한다.
l        Need more information (추가 정보 필요) 만약에 할당 받은 Task의 내용이 명확하지 않거나 추가 정보가 필요할 경우 Need more information으로 상태를 바꾸고 PM/PL에게 Task의 재정의를 요청하는 상태이다.
l        In Progress 지정된 (진행중) TASK를 개발자가 작업을 시작했을 때 “진행중” 인 상태를 나타낸다.
l        Postponed (연기됨) 진행중인 작업이 어떤 이유(Product Bug, 환경 준비 미비)로 인해서 더 이상 진행할 수 없을 때, PM과 상의하여 해당 Task를 “지연” 상태로 변경한다.
l        Resolved (해결됨) 개발자가 할당된 TASK를 완료하고 종료조건을 충족하였을 때, “해결됨” 상태로 바꾸고 PM에게 작업이 완료되었음을 알린다.
l        Closed (종료됨) PM은 개발자가 완료한 작업을 TASK의 지시사항대로 제대로 종료되었는지 확인하고, 종료조건을 충족하여 제대로 완료되었을 경우에는 “종료” 상태로 바꾸거나, 만약 제대로 종료가 되지 않았으면 상태를 Assigned로 바꿔서 다시 개발자에게 할당한다.

Step 5. Ending Sprint

정해진 기간 동안 Sprint가 종료되면, Sprint를 정리 한다.Sprint의 종료 조건은 팀에 따라 정할 수 있는데 크게 아래 조건들을 많이 사용한다.
l        정해진 시간
l        Task 종료
l        예산 종료시 까지

어떤 조건을 사용하던지, 가장 중요한 것은 명시적인 종료 조건을 정의 해야 한다는 것이다.
좋은 종료 조건의 예
1)       구현의 경우  : 단위 테스트 100% 성공, Code Coverage Rate 60% 달성
2)       설계 단계 : 메시지 채널 설계 문서 고객 확인 받음
3)       설계 단계 : Prototype 작성 및 A,B,C,D 기능 동작 확인
4)       기간 BASE 경우 : 3/19일까지 코드 분석된 내용 리뷰 (이 경우, 컨설팅이나 Code Inspection, 탐색적 테스팅 같이 특정 기간과 예산을 가지고 진행하는 경우에는 기간 단위의 종료 조건을 사용하는 경우도 있다. )

Review Sprint

Sprint가 종료된 후에는 Sprint에서 구현된 산출물을 Review하는 단계가 필요하다. 요건에 따라 적절하게 구현이 되었는지 품질은 만족해야 했는지 등의 검증이 필요하다.

단순히 Sprint에서 무엇 무엇을 했고, 잘됐다 안됐다가 아니라, 실제 구현 코드, 산출 문서, 테스트 결과등의 구체적인 자산을 가지고 Review를 수행해야 한다.

이 과정에서는 고객을 참여 시켜서, 자산에 대해서 간략한 데모를 고객에게 수행한다. 이 데모는 고객 보고를 위해서 별도의 PPT나 데모 준비를 하는 것이 아닌 Informal한 리뷰이다. Formal한 리뷰는 Release 시기별로 진행하도록 하고, Sprint Review 준비를 위해서 별도의 시간이나 Resource를 낭비하지 않도록 한다. 

Test

특히 Sprint가 Implementation인 경우, Implementation이 제대로 완료되었는지 아닌지를 확인할 수 있는 방법은 Testing 밖에 없다.

Sprint Planning에서 Implementation의 경우 Test Task를 반드시 포함시켜야 하고, Review과정에서는 이 Test 결과를 Review하도록 한다. Test는 기능적 테스트 뿐만이 아니라 , 안정성이나 성능과 같은 비기능적 요건에 대한 Test도 반드시 포함되어야 한다.

 Sprint별 테스트를 통해서 잠재적인 문제를 빨리 찾아낼 수 있고 필요에 따라서 디자인이나 아키텍쳐에 대한 변경을 가할 수 있다. 

 Scrum을 사용하는 실제 구현 팀에 대해서 테스팅 구현은 다음과 같은 구현을 권장한다.
l        단위 테스트 (Unit Test) : 개발자가 개발 컴포넌트 단위로 테스트 수행
l        회귀 테스트 (Regression Test) : 테스트 했던 내용을 다음 테스트에도 포함 시켜 새로운 코드 추가나 변경이 기존 기능에 영향을 주지 않는 지 매번 검증
l        테스트 자동화 (Test Automation) : 테스트를 자동화 하여 회귀 테스트를 지원하고, 테스팅의 효율성을 극대화 함
l        점진적 통합 (Contiguous Integration) : 일일 빌드등을 통해서 BIG BANG방식의 코드 통합이 아닌 점진적 통합 전략을 사용함 

[!] 위의 내용은 본 문서에서 다루고자 하는 범위가 아니기 때문에 좀더 자세한 부분은 ALM/Test Automation 과 ALM/Build Automation 을 참고하기 바란다.

Code Review

Code Review는 완성된 산출물을 같이 Review하여 Defect를 찾아내고, 좀더 좋은 개선 방안에서 의견을 수렴하는 자리다. 일반 Review와 달리, 특정 산출물을 가지고 진행한다는 것이 다른데, 주로 Design이나 Implemented code와 같은 구현에 밀접한 산출물을 가지고 진행한다.

Code Review는 원래 Code Inspection이라는 개념에서부터 시작했다. Code Inspection 전문적인 지식을 가지고 있는 팀이 정형화된 프로세스에 따라서 Code를 Review하고 Defect를 발견하는 과정을 정의 한다. Code Inspection은 Assembly 로 코딩하던 시절에 시작되었고, 요즘과 같이 많은 코드와 변경 사항이 있는 시스템에서는 적용하기가 적절하지 않다. 그래서 좀더 비형식적인 Code Review 형태가 개발되었는데, Team Review, Walkthrough, Peer Review등이 그것에 속한다. 

[!] Code Inspection은 특정 룰을 바탕으로 하기 때문에 자동화된 툴을 통해서도 어느 정도 효과를 볼 수 있다. Code Inspection을 위한 팀과 프로세스를 구성하는 것보다 Test 과정에 Inspection 도구를 사용하면 최소한의 비용으로 효과를 볼 수 있으며, Open source 기반의 Inspection 도구로는 PMD, FindBugs를 권장한다.

 어떤 형태로건, 비형식적인 Code Review는 준비 시간이 짧고, 그에 비해서 Defect나 시스템 개선에 대한 효과가 상대적으로 크기 때문에, Sprint 말에는 Code Review를 수행하는 것을 권장하며, Sprint 중간에라도, 구현 Task 가 끝났을때는 비정기적으로라도 Code Review를 수행하는 것을 권장한다. 

[!] 위의 내용은 본 문서에서 다루고자 하는 범위가 아니기 때문에 좀더 자세한 부분은 ALM/Collaboration 을 참고하기 바란다.

 Code Review를 진행함에 있어서 중요한 점은 Code Review도 Resource와 시간이 투여되는 작업인 만큼 하나의 Task로 정의되어 관리 되어야 한다.

Code Review시에는 Code Review 결과를 Wiki등에 Meeting Minutes (회의록) 형태로 기록 해야 하며, Review 과정에서 나온 내용들은 Action Item으로 정리되어 Sprint Back Log내에 Task로 생성되고 관리되어야 한다.

Step 6. Update product backlog

Review가 끝났으면 Review 과정에서 나온 추가 요건이나 변경 상황을 반영하여 Product Back Log를 업데이트 한다. 팀이 모여서 우선 순위를 재 조정하고, 요구 사항을 좀더 구체화 하며, 예상 소요 시간을 업데이트 한다.

사람들은 프로젝트를 수행하면서 배우게 되고, 실력적으로 진화하게 된다. 그래서 요구 사항이나 예측치는 그때 상황에 따라 계속 업데이트 되어야 한다. Product Back Log 는 고정된 것이 아니라 항상 변경되고 실상황을 반영해야 한다.

Step 7. Retrospective

 Sprint가 종료되고 모든 작업이 끝나면, 팀에서 운영중인 방법론 자체에 대한 Review가 필요하다. 팀에서 운영중인 Task Management Process는 처음에 셋업 되면 많은 시행 착오를 겪게 된다. 수행 시간 예측이나, Sprint 주기 설정, Task 관리 프로세스 등등 많은 과제들이 있는데 Sprint의 경험을 기반으로 회고를 수행함으로써, 프로세스를 발전시킬 수 있는 방향을 찾을 수 있다.

가장 간단한 수행 방법은 PM이 이메일이나 종이를 이용하여 이번 Sprint에 “무엇이 잘되었는가?” 와 “무엇이 잘못되었는가”를 수집한다음에 SWOT 분석

(http://en.wikipedia.org/wiki/SWOT_analysis )  등을 통해서 개선 방안을 찾아볼 수 있다.

 Process Summary

지금 까지 설명한 프로세스를 개념을 한 그림으로 정리해보면 다음과 같다.


 Implementation

실제로 Task Management Process를 구현하는 몇 가지 방법에 대해서 설명한다. 가장 중요한 점은, 어떤 툴을 사용하느냐가 아니라 어떤 프로세스를 사용하느냐이다.

종종 ALM / Task Management Process를 현업에 적용해보면 문제가 프로세스에 대한 인식이나 성숙된 적용이 없이, 툴을 도입해서 툴에 이끌려가는 경우가 많다. 그래서 프로세스 자체가 또 다른짐이 되고 실제 업무 따로 Task 관리가 따로 이루어 지는 경우를 많이 봤다.

어떤 툴을 사용한다고 해도, 조직과 업무에 맞는 현실적이고 실행 가능한 프로세스를 사용하는 것이 가장 중요하며, 이를 위해서는 1~2개월 정도의 시행 착오 기간이 생길 수 있고 가급적이면 이 기간 중에는 프로세스를 관리하고, 이해 당사자들이 제대로 프로세스를 준수 하는 지를 챙길 수 있는 Coach를 두는 것을 권장한다.

Jump start with Excel

소규모의 팀에서 이 Task Management Process를 사용하기 위해서는 툴과 도구를 설치하는 시간에 대한 소모를 줄이기 위해서 Microsoft Excel만을 사용해도 충분하다. 보통 단일팀에서 10명 이하라면 약간 불편하긴 하지만 빠르게 방법론을 적용할 수 있고, 만약에 시스템을 적용하더라도, 가장 중요한 것은 프로세스이기 때문에 구축 전에 미리 Excel을 이용하여 프로세스를 적용해보고 단계적으로 발전 시켜가는 것을 권장한다.

Excel Template은 http://bcho.tistory.com에서 다운 받을 수 있다.

Implement Task management process with Atlassian Product

회사내에 자체적으로 ALM을 구축하고자 할때는 Atlassian Product를 추천한다.

Atlassian은 JIRA라는 Issue tracking 시스템을 가지고 있는데, 태생 자체가 Task 와 같은 프로젝트 관리 관점 보다는 Bug Tracking 관점의 접근이기 때문에 툴과 Process에 대한 Customizing이 필요하다 그러나 상대적으로 가격이 매우 저렴하고, (Professional Version이 250만원선) 전세계적으로 매우 널리 사용되기 때문에, 관련 자료나 Plug in 들이 많다.

또한 CI나 테스팅 툴, SCM 도구들과 잘 통합이 되는 장점도 가지고 있다.

아래는 ALM/Task Management process 구축을 위한 Atlassian 제품을 이용한 권장 구축 아키텍쳐 이다.


1)       Task Management : Sprint에서 관리되는 각종 Task를 관리한다. Atlassian의 JIRA(이슈 트랙킹) 시스템으로 구축하되, Product BackLog Item과 Sprint Back Log Item이 서로 Parent/Child 관계로 맵핑이 되어야 하기 때문에 Issue에 대한 Parent/Child 관계는 JIRA Professional Version 이상에서만 지원한다.

2)       Product Back Log Mgmt : Product Back Log에는 Product Back Log Item들과 그에 대한 자세한 설명 (예를 들어 Use case)이 들어간다. Product Back Log Item은 JIRA내에 Parent Task로 등록해서 관리할 수 있기 때문에 이에 대한 연관 관계를 JIRA내에 확장 필드로 등록하여 Wiki와 JIRA 사이에 상호 추적이 가능하도록 구축한다.
그 위에 Zagile의 Wiki Smart라는 플러그인을 사용할 수 있는데, Wiki Smart를 사용하면, Product Back Log Item 입력등을 위키 형식이 아니라 좀 더 정형화된 폼을 이용해서 사용할 수 있다.

3)       WBS Mgmt : 전체 프로젝트의 WBS를 관리할 때 통상적으로 사용하는 도구가 MS Project이다. http://www.the-connector.com/ 에서 제공하는 플러그인은 MS-Project의 Task와, JIRA의 Task를 연계 시켜준다. 이 도구를 이용하여, MS-Project를 이용한 WBS 관리와 JIRA를 통한 실제 Task 관리를 연동 할 수 있다.

4)       Integrated view : JIRA와 Wiki는 각각의 View를 가지고 있기 때문에 한눈에 원하는 화면을 보기도 어려울 수 있고 이로 인해서 툴의 사용 효율성이 떨어질 수 있다. zAgile의 Portal 도구는 Atlassian의 툴을 하나의 View로 통합할 수 있는 기능을 제공한다.

5)       Personalized view : 각 이해 당사자 Customer/PM/PL/개발자 별로 봐야 하는 화면이 틀리다. Customer나 PM은 프로젝트의 진척도나 위험도등의 간단한 Dash board를 보고 싶어하며, 개발자는 자신에게 할당된 작업상황에 대한 모니터링을 원한다. zAgile Portal은 개인화 기능을 제공함으로써 역할별로 원하는 화면을 만들 수 있도록 한다.

 Implement Task management process with VersionOne

다음으로 Version One (http://www.versionone.com )이라는 전문화된 Task Management 도구가 있다. AUP나 Scrum과 같은 Agile 방법론을 기반으로 하고 있기 때문에 본 Task Management Process에도 적용이 잘 된다.

 또한 패키지 판매와 함께, Hosting service도 제공하기 때문에 프로젝트 수행후 빠지는 SI 성 프로젝트에서 임시로 사용하기에는 그만이다. (1 Project의 경우 제한된 인원 내에서 무료로 사용할 수 있으니,작은 조직에서 툴을 Evaluate 할 경우 추천한다.)

 단 Issue tracking에 주 목적을 두고 있기 때문에 ALM의 Build Automation이나 Test Automation등의 통합에 문제가 있을 수 있다.

 Conclusion

Agile 방법론이 아무리 실용성을 강조하더라도, Risk관리 측면이나 일정 비용을 가지고 프로젝트를 진행하는 현실에서는 Agile의 목표가 불 명확한 방법론은 적용하기가 어렵다. 그래서 전체 프로젝트에 대한 큰 Mile stone은 기존 방법론을 적용하고, 그 아래에서 Agile 방법론을 팀의 Task 관리 기법으로 사용하도록 디자인 된 것이 ALM / Task Management Process이다.

 ALM/Task Management Process를 실제로 구현하는데 가장 중요한 것은 어떤 전문화된 시스템이나 도구가 아니라, 팀이 최대한의 효율을 낼 수 있는 프로세스이다. 도구는 프로세스를 도와주기 위해서 존재하는 것이지, 도구에 프로세스나 팀이 이끌려 가서는 안된다.

Reference

Methodology

1) SWOT Analysis : http://en.wikipedia.org/wiki/SWOT_analysis
2) Scrum in 5 minutes : http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf
3) Scrum primer : http://scrumtraininginstitute.com/home/stream_download/scrumprimer

Tools

1) Atlassian : http://www.atlassian.com
2) JIRA : http://www.atlassian.com/jira
3) Confluence Wiki : http://www.atalssian.com/confluence
4) JIRA & MS Project Connector : http://www.the-connector.com/
5) zAgile  : http://www.zagile.com
6) VersionOne : http://www.versionone.com





 

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Scrum 지원 도구

ALM/Task Management | 2009.01.29 18:23 | Posted by 조대협

  • Version One (Saas와 Windows 기반 PKG모두 지원)
  • Rally Enterprise (Saas)
  • BaseCamp
  • Scrumworks 이 제품은 Scrum 개념을 아주 충실하게 지원함

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
ALM 프레임웍중에서, JIRA와 같은 이슈 추적 시스템을 이용하여 스케쥴 관리와 작업 추적을 할 수 있지만,
프로젝트에 따라서는 이슈 추적 시스템의 도입이 어렵거나, 별도의 프로세스 정립이나 Learning Curve가 필요한 경우가 있기 때문에, 때에 따라서는 Excel 기반의 Task관리가 효율적일 수 있다.

조엘 온 소프트웨어에서도 언급된바있는 내용인데,

엑셀 항목에
TASK # | Category | Sub task | Detail Task | Assignee | Priority | Due data | Status 를 정한다.
  • Category는 Task의 종류가 된다. 디자인,분석 같은 단계가 될 수 도 있고, Logging,Exception Handling과 같은 각 패키지가 될 수 도 있다.
  • SubTask는 Task들을 나눠서 정의하는 부분으로 Sub category정도로 생각하면 되고, 가장 좋은 단위는 독립된 기능으로 하는 것이 좋다.
  • Task는 실제 작업을 해야하는 Task인데, 보통 1일단위로 나누는 것이 좋고 최대 3일을 넘지 않아야 제대로된 관리가 가능하다.
  • Assignee는 작업이 지정된 사람을
  • Priority는 중요도를
  • Due date는 작업 예상 종료일을 지정한다.
  • Status는  New/Assigned/In Progress/Postponed/Closed 로 정하는데, New는 새로 생성된것, Assigned는 생성되고 각 개발자에게 할당된 작업, In  Progress는 실제 작업중인것, Postponed는 일정에 의해서 미뤄진 작업이고,Closed는 완료된 작업이다.
뒤에 그래프는 날짜별로 작업을 진행하는 기간을 명시한다.

프로세스
크게는 Scrum 방법론을 따르는데, 기본적으로 해야할 Task list들을 정하고 Iteration 기간을 정한다. 보통 한달 이하가 적절하다. Task list를 뽑는 것은 PM이 주도로 하고 세세한 Task는 각 구성원이 직접 작성하고 그에 필요한 시간 역시 직접 작성한다. 그래야 책임 여부가 확실해 지지만, 이것은 스케쥴이 늦어 졌을때 책임을 묻기 위함이라기 보다는 좀더 현실적인 스케쥴링을 하고 책임감을 부여하기 위함이다.
PM은 구성원이  작성한 스케쥴을 가지고, Iteration 기간내에 맞출 수 있는지 체크하고 Task 가 over되었을 경우에는 Priority에 따라서 다음 Iteration으로 넘기거나, Resource를 더 할당 한다.

Task 시간을 예측 하는데는 몇가지 규칙이 있는데,
절대 Task는 각 팀원의 Utilization을 100%로 해서 잡지 않는다. 80%가 적절한데, 80%로 잡더라도 항상 100% 근처가 되기 때문에, 낭비가 되지는 않는다.
그리고 다른 규칙은 모듈을 개발할때, 설계:구현:테스트의 비율이 실제적으로 실행해보면 1:1:1 의 비율을 갖는다. 설계 단계에서는 관련 기술을 Search하고, 테스트 하고 문서화 하는 기간, 테스트 에서는 버그 추적 및 Refactoring등의 기간이 들어가기 때문에 1:1:1의 법칙역시 많은 시간을 소요 하는 것은 아니다.

이를 바탕으로 오전에 10~20분 정도 팀원의 스케쥴을 체크하고 문제 사항이 없는지 도움을 주거나 받을 사항을 간단하게 이야기 하고 매일 Task List를 업데이트 하여 스케쥴 상에 발생할 수 있는 Risk를 관리한다.

예전에 Issue Tracking 시스템을 쓸 수 없는 프로젝트에서 한번 사용했었는데, 요즘도 참 유용하게 사용하고 있다는..



저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

ALM-Project Management

ALM/Task Management | 2008.12.24 10:43 | Posted by 조대협
ALM의 이슈트랙킹 시스템을 통한 프로젝트 관리 방법입니다.
아래 그림이 구현하고자 하는 내용의 모두라고 볼 수 있습니다.
  •  PM : 요구 사항을 시스템에 등록하고 각 요구 사항에 대해서 스케쥴링을 한후에 각 요구사항을 해당 개발팀의 팀장에게 ASSIGN합니다.
  • PL : PL은 각 요구사항을 분석하여 실제 작업(TASK)로 쪼게고 개발자의 스케쥴과 역량 그리고 작업의 심각도와 긴급도에 따라서 개발자에게 ASSIGN합니다.
  • 개발자 : 개발자는 진척 상황을 TASK에 COMMENT로 로깅하고, 각 TASK에 연관된 단위 테스트 케이스를 작성하여 진행을 합니다.
  • PM은 요구 사항을 개발 PL뿐만 아니라, QA 팀에도 ASSIGN하는데 QA 팀에서는 각 요건을 검증할 수 있는 테스트 케이스를 개발 초기단계 부터 작성합니다. 이 테스트 케이스들 (실제로 구현된 JUnit과 같은 구현체)은 Test case management 라는 툴에서 관리 됩니다. 한번 등록된 테스트 케이스들은 이 툴에서 다시 Invoke될 수 도 있고, 그 결과 역시 시스템에 다시 레코딩이 됩니다.
  • 테스트 과정에서 발생된 문제는 Defect Management System(버그 추적도구)에 의해서 리포팅이 되고 각 버그는 하나의 TASK로 PM->PL을 거쳐 개발자에게 다시 ASSIGN이 됩니다.


    이 일련의 프로세스가 ISSUE TRACKING시스템을 통해서 구현되고 각각의 TASK가 추적성을 갖게 됩니다.

이것이 ALM의 PROJECT MANAGEMENT모듈의 개념입니다.
어떤 툴을 사용하느냐, 개발팀의 모델이나 일정 수준에 따라서 Variation이 상당히 많습니다. 그외에 PM이나 고객을 위해서 DASHBOARD를 제공하거나 개발자를 위해서 Eclipse에 플러그인(Mylyn)을 제공하거나 환경적인 설정 방법도 상당히 많습니다. 제대로 적용하면 상당히 효과가 좋은 모듈이지만 반대로 잘못하면 자체가 짐이 되버리는 경우가 많기 때문에 도입시에 많은 고려가 필요한 부분입니다.

개인적으로 JIRA,Mantis,Bugzilla를 프로젝트에서 사용해봤고, Trac,Polarion,Code Beammer, Rally Enterprice, VersionOne등의 이슈관리 도구들을 테스트해봤지만 개인적으로 가장 사용하기 편하고 유연성이 있으며 가격대비성능(ROI)가 높은 도구는 JIRA인것 같습니다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

 회의를 하면서 느끼는 건데..
특히나 요구사항과 관련된 회의 등에는 요구 사항은 많이 나오는데 정리가 안되거나 나중에 실제 해야할일들이 누락되서 낭패를 당하는 경우가 많다.

회의록을 정리하는 기법이다.

1. 회의 내용 기록하기
구글 DOC을 이용해서 실시간으로 회의 참여자들이 회의 내용을 기록한다. 이때 누가 어떤 이야기를 했다는 것 정도는 기록되는 것이 좋다.
Terry/HP@Byungwook/Oracle :....
HP의 Terry가 Oracle의 Byungwook에게 ... 런 이야기를 했다.
이런식으로  정리하고 가능하면 회의록에 요점을 정리하거나 ACTION ITEM을 뽑는것도 방법이된다.

2. Action Item 추출
회의가 끝난후에 회의 내용을 정리해서 해야할일들을 Action Item으로 정리한다. 각 Action item 아래에 회의에서 오갔던 내용들을 Copy & Paste해서 붙여 넣는다.

3. Action Item 검증
팀장이나 또는 의사 결정자가 Action Item을 Review하여 실제로 수행해야할 Action Item들만 추출한다.

4. Issue로 등록
Issue Tracking 시스템이 있다면 Issue Tracking 시스템에 각 Action Item을 등록하거나 또는 Excel 장표로 정리한다.

5. Action Item과 Issue Mapping
Issue #를 회의록에 Action Item #와 맵핑 시켜서 기록해놓는다.
이렇게 해서 추후에 고객이 요청했던 내용의 진행 내용을 Full 로 Trace할 수 있다.

6. 고객에게 회의록 전달
Google Doc에 정리된 회의록을 MS-WORD로 Export한 후, 고객 회의록 포맷에 맞춰서 고객에게 전달한다.

아래는 위의 프로세스를 정리해놓은 그림이다.


 

사용자 삽입 이미지

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
작년에 ALM에 대한 research를 하면서 관심 분야가
프로젝트 관리와 테스팅쪽으로 많이 옮겨왔다.

요즘 하는 프로젝트에서 캐나다 출신 컨설턴트와 일을 하고 있는데..
예전에 고민했던것중 하나가 프로젝트 관리를 어떻게 시스템화 할것인가?? 가 하나의 과제였다.
그 대안이 JIRA나 WIKI등을 이용한 방법이었는데.
이친구는 새로운 접근 방법을 사용하더라..

그 방법이 Google Application인데.
나열해보면 아래와 같다.

1. Google Groups
메일링 그룹을 설정하는 기능이다. 간단하지만 막상 프로젝트 들어가면 꼭 필요한것이 메일링 그룹인데. 서버 관리자에게 부탁하기도 어렵고.. 또는 Outlook을 사용하자니 혼자만 되는데.. 깔끔하게 고민을 해결해준다.

2. Google Calendar
말 그대로 간단한 달력인데. 재미있는 것이 사용자간에 Share가 된다. 내가 만든 일정을 팀원이 공유할 수 있고 참석자도 설정할 수 있다는 것. Outlook에는 당연히 있는 기능이지만 프로젝트 나가는 곳에는 Outlook이 안되는 상황이 많기 때문에 제법 유용하게 사용된다.

3. Google Doc
역시 Google이다 할만한 작품인데.
단순하게 MS-WORD를 웹상에서 한다고 생각하면 된다. 단!!! 재미있는 것이
동시에 여러명이 하나의 문서를 편집할 수 있다는 것. 고로 문서에 대한 협업이 가능하고 이 문서는 사용자간 공유가 가능하기 때문에 산출물을 어디에 저장할 것인지 그리고 서로 SYNC가 안맞는 문제가 단박에 해결된다. History기능도 있기 때문에 잘못된 문서를 저장하는 것도 rollback하는 것도 물론이고~~
그리고 MS-WORD로 Export/Import가 자유롭기 때문에 나중에 산출물로 제출하는 것도 가능하다.

일반 Document뿐만 아니라 회의중에 회의록을 작성하는 것에도 유용하게 사용되는데.
프로젝트 특성상 외국인은 많은데 발표나 회의가 한글로 진행되는 경우 Google doc을 열어놓고 서로 실시간으로 회의 내용을 영어로 적어서 공유하고 필요한 내용도 Comment를 달아 놓으니.. 진짜 효율적이다.
Word process뿐만 아니라 spread sheet(Excel), Presentation tool(PPT)도 지원한다.

4. Google Team Site
 이게 정말 물건인데. 간단하게 생각하면 위키 같은 개념으로 Customization이 가능한것이라고 생각하면 된다. 그중에서도 좀더 프로젝트 관리에 가까운 툴인데.
위에 모든것들을 여기에 모아 놓는다. Caledar를 여기에 놓고
MS-WORD와 같은 산출물들을 Shared File 폴더를 만들어서 보관한다. (같은 이름으로 파일을 계속 올리면 자동으로 Versioning이 되고, 마찬가지로 rollback도 가능하다.)

Google doc에 대한 문서 리스트도 링크 시켜 놓으면 최근에 업데이트된 내용을 Dashboard에서 확인할 수 있도록 되어 있다.

Google Ap 기반으로 프로젝트를 관리하면 좋은 점이... 초기에 설치에 대한 비용이 필요없다는 것이고 Google 답게 사용하기가 쉽기 때문에 Learning curve에 드는 cost가 매우 적어서 프로젝트 제반 환경 설정이 매우 신속하다는 것이다.

지금도 프로젝트를 하면서 계속 좀 더 최적화 시켜나가고는 있는데, 나중에 하나의 툴킷으로 만들어서 사용해보도록 해야겠다...

쓰면서 느낀것이.. 역쉬 구글이다.. 그리고 비싼돈 받는 컨설턴트는 모가 달라도 다르구나...
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Code Complexity 측정 도구

ALM/Task Management | 2008.08.12 01:13 | Posted by 조대협
LOC계산과 Cyclomatic complexity를 계산해준다는 툴인데..
쓸만 할려나?
http://www.geocities.com/sivaram_subr/codeanalyzer/description.htm
물론 꽁짜툴!!

Cyvis
http://cyvis.sourceforge.net/screenshoots.html

이것 괜찮다. JAVA 기반으로 Cyclomatic complexity 계산도 해주고 ANT TASK 지원은 물론이고
결과를 XML이나 HTML로 Generate 해준다.
Test Coverage이나 Complexity vs Defect 비율 계산에 유용할듯


http://www.onjava.com/pub/a/onjava/2004/06/16/ccunittest.html
Code complexity 분석을 통한 코드 향상 기법
여기 보니 PMD로도 Complexity 분석이 가능하다

그리고 여기에도 흥미로운 툴들이 많다. 이클립스 기반의 도구들
http://linuxne.springnote.com/pages/1460384
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
 

티스토리 툴바