Chapter 2. 애자일 주요 원리: 자기 조직화, 린, 몰입

2.1 애자일 소프트웨어 개발 선언문의 이해

[배경]

• Jim Highsmith, Ken Schwaber 등 소프트웨어 개발 전문가들은 프로젝트를 복잡적응계(complex adaptive system)로 인식하고, 그동안 개발 과정에서 간과했던 구성원 간의 커뮤니케이션을 강조하면서 프로젝트 상황에 따른 적응형(adaptive) 개발 방법을 주장했다.
• Kent beck 역시 전통적 프로젝트 관리에서 문제가 되었던 중간 산출물 과용의 대안으로 코드 중심의 소프트웨어 개발을 강조한 방법론을 발표했다.
• 1990년대 중반부터 지금까지 발표된 다양한 애자일 개발 방법(methods)이다.
  • DSDM(Dynamic Systems Development Methods, 1994)
  • 스크럼(Scrum, 1995)
  • 크리스털 방법론(Crystal Clear, 1996)
  • XP(Extreme Programming, 1996)
  • FDD(Feature Driven Development, 1997)Indi
  • ASD(Adaptive Software Development, 2000)
  • 린(Lean SW Development, 2003)
  • 칸반(SW Kanban, 2006)
  • 린 스타트업(Lean Startup, 2011)

[탄생]

• 2001년 애자일 전문가 17명이 한 장소에 모여 함께 토론하면서 이런 방법에 내포된 공통적인 개발 철학을 정리했다. 이것이 애자일 소프트웨어 개발 선언문(Manifesto for Agile Software Development)이다.
• 애자일 소프트웨어 개발 선언문에는 개발 패러다임을 바꿔야 한다는 선언적 문장 4개와 이를 뒷받침하는 원칙(principles) 열두 가지가 담겨 있다.

※ Jim Highsmith, "프랙티스 없이 빈약한 원리는 빈 껍데기와 같고, 원리를 이해하지 못하고 수행하는 프랙티스는 판단 없는 암기에 불과하다."

[애자일 소프트웨어 개발 선언문의 중심 내용]

1. 프로세스와 도구보다는 개인과 개인 간의 상호작용에 더 큰 가치를 둔다.

   (Individuals and interactions over processes and tools.)

• 프로세스, 도구, 사람. 이 세 가지 요소를 갖춰야 성공적으로 제품을 개발할 수 있다.
  • 기존 방법론에서는 대부분 프로세스에 초점을 맞춘다.
  • 사람에게는 별 관심이 없고 기껏해야 교육훈련이 전부다.
  • 애자일은 아무리 좋은 도구와 프로세스가 있어도 이해관계자 간의 상호작용이나 소통이 원만하지 않으면 좋은 프로젝트가 성공하기 어렵다고 생각한다.

2. 포괄적 문서화보다는 동작하는 소프트웨어에 더 큰 가치를 둔다.

    (Working software over comprehensive documentation.)

• 규모가 크고 복잡한 프로젝트에서 문서화된 중간 산출물은 어느 정도 필요하다.
• 아무리 좋은 프로세스라도 프로젝트 상황에 따라 적절하게 테일러링되지 않는다면 자칫 목적 없는 문서를 양산하기 쉽다.

3. 계약 협상보다는 고객과 협력에 더 큰 가치를 둔다.

   (Customer collaboration over contract negotiation.)

• 전통적인 프로젝트 관리 관점에서 일정 수준의 요구 변경은 수용할 수 있지만 그 이상이라면 계약 변경이 불가피하다. 
• 하지만 대부분의 프로젝트에서 일정과 비용을 늘리기는 쉽지 않다 보니 개발팀과 고객 사이에 갈등이 발생하게 된다.
• 따라서 개발팀과 고객도 이런 상황을 잘 이해하고 주어진 조건에서 서로가 협력하는 지혜가 필요하다.

4. 계획을 따르기보다는 변화에 대응하는 것에 더 큰 가치를 둔다.

   (Responding to change over following a plan.)

• 프로젝트 초기에 설정한 업무 범위와 일정, 비용을 준수하는 것은 의미가 있다. 하지만 절대적이 되어서는 안 된다.

 

2.2 애자일 소프트웨어의 개발 원칙 열두 가지

1. 소프트웨어 개발을 수행하는 최우선 목표는 빠르고 지속적으로 가치 있는 소프트웨어를 전달하여 고객을 만족시키는 것이다(Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.)

• 고객 요구사항에는 여러 개의 업무 시스템 개발이 포함될 수 있으며, 고객은 이 중 일부를 현업에 먼저 활용하고 싶을 수도 있다.
• 폭포수 개발 방식은 이런 요구사항을 한꺼번에 모아서 개발하기에 고객은 원하는 시스템을 빨리 전달받기가 어렵다.
• 점진적, 반복적으로 개발하면서 고객에게 지속적으로 가치를 주는 개발 방식이 고객을 훨씬 만족시킬 수 있다.

2. 애자일 프로세스는 고객의 경쟁력을 위해서라면 비록 개발 후반일지라도 요구사항의 변경을 환영한다(Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.)

 

3. 동작하는 소프트웨어를 2주일에서 2개월까지 짧은 간격으로 자주 전달하라(Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.)

• 요구사항을 문장이나 표, 그래프 등 다양한 문서 형태로 작성하여 고객과 소통하는 데는 한계가 있다.
• 소프트웨어 공학에서 요구사항을 분석하는 방법을 다양하게 연구해 왔지만 고객에게 직접 보여주는 것만큼 확실한 방법은 없다.
• 즉, 고객에게 실제 동작하는 제품을 자주 보여주고 피드백을 받는 것이 최선이라는 의미다.

4. 요구사항을 내는 고객과 개발자는 전체 프로젝트에서 매일 함께 일해야 한다(Business people and developers must work together daily throughout the project.)

 

5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하고, 그들에게 필요한 환경과 지원을 제공하고, 일을 잘 끝낼 수 있도록 신뢰하라(Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.)

• 많은 기업에서 프로젝트에 참여할 팀원을 팀원 개인의 의지와는 상관없이 팀장의 판단으로 결정하는 경향이 있다. 이런 팀원은 자신의 의사와는 상관없이 참여가 결정되었기 때문에 현실적으로 동기부여가 쉽지 않으며, 최선을 다해 업무에 임하려고도 하지 않는다.
• 프로젝트 참여자를 결정할 때는 상위 관리자가 일방적으로 결정하기보다는 개인의 의사를 최대한 존중해주는 것이 팀의 성과를 높이는 데 도움이 된다.
• 한편 고객은 일을 맡겼다면 개발자들이 쾌적하게 일을 할 수 있는 환경을 제공하고 신뢰해야 한다.
• 여기서 신뢰란 개발팀이 자신들의 방식으로 일할 수 있도록 자율성을 주고 성과로만 판단하는 것을 의미한다. 늦게까지 일하도록 강요하거나 업무에 세부적으로 간섭하는 것은 결코 바람직하지 않다.

6. 개발팀 내부에서 정보를 전하는 가장 효율적인 방법은 서로가 얼굴을 마주 보면서 대화하는 것이다(The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.)

• 커뮤니케이션 이론에 따르면 단어 자체보다는 전달하려는 사람의 목소리 톤, 표정, 몸짓에 더 많은 정보가 담긴다고 한다.

7. 작동하는 소프트웨어는 진척의 주된 척도다(Working software is the primary measure of progress.)

 

8. 애자일 프로세스는 지속 가능한 개발을 장려하며 스폰서, 개발자, 사용자는 일정한 개발 속도를 계속 유지해야 한다(Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.)

• 프로젝트를 연속적으로 수행하는 개발팀은 과도한 업무에 시달리다 보면 아무리 좋아하는 일이라도 열정이나 흥미를 잃기 쉬우며 집중력 또한 멀어지게 된다.
• 고객과 경영자는 개발자가 업무에 지속적으로 집중할 수 있도록 일과 인생의 균형을 유지할 수 있는 환경을 만들어 주어야 한다.
• 상습적인 야근은 팀의 지속 가능한 개발을 방해하여 성과를 오히려 떨어뜨린다.

9. 기술적 탁월성과 좋은 설계에 갖는 지속적 관심이 민첩성을 높인다(Continuous attention to technical excellence and good design enhances agility.)

• 좋은 설계나 탁월한 기술은 제품의 확장성과 재사용성을 높이므로 비즈니스 변화에 따른 요구사항 변경에 빠르게 대응할 수 있다.
• 경영진은 개발자가 최신 기술에 관심을 갖고 실험할 수 있도록 시간적 여유를 제공해야 한다.
• 당장 업무가 바쁘다고 교육이나 기술 세미나에 참석하는 것을 제한한다면 개발팀의 역량은 향상되지 못한다.

10. 간단함, 즉 하지 않은 일의 양을 최대화하는 기술이 필수적이다(Simplicity--the art of maximizing the amount of work not done--is essential.)

• 과도한 분석·설계는 바람직하지 않으며 해당 요구사항이 분명하고 명확할 때 개발에 착수하는 것이 효과적이다.

11. 최고의 아키텍처, 요구사항, 설계는 자기 조직화된 팀에서 창발한다(The best architectures, requirements, and designs emerge from self-organizing teams.)

• 자기 조직화된 팀이란 구성원이 누군가의 지시가 없어도 자기 주도적으로 업무를 수행하고 유기적으로 협력하는 팀을 의미한다. 복잡계 이론(complex system theory)에서 파생된 용어다.
• 많은 창의성 전문가가 혁신은 계획할 수 있는 것이 아니며 구성원이 자유롭게 소통하고 협력할 때 나타난다고 이야기한다.

12. 정기적으로 어떤 방법이 팀에 더 효과적일지 숙고하며 이에 따라 팀의 행동을 조율하고 조정한다(At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.)

 

 

2.3 프로젝트는 복잡적응계다

[복잡계란]

• 태풍의 불규칙한 진로나 기상이변, 부동산과 주식 가격의 불규칙한 변동 현상 등 구성 인자의 복잡한 상호작용으로 구성 요소의 특성과는 다른 새로운 현상과 질서가 나타나는 시스템을 의미한다.
• 복잡계 과학은 부분을 안다고 해서 전체를 정확하게 예측할 수 없다는 것을 전제로 한다.

[개발 방법론의 관점]

• 애자일은 프로젝트 자체를 예측하기 어려운 복잡적응계로 인식한다.
• 전통적 개발에서는 프로젝트를 수행할 때 팀에 업계에서 검증된 '표준 프로세스'를 준수하도록 요구하는 경향이 있지만, 애자일 개발에서는 경험과 학습으로 기존에 알려진 표준 프로세스보다 더 좋은 방법을 찾을 수 있다고 가정한다.
• 켄 슈와버는 주변 환경이 안정적이고 변화가 적다면 정의된(defined) 프로세스가 효율적이지만 반대의 경우라면 경험적(empirical) 프로세스가 훨씬 효과적이라고 이야기한다.

※ 복잡적응계는 복잡계가 확장된 형태로, 많은 구성 요소가 상호작용하면서 경험과 학습으로 상황에 적응해 나가는 시스템이다.

 

 

2.4 스스로 일하는 개발팀 : 자기 조직화된 팀

[원하는 바]

• "일일이 시키지 않아도 팀원이 알아서 업무를 척척 처리해 주면 얼마나 좋을까?"
• 관리자의 지시가 아니라 팀원이 스스로 해야 할 일을 계획하고 상호 협력하여 업무를 수행하는 팀의 형태를 자기 조직화(self-organization)된 팀이라고 한다.

[필요성]

• 키스 소여(Keith Sawyer): "팀원이 알아서 자기 관리를 하는 팀은 급변하는 환경에서 혁신을 효과적으로 이룰 수 있다."
• 이런 팀은 예기치 않은 상황이 발생할 때 리더의 지시를 받지 않고도 조직을 재편할 수 있는 능력이 있으며 창의적인 아이디어도 자주 나온다.

[메커니즘]

• 자기 조직화의 개념: 복잡계 이론에서 나오는 핵심 개념으로, 불균형 상태에 있는 시스템이 외부의 의도적인 간섭 없이 구성 요소 사이의 집합적인 상호작용으로 스스로 조직화된 질서를 만들어내는 현상 예시) 물 분자들의 상태 변화, 철새 무리의 군무
• 중요한 조건: 조직에서 팀원이 스스로 계획하고 수행할 수 있도록 팀원에게 자율성과 책임감을 주어야 한다. 자기 조직화된 팀의 리더는 팀원이 자신의 잠재력을 최대한 발휘할 수 있도록 지원하고 돕는 역할로 변해야 한다.

 

2.5 테일러리즘 vs. 린

[개념]

• 1990년대 초 MIT 교수 워맥(Womack)은 일본의 제조 경쟁력을 분석하면서 도요타의 생산 방식을 일체의 낭비를 허용하지 않는 군살 없는 린 시스템(lean system)이라고 일컬었다.
• 그때까지 전 산업을 지배하던 테일러리즘(Taylorism) 중심의 대량 생산 방식은 심각한 회의를 불러왔다.
• 시장 자체가 만들면 팔리는 공급자 중심에서 수요자 중심의 치열한 경쟁 상황으로 전환되면서 주문형 생산 방식인 린 시스템에 더욱 많은 관심을 갖게 되었다.

※ 테일러리즘(Taylorism): 사람을 생산 시스템을 구성하는 기계적인 요소의 하나로 보고 표준화·분업화하여 노동 생산성을 증진하고자했던 과학적 관리 기법을 의미한다.

 

[패러다임 전환]

1. 장비의 가동률을 무조건 늘리는 데 초점을 맞추기보다는 장비와 인력을 효율적으로 활용하면서 제품의 리드 타임(lead time)을 줄이는 데 초점을 맞췄다.

• 리드 타임(lead time): 고객 주문 ~ 제품 출고까지의 시간
• 기존의 대량 생산 방식은 과잉 생산을 낳고, 결함의 잠복 기간을 늘려 결국 비효율성을 초래했다.
  • 규모의 경제가 지배하다 보니 대량 작업이 배치 작업(batch job:일괄 작업) 형태로 순서를 기다리며 기능별로 수행된다. 예시) 자동차 프레임 100개 → 엔진 100개 → 바퀴 100개 → 완제품 100개
  • 결함이 있어도 나중에 조립·테스트 단계에서야 알 수 있었다.
• 도요타는 배치 작업이 아닌 제품 단위당 연속 생산 방식을 적용하여 리드 타임을 줄이면서도 높은 생산성을 달성할 수 있었다. 예시) 자동차 프레임 1개 + 엔진 1개 + 바퀴 1개 = 완제품 1개 → 자동차 프레임 1개 + 엔진 1개 + 바퀴 1개 = 완제품 1개

2. 생산 근로자를 단순하게 작업을 수행하는 기계적 요소로 보지 않고 업무를 개선하는 부가가치 창출의 원천으로 보았다.

• 대량 생산 시스템에서 생산 그로자는 표준화된 업무만 수행하면 되었다.
  • 공정을 개선하고 문제를 해결하는 일은 별도의 전문 엔지니어의 업무였다. 즉, 공정을 설계하는 사람(thinker)과 실행자(doer)는 따로 분리되었다.
  • 관료적인 명령과 통제 중심의 문화가 발달하여 정형화된 절차와 규칙이 프로세스를 지배했다.
• 도요타는 근로자들에게 학습을 권장하고 동기부여를 함으로써 그들이 주도적으로 생산 공정을 변화시키고 효율성을 높일 수 있도록 장려했다. 

 

2.6 린의 주요 원리

1. 지속적인 가치 흐름을 확인하고 낭비를 제거한다.

• MIT 교수인 워맥은 린 사고(lean thinking)란 제품이나 서비스 가치(value)를 명확히 정의하고 그 흐름을 확인하여 낭비를 제거하는 것이라고 정의한 바 있다.
• 가치: 최종 고객이 정의하는 것
• 가치 흐름(value stream): 특정 제품을 구현하는 데 가치를 부여하는 개별 활동을 연결한 것
• 린 사고의 핵심은 고객의 요청부터 최종 배포까지 가치 체인을 연결하다 보면 대기 시간이나 과잉 생산 등 낭비 요소가 발생하는데 이런 낭비 요소를 지속적으로 제거하라는 것이다.

2. 풀 시스템을 활용하여 과잉 생산을 피한다.

• 풀(Pull) 시스템: 고객 수요에 따라 제품을 생산하는 개념
  • 슈퍼마켓에서 고객이 실제로 가져가는 양만큼 재고를 보충하게 되면 재고 비용을 최소로 할 수 있다는 생각에서 나왔다.
  • 개발 프로세스 상의 재고를 최소로 하고 과잉생산을 피할 수 있는 장점이 있다.
• 푸시(Push) 시스템: 고객 수요에 따라 생산하는 것이 아니라 부정확한 판매 목표에 근거하여 생산하는 방식을 의미한다. 

3. 사람이나 장비의 작업 부담을 줄이고 작업 오더의 불균일성을 제거한다.

• 도요타는 한계 수준 이상으로 사람이나 장비를 무리하게 작업시키면 근로자의 의욕 저하와 품질 문제, 고장을 초래하므로 과도한 부담을 주지 않는 것이 바람직하다고 제시한다.
• 개발자나 근로자에게 무리가 가지 않도록 균일한 작업량을 유지하는 것이 전체 성과를 높일 수가 있다.

4. 품질과 문제를 해결하는 스톱 문화를 구축한다.

• 조직에서 품질보다 제품의 생산량이나 일정을 중요하게 여긴다면 결함을 발견해도 쉽게 생산을 중단할 수가 없다.
• 하지만 결함이나 문제점을 해결하지 않은 상태에서 다음 단계로 넘어가면 나중에 결함을 수정하느라 더 큰 비용과 시간이 든다.

5. 어떤 문제도 숨길 수 없도록 시각적 관리 기법을 사용하고 직접 현장을 확인한다.

• 시각적 관리 기법(visual management)은 어떻게 업무 흐름을 진행하고 어떤 문제점이 있는지 신속하게 파악할 수 있게 해준다.

6. 근로자의 책임과 참여 하에 프로세스를 수립하고 지속적인 개선을 추구한다.

• 전문가는 표준 프로세스를 수립하고, 개발자는 주어진 방식대로 일하는 형태다.
• 이런 형태는 개발팀에 그 어떤 동기부여도 하기 어렵다.

7. 협력업체를 돕고 지원하여 동반 성장의 길을 모색한다.

 

8. 냉정한 반성과 지속적인 개선으로 학습하는 조직을 구축한다.

• 처음에 정한 프로세스가 효율성을 지속적으로 보장하는 것은 아니다.
• 팀에서는 더 좋은 개발 방법을 찾으려고 지속적으로 노력해야 한다.

9. 개발팀은 기능 혼합팀으로 구성하여 상호 협력한다.

• 기능 혼합(cross-functional)팀은 서로 다른 기능을 보유한 팀 구성원이 공동된 목표와 책임하에 서로 협력하면서 업무를 수행하는 팀을 의미한다.
• 이런 팀은 다양한 관점에서 판단할 수 있고 활발하게 상호작용함으로써 팀 내 협업을 촉진시킨다.

10. 개발 과정의 낭비를 제거하라(2.7 참조)

 

 

2.7 소프트웨어 개발의 낭비 요소 일곱 가지

1. 미완성 작업

• 개발 과정에서 만드는 중간 산출물(분석·설계 문서, 테스트하지 않은 코드 등)이 필요한 업무이기는 하지만 고객 관점에서 실질적인 가치를 제공하지는 않는다.
• 따라서 프로젝트에서는 미완성 상태인 중간 산출물을 최소화할 수 있도록 관리해야 한다.

2. 추가 프로세스

• 개발팀에 가치를 주지 못하는 (표준)프로세스는 주기적으로 검토하고 개선할 필요가 있다.

3. 추가 기능

• 고객이 직접 이야기하지는 않았지만 향후 사용에 대비하여 개발자는 종종 기능을 추가로 넣을 때가 있다.
• 전통적 프로젝트 관리에서는 이를 '금 도금(gold-plating)'이라고 이야기하는데 즉, 불필요한 일을 하지 말라는 의미다.

4. 멀티태스킹

• 많은 조직에서 한 사람이 여러 프로젝트에 관여하는 경우가 많다.
• 업무 특성상 비슷한 일이고 다른 사람과의 연관성이 낮다면 나쁘지 않은 방법이다.
• 하지만 반대라면, 프로젝트를 진행하다가 다른 프로젝트로 바로 업무를 전환하여 수행하기가 쉽지 않다.
• 업무 전환 시간은 그대로 낭비 요소가 된다.

5. 대기 시간

• 개발 업무를 진행하다 보면 고객과 여러 분야의 기술자들이 모여서 빠르게 의사 결정해야 할 일들이 생긴다.
• 이때 고객이나 팀원이 모두 한 공간에 있다면 바로 의사 결정을 할 수 있지만 그렇지 않다면 약속 시간과 장소를 별도로 잡아야 한다.
• 회의에서 의사결정을 얻기까지 중단했던 일을 다시 시작하려면 업무 전환 시간이 필요하게 된다.

6. 이관: 문서 전달

• 고객은 생각하는 것을 모두 말로 표현하지 못하고 말로 표현한 것이라도 모두 문서에 담지 못한다.
• 전통적 프로젝트에서 개발자는 고객의 요구사항을 문서로 전달받는데, 문서를 보고 개발하면 고객의 기대와는 상당히 거리가 먼 시스템이 나올 수밖에 없다.
• 올바른 요구 사항은 초기에 나오기 어려우며 고객과 자주 커뮤니케이션할 때 나타난다.

7. 결함

• 제품을 개발할 때 결함은 반드시 발생하며 늦게 발견할수록 그것을 바로잡는 데는 더 큰 노력이 들어간다.
• 결함은 조기에 발견하여 수정하거나 아예 결함이 발생하지 않도록 하는 것이 최선의 방법이다.
• 전통적 프로젝트에서는 구현과 테스트를 분리하여 진행하지만 애자일 개발은 구현과 테스트가 일체화된 공정 하나로 진행하여 코딩 단계부터 결함을 예방하는 데 힘을 쏟는다. TDD(Test Driven Development)는 이런 기법 중 하나다.

 

2.8 몰입

※ 미하이 칙센트미하이 「몰입의 경영(Good Business: Leadership, Flow, and the Making of Meaning)」

1. 구성원이 가치를 느낄 수 있는 명확한 목표

• 구성원이 프로젝트에서 오너십(ownership)을 갖게 하려면 업무 수행의 가치를 느낄 수 있는 명확한 목표를 제시해야 한다.
• 목표는 관리자가 일방적으로 전달해서는 안 되며 팀원이 마음으로 받아들일 수 있어야 한다.
• 그렇게 하려면 개발 내용이나 목표를 자유롭게 토론할 수 있는 자리를 마련해 주어야 하고, 주기적으로 장단기 개발 목표를 함께 공유해야 한다.

2. 목표 실행을 위한 자율성

• 개발자에게 자유롭게 탐색하여 목표를 달성할 수 있도록 업무 수행의 자율성을 주어야 한다.
• 리더는 전체적인 방향을 설정하고 이끌어야 하지만 세세한 개발 방법까지 관여하다 보면 오히려 팀원의 책임감을 떨어뜨릴 수 있다. 초보 개발자 같은 사람들에게는 좀 더 상세한 가이드와 지도가 필요하다.

3. 업무 수행 피드백

• 사람은 어떤 일을 할 때 자신이 얼마나 잘하는지 주기적으로 피드백을 받지 못하면 계속해서 그 활동에 몰입하기가 어렵다.
• 개발팀이 수행한 업무는 주기적으로 동료와 이해관계자에게서 평가를 받아야만 구성원이 업무 추진에 자신감을 얻을 수 있다.

4. 과제와 역량 사이의 균형

• 역량에 비해서 주어진 과제가 너무 많거나 감당하기 어렵다면 그 팀은 쉽게 불안해진다.
• 반대로 과제가 너무 적거나 쉽다면 팀은 권태를 느껴 몰입을 하지 않게 된다.
• 따라서 프로젝트에서는 이런 워크 로드(work load)를 적절하게 관리하여 몰입과 개발 효율을 높일 필요가 있다.

 

2.9 애자일 프로젝트 관리의 목표

• 애자일 개발 전문가 짐 하이스미스는 애자일 프로젝트 관리의 목표를 다음 다섯 가지로 정리한다.
  1. 지속적인 혁신(continuous innovation)
  2. 제품 적시 출시(improved time-to-market)
  3. 확장성 있는 제품(adaptable product)
  4. 사람과 프로세스의 적응력(people and process adaptability)
  5. 신뢰성 있는 결과(reliable results)
• 저자가 제시하는 현실적인 애자일 프로젝트 관리의 목표 세 가지
  1. 고객에게 가치 있는 제품 개발(customer value)
     • 프로젝트 초기 요구사항을 무조건 준수하기보다는 주기적으로 고객 가치를 따져 보고 개발하는 것이 필요하다.
  2. 제품 적시 출시(time-to-market)
     • 프로젝트 초기에 제품 출시 일정을 정했어도 비즈니스 상황 변화에 따라 언제든지 조정할 수 있어야 한다.
  3. 신뢰성과 확장성 있는 제품(reliable and adaptable product)
     • 소프트웨어는 소모품이 아니라 계속해서 확장하고 유지보수해야 하는 생명체와 같으므로 신뢰성과 확장성을 고려한 개발이 필요하다.

 

2.10 전통적·애자일 프로젝트 관리의 비교

구분	전통적 프로젝트 관리	애자일 프로젝트 관리
계획 수립	초기에 상세 요구사항을 도출하고 상세한 일정 계획 수립 추구 (고정된 범위, 일정, 비용)	개략적인 요구사항과 일정을 수립하고 주기적으로 상세 요구사항 도출 및 계획 수립 (유동적인 범위, 일정, 비용)
개발 및 테스트	분석, 설계, 구현, 테스트를 순차적으로 수행	점진적으로 개발을 진행하고, 이터레이션 단위로 동작하는 제품 개발에 초점
프로세스	* 정의된(defined) 프로세스 통제 * 프로세스가 정형화, 상세화	* 경험적(empirical) 프로세스 통제 * 유연하고 간소하며 주기적으로 개선
업무 수행 형태	* 관리자 주도적 명령과 통제 * 개인 책임으로 업무 수행	* 자기 조직화된 팀 관리 * 팀 공동 책임으로 업무 수행
조직	* 기능 중심팀(functional) * 분업화되고 역할이 한정	* 기능 혼합팀(cross-functional) * T자형 인재, 1인 다역
팀 관리	지시, 감시, 경쟁	코칭 및 퍼실리테이션, 협력
평가	상위 관리자 평가, 상대평가	다면 평가, 절대평가
성공 척도	계획 준수	고객 가치 전달