Page History
...
각 단계는 다음 단계에 입력을 주지만, 피드백은 없다.
폭포수 모델 세부논의
1-착수
- 단계 : 상위 경영진 수준에서 수립하는 전략 계획이나 사업을 진행하면서 나온 결과를 토대로 시작할때가 흔하다.
- 주의점 : 이 단계에서 컴퓨팅 전문가의 도움이 필요없다고 결론 짓는다. 대부분 나중에 이것 때문에 문제가 발생한다.
2-요구사항 수집및 분석
- 단계 : 엔지니어링 생명주기의 시작부분으로 시스템명서,설계문서,인터페이스 요구 명세,개발 계획등으로 구성된다.
- 주의점 : 사용자를 위해 무엇을 해야하는지 설명이 되지만, 시스템이 어떻게 작동될지에대해 관심이 없다. 어떻게는 다음단계인 기초설계에서 이야기가 될수 있다. 여기서 문제가 발생하는데 '무엇'과 ''어떻게' 를 분리해서 별도의 단계로 나누는것이 자연스럽지 않기때문이다.
3-기초설계/상세설계
- 단계 : 기능 명세는 요구사항 분석의 '무엇'과 기초설계 단계의 '어떻게'를 연결하는 다리 구실을 한다.
- 주의점: 비즈니스 시스템의 개발자는 상세 설계 때 무척 바쁘다. 너무 바빠서 여러 작업들이 소홀히 되거나 아예 무시되곤 한다. 기술 문서작성자가 이 시점까지 참석하지 않았다면 많은 문서가 비슷한 운명을 겪는다. 사용자 메뉴얼은 완전하지 않고 프로그래머 메뉴얼은 아예 작성되지 않는다.
기초 프로그램 계획단계가 포함될수 있으며
WBS(Work breakdown structure) 작성이 진행될수도 있다. WBS는 워터폴모델의 계획을 가시화및 추적할수 있으며,
WBS를 작성하고 있다고하면 하향식구조 개발방법 즉 워터폴모델을 따르는것이다.
4-코딩
- 단계 : 코딩단계는 앞단계와 결합할때도 있지만,다음 단계와 결합할때도 있다.
- 주의점 : 불행히도 코드 작성은 사소하게 보일 때가 흔하다. 하지만 이 단계에서 시스템의 구성요소를 전부 만든다.
...
- 프로토타이핑 : 시스템이 어떻게 작동하는지 설명하는 '모델'을 만드는 프로세스
- 즉각모델 : 외부 관찰자에게 모든활동이 동시에 끝나는 것처럼 보인다. 문제해결 분석이 되지 않는 고약한 문제를 해결 할때 유용할수 있다.
- 사시미 : 폭포수 단계를 4단개로 줄여, 유연성을 위해 전통적인 단계들을 약간씩 겹치게함 (회 여러 조각이 앞뒤로 약간씩 겹치는데서 유례, 상위단계 피드백이 가능해지며 유연성이 생김 스크럼의 실질적인 기초개념에 기인 )
- 스크럼 : 사시미 방식의 4단계조차 한단계로 줄여 겹치게함, 럭비에서 공을 차지하려고 상대팀을 앞으로 밀어야하는데 이때 사용되는 팀의 기본 대형(스크럼)에 유례
- 투맨접근-수갑채우기 : 스크럼 2인용 버전 , 최종사용자와 프로그래머를 함께 일하게하는 방식
- 원맨접근-해킹 : 스크럼 1인용 버전 , 해결할 문제에대한 상세한 지식을 프로그래밍 지식이나 기술과 결합
...
- 사시미 : 개발속도와 유연성을 중요시한 일본에서 폭포수를 경험하면서 만든 모델(하향식절차를 간소화하고 약간씩 겹치게만듬, 개인적으로 애자일 인식의 시초라고 보여집니다. )
- 스크럼 : 사시미에서 한번 더 나아가, 하나로 뭉침
중요결정과 책임이 점점 수평화되어 갑니다.
하향식접근 방식이 아닌, 중첩이 되며 더 많은 피드백및 수정을 할수있게됩니다.
피드백을 주고받으며 완성해나가기때문에, 훨씬많고 적은 단위의 일이 계속 발생할수 있습니다.
폭포수에서 스크럼에 근접할수록
- 인접구간의 협력및 커뮤니티 강화
- 다자학습 약한 통제
- 피드백을 통한 인접단계 수정가능
- 폭포수의 단계 2~3단계의 경계를 개개인이 할수 있어야 하기때문에 수준높은 전문성이 요구된다 ( 개인 생각 )
- 여기서 전통적인 목업 그리는 기획자의 역활은 존재하지 않는다. ( 스크럼에서 모두가 분석가이자 기획자이다. / 심지어 초기단계에서 목업을 그리는것을 아주 경계한다. , 개인 경험 )
애자일 인식의 뿌리
30년전 고서 "Wicked Problems,Righteous Solution" 에서 이야기하는것들을 압축하였으며
...