http://subokim.wordpress.com/2011/11/07/agile-work/

Agile하게 일하기

Agile 방법론이 대세이고, 화두입니다. (Agile = 날렵한, 재빠른, 기민한)
“어떻게 일해야 하고, 어떻게 해야 성공적일 수 있을까?”를 고민해보았습니다.

왜 대세인가?

소프트웨어 제품은 만드는 것도 중요하지만, 계속해서 온라인으로 업그레이드 시킬 수 있다는 장점이 있습니다.
이것은 제품 출시 후에는 업그레이드 할 수 없는 하드웨어보다는 매우 매력적인 특성입니다.

온라인 서비스의 경우는 특히 “신규 개발”보다 “운영 및 지속적 업그레이드”가 중요한 비즈니스입니다.
하지만, 안타깝게도 비즈니스 환경이 개발자가 선호할만한 환경은 아닙니다.

체계적인 요구사항이 없다.
사업 환경에 따라서 구현하거나 보완해야 할 사항이 자주 바뀐다.
어떤 것이 목표인지 목적인지 뚜렷하지 않다. 신기술이나 실험적인 시도도 필요하다.
이런 짓을 평생 반복해야 한다.

이런 상황에 대해 분석, 설계, 개발을 엄격하게 규정짓는 Waterfall 방법론은 넌센스라고 할 수 있습니다.
Waterfall 은 “요구사항을 Fix시키지” 않으면, 이후 프로세스를 진행할 수 없기 때문입니다.
그리고, “요구사항이 변경”되면 그만큼 Roll back해야 합니다.
과거 하드웨어 중심의 프로젝트에서는 제품출시 후 변경하기 어려웠으므로, 개발 착수 전에 모든 걸 결정짓는 Waterfall 방법론이 적합했습니다.
하지만, 소프트웨어 비즈니스에서는 위와 같이 규정짓기 힘든 경우가 태반입니다.
즉, Agile 이 주목받고 있는 이유는, 소프트웨어 시장이 포화가 되어서 신규구축이 많이 없어졌고, 시장에 유연하게 대응하면서 사업을 성장시키는 노하우가 중요해졌기 때문입니다.

누가 필요로 하는가?

Agile 한 환경을 누가 필요로 할까요?
Waterfall 은 버려야 할까요? 그렇지 않습니다. 방법론은 “프로젝트를 성공시키는 수단”일 뿐.
방법론을 잘 지켰다고 반드시 프로젝트가 성공하지는 않기 때문입니다.

Agile하다는 것은 “눈에 보이는 (작은)성과물을 가지고 Speedy 하게 Communication 하는 것”을 말합니다.

Agile 은, “프로세스가 없어서 일을 못한다고 이야기하는 조직”이 해야 합니다.

프로세스를 이야기하는 조직은 대부분 큰 조직들입니다. 프로세스는 감정적인 분쟁을 억제하고, 전체적인 책임으로부터 자유롭게 해줍니다.
프로세스를 중시하는 조직에서는, Agile을 “또 하나의 프로세스”로 이해하는 경우가 있습니다.
그러나, Agile 은 일하는 방법이지, 프로세스가 아닙니다.

작은 조직이이라면, 프로세스를 논의하기 전에 Agile 한 방법을 도입해보길 강력히 추천드립니다.
큰 조직이라면 상황이 다릅니다.

Agile 은 “매일 상황이 변하는 서비스 운영 조직”에서 해야 합니다.

작게 일을 나누고, 작게 개선합니다. 그리고, 많이 커뮤니케이션합니다.
“이야기하면서 방향을 정하고, 이야기하면서 피드백합니다.”
상황이 매일 변하므로 약속과 원칙에 얽매이면, “변화의 시기”를 놓쳐버리기도 합니다.
여기서 중요한 것은, 노하우를 기록하고 남겨야 한다는 것입니다.
Agile 은 작고 가볍기 때문에 체계가 부족합니다.
즉, 실패를 기록해두지 않으면 반복할 가능성이 큽니다.
노하우가 유사한 환경의 멤버들에게 공유될 수 있어야 합니다.
기록을 공유하는 가장 쉬운 방법은 사내 게시판을 활용하는 것입니다. 잊지 마십시요. Agile은 툴이 아닙니다.

사내 게시판이 없는 경우는 메일을 사용해도 좋습니다.

어떻게 일해야 하는가?

Agile 방법론은 “프로세스”가 아니라“문화”입니다.
일하는 방식에 대한 것입니다. 형식없는 형식입니다. (무슨 도 닦는 이야기 같군요.)

첫째, 목표를 정하라.

진행하다가 목표가 달라지면, 연관된 것을 재점검합니다.
목표를 정하는 것은 협업의 기본입니다.
무엇을 바라봐야 할지 정하는 것은 당연합니다.
목표가 공유되지 않았는데, 이야기할 거리가 있을까요?
아무도 그 목표에 대해 고민하지도 않을거고 서로의 역할에 대해서 말하지도 않을 겁니다.
주욱, 텍스트로 적으십시요. 그리고, 그것으로 논의하십시요.

둘째, 기한을 정하라.

언제쯤이면 무엇을 눈에 볼 수 있는지 기한을 정하십시요.
그래서, 무엇을 평가하고 어떻게 피드백할 것인지도 사전에 공유하십시요.
“이 기능이 되면, 이런게 만족 되는지 보자.”라고 이야기하십시요.
iteration의 기본은 반복하는 것입니다. 즉, iteration 이라는 갈림길에서 어떤 의사결정을 할 것인가를 미리 공유해두는 건 매우 중요합니다.
팀원들은 그 의사결정을 할 수 있도록 충분히 준비할 것입니다.

셋째, 각 일의 책임자를 정하라.

애매한 것이 없도록 나누어서 맡아야 합니다.
애매한 것의 업무부담은 PM이 조절해야 합니다.
PM은 쪼개어진 일에 따라 전문인력을 쉽게 넣고 빼고 할 수 있어야 합니다.
모듈의 전문성을 높이기 위해서는 일단위의 시작과 끝을 적절히 자르는게 중요합니다.
그렇지 않으면, 한 번 투입된 인력이 오랫동안 투입되고 단위업무의 품질은 떨어지고, 전체일정의 혼란은 가중될 것입니다.
PM은 Job Load 에 대한 분배와 함께 전체 스토리가 초점을 잃지 않도록 관리해야 합니다.

넷째, 빠진 것이나 이슈는 bucket list로 관리하라.

iteration 을 도는 동안 test 를 하면서, 문제나 이슈가 제거되거나 완화되어야 합니다.
iteration 을 하면서 만들어진 새로운 기능이 “다른 문제를 야기”하지 않도록, Business Unit을 모듈화시키고, “Sandbox 형태”로 설계해야 합니다.
만일, exception을 발생시킨다면 다른 iteration에서 쉽게 참조할 수 있도록 document 가 있어야 합니다.
project wiki page 를 하나 만들고, 거기서 관리하십시요. 아니면, issue tracker도 좋습니다.
이슈 관리에 “메일”은 가능하면 쓰지마십시요. “메일”은 공유의 개념보다 책임 떠넘기기로 오해될 수 있습니다.
wiki 나 게시판 같이 함께 볼 수 있는 곳에 게재하십시요.

다섯째, 위험의 크기를 사전에 공유하라.

기일을 정했는데 변할 수 있습니다.
Feature를 정했는데 변경될 수 있습니다. 기한 내에 맡은 일을 못할 수도 있습니다.
어떤 경우든 팀원들이 빨리 위험신호를 알리고 미리 대응할 수 있게 해야 합니다.
위험을 미리 예상하여 작게 쪼개어서 점검할 수 있게 계획하십시요.
실패에 대한 부담이 적을수록, 창조적으로 일하게 된다.

기일을 못맞추면 어떤 일이 생기는지 구성원들이 사전에 공유하십시요. 위험에 대한 인식이 다르면, 협업이 힘들어집니다.

Agile 방법론의 종류

이 항목은 wiki 페이지를 참조하였습니다.

eXtreme Programming 해야 할까?

무조건 우선 개발을 시작하는 방식입니다.
처음에 고객과 2주 정도 이야기하면서 컨셉을 잡고는, 우선 개발합니다.
구성원들이 시스템에 대한 이해도가 높아야 하고, 전문가들이어야 합니다.
따라서, 외주활용이 힘듭니다.
중요한 것은 자동화된 테스트 시스템이 있어야 합니다.
즉, 개발환경(테스트가 가능한)이 없으면 결과를 확인할 수 없어서 다음 Cycle에 진입할 수가 없습니다.
개발환경 하에서 짧게 짧게 Cycle을 돌면서 개발을 하는 것이므로, “기능개선 중심의 과업”에 적합합니다.
하지만, 개선효과를 금방금방 확인할 수 있으므로 신기술을 플랫폼에 도입하거나, 중소규모의 기능을 플랫폼에 추가하고자 할 때 적합합니다.
개발환경없이 신규멤버로 맨땅에서 시작하는 경우라면, XP 개발은 하지마십시요.
구성원들 간 커뮤니케이션에 혼란이 생길 것입니다.
XP 를 하기 위해서는 개발환경을 잘 갖추는게 중요합니다. 아주 빡센 개발방법입니다.

Scrum 원래 Scrum은 한 달 단위로 한다고 합니다.

사전에 개선할 목록을 뽑고, Iteration 마다 동작가능한 결과물을 내어 놓을 수 있도록 일을 나누어 일하는 방식입니다.
매일 정해진 시간에 모여서 짧게 개발을 하는 방식인데, 오픈 소스 커뮤니티가 많이 사용한다고 합니다.
조금 느슨하므로, 구성원들의 참여의욕이 높아야 합니다. 너무 Free 해보여서 기업형 개발에는 적합하지 않을 것 같네요.

Feature-Driven Development

도메인 객체 모델이 중요합니다. 전체 업무를 객체단위로 부품화하고, 이 목록대로 기능을 나누어서 개발합니다.
2주 단위로 Cycle 을 돌면서, 반복 개발합니다.
분석 설계를 끝나고, 개발단계 이후로 iteration을 할 수 있네요.
최근에 “아키텍쳐 개발방법”에 많이 사용되기도 합니다.

Adaptive Software Development

이게 Agile 을 대표하는 방법론이 아닐까 싶습니다. 이 방법은 Rapid Application Development 의 확장판입니다.
이것은 상시 적용이 가능하다는 전제에서 시작합니다.
ASD는 추측, 협동, 학습을 반복하는 것인데요.
추측이란 의사결정권자들이 어떤 관점에서는 이슈를 잘못 판단할 수 있다는 가정에서 시작하는 것입니다.
학습이란, 디자인-개발-테스트를 반복함으로써 의사결정권자들이 알게하는 것을 말합니다.
ASD 는 의사결정권자들이 쉽게 결정할 수 있도록, 포인트를 나누어서 iteration을 도는 것을 말합니다.
Waterfall 방법론과 섞어서 진행할 수도 있습니다.
중요한 건, 중간 성과를 자주자주 보고하는 것입니다.

Agile 하게 일하지 않아야 하는 경우는?

SI 용역 프로젝트의 경우 Agile 하기 힘듭니다.
외부집단이 내부 내용까지 깊이있게 이해하기 힘들 뿐더러, 책임감이나 위기의식이 공유되기 힘들기 때문입니다.
Agile을 적용하기 힘들다면 “전통적인 Waterfall 방법론에 Agile 한 문화를 조금 섞어서” 해보길 추천드립니다.
중간 산출물에 대해 Feed-back 만 제대로 할 수 있어도 Risk는 꽤 줄어듭니다.
그러기 위해서는, PM 이나 아키텍쳐가 상세레벨까지 이해할 수 있어야 합니다.