2 Rapid-Development Strategy #1111
Description
제2장 쾌속 개발 전략
더 빨리 개발하려는 사람이 가장 쉽게 빠지는 함정 중 하나가 한 가지 일정위주 개발법에만 지나치게 치중하는 것이다.
일정위주 개발법은 일정을 최대한 단축하기 위해 해야 할 활동의 일부일 뿐이다. 이 장점을 활용하기 위해서는 기반구조가 필요하다.
사례 연구 2-1. 명쾌한 전략없이 추진한 쾌속 개발
사용자 인터페이스 동결 시점에 코트 통합을 시도, 하지만 이 시기가 최종 기한 전날 오후 2시였음
오류가 너무 많아 이 오류를 수정하고 시스템이 돌게 하는데 2주의 시간이 소요.
하지만 테스트를 할 수 없을 정도로 시스템이 죽어서 안정시키는데 한 달의 시간이 소요.
여기서 총 프로젝트 기간 10개월 중 2주만 남음.
결국 소프트웨어를 완성하는데 15개월이 걸림.
2.1 일반적인 쾌속 개발 전략
쾌속 개발은 다음 전략 네 단계로 이룰 수 있다.
- Avoid classic mistakes.
- Apply development fundamentals.
- Manage risks to avoid catastrophic setbacks.
- Apply schedule-oriented practices
Figure 2-1. The four pillars of rapid development. The best possible schedule depends on classic-mistake avoidance, development fundamentals, and risk management in addition to the use of schedule-oriented practices.
쾌속 제품 개발은 제품을 시장에 더 빨리 내보내려는 임시 해결책이 아니다.
반드시 바닥부터 순서대로 쌓아야 하는 전략적 방법이다. - 프레스톤 스미스, 도널드 라이너튼, 제품 개발 기간 절반으로 줄이기
그림의 첫 세 기둥이 제대로 지탱하지 못하면 최단 일정은 위태롭다.
- 프로젝트 초기에 품질 목표를 낮게 잡으면 후반에 결함을 고치느라 시간을 낭비하는 대가를 치르고 프로젝트는 지연된다.
- 구현 전에 설계한다는 개발 기본을 빼먹는다면, 개발 도중에 개념이 조금만 바뀌어도 프로그램은 무너지고 결국 지연된다.
- 위험을 관리하지 않으면 출시 직전에야 중요한 하청 업체의 일정보다 3개월이 늦는다는 문제를 알아채고 일정은 지연된다.
이 얘기는 일정 위주의 개발법이 없이도 최단 일정을 달성할 가능성이 있다는 얘기다.
일정위주 개발법만으로 해결하려 한다면 어떻게든 한 번은 달성할 수 있어도 다음에도 그렇게 하기엔 어려울 것이다.
2.2 사차원에 걸친 개발 속력
소프트웨어 프로젝트는 사람, 공정, 제품 기술이라는 네 가지 중요한 차원에서 움직인다.
- 사람은 빨리 일하기도 하고 천천히 일하기도 한다.
- 공정은 지렛대 구실을 하기도 하고 난관을 만들어 내기도 한다.
- 제품은 의문의 여지가 없도록 빈틈없이 정의할 수도 있지만, 제작자의 수고를 무산시킬만큼 허술하게 정의할 수도 있다.
- 기술은 개발 노력을 줄이기도 하고, 최선을 다한 시도를 물거품으로 만들기도 한다.
소프트웨어 개발 회사는 초점을 맞추기 원하지 않는 차원을 고정시켜 바라보는 경향이 있으며
이런 태도가 프로젝트 계획, 일정 계획에 실패하는 한가지 이유가 된다.
사람
피플웨어(peopleware)에 대한 연구 결과는 15년에서 20년에 걸쳐 꾸준히 쌓여 왔다.
연구 결과를 넘어 일반적인 결론을 도출하면 다음과 같다.
첫째, 피플웨어가 다른 어떤 요인보다 생산성과 품질에 크게 영향을 미친다는 사실을 확신할 수 있다.
나사 소프트웨어 공학 실험실 연구원들은 기술이 답이 아니라고도 결론을 내렸으며
효과적인 방법은 개발자의 잠재력을 끌어내는 개발법이다.
생산성 향상에 진지한 회사라면 동기부여, 팀워크 인재 선발, 재교육과 같은 피플웨어를 먼저 고려해야 한다.
피플웨어는 다른 세 가지 치원보다 중요하다.
- 팀 프로젝트에 맞는 인재 선발
- 최고 재능
- 적합한 임무
- 경력 관리
- 팀 조화
- 부적격자 배출
- 팀 구성: 프로젝트 크기, 제품 특성, 일정 목표에 맞게 팀을 꾸려야 한다.
- 동기부여: 지시를 받지 않는 이상 저녁과 주말을 포기할 수 있는 이유는 동기 뿐이다.
공정
소프트웨어 개발에서 공정은 관리 방법론과 개발 방법론 모두를 포함한다.
공정은 사람만큼 개발 속력 향상에 크게 기여한다.
일부 공정은 심하게 경직되었거나 지나치게 관료적이기는 하다.
공정을 오용할 수 있다는 이유로 공정으로 얻을 수 있는 이익을 얕봐서는 안된다.
- 재작업 회피: 공정을 통해 재작업 시간을 아낄 수 있다.
- 품질보증: 품질이 합격할 만한 수준인지 확인, 최소 시간과 비용으로 고칠 수 있는 단계에서 오류를 발견하려는 목적
- 개발 기본: 소프트웨어 공학 표준 기법으로 프로젝트가 제어 불능이 되는 상황은 막을 수 있다. 쾌속 개발의 목적은 결함 방지고 이는 소프트웨어 공학의 기본 원리이다.
- 위험 관리: 결험 회피에 초점을 두는 개발법
- 자원 목표설정: 생산성을 고려한 사무실, 기간확정 개발, 정확한 일정, 자발적인 초과근무가 일일 업무량을 최대한 향상하도록 돕는다.
- 생명주기 계획: 위험이 큰 프로젝트는 위험위주 생명주기 모델로 요구사항이 애매하다면 점진적인 생명주기 모델이 가장 효과가 있다.
- 고객 중심: 소프트웨어 개발은 전체 해야할 일의 절반이며, 나머지는 고객이 어떤 제품을 원하는지 깨닫도록 돕는 일이어야 한다. 재작업을 피하려면 처음부터 고객과 같은 입장에서 보는 방법이 가장 바람직하다.
제품
제품 크기와 특성에 집중하면 일정을 단축할 엄청난 기회가 생긴다.
제품 기능을 줄일 수 있다면, 일정을 단축할 수 있다.
외형, 성능 특성, 품질 특성이 유연하다면 기존 컴포넌트를 이용해 제품을 조립하여 고객맞춤 코드량을 최소화할 수 있다.
- 제품 크기: 제품 크기를 축소하면 개발 속력을 불균형적으로 빠르게 감소시킬 수 있다. 필수적인 기능에만 집중해서 크기를 바로 줄일 수 있다.
- 제품 특성: 성능, 메모리 절약, 견고함, 신뢰성 같은 목적은 그렇지 않은 제품보다 오래 걸린다.
기술
효율적인 도구의 사용은 개발 속력을 빠르게 향상시킨다.
효율적으로 도구를 선택하고 도구에 관한 위험을 관리하면 쾌속 개발을 주도할 수 있다.
상승 작용
사람, 훈련, 업무환경에 대한 투자 비용이 Low to Medium으로 가면 이익에 비려해서 증가한다.
그런데 Medium to High로 가면 생산성이 2배, 3배로 치솟는다. (Olsen 1995)
소프트웨어 공학 기법도 상승 작용을 불러 일으킬 수 있다.
코드 표준을 세우면 다른 프로젝트의 코드를 재사용하기 쉽게 한다.
재사용 가능한 컴포넌트를 관리해서 코드 표준을 만들면 같은 효과가 있다.
설계 검토와 코드 검토를 통해 코드 표준과 재사용 가능한 컴포넌트에 대한 지식을 공유해서 재사용이 성공하도록 설계와 코드 질을 향상시킬 수 있다.
2.3 일반적인 빠른 개발 분류
표 2-1 일정 위주 개발법의 특성
| 개발법 | 일정 | 비용 | 제품 |
|---|---|---|---|
| 보통 개발법 | 보통 | 보통 | 보통 |
| 균형있는 효율적 개발 | 보통보다 나음 | 보통보다 나음 | 보통보다 나음 |
| 일정을 강조한 효율적 개발 | 보통보다 훨씬 나음 | 보통보다 다소 나음 | 보통보다 다소 나음 |
| 전면적인 쾌속 개발 | 가장 빠름 | 보통보다 나쁨 | 보통보다 나쁨 |
효율적인 개발
표 2-1에서 제시한 둘째 방법을 효율적인 개발이라고 부른다.
그림 2-4를 통해 최단 일정을 떠받치는 첫 세 기둥을 결합한 개발법이다.
대다수의 프로젝트에서 효율적인 개발이란 비용, 일정, 제품 특성을 분별있게 최적화하는 활동이다.
Figure 2-4. Efficient development. The first three steps in achieving the best possible schedule make up "efficient development." Many project teams find that efficient development provides all the development speed they need.
효율적인 개발 없이 일정위주 개발법으로 성공할 가능성은 불확실하다.
Figure 2-5. The road to rapid development. From where most organizations are now, the route to rapid development follows the same road as the route to fewest defects, maximum user satisfaction, and lowest development costs. After you reach efficient development, the routes begin to diverge.
효율적인 개발을 강조하는 또 다른 이유는 회사 입장에서 효율적인 개발과 일정 단축으로 가는 길이 동일하기 때문이다.
그림 2-5에서 효율적인 개발에 도달하고 나서야 길이 갈라지기 시작한다.
그래서 현재 위치를 고려해 개발팀은 효율적인 개발로 가는 길을 택하는 편이 낫다.
최단 일정에 가까운 효율적인 개발
효율적인 개발을 하면서 짧은 일정을 달성하려면 개발 속력을 높이고, 일정 위험을 줄이고, 진행상황 가시화를 높이는 데 치중하는 개발법을 선택한다.
속력과 예측성을 얻는 대신, 비용과 제품 기능면에서 약간은 희생을 감수해야 한다.
효율적인 개발이라는 기반에서 시작한다면 보통 보다는 좋다.
전면적인 쾌속 개발
최대한 열심히 지혜롭게 일하고도 비용을 늘이거나 기능을 축소하거나 제품 끝마무리를 포기해야만 할 때가 있다.
인력을 추가해 일정 25%를 줄일 수 있지만 의사 소통과 관리 부하가 증가하므로 팀 크기를 75% 키워야 한다.
일정을 줄이고 팀 크기를 키울 경우 프로젝트 비용은 일반 프로젝트보다 35% 증가한다.
전면적인 쾌속 개발은 커다란 결정이다. 일정 위험이 증가하고, 비용과 제품 기능 중 하나 혹은 둘 다 희생해야 할 수도 있다.
이런 희생을 받아들이는 프로제트는 없으므로 어떤 형태로 하든 효율적인 개발을 선택하는 편이 훨씬 낫다.
2.4 어느 차원이 가장 중요한가
각 프로젝트는 각기 다른 요구사항이 있다.
그러나 핵심은 바꿀 수 없는 차원의 한계를 인정하고 다른 차원을 강조해 일정을 줄이는 전술을 선택해야 한다.
예로 자동차용 연료주입 시스템과 내부 비즈니스 프로그램을 개발하는 경우는 차원이 다른 제약이 있다는 것이다.
어느 차원에서 최고의 이익을 얻을 수 있는 지 결정한다면 쾌속 개발로 가는 성공길이다.
2.5 대안으로 쓰이는 쾌속 개발 전략
최고 인력을 고용하고, 완벽한 헌신을 요구하며, 거의 완전한 자율을 허용하고, 극단적일 정도로 높은 동기를 부여해서
사람이든 프로젝트든 끝장이 날 때까지 주당 60, 80, 100시간을 일하는 방식이 이 방법의 특징이다.
이런 약속은 투지, 땀, 결단력을 통해 이루어진다.
이 방법은 마이크로소프트의 윈도우즈 NT 3.0과 데이터 제너럴의 이글 컴퓨터 같은 주목할 만한 성공을 가져다 주었다.
팀을 작게 유지해 의사소통, 조정, 관리 부하를 감소시키고 위험을 제대로 인식해 조금만 자제해서 수행하면 이 방법은 성공적일 수 있다.
불행하게도 이 방법을 주의깊게 수행하는 경우는 거의 없다.
응급 처지법이라서 많은 문제가 있기 때문이다.
이 방법에 대한 비판으로 아래 내용들을 정리한다.
성공 아니면 실패
원하는 기능을 얻지만 제대로 된 게 아닐 수 있다. 품질 목표도 불명확하다. 제품 특성을 제어하기가 어렵다.
장기적인 관점에서 동기유발 문제를 일으킨다
처음에 개발자들이 열성적으로 하지만 해야할 일들이 많다는 걸 알게 되면 초과 시간을 쓰게 된다.
초과 시간을 써도 약속한 일정을 맞추는데 실패하고, 실패를 인정함에 따라 사기는 저하된다.
한번 열정을 쏟았다가 실패하고 나면 추가 약속을 하지 않고 초과근무를 꺼리게 된다.
약속을 하는 척 하게 되면 프로젝트 계획이나 제어는 불가능해진다.
예측 불가능하다
한번은 성공해도 그 다음에도 성공한다는 보장은 없다.
프로젝트 후에 생기는 인력 손실 또한 극복하기 쉽지 않다.
프로젝트 평가를 통해 살펴보면 항상 대규모 이직이 뒤다른다는 사실을 발견한다.
전문개발회사가 아니면 힘들다
미친듯이 구현하기 개발은 조정, 협동 계획보다 개인적인 영웅심에 근거하고 있기 때문에
관련자들이 프로젝트 진행상황을 볼 수 없고 통제할 수도 없다.
빠르게 개발에 성공하더라도 사전에 프로젝트가 얼마나 걸릴지 끝날 때 까지 알 방법이 없다.
속력 이점을 얻었어도 개발팀과 조율이 필요한 다른 테스트, 문서, 마케팅 팀이 계획을 세울 수 없다는 단점이 있다.
개발팀에 믿을 만한 일정을 얻을 수 없어 개발팀과 대립하게 된다.
소프트웨어 부서에 이익이 되는 방법이 반드시 전체 프로젝트에 이익이 된다고 할 수 없다.
터무니없는 인력 낭비다
개발자들은 프로젝트를 끝내기 위해 가족, 취미, 자신의 건강도 버린다.
비즈니스 소프트웨어를 개발하기 위해 이정도 희생을 해야할 이유는 없다.
표 2-2에서 미친듯이 구현하기 개발과 이 책에서 제시하는 방법의 차이점을 정리한다.
[표 2-2] 미친듯이 구현하기와 이 책에서 제시한 방법 비교
| 미친듯이 구현하기 | 이 책에서 제시한 방법 |
|---|---|
| 지지자는 개발 시간에 있어 즉각적으로 놀라운 향상을 주장한다. | 지지자는 즉각적으로 적당한 향상과 장기적으로 큰 향상을 주장한다. |
| 구현 지식 외에는 전문적 지식이 거의 필요없다. | 구현 지식 외에도 상당한 전문적 지식이 필요하다. |
| 고위험: 효율적으로 수행해도 실패한다. | 저위험: 효율적으로 수행하면 거의 실패하지 않는다. |
| 남들이 극단적이고 튄다고 한다. | 남들이 보수적이고 따분하다고 한다. |
| 스스로 모든 것을 바쳐 일한다고 느낀다. | 스스로 열심히 일하는 것 같지 않다고 느낀다. |
| 인력을 엄청나게 낭비한다. | 인력을 효율적이고 인간적으로 사용한다. |
| 가시성이나 제어력을 제공하지 못한다. 해봐야 한다. | 원하는 만큼 가시성과 제어력을 제공하도록 조절이 가능하다. |
| 이 개발법은 소프트웨어 역사만큼이나 오래되었다. | 이 개발법 중 핵심 부분은 15년 이상 성공적으로 사용해 왔다. |
출처: Rewards of Taking the Path Traveled(Davis 1994)
미친듯이 구현하기 방법은 엄청난 희생을 보장하지만, 결과를 보장하지는 않는다.
최고 개발 속력을 목표로 한다면, 효율적인 개발로 눈을 돌려야 한다.
읽을 거리
다음 책 세 권은 소프트웨어 개발에서 피플웨어 접근방식에 대한 정보를 제공한다.
- DeMarco, Tom, and Timothy Lister. Peopleware: Productive Projects and Teams. New York: Dorset House, 1987.
- Constantine, Larry L. Constantine on Peopleware. Englewood Cliffs, N.J.: Yourdon Press, 1995.
- Plauger, P. J. Programming on Purpose II: Essays on Software People. Englewood Cliffs, N.J.: PTR Prentice Hall, 1993.
다음 책 세권에서 첫번째는 조직 차원에서, 두 번째는 팀 차원에서, 마지막은 개인 차원에서 소프트웨어 공정에 대한 정보를 제공한다.
- Carnegie Mellon University/Software Engineering Institute. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, Mass.: Addison-Wesley, 1995.
- This book is a summary of the Software Engineering Institute's latest work on software process improvement. It fully describes the five-level process maturity model, benefits of attaining each level, and practices that characterize, each level. It also contains a detailed case study of an organization that has achieved the highest levels of maturity, quality, and productivity.
- Maguire, Steve. Debugging the Development Process. Redmond, Wash.: Microsoft Press, 1994.
- Maguire's book presents a set of folksy maxims that project leads can use to keep their teams productive, and it provides interesting glimpses inside some of Microsoft's projects.
- Humphrey, Watts S. A Discipline for Software Engineering. Reading, Mass.: Addison-Wesley, 1995.
- Humphrey lays out a personal software process that you can adopt at an individual level regardless of whether your organization supports process improvement.