Agile vs Waterfall 차이점은 ?

Product을 마지막 시점에 보여주는 것보다는 반복 주기 별로 고객에게 보여 줌으로서
Product의 가치를 초기부터 제공할 수 있어 결과적으로 고객이 원하는 Product 을 공급할 수 있다.

요즘의 Project는 Iterative Waterfall 형태로 진행하는 경우도 많은 것 같다(단계별 Open)
Agile에서 이야기하는 Release Plan에 의한 배포와 유사하다.

예를 들어 Iterative Waterfall 에서 (Plan-build-test-review-deploy)가 1~2개월이라면
프로젝트는 Agility 하게 진행 하는 것이라 할 수 있다.
이런 환경이면 Agile 에서는 Sprint를2~4번을 반복계획을 세울 수 있다

프로젝트에서 하나의 반복주기(Sprint)가 4주를 넘지 않게(2~4주) 계획할 수 있다면
이미 Agility 한 것이고, Agile의 활동 및 기법들을 효과 적으로 활용할 수 있다면
프로젝트에는 큰 도움이 될 것이다.

¶™ Agile is a culture !

난 PM 오픈에 대한 신뢰 어떻게 확보할까 ?

방법론이 프로젝트의 성공을 좌우하진 않습니다.
방법론은 프로젝트의 위험을 감소시키는 것을 목표로 합니다.
어디에나 적용 가능한 최적의 방법론이란 존재하지 않으며, 프로젝트와 팀에 따라
달라질 수 있습니다.

Agile 방법론이 화두 입니다.
하지만, 도입만 하면 저절로 잘 되는 건 아닙니다.
얼마만큼 방법론에서 제시하고 사전에 팀원과 약속한 활동 등을 잘 실천 했는가가
중요 합니다.

PM은 언제쯤 오픈 에 대하여 스스로 신뢰할 수 있을까요 ? 그리고 어떤 것을 통하여....
보통은 품질목표 또는 타 측정지표 등을 기준으로 고객과 오픈 에 대한 기준을 정하고 프로젝트를 시작 합니다.

PM을 경험해 보신 분들은 오픈 에 대한 확신을 언제 가졌는지 회상해보시면 어떨까요 ?
아마도 통합테스트 기간이 끝나가는데도 확신이 서질 않는 경우를 경험해보셨을 겁니다.
누군가가(Stakeholder) 잘되고 있어 ? 다음달 오픈 가능하지 ? 라는 질문에 우리는 자신 있는 대답을 했던가 ?

프로젝트 초반에는 오픈 에 대한 자신감 기대감은 높으나, 진행하는 과정에 그 기대감은 불안감으로 이어지며 오픈 에 대한 신뢰가 희미해지며 프로젝트 후반부에 힘들었던 경험 몇번쯤은 있었을 거라고 생각합니다.

그럼 이러한 문제를 해결할 수 있는 좋은 방법은 없는 걸까요 ?

Agile의 장점이 무엇인가? 라는 질문에 저는...
Agile 방법론은 타 방법론 보다 예측 가능성을 높여준다 라고 이야기를 합니다.
그리도 덪붙여 Agile 방법론만 적용하면 저절로 이루어지는 것은 아니라고 이야기 하죠..^^
Agile에 대한 가치는 애자일 메니페스토(http://agilemanifesto.org/)와
12개의 적용원칙(Twelve Principles of Agile Software)에 잘 나타나 있습니다.

Agile에서는 프로젝트 팀원과 고객이 함께 Product 에 대하여 완성해가는 Cycle을 개발시작(Sprint#1)부터 지속적으로 공유 및 Feedback을 하자 입니다.(가능하지 않을까요? 꼭 완성도를 높여서 고객에게 보여줘야 할까요?)

이 활동을 통합테스트 전까지 꾸준히 하고(이는 단위테스트 완료를 의미함)
통합테스트 에서는 진정한 시나리오 기반의 통합테스트를 하자 입니다.

위 그래프는 Agile vs Waterfall 프로젝트의 결함 식별과 잔존결함의 추이를 나타내는 그림 입니다.
반드시 이러한 결과가 나온다는것은 아니며, Waterfall 방식은 프로젝트 후반부에, Agile은 초반부터 결함이 식별됨을 강조하기위해 예측한 그래프 입니다. Waterfall의 그래프는 많은 부분 동감하리라 생각 합니다.

위의 Agile 방법론의 추이대로 팀이 움직일 수 있는가가 열쇄 라고 생각합니다.

이렇게 되면 아주 많은 기간동안(상대적으로) 우리 스스로 그리고 고객 또한 Product에 신뢰를 가지게 되며 승인테스트 및 Open에 대하여 아주 유리한 환경이 조성될 수 있습니다.(실제로 믿음이 생김)

Agile을 적용하며 Sprint기간내 단위테스트(3자,고객) 및 Feedback을 제대로 못한다면 Waterfall 방식의 프로젝트와 다를게 없다고 생각 합니다.

실제 Agile 방법론을 적용한 프로젝트를 보면 ①의 시점은 Waterfall 에서의 설계 단계이며 Agile 방법론에서는 Sprint#1 이며 이떄부터 Product backlog의 개발로 부터 테스트(3자,고객)에 의해 결함이 식별되고 Feedback이 관리 되어 ②통합테스트 단계를 단축되는 사례가 나오기도 합니다.

Sprint에 들어가면 개발자에게서 개발완료된 프로그램을 최대한빨리(바로) 테스트(3자, 고객)하자 입니다.(고이 모셔두지 말자)

테스트를 하면 Bug가 나오는데 그 Bug를 통해 팀은 배우게 됩니다. 그 배움은 미 개발 Product에 반영되어 실수를 줄일 수 있습니다. 이러한 활동은 Working S/W 로 Product이 유지됨을 신뢰할떄 예측 가능성을 높임(오픈 등..)

1. 남아있는 Product backlog 개수(진척) : 완료된것 보다는 남아있는 것에 관심을 가짐
    (Burn-down chart)
2. 결함은 꾸준히 식별 되고 있는가(테스트:3자, 고객) : 적절한 결함 식별
    (ex 요구사항, 설계+개발 : 5개/FP)
3. 미조치 결함(기능개선 등 포함)은 증가되지 않게 관리 : 결함은 빨리 처리할수록 비용이
    적게들고 쉽게 고침

매일 Scrum Meeting 을 통해 공유하며 이는 Risk, Issue가 빨리 그리고 투명하게 식별되어 대책 또한 한발 빠르게 대처함 이런과정에서 오픈에 대한 예측 가능성을 아주 높일 수 있다고 생각합니다.
(팀원은 특히 개발자는 힘들어 할 수 있음.. 이런식으로 일을 해보지 않아서.... 나의 실적이 공개되어서... 비교되네...휴~~ 등...)

이런경우 개발자 입장을 고려 기존 방식대로 할것인가 ? -> 리더쉽 및 동기부여 등의 고민 필요합니다.

핵심 실천사항 및 가치로 이야기 하고 있는 부분을 얼마만큼 실천하며 프로젝트를 했는가? 를 함께 봐야 합니다.

위의 과정을 아주 잘 실천 했다면 분명 프로젝트에 긍정적인 요인으로 작용하여 분명 도움이 될것을 아주 긍정적으로 봅니다.

위 들어가며 에서 던진 질문. PM은 언제쯤 오픈에 대하여 스스로 신뢰할 수 있을까요 ?
 위 <그림>에서 ⓐ,ⓑ,ⓒ,ⓓ 시점에 프로젝트 Open에 대하여 PM은 신뢰도를 얼마만큼 가질 수 있을까요 ?

Agile 프로젝트 에서는 ⓐ -> ⓑ -> ⓒ -> ⓓ 로 갈수록 오픈에 대한 신뢰(가능성) 계속 높아질것이고 ⓐ 시점만 보더라도 Waterfall 방식보다 훨씬 높을거라 생각해본다.
 이런 그래프게 될수 있도록할 수 있는 팀이 진정한 Scrum 팀이 아닐까 생각 합니다.

¶™ Agile is a culture !

어떤 의사소통이 효과가 높을까요 ?

의사소통의 효과성을 보여주는 그래프입니다.
Agile 방법론의 Daily Scrum Meeting은 위 그래프에서 보여주는 효과적인 의사소통 방법이지요...
그렇다고 해서 Paper에의한 의사소통이 중요하지도 필요 없다는 이야기는 아니라고 생각합니다.
그상황에 맞는 의사소통을 하는게 맞을 것이며, 그중에서도 Face-to-face 의사소통이 효과가 높다는 것이겠지요
예을 들어 아주 복잡한 Business, 알고리즘, 프로젝트의 Architecture 등은 Paper로 잘 요약하여(1page 요약) 공유 한다면 효과적 이겠지요.

Google Creative Lab 메니저 Ji,Lee 에 의해 소개된 오늘날의 통신 친밀도 10단계 입니다.
10 Level 이 Face to face 이고 1 Level 이 트위터(재잘거림) 으로 소개되었네요..

¶™ Agile is a culture !

Ctrl+S 에 숨어있는 가치

Ctrl + S 는 우리가 작업 하면서 사용하는 키보드 조합 키중 많이 사용하는 키 조합중 하나이다.
Ctrl + S 는 주 기능은 자료 저장(Save) 기능이다.
특히 개발시에는 무 의식적으로 자주 사용한다.
(지금까지 코딩한 소스코드를 저장히기 위해서 이다)
요즘은 대부분 통합개발환경(IDE) 에서 코딩을 한다.
여기에 숨어있는 Ctrl + S에서 Agile 방법론의 가치를 잠시 이야기 해보고자 한다.

 = Agile 에서 강조하는 Feedback 과 유사한 숨어있는 가치가 있다.


Agile 방법론(Scrum,Xp 등..)의 특징중 하나는 Feedback 을 강조 합니다.
Feedback은 고객의 요구사항에 대하여 확인한다는 측면에서 프로젝트에서는 아주 중요한 활동이라 생각 합니다.

아래 그림은 주부가 요리중에 맛을 보는 모습 입니다.
고객의 입맛에 맞는 김치찌게(Product)를 만드는 프로젝트라 할때
프로젝트 후반부에 가서 고객에게 김치찌게의 맛을 보게 했을때, 그래 바로 이맛이야~~
보다는  Yes, But(그래 김치찌게가 여기 있군.. 그런데 내가원한 맛이 아닌데) 라고 말할
확율이 높습니다.

고객이 요구하는 맛에 대하여 중간중간 Feedback 을 받아 봐야 고객이 원하는 맛에 접근할수 있습니다.
주부가 중간에 맛을 보는것은 Feedback 과 유사합니다.
(Agile 적용할땐 프로젝트 팀원간 그리고 고객과 지속적으로 피드백을 하는데 문서가 아닌 Working S/W로 함이 중요 하다.)
Ctrl + S는 바로 Feeback 입니다.
개발자는 IDE 환경하에 단지 저장을 하기위해 수시로 키보드를 누르지는 않습니다.
Ctrl + S 누르면 동시에 모든 소스를 Compile을 하여 결과를 Feedback 해줍니다.
(문법 오류, 변수관련 오류, 다른 컴포넌트 참조 오류, 등...)
만약 Ctrl + S 시점에 Compile을 하지 않고 개발이 완료 되었다고 생각하는 시점에 Compile을 한다면...
무척 답답 하겠지요. 개발자들은 그래서 자주 Ctrl + S를 스스로 아주 자주 합니다.

개발자가 개발하면서 Ctrl + S를 지속적으로 하는 이유는 우리가 고객과 Feedback을 지속적으로 해야하는 이유와 같지 않을까 생각 합니다.

¶™ Agile is a culture !

6시그마 - CMMI - Agile 끼리 친할까 ?

뭐니뭐니 해도 6시그마와 CMMI, Agile방법론은 Process나 방법론 분야에서 확실한 키워드라고 할 수 있습니다. 이들 키워드들은 정치적 경제적 환경으로 인해서 비교되고 적대시 되는 경우가 비일 비재합니다만, 이들을 서로 분리하여 적으로 여김을 당한 부류의 내용들이 아닙니다.


다음의 그림은 6시그마와 CMMI, 그리고 Agile 프로세스에 대한 개념을 비유적으로 표현한 그림입니다.





















하늘에서 내리는 비를 프로젝트의 실패를 초래하는 위험요소라고 하였을 때, 6시그마와 CMMI, 그리고 Agile 프로세스는 실패를 막아주는 우산이 됩니다.


Agile프로세스는 우산의 살과 지주가되고, CMMI는 살을 하나로 모아 비를 막아줍니다. 가장 정점의 꼭지에는 6시그마가 존재합니다.


이들은 하나가 되어 우리가 비를 맞지 않고, 맞더라도 최대한 적은 양의 비를 맞도록 해줍니다.
6시그마와 CMMI, Agile프로세스는 만든이가 다릅니다. 6시그마는 산업공학, 다시 말해 경영학도에 가까운 사람들이 만들어낸 방법론입니다.
CMMI는 개발에 가까운 관리자들이 만들어낸 방법론이며, Agile은 개발자들이 만들어낸 방법론입니다.


이런 태생적 차이로 이들은 서로 다르지만 모이면 하나가 됩니다.
CMMI의 대 전제는 "조직 고유의 프로세스가 존재한다."입니다. 조직 고유의 프로세스를 CMMI라는 하나의 통합 프레임워크에 통합시키고 직관적으로 관리가능하게 하고, 최상의 프로세스로 개선시켜 줍니다.


대부분의 실패한 CMMI프로젝트는 CMMI를 통하여 조직에 프로세스를 만드려고 하기 때문입니다.


조직내의 고유한 프로세스는 Agile 개발 프로세스로 충분히 가능합니다.
Agile 방법론으로 각 프로젝트 별로 구성된 프로세스는 CMMI에 의하여 조직자체가 통합적으로 관리하게 됩니다.
물론 TSP/PSP나 RUP등과 같은 기존의 다른 프로세스들도 마찬가지 입니다.
(하지만, 현대사회는 Agility가 중요합니다.) Agile프로세스가 팀이나 프로젝트에서 개인적으로 사용하는 관행을 탈피해야 합니다.


마지막으로, 6시그마는 CMMI레벨 4 이상의 환경에서 정확히 동작합니다. 뒤집어 이야기 하면, CMMI레벨 2,3을 만족하는 조직에서 최적의 퍼포먼스를 낼 수 있습니다.
실제 CMMI레벨 4,5에는 프로세스 영역이 몇개 존재 하지 않습니다.
보잉의 존부씨의 말로는 CMMI개발자들이 레벨4/5환경을 잘 알수 없기 때문이라고 말하기도 하였습니다.


이 부분은 개발이나 관리의 영역이 아닌, 수치화와 유기적인 조직이 중시되는 경영의 영역이 됩니다.

6시그마는 이하 모든 프로세스를 기반으로 완전한 정형적 환경을 구축하게 해줄 것입니다.

Agile 신도분들은    Agile이 좋다는 것을 잘 알고 있습니다.
    좋은것을 자신의 선에서 끝내지 마십시오.
    조직의 도움을 받고 주십시오.

CMMI 신도분들은    CMMI로 모든 프로세스를 정의하려 하지 마십시오.
    개발은 CMMI관련 책에 나오는 것처럼 정형화 되고 쉬운일이 아닙니다.

6Sigma 신도분들은    속임수에 넘어가지 마십시오.
    CMMI로는 볼 수 없었던, 가시적인 통계물을 얻었다고 해서 변하는 것은 없습니다.
    수치화는 가장 보기 좋은 거짓말에 지나지 않습니다.

출처 : tong.nate.com/anythink/


위의 그림이 재미 있네요.

(마지막엔 Agile, CMMI, 6Sigma에 대하여 쓴 소리도 있네요. Bolg에서 그대로 가져온 글이라 판단은 개인에게 맡기며...)

균형된 시각은 중요하다고 생각합니다.^^
Agile이 처음 나왔던 2000년대 초반에는 S/W엔지니어링 진영과 Agile 진영이 싸웠다고(?)합니다.
10년이 지난 지금은 상호 보완적으로 서로의 장점을 수용하는 모습을 취하고 있습니다.
수동적+획일화된 거대한 프로세스 가 2세대 였다면 앞으론 능동적+프렉티스 중심의 3세대 프로세스에
주목 해야한다 고 합니다.

Link : http://www.dt.co.kr/contents.html?article_no=2007021602012369631001

¶™ Agile is a culture !

닭(chiken)과 돼지(pig) 이야기

"스크럼(Scrum)에서는 팀원과 비 팀원의 역할을 돼지와 닭 이라고 이름 붙였다. 팀원은 돼지(자존심 접었다!)고 비 팀원(관리자, 지원, QA 등)은 닭이다. 이 용어는 농장의 동물이 모여서 식당을 연다는 우화에서 나왔다. 아침 메뉴로 베이컨과 계란 프라이를 내놓으려고 할 때, 닭은 단순히 계란을 하나 내며 참여하는 수준이지만, 돼지는 자기 살을 내어주는 헌신인 것이다.

오직‘돼지’만이 스크럼 스탠드 업 미팅에 참석하는 것이 허용된다."

- 애자일 프랙티스 226쪽에서 -

닭 : 우리 식당 같이 해보지 않을래 ?
돼지 : 좋은 생각이야. 그런데 그 식당 이름은 뭐라고 하지 ?
닭 : "햄과 달걀“ 이라고 부르는 것이 어떨까!"
돼지 : 글쎄.. 좋은 생각이 아닌 것 같아. 난 희생해야 하는데 넌 단지 관여만 하려고 하잖아!

이 우화는 Scrum 및 XP 등의 Agile 방법론에서 중요하게 중요하게 생각하는 Team Work에 관한 이야기다.

프로젝트에 돼지와 같이 희생정신을 가진 팀원이 있을때 프로젝트의 성공 가능성은 그많큼 높겠지요.

돼지와 같은 팀원을 바란다면 PM 또는 프로젝트 에서의 리더는 동기부여 및 보상을 함께 고민도 필요 하겠지요.

¶™ Agile is a culture !