Agile 방법론

06.Agile 2009.10.07 15:58

 

제가 전달하고자 하는 부분은 애자일(Agile)개발 방법론에 대한 것이 아니라, 애자일(Agile)개발 방법론을 어떤식으로 현재 개발상황에 어떤식으로 어떻게 적용시킬 것인가에 대한 내용입니다.

 

그전에 애자일(Agile)개발 방법에 대한 개념에 대해 설명하도록 하겠습니다.

애자일 개발 프로세스란, 어느 특정 개발 방법론을 가리키는 말이 아닌, 애자일(Agile=기민한, 좋은 것을 빠르고 낭비없게 만드는 것)개발을 가능하게 해주는 다양한 방법론 전체를 일컬어서 "우리는 이것을 애자일(Agile)이라고 합시다" 라고해서 이름 붙게 되었습니다.

 

다음은 애자일(Agile) 개발 프로세스로 불리는 개발 방법론에 대해서 간단한 소개를 하겠습니다.

 

  • 익스트림 프로그래밍(Extreem Programing, XP) - 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트와 우선 개발을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.
  • 스크럼 - 30일마다 동작 가능한 제품을 제공하는 스플린트를 중심으로 하고 있다. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다.
  • 크리스털 패밀리 - 이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공한다. 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍 만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다.
  • Feature-Driven Development - feature마다 2주정도의 반복 개발을 실시한다. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가진다.
  • Adaptive Software Development, ASD - 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론이다. 내용적으로는 다른 방법론들과 유사하지만, 합동 어플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는것이 조금 다르다.
  • 익스트림 모델링 - 익스트림 모델링은 UML을 이용한 모델링 중심 방법론이다. 다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 한다.

- 위 내용은 <위키백과>에서 참조하였습니다.

 


애자일에 대해서 말하자면 수많은 좋은 내용들이 있겠지만, 게임 개발자 컨퍼런스(KGC2008)(08.11.14)에서 강연을 했었던,

  1. 엔트리브의 김기웅씨 "애자일 게임 개발이란?"
  2. 애자일 컨설팅의 김창준씨 "애자일 게임 개발 도입하기(월드 카페)"

강연을 듣고 이야기하고 나누었던 내용들에 대해 정리해보고자 합니다.

 

단순히 자리에 앉아서 졸고 인터넷에 널리 퍼져있는 말들이나 스크린에 비춰가면서 와닿지도 않는 말들을 노트에 끄적이고 했던 다른 강의와는 달리 전문강사가 아닌 현역 개발자분들이 직접 나와서 경험한 개발 방법론에 대해 설명하다보니 미숙할 수도 있었지만, 제가 참가한 월드 카페식 토론에서 짧지만 약 6시간중...50여명의 개발자분들의 다양한 경험이나 의견 및 이야기를 공유할 수 있었습니다.

 

 

월드 카페 진행 주제 : 어떤식으로 애자일(Agile)을 적용할 것인가?

 

1. 애자일(Agile) 방법론을 꼭 적용해야 하는가?

아니다. 애자일(Agile)에서 추구하는 것은 더 낳은 개발 프로젝트 관리 및 성공을 위한 열쇠로 사용되려 하는 것이지, 무조건적인 적용으로 불필요한 시간을 낭비해서는 안된다.(* 어떠한 방법론이라도 마찬가지 일 것이다)

애자일(Agile)이 아니더라도 현 프로젝트에 가장 적합하고 성공으로 이끌 수 있는 개발 방법론을 사용하고 있다면, 무리하게 적용할 이유가 없다.

 

2. 어떤식으로 애자일(Agile)을 적용할 것인가?

- 소규모 팀 단위 적용실천법 -

 발표자 : 조현희(소속 :  포뎁스)

"화이트 보드를 활용한 방법에 대해 제시하겠습니다"


  1. 업무를 단위별로 구분(업무 기간별 조정 필요)

    포스트잇등의 메모장을 활용하여 업무에 대한 내용을 기재, 화이트보드에 업무단위별(대기,진행,완료등..)로 구분짓고 게시한다.

  2. 업무에 대한 담당자를 표시하여 게시한다.

    다른 팀원이 어떤일을 하는지 모두가 파악이 가능해지며, 업무관한 자연스런 토론 및 미해결건에 대한 해결책을 자연스럽게 제시 할 수 있는 환경이 만들어질 것이다.

  3. 완성된 업무에 대한 분류

    업무에 대한 진척도가 파악되어 프로젝트의 전체적인 일정관리 및 조정이 한결 수월할 것이다.

 

이를 활용하게 되면 현재 진행하고 있는 프로젝트의 진행상황 및 문제점등이 투명하게 관리되어 전체적인 현황관리가 수월해 질 것입니다.

 

"완성된 업무에 대하여 개발과정이나 문제점 해결 방법등에 대한 간단한 발표를 통해 팀원간 성과에 대한 인식 및 칭찬을 통하여 다음업무를 위한 '파이팅'을 부여하면 좋을 것 같습니다" - 발표 후 토론중 의견제시...

 

- 개인별 적용 방안제시 -

발표자 : (소속 : 루벤소프트)

"화이트보드 활용 방법을 재구성하였습니다"

  1. 업무별 주제 부여
  2. 단위별 업무에 대한 익명게시

    다른 팀원이 가벼운 마음으로 업무에 대해 접근할 수 있도록 환경제공

  3. 해결된 업무에 대한 이력 게시

    '담당자'와 '해결자(해결방안 제시자)'가 의견을 주고받은 내용을 기록하여 각 팀원들이 알 수 있도록 내용을 게시 및 전파한다.

    애자일(Agile)이라는 생소한 단어를 꺼내서 "해봅시다!"라고 하는것 보다 팀원들이 이러한 과정에 대하여 '호기심'을 가질 수 있도록 유도하여 자연스럽게 접할 수 있도록 하는 것이 주목적.

 

이론적인 개발실천법을 따라가는 것이 아닌, 팀원 모두가 실천법에 대해 '이해'하여 우리팀에 맞게 재구성하면 새로운 개발론에 대한 어려움이 들할 것이다.

 

- 패턴 로그 제시 -

개발하면서 성공적인 사례를 패턴화하여 관리하는 프로그램을 구성.

게시된 패턴을 보고 각자의 생각 및 의견을 반영하여 더 낳은 구성으로 패턴을 '진화'시키며, 팀원들이 타프로젝트 혹은 이전프로젝트에서 사용되었던 패턴을 활용하게 되면 패턴개발등으로 소모될 시간을 단축하여 더 높은 품질의 프로그램을 제작하는데 시간을 투자할 수 있을 것이다.

잘은 기억이 안나지만 김흥배(?)님께서 경험공유로 의견을 내주신것 같다.

 

- 기타 의견들 -

  1. Daily Meeting

    매일매일 약 20여분간의 간단한 회의를 통해 자신이 그날&그주에 맡은 업무에 대해 다시 한번 확인한다.

  2. 열린 개발환경 제시

    간단한 회의를 위해서 모두 자리를 뜨고 회의실로 몰려가는 불필요한 자리이동 없이 서로 마주 볼 수 있도록 업무환경에 대해 개선

    일과 회의가 자연스럽게 하나가 되어 즉흥적이면서 유기적인 관계를 통해 신속정확한 대처로 업무의 효율성을 극대화 시킬수 있을 것이다. ( 엔트리브 김기웅씨 강연내용 )

     

    ms-pnp_teamTable.jpg

    강연내용에 소개되었던 샘플사진을 구하지 못하여,  

    인터넷에서 MS PNP(patterns & practices)팀의 개발환경사진을 구해 대체하였습니다.

    사진에서 볼수 있듯이 팀원간에 파티션이 없어 간단한 업무 협의나 회의장소의 이동없이 쉽게 이루어 질수 있습니다.

     

     

  3. 회의 방식에 대한 개선 필요

    '팀장'주도하에 이루지는 회의는 책임감이 떨어진다.

    '팀원'들 모두 진행하는 프로젝트에 대한 '이해'속에서 서로의 의견을 주고받음으로써 다양한 의견속에서 가장 좋다고 판단하는 의견을 팀원들이 선택, 반영 및 검토한다.

    '팀원'들 스스로가 자기일의 '책임자'가 되어 자신의 업무와 관련된 팀원들간의 자발적인 회의를 통해 의견을 주고 받으면서 '일'에 대해 정확히 '이해'하여 전체적인 그림을 그려나간다.

 


- 애자일 방법론 적용경험 공유 -

 

개발자라 상상을 한다면 사무실 구석에서 자기만의 성을 짓고, 문서만을 넘겨받아 요건을 충족시키고 그 요건에 맞추어 개발을 완성하였을때, 클라이언트가 건네준 문서의 요건과 클라이언트가 실제 기대하는 요건과는 조금 틀릴수 있다는 것을 눈치채지 못한채 자기만족을 느끼며 '개발완료'라고 도장을 찍고는 했습니다.

 

애자일 개발방법론에 대해 어느정도 이해를 하고 나서는 생각을 고치게 되었습니다.

 

애자일 개발헌장을 참조하게 되면,

 프로세스와 개발 보다 사람과 의사소통

                  기획문서 보다 눈에 보여지는 결과물

                                                계약과 협상 보다 고객과의 협업(빠른 피드백으로 회의시간 단축)

계획에 대한 맹종 보다 변화에 대한 대응

 

고객과의 협업, 즉 클라이언트와의 피드백 교환으로 클라이언트가 원하는(중간중간 변할수 있는) 요건에 대해 발빠르게 대응하여 결과적으로 문서가 아닌 클라이언트가 원하는 프로그램을 보여주는 것이 완성도 높은 프로그램을 만드는 것이라 생각하게 되었습니다.

 

현재 1인파견개발자로써 본사 사무실 구석에 앉아 문서만 챙겨서 개발하는 것에 변화를 주어 직접 클라이언트의 회사에 자리를 마련하여 실담당자와 많은 의견교환과 문서로 파악한 내용이 맞는지 대한 확인절차를 통하여 이유없이 고민해야할 부분들에 대한 시간단축을 통해 완성도 높은 프로그램을 만들어 내기 위한 노력을 하고 있습니다.

 

제가 한 행동은 본사 사무실에서 단지 클라이언트의 회사로 자리를 옮긴 것 뿐이지만, 그 효과는 약 1주일의 시간단축을 가져왔고, '어떻게 만들어야 하지?'라는 맹목적인 고민에 대해 빠른 결단을 내릴 수 있게 되었습니다.

그리고 앞서 말한 애자일 개발헌장에 있듯이 사람과 의사소통, 눈에 보여지는 결과물, 고객과의 협업, 요구조건이 바뀌더라도 그에 대응하게 되는 점들 모두 충족하면서 개발하고 있다고 생각합니다.

 

2008.12.19 - 내용추가-_-;

새로운 방법론에 대한 부작용이랄까...너무 잦은 의견교환으로 클라이언트가 나에게 사소한것까지 일처럼 불려서 나한테 시키고 있다는 단점을 알게 되었습니다.(클라이언트가 스스로 해도 되는데 말이지요.)

휴가기간임에도 불구하고 어김없이 날아오는 업무메일이 증거. ㅠㅠ..이건 꼭 애자일이 아니어도 그럴꺼라는 생각이 드네요...

  

  ...

신고

'06.Agile' 카테고리의 다른 글

Agile 방법론  (0) 2009.10.07
스크럼, 팀의 생산성을 극대화시키는 애자일 방법론  (0) 2009.08.25
Posted by Stewie


티스토리 툴바