2월 16, 2012 
Agile 방법론에 대해 글을 올리다보면 제게 Agile은 소스통합, 코드리뷰 등을 포함하여 technical하게 중요시해야한다고 이야기하는 분도 계셨는데요. 맞는 말씀이긴 합니다만, 제가 바라보는 시점은 좀 더 큰시각으로 프로젝트관리자가 갖춰야하는 PMBOK/42지식체계를 어떻게 Agile로 승화하여 적용시키느냐입니다. 우선 이러한 General Management 가 확립한 후 Technical Management/ Governance 로 접근해야지요.
물론 개발자 분들께는 XP라든가 FDD 가 좀더 현실적이겠지만, 이러한 Management Skill을 익혀야 개발PM으로 혹은 개발리더로써 역량을 발휘할 수 있지 않을까요? 중요한것은 Manifesto 및 12원칙의 핵심을 지키기위해, 현재 기업/프로젝트의 AS-IS 환경을 어떻게 TO-BE 모델을 잡아 단계적으로 적용하느냐입니다.
이러한 관점으로 Agile을 PMBOK과 연계하여 진행하는 기업 Agile 체화 강의/멘토링을 하면서 받은 피드백을 정리해 봅니다. (다들 IT PM분야 5-10년차 이상 분들의 피드백입니다.)
시간이 날때마다 주제별로 상세 설명드려볼께요. 다양한 댓글 의견 환영합니다.
[비유/기존프로세스와다른점]
1. 소화제 (소:소통, 화:화합)
2. 실시간 교통정보 시스템이 반영된 차세대 3D 네비게이션
3. 과거 진도율 체크가 완료여부관점으로 변환, 과거 요구사항 프리징이 요구사항의 유동적 적용이 차별화
4. 기존이 What/관리에 초점을 맞추었다면, Agile은 구체화/R&R/Daily확인에 초첨을 맞춤. 결국 HOW였음
5. 기존 산출물이 형식적인 면이 강한데, Agile은 참여를 통한 의사소통 증대를 통한 실용성면이 강함
6. 교훈의 공유에 동감 함
7. 실패확율을 줄이기 위한 Tool
8. 기존 PMBOK/프로젝트관리기법과 Agile에 차이점 대해 이해
[사람/전문성/자발성/인간존중]
9. Agile Process의 중요성과 “갑”의 Engagement가 중요함을 깨달음
10. 수평적 조직, 자발성 중요, 선성설로 우수한 팀원이 기본이 되어야 함,
11. 자발적인 참여를 위한 팀원까지 Level-up 이 필요해 보임
12. PM이 현업 능력 부족시 Agile 활용하면 좋을 것 같음 (의사소통기반 팀원 위주 진행이기때문에)
13. 참여자의 자율성이 중요함
14. 고객/요구 프로젝트 수해자간 의사소통
15. 요구사항의 수용, 변동 %
16. 민주화로 집단 토론 유발을 통해 사용자의 자발적 관심도 향상 및 참여 유도
[소통/협업/화합]
17. Collaboration, 작동SW, 주기적인도, 수평적 대화/적용 기법이 중요함을 깨달음
18. Visualization 의 시각화 중요성 및 유용성 확인 함
19. Virtual Team에서의 독립성 및 Dashboard의 중요함을 깨달음
20. Burndown-chart의 시각적 중요성과“갑”의 요구사항의 적절한 반영이 인상적
21. 참여/창의성/소통을 중요시 여김
22. 소규모 프로젝트에서 유리
Project Research 
좋은글 잘 읽었습니다.
저도 Agile 을 기술적으로 보기보다는 구성원간 소통을 근간으로 하기 때문에 무엇보다 팀원의 자발적인 참여와 자율성이 중요한점을 동감합니다. 때문에 스크럼마스터가 팀원에게 적절한 동기부여를 하는 영역에서 많은 노력을 기울여야하는데 쉽지 않네요.
동감합니다. 팀원의 자발적 참여와/자율성은 회사/조직의 분위기와도 상관되는 것 같습니다. 물론 가장 훌륭한 팀원은 self-motivation 되어서 스스로 하며, 자체 전문성을 가져야 겠지만, 이런 상황은 이상적인 거잖아요? .. 애자일 방식은 어느정도 수준되는 팀원들이 모여서 해야 시너지가 나는 것은 맞는 것 같습니다. 완전 초보자는 다른 방식을 취해야할 것 같구요.
“업무가 어느정도 규정된 프로젝트의 경우(Earned Value 중심)는 PMBOK 관점으로 접근하고 새로운 제품을 완성해가는 경우(요구사항 및 Issue 중심)은 Agile을 적용하는 것이 좋습니다. ” 라는 설명은 어떠신지요.
좋은 설명문구네요. 감사합니다. 저도 이형록님과같이 보통 전통전 산업 (항공/건설/우주/선박/제조..) 는 전통방식대로 WBS/EVM으로 관리하는 것이 맞고, IT Product/R&D는 애자일이 효율적인 방법 중의 하나라고 생각됩니다.
비전문가인 제가 읽기에는 어려운 글이네요. 용어가 무슨 뜻인지 모르겠습니다 ㅠㅠ 교육에서도 이제 학생의 참여, 소통, 협업 이런 것들이 중시 되고 있는데 제가 참고할만한 자료가 없을까요?
김재동 선생님이 선구자이시잖아요. 칸 아카데미 영상 추천드려요. (이미 보셨을것 같은 느낌이…)
잘 모르는 식견이지만, PM보다는 PL역할로서 팀원들과의 수평적 소통으로서 업무를 리드하고 갑과의 정기적 일정을 가지고 요구사항을 반영해가는 부분에 있어 납기일이 정해진 프로젝트에서 얼마나 요구사항을 반영하고 완성도 있는 프로젝트를 할 수 있을까 의문이 생기기도 합니다.
우리나라 PM등이 약한 것이 요구분석과 계획/범위 확정 아울러 이를 기반으로한 베이스라인의 관리 통제 부분이에요. 이 과정에서 발생하는 이해당사자와의 소통과 협의/합의의 도출을 잘 이끌어내야하는데, 우린 대부분 부실한 설계를 PM이 커버해야하는 사후 조치에 가깝죠.
합의된 베이스라인이라도 잘 관리하는 것이 필수에요.