목적: Software engineering의 이해

뱀 뿔: 22개의 도구 중 총 4회 회당 5개씩(마지막은 7개)으로 나누어 배포할 계획입니다. 그러나 책을 완독 후의 요점 정리이므로 자세한 내용은 책을 구입하시길 권합니다.

용어 설명
– 린(Lean)
5 (문제・표현이) 간결한.
9 (자동차가 연료를) 적게 쓰는; 낭비가 없는.

1장. 낭비를 제거하라
도구 1: 낭비 찾아내기Seeing waste

• 미완성 작업Partially Done Work: 결국 그것이 사용될지 안될지 알 수가 없다는 사실이다.
• 가외 프로세스Extra Processes: 고객의 가치를 향상시키지는 않지만 꼭 해야 하는 문서 작업이 있다면 다음 세 가지 규칙을 기억하라. 가능한 한 짧게, 상위 차원에서, 오프라인에서 유지하라. 어떤 문서 작업이 가치 있는지를 확인하는 가장 좋은 방법은 그것이 만들어지길 기다리는 사람이 있는지 확인하는 것이다.
• 가외 기능Extra Features: 지금 그 코드가 필요하지 않는데, 시스템에 넣는 것은 낭비다.
• 직무 전환: 한 사람을 여러 프로젝트에 투입하는 것은 낭비의 근원이다. 여러 팀에 속하는 것은 더 많은 중단과 더 많은 업무 변경을 야기한다. 하나를 끝내고 다른 하나를 시작하라.
• 대기: 가장 큰 낭비 중 하나는 어떤 일이 일어나기를 기다리는 것이다.
• 이동: 개발자, 테스트 담당자, 고객 등 관련된 모든 사람이 하나의 작업 공간에서 작업하도록 권장한다.
• 결함: 결함 때문에 발생한 낭비는 발견되기까지 걸린 시간과 결함의 파급력에 비례한다.
• 관리 활동: 복잡한 추적 시스템을 만들기 전에 시스템에서 흘러가는 업무 흐름을 빠르게 만들어 추적 문제를 최소화하라.

도구 2: 가치 흐름도 작성Value strean mapping
　프로젝트의 흐름 중에서 가치도가 높은 부분은 어떤 부분인가? Dell은 제고가 가장 큰 리스크라고 생각했다. 왜냐하면 PC에 사용되는 모든 컴포넌트의 개발주기는 매우 짧기 때문이다.

2장. 배움을 증폭하라

• 품질에 대한 관점: 서비스 산업에서 품질이란 명시된 내용과 일치한다는 의미가 아니고, 다양한 고객의 변화무쌍한 기대를 채울 수 있는 융통성을 발휘한다는 의미다.
• 소프트웨어 개발에서의 품질: ①인식 통합성과 ②개념 통합성 두 차원에서 생각할 수 있다. ①인식 통합성이란 제품이 기능, 사용성, 신뢰성, 경제성 등 전체적인 면에서 균형을 이루어 고객을 만족시킨다는 의미다. 반면 ②개념 통합성이란 시스템의 중심 개념이 유연하면서 응집력 있게 잘 작동한다는 의미다. 즉, 설계의 품질은 요구사항에 부합conformance하는가 라기 보다는 용도를 실현하는가 혹은 사용에 적합한가를 의미한다.
• 가변성: 개발의 목적은 동일한 결과물을 만들어내는 것이 아니라 독특한 고객의 문제에 대한 적절한 해결책을 만드는 것이다.
• 설계 주기: 하양식 분할벙법top-down decomposition, 훌륭한 설계자들이 불명확한 문제, 즉 단일한 정답이나 해결책에 도달하는 최선의 길이 존재하지 않는 문제를 다루는 경우, 상위 수준 설계와 상세 해결책 사이를 오가는 것이 전형적임을 발견했다.
• 처음부터 제대로 해야 하는가?: ①처음부터 모든 설계와 코드가 완벽해야 한다고 개발자들이 확신하도록 독려하는 것이다. ②설계와 코드가 처음부터 정확하도록 하는 것보다는 소규모로 신속하게 ‘시도/테스트/수정try-it, test-it, fix-it’하는 사이클을 만드는 편이 더 좋다는 것이다. ①처음부터 제대로 진행하는 접근법은 구조화가 잘 된 문제에는 좋지만, ②잘 구조화되지 않은 문제에는 대개 후자의 접근 방법이 더 나을 것이다.
• 학습 주기: 사용자는 대부분 요구사항 문서보다 실제 화면을 친근하게 여기기 때문에, 실제 작동하는 소프트웨어가 더 좋은 지식을 더 빨리 생성하는 경향이 있다. 즉, 가장 중요한 질문은 ‘어떻게 해야 가장 효과적으로 배울 수 있는가?’ 이고, 그 대답은 짧은 학습 주기를 여러 번 거치면 된다는 것이다.

도구 3: 피드백Feedback
　전통적인 프로젝트 관리 방법에서는 피드백을 통한 학습이 기존 계획의 수정을 초래하리라는 우려 때문에 피드백 루프를 위험하다고 여긴다. 이러한 프로젝트 관리 방법은 초기 계획대로 범위, 비용, 일정을 관리하는 것에 가치를 두기 때문에 계획을 변경시킬 수 있는 피드백을 받아들이지 않으려 하고, 심지어 전체적이 비즈니스 목표에 도달하지 못하는 결과를 낳기도 한다.

　대부분의 상황에서 개발 프로젝트가 문제에 부딪힐 때 환경을 개선하는 가장 효과적인 방법은 피드백을 줄이는 것이 아니라 늘리는 것이다.

• 결함을 쌓아두지 말고, 그 코드를 작성하는 대로 바로 테스트하라.
• 문서나 상세 계획서를 더 만들지 말고, 코드를 작성해서 아이디어를 확인하도록 시도하라.
• 사용자에게 요구사항을 더 모으지 말고, 나중에 사용하게 될 사용자 화면 중 몇 가지를 보여주고 의견을 수집하라.
• 사용할 도구를 고르는 데 너무 많은 노력을 들이지 말고, 현재 도구 가운데 가장 나은 세 개 골라 테스트해 보라.

도구 4: 반복Iterations
첫째, 시스템에서 빠르게 작동하는 작은 단위의 작업이 모든 면에서 좋다.
둘째, 반복 주기가 짧아지면, 시스템에 예측보다는 사실에 더 반응하게 된다.
셋째, 반복은 작업자 개인이나 여러 팀과 고객 간의 의견을 동기화하는 접점이다

• 반복 계획: ①고객이나 고객 대표로 하여금 예상 비용을 감안하여 기능의 우선순위를 결정하게 하는 계획 세션을 수행한다. ②반복주기는 설계/구현/테스트 주기를 소화할 만큼 길면서 시스템을 사용하는 고객에게서 피드백을 자주 받을 만큼 짧아야 한다.
• 팀 수준의 약속:
  • 팀은 필요한 전문지식을 가진 소수 인력으로 구성되어야 한다. 팀원 중 일부는 해당 업종에 대한경험이 있어야 하고, 일부는 핵심critical 기술에 경험이 있어야 한다.
  • 주어진 기간 내에 무엇을 달성할 수 있는지 결정하기 위해서는 고객이 요구한 기능에 관한 정보를 충분히 알아야 한다.
  • 팀은 필요한 자원을 확보할 수 있어야 한다.
  • 팀원들은 책임을 완수하기 위해 자유로운 분위기에서 지원받고 기술을 갖춰야 한다.
  • 팀은 좋은 개발환경을 갖추거나 만들어 내야 한다.
    – 자동화된 빌드 프로세스
    – 자동화된 테스팅 환경
    – 코딩 표준
    – 버전 컨트롤 도구
    – 기타
• 요구사항 수렴: 가장 적합한 피드백 방법은 너무 짧아서 스래싱(thrashing) – 컴퓨터에서 자원의 고갈이나 부족 등으로 인해 작업의 진전이 아주 적은 상태를 말한다 – 이 생기지 않게 하면서 가능한 짧게 해야 하는 것이다.
• 협상 가능한 범위: 요구사항 수렴을 성취하기에 좋은 전략은 우선순위가 낮은 항목을 해야 할 목록to-do list에서 제외하고 우선순위가 높은 항목을 먼저 하는 것이다. 확정된 상세한 범위까지 달성하기 전에는 개발이 완전히 끝나지 않으리라고 생각하며 일한다면, 그 시스템은 정말 수렴하기가 어려울 것이다. 이하 내용은 한국의 SI 실정과 너무나도 맞지 않아 생략. 번다운 차트burn down chart의 상세한 내용은 O’REILLY의 Head First Software Development를 참조

도구 5: 동기화Synchronization
　개별기능들은 보통 여러 클래스의 수정을 동반하기에 FDD Feature-Driven Development에서는 연관된 클래스 들의 소유자들을 모아 해당 기능을 개발하게 하는 기능 팀feature team을 구성하며 코드의 동기화를 유지시킨다.

• 첫째, 동기화와 안정화: 개발자들은 출근하면 구성 관리 시스템을 통해 소스코드를 확인해서 변경을 한다. 그 다음 다른 사람이 같은 코드를 수정했는지 확인하기 위해 ‘개인 빌드’에서 그 변경을 테스트하고, 만약 변경이 있었다면 충돌을 바로 잡기 위해 새로운 코드를 검토한다. 하루 업무가 끝나면 빌드를 한 다음 자동화된 테스트를 실행한다. 만약 빌드가 작동하고 테스트를 통과하면 개발자들은 동기화 되었다고 할 수 있을 것이다. 이러한 기술을 일일 빌드daily build와 스모크 테스크smoke test라 부른다.
• 둘째, 스패닝 애플리케이션: 몇 개 팀의 작업을 동기화하는 다른 방법은 소규모 선발팀에게 전체 시스템에 적용되는 간단한 스패닝 애플리케이션spanning application – 예광탄 – 을 개발하여 운영하게 하는 것이다.
• 셋째, 매트릭스: 전체 아키텍처를 대강 정의한 후 각 팀들이 독립된 컴포넌트와 서브시스템들을 개발하는 방법이다. 이 방법을 이용하면 다른 팀과의 의사소통을 최소화하면서 작업을 진행할 수 있기 때문에 팀들이 같은 장소에 있지 않는 경우에 특히 좋다. 매트릭스 접근법에서는 먼저 인터페이스를 개발하고 서브시스템을 개발해야 한다.

출처
인사이트 – 린 소프트웨어 개발Lean Software Development