메모 : si, agile 생각 공유

애자일(Agile)과 SI 프로젝트, 해결해야 하는 질문들, 잊어서는 안되는 원칙들

'SI 프로젝트에 Agile 을 적용하기 위해서는 어떠한 문제점을 고려해야 하는지'란
본문에 나열되어 있던 질문에 나름대로 정리해 보기.

1. 방법론과 관계없이 모든 요구사항을 관철시키려고 하는 고객을 어떻게 설득할 것인가?
   - 계약과 비용한도 내에서라면 수용.
2. 팀 맴버 구성 비율을 어떻게 가져갈 것인지?
   - 8명 이내. 종(커뮤니케이션비용)과 횡(context분리비용)이 조화를 이루는 조직구조 고민.
3. 기존 방법론에 충분히 익숙한 프로젝트 리더 들의 사고 전환을 어떻게 할 것인가?
   - 방법 제시와 강요는 전혀 효과 없음.
   - 이유있는 합당한 성과목표와 측정으로 유도.
4. 앉아서 '아~ '하고 입만 벌리던 고객을 어떻게 참여시킬 것인가?
   - '왼손은 거들뿐'으로 출발. 자신이 거든 결과로 나아지고 있다는 것을 느끼게 하기. 칭찬하기.
5. 타협하고 싶어진다. (자동화된 Test는 어려우니까 빼고…etc)
   - 어느정도(타협비용 효율정도로 판단) 타협은 수용.
6. Agile 에 대한 개발자들의 오해와 마음가짐
   - agile을 언급하지 않는다. stealth-mode pattern참조
7. 기법 활용 미숙 (User story ? Story point?, 스크럼 미팅? CI?)
   - 거드는 누군가가 필요(코치)
   - 새로운 기법이 미숙하다면 기존기법을 활용.
8. 외부 감리는 어떻게 설득할 것인가?
   - 감리기준을 어떻게 만족하는지 보이기(법령,지침,표준을 이해할 필요)
   - 감리기준에 그다지 벗어나지 않고 합리적이라면 수용가능한 결과 획득 가능.
9. SI에는 분석 설계가 끝난 다음에 개발자가 투입되는 경우가 많습니다. 하지만, 이는 대부분의 Agile 방법에 상치됩니다.
   - 계약형태와 경직된 계획을 정의하는 것이 원인
   - 선행설계 형태로 받아들이는 것도 나쁘지 않음..(커뮤니케이션 비용에 문제만 없다면..)
10. 초급 개발자들이 많은 프로젝트는 어떻게 해야 하나요? 문제를 일으키는 개발자가 있을 경우에는요? 그리고, 인원교체가 쉽지 않은 경우에는요?
    - 초급 개발자가 많은 것은 문제가 되지 않음.
    - '문제를 일으키는 개발자' -> 그런 상황으로 이끈 환경이 대부분 문제.. 원인파악해서 해결.
    - 인원교체하지 않고 해결하는 것이 베스트.(수행능력에 문제 있거나 성격상 결함이 있더라도..) 
11. 혹시, 사내에서 필수로 사용해야 하는 프로젝트 프로세스나 시스템(진척도,공정관리 등등)들은 어떻게 할까요? 예외로 할까요?
    - 해당 프로세스나 시스템 담당자와 협의 하에 경량화시도하고 수용.
    - 회사차원에서 필요한 것을 프로젝트팀의 임의판단(효율성,성공가능성)만으로 무시할 수 없음.
12. '전체비용절감'을 생각하는 Agile에서 봤을 때, 배포전까지의 비용이 오히려 예전보다 높을 수 있습니다. 구축만 하고 빠지는 프로젝트의 경우 그걸 감당하려는 PM이나 팀을 만들 수 있을까요?
    - 비용이 낮을거 같은데..
    - 그걸 감당한다..란 의미를 잘 모르겠음