3. 준비는 철저하게 : 선행조건
Measure twice , cut once,
Upstream prerequistes
목수들 사이에서 전해지는 속담에 " 자로 재기는 두번 하고 자르기는 한번 하라" -p66
구현과 설계에 대한 이야기가 아닐까? 그다음 upstream 은 어떻게 번역해야 될까?
prerequiste 이건 만으로 선행이란 의미는 들어가는데 upstream에 조건이 들어간다는 걸까?
번역이 잘못되어 있다는 게 아니라. 저자가 이야기 한 바를 정확히 알고 싶어서 써보는 거임다.
3.1 선행조건의 중요성
꽤 동의하고 있는 주제이다. 설계를 어떻게 하는가에 따라서 구현에 막히는 부분이 줄어들고,
수정 비용이 절감한다는 것은 누구나 ...
그렇기에 PM의 협상력이 중요하다. 된다고만 밀어부치는게 아니라 구현 가능한 것과 불가능한 것, 어려운 것 (구현하더라도 고객 만족이 되기 힘든 사항) 등등을 잘 정리해서 어필을 잘해야 된다는
한국적 사고인지는 몰라도 그렇다고 본다.
[경험담]
1년 프젝중 6개월 프젝 경험으로 이야길 해보면, 고객이 첫 시스템 구현을 2년 동안 했기에 정확히 알고 있는 상황이라 오히려 XP 방법론을 사용하면 괜찮겠더라 싶었다.
그런데, PM은 3개월 만에 그만두고, PL의 요구사항 정리는 없고, 그리고, 프리랜서의 사고에 막혀 힘들었던 적이 있다. 1차 오픈 후 회사내 새로운 프젝때문에 빠져 나온 것에 행복감을 느꼈다.
1년중 6개월을 하고 나왔음에도 만족감도 없이 *_* 하지만, 그 기간에 피플웨어를 한번 더 읽고 내가 PL이란 가정하에 준비하곤 했다.
1차 오픈일때는 최소한의 요구만 수용하고 완료일에 맞춰 구현 가능한 개발이 이루어져야 되지 않을까? 개발의 연속성은 없고, clear case (cvs 의 IBM 버전정도로 생각하시면 되겠습니다.) 등과 같은 툴은 개발하면서 이용도 못하고, 역시나 수작업으로만 ... 우띠 했다~~ tivoli도 사용해보긴 했군!
가장 큰 책임은 여하튼 PM이란 걸 다시금 느꼈다.
10억 단위의 큰 프젝인 경우에는 분명 PM의 선경험이 가장 큰 도움이 될 것인데, 그리고 인화 란 부분도 역시나 실력으로 이끌어주었다면... 여기까지.
steve 책의 장점은 근거의 자료 제시이다.
선행 조건을 착실히 할 경우 비용이 줄고, 거기에 한꺼번에 개정비용이 들어가지 않는다는 잇점이 있음을 도표로 보여주고있다.
3.2 소프트웨어 종류 결정
- 비지니스 시스템
예) 인터넷 사이트, 창고관리, 정보관리 , 봉급 지불 시스템
- 미션-크리티컬 시스템
내장형 소프트웨어, 게임, 패키지소프트웨어
- 내장형 라이프-크리티컬 시스템
항공 전자 소프트웨어 운영체제, 의학 소프트웨어
대상이 다르면 적용 방법도 다름을 보여 주고 있다.
3.3 문제정의의 선행 조건
steve 님이 말하는 첫번째 선행 조건은 시스템이 해결해야 하는 문제를 명확하게 기술하는 것이다.-p82란 부분이다.
그다음에 이런 말이 있습니다. 문제 정의는 가능한 해결책에 대해서는 언급하지 않고 문제가 무엇인지를 정의한다.
공감하는 부분입니다.
3.4 요구 사항의 선행 조건
요구 사항에 오류가 없다는 확신이 들었을 때 개발을 시작함으로써, 개발을 시작하고 난 후의 변경 사항을 최소화하는데 도움을 준다.-p84
25% 정도의 요구 사항 변경을 경험한다고 한다.(Boehm 1981;Jones 1994;Jones 2000)-p86
3.5 아키텍처 선행 조건
'책(BooK)' 카테고리의 다른 글
| 왓슨이 들려주는 DNA 이야기 - 모르는 것은 모른다고, 모르면 알려고하자! (0) | 2005/09/28 |
|---|---|
| Linux Administration - 차례가 마음에 들다. (1) | 2005/09/24 |
| [CC2E] 3. 준비는 철저하게 : 선행조건 (0) | 2005/09/12 |
| [CC2E] 2. 소프트웨어 개발의 이해를 돕기 위한 비유 (0) | 2005/09/12 |
| [CC1E] 4. 루틴의 작성 단계 (0) | 2005/09/06 |
| 우리 아이 인재로 키우는 최성애 조벽 교수의 HOPE 자녀교육법-서로다름 (0) | 2005/09/05 |
