Younghoe.Info v3 :: 린 소프트웨어 개발의 7가지 원칙

2장에서 메모할만한 내용을 옮겨본다.

원칙 1: 낭비를 제거하라.
<중략> 소프트웨어 개발에서 무엇보다 가장 큰 낭비는 가외 기능extra feature이다. 일반적인 커스텀 소프트웨어의 경우 대개는 20% 정도의 기능만이 일상적으로 사용된다.
잘못된 통념: 스펙 조기 확정이 낭비를 줄인다.

요구사항 정의와 개발이 멀리 떨어져 있을수록 위험하단거구만... 신뢰에 입각한 고객관계 유지가 아니라면 초기에 요구사항을 명확하게 확인하지 않고 진행할 수 있을까?

원칙 2: 품질을 내재화하라.
<중략> "아, 우리는 벌써 그렇게 하고 있어요! 결함 추적 시스템에 다 기록해 두거든요."
<중략> "그럼 그 결함들을 이미 알고 있으면서 마지막까지 아무 조치를 취하지 않는다는 말씀이세요?" 나는 놀라서 물었다. <중략>
결함 추적 시스템은 미완성 작업의 대기열이다. 만약 여러분이 결함을 수정하려고 덤비면 그때부터는 재작업의 대기열이다.
잘못된 통념: 테스팅의 역할은 결함을 발견하는 것이다.
테스트의 역할 그리고 테스트를 개발하고 실행하는 사람들의 역할은 결함을 '예방'하는 것이지 발견하는 것이 아니다.

힘들어도 TDD를 해야 하는 이유

원칙 3: 지식을 창출하라. <중략>
맥코맥은 성공적인 소프트웨어 개발을 위한 실천법을 다음과 같이 4가지로 정리하였다.
1. 고객의 평가와 피드백을 위한 최소 기능 집합의 조기 출시
2. 일일 빌드와 통합 테스트를 통한 빠른 피드백
3. 좋은 판단을 할 수 있는 경험과 직관을 갖춘 팀 그리고/또는 리더
4. 새로운 기능을 쉽게 추가할 수 있는 모듈화된 아키텍처

최소 기능 집합의 조기 출시와 일일 빌드... 도전과제다.

원칙 4: 확정을 늦춰라
잘못된 통념: 계획을 세우는 것은 확정하는 것이다.

잘못된 계획에 맞추느라 프로젝트를 망칠 수는 없지 않는가? 나는 아주 최근에도 모두가 잘못되었다고 지적해도 프로젝트 제안시점에 세운 일정 계획을 바꾸지 않으려는 관리자를 목격한 일이 있다.^[각주:1] 계획이 효과를 발휘하려면 결국 반복 주기가 짧아야 한다.

원칙 5: 빨리 인도하라.
잘못된 통념: 서두르는 것은 낭비를 낳는다.

웹 2.0 사이트의 Beta 서비를 떠올려보자. 혹은 오픈소스의 진화/안정화 모델을...

원칙 6: 사람을 존중하라.
잘못된 통념: 유일한 최선의 방법이 존재한다.

개인적으로는 지루해서 읽다 말았던 조엘 온 소프트웨어에 이런 인상적인 이야기가 있었다니. 신입사원 조엘이 사내 최고의 아키텍처 그룹에 반하는 설계 전략을 주장했더니 회사를 짤리는 것이 아니라 도리어 아키텍처 그룹이 해체되었다는 전설적인 이야기. 조엘을 말을 첨부한다.

"마이크로소프트웨어에서는 여러분이 엑셀 매크로 전략 팀의 일원이라면, 여러분이 입사한지 6개월도 안 되었다 하더라도, 그것은 중요하지 않다. 여러분이 엑셀 매크로 전략에 있어서는 신(神)이며 누구도, 설사 그가 회사 내 서열 6위라 할지라도, 여러분의 길을 가로 막을 수는 없다."

원칙 7: 전체를 최적화하라.
잘못된 통념: 부분으로 나누어 최적화하라. <중략> 만약 여러분이 가치흐름을 여러 조각으로 나누어 창고Silo에 넣고 각각을 최적화하면, 그 동안의 경험으로 볼 때 전체 시스템은 부분 최적화될 것이 확실하다.

Divide and Conquer에도 맹점이 있다. 분석/설계/구현 단계적으로 최선을 다 해도 프로젝트는 실패할 수 있고, 각 모듈은 아무리 잘 만들었어도 시스템은 오작동 할 수 있다.