Succeeding With Agile

'SUCCEEDING WITH AGILE Software development using Scrum, Mike Cohn' 책에대한 스터디후 Re-Memorizing 하기위하여 정리된 내용임. 

1      Part One: Getting Started

1.1          Why Becoming Agile Is Hard (But Worth It)

조직은 기본적으로처음 시작했던 방식으로 회기하려는 본능을 가지고 있다.스크럼은 아무리 의도가 좋아도 지속적으로 변화하려는 노력이 실패한다.

    어려운 이유

1)       Successful Change Is Not Entirely Top-Down or Bottom-Up

a)       스크럼에서는 상향식과 하향식이 변화가 이상적이다.

2)       The End State Is Unpredictable

a)       고유환경에 맞는 프로세스를 Tailoring 한는것이 중요

b)       실행해보고 관찰하기

3)       Scrum Is Pervasive

4)       Scrum Is Dramatically Different

5)       Change Is Coming More Quickly Than Ever Before

6)       Best Practices Are Dangerous

 

성공을 위해 다음 스텝으로 가는데 있어 주요한 방해물이 무엇인지 고찰해본다.

 

    노력할 만한 가치의 이유

더 많은 직원들이 높은 업무 만족을 느끼면 생산성이 더 높아 질 뿐만 아니라 지속적인 개선효가가 나타나게 된다.

1)       Higher Productivity and Lower Costs

a)       수시로 받게되는 피드백, 반복되는 스프린트 그리고 매  스프린트마다 Reprioritize 등의 액티비티 등으로 인한 스크럼 팀은 사용자가 원하는 특징에 더 집중해서 일을 하게된다. 

2)       Improved Employee Engagement and Job Satisfaction

3)       Faster Time to Market

4)       Higher Quality

a)       Pair programming, Refactoring 그리고 초기부터 강요되는 자동화된 테스트와 같은 Engineering practices 에의해 개선된다.

5)       Improved Stakeholder Satisfaction

a)       애자일 실천법이 오늘날 빠르고 경쟁적인 조직문화에서 우선순위를 조정하는 방식과 잘 맞기 때문.

b)       스크럼 프로세스는 일일 리뷰와 토론으로 더 많은 참여를 이끌어내며 어떤 변경이 있을지 조기에 알아차리고 대처 할 수 있게 해준다.

c)       전체적인 가시성과 투명성을 가져옴으로서 믿을수 없을 만큼 생산성이 향산된다.

6)       What We’ve Been Doing No Longer Works

 

1.2          ADAPTing to Scrum

1)       성공을위한 공통5액티비티 : Awareness, Desire, Ability, Promotion, Transfer

2)       조직의 다양한 측면에서 이런 액티비티를 어떻게 적용할지 고민해야 한다.

a)       Organizationally

b)       As individuals

c)       As teams

d)       Per practice

 

1)       Awareness : 현재 프로세스가 납득할만한 결과를 주지 못한다.

a)       변화의 필요성을 인식하는데 느린이유

§  전체모습을 볼수 없다.

§  눈앞의 사실이 맞다는 것을 알면서도 거부

§  개선을 위한 행동의 혼란스러움

§  Listening to our own propaganda.

b)       Tools for Developing Awareness

§  문제가 있다는 사실을 알리기

§  지표를 이용하기

§  새로운 사람들의경험을 볼 수 있게 하기

§  파일럿 프로젝트를 진행하기.

§  변해야 하는 가장 중요한 이유에 주의를 집중 시키기.

2)       Desire : 현재 문제를 해결하는 방법으로 스크럼을 도입하고자 한다.

a)       Tools for Increasing Desire

§  더 좋은 방법이 있다는 사실 알리기

§  위급하다는 생각을 하게 만들기

§  Build momentum

§  Get the team to take Scrum for a test drive

§  Agile incentives(or at least remove disincentives)

§  두려움에 나타내는 부분에 집중하기

§  Help people let go

§  Don’t discredit the past

§  Engage employees in the effort.

3)       Ability : 스크럼을 이용해 성공할 수 있어야 한다

a)       스크럼으로 성공하려면 새로운 기술도 배워야하지만 예전 것들도 버려야 한다.

b)       스크럼 팀이 직면하는 것들

§  새로운 기술을 익혀라

§  팀으로서 일하고 생각하는 것을 배워라

§  짧은 기간 내에 동작하는 소프트웨어를 만드는 법을 배워라

c)       Tools for Developing Ability

§  코칭하고 교육하기

§  개인의 책임 주지시키기

§  정보 공유하기

§  합당한 목표 설정하기

§  일단 시작하기

4)       Promotion : 경험을 공유하고 다른사람들의 성공 사례를 보게하여 스크럼 도입을 장려한다.

a)       Tools for Promoting Scrum

§  성공스토리를 떠들고 다니기

§  애자일 탐험대 기획하기

§  관심과 흥미를 이끌어내기

5)       Transfer : 회사 전체에 스크럼을 이용하는 의미를 전파 한다.

 

 

 

1.3          Patterns for Adopting Scrum

1)       스크럼을 도입하려고 할때 떠오를수 있는 질문

a)       한두 개 팀으로 시작해야 할까, 모든 팀을 동시에 바꿔야만 할까?

b)       의도를 드러내야 할까, 아니면 당장은 조용히 변화를 진행 해야할까?

2)       Reasons to Prefer Starting Small

a)       작게 시작하면 비용이 적게든다.

b)       초반 성공을 거의 보장할 수 있다.

c)       작게 시작하기는 한번에 시작 했을때의 큰 위험을 파하게 해준다.

d)       작게 시작하기가 스트레스를 덜 준다.

e)       작게 시작하기는 조직 개편이 필요없다.

3)       Reasons to Prefer Going All In

a)       한번에 도입하면 저항을 줄일 수 있다.

b)       스크럼 팀과 기존팀이 같이 일하면서 일어나는 문제를 파악하게 해준다.

c)       한번에 도입하면 더 빨리 끝낼 수 있다

4)       Choosing Between Going All In and Starting Small

a)       작게 시작하기는 애자일 도입에 가장 많이 사용되는 일반적 접근 방식이다.

b)       스크럼의 장점을 긴급하게 필요로 한다면 작게 시작하기가 최선은 아니다.

c)       한번에 도입하기를 원한다면 소수의 주요 인물과 이해관계자들에게 스크럼을 도입하겠다는 명확한 메시지를 보내라.

5)       Public Display of Agility or Stealth

a)       Reasons to Favor a Public Display of Agility

§  모든 사람들이 여러분이 진행하는 것을 알게되면 그 일을 고수하려는 경향이 더 커진다. 의도를 이미 말해 버렸기 때문에 성공에대한 무언의 부담을 느끼게되고 친구도 여러분을 지지하거나 북돋아 줄 수 있기때문

§  공개하면 도입에대한 비전을 수립하게된다.

§  공개로 진행하는 것이 여러분 의지에 확실한 선언이된다.

§  조직의 지원을 요청할 수있다.

§  목표를 설명하고 이를 달성하는 것이 더 강력한 메시지가 된다.

b)       Reasons to Favor a Stealth Transition

§  저항이 시작되기 전에 진행할 수 있는 기회를 갖게 된다.

§  숨겨서 도입하면 부가적인 압력을 받지 않아도 된다.

§  여러분이 말하기전에는 아무도 모른다.

§  스크럼을 하는지 아무도 모른다면, 그만두라고 말할 사람도 없다.

6)       Choosing Between a Public Display and Stealth

a)       일반적으로 공개적으로 도입하는 쪽이 성공적인 도입을 더 즐기게된다.

7)       Patterns for Spreading Scrum

a)       Split and Seed

b)       Grow and Split

c)       Internal Coaching

 

                  스크럼을 단편적으로 도입하는 것에대하여 반대하는 이유를 다음과같이 말 할수도 있다.

8)       변화과정이 일정기간동안 지속되는것이 더 괴롭다.

9)       근본적인 문제를 들어내지 못한다.

10)   완전한 도입일 이끌기 어렵다.

11)   비지니스 측면에서 이점을 얻기에는 변화가 너무 느리게 진행된다.

12)   전문가 도움없이 쉽게 포기하게되고 비용도 많이 든다.

 

1.4          Iterating Toward Agility

1)       The Improvement Backlog : 조직에 스크럼을 적용하는 노력을 추적하고 저 잘 할 수 있는 항목 기록. 다음과 같은 예를 들 수 있다.

a)       스크럼을 사용하는 팀을 늘려나간다.

b)       테스트 자동화 도입을 늘려나간다.

c)       각 팀이 지속적인 통합을 사용한다.

d)       각 팀에 제품 책임자가 있어야 한다는 사실을 이해시킨다.

e)       스크럼 도입 효과에 대한 측정 방안을 결정한다.

f)        단위 테스트와 테스트 주도 개발의 사용을 증가 시킨다.

 

2)       The Enterprise Transition Community : 스크럼을 소개하고 개선하려는 조직의 노력을 지원하고 장려하고 시작작한는 작은 구룹(ETC).  구성원은 보통 12명이며 스크럼 도입에 관여하는 사람들중 최상위층에 속하는 사람들이다.

a)       ETC Sprints

§  ETC도 스크럼을 사용하기 때문에 스프린트 진행상태를 기록, 기간은 구성원들에게 달려있다.

§  도입 스폰서는 도입하려는 조직 수준과 맞아야하며 일반적으로 강안 스폰서의 역할이 중요하다.

§  Community ship은 참여하고 관리하기위해 더 겸손한 유형의 리더십을 필요로 한다.

b)       Responsibilities of the ETC : 스크럼 도입에 관한 에너지를 만드는 일이 가장큰 업무

§  지속적이고 창의적인 변화에 동참하게 하기위한 일들

·         컨텍스트를 명확히 하기

·         대화를 활성화 시키기

·         자원을 제공하기

·         적동한 목표를 산정하기

·         모든 사람이 참여하게 하기

§  사람들에게 발생할 이슈를 찾아서 대책을 세우기

§  장애요소를 찾아서 제거하기

§  실천법과 원칙에 동시게 집중하도록 장려하기

3)       Improvement Communities : 조직을 개선하려는 사람들이 다 같이 참여하는 그룹

a)       Catalysts for Improvement :  커뮤니티를 개선촉매제로 활용

b)       An Improvement Community Sprint: 권장기간은 2주

c)       Focus on Goals with Practical Relevance

d)       Improvement Community Members

e)       Disbanding a Community

4)       One Size Does Not Fit All

 

1.5          Your First Projects

1)       Selecting a Pilot Project

a)       Four Attributes of the Ideal Pilot Project

이상적인 파일럿 프로젝트는 크기,기간,중요성, 비지니스 스폰서의 참여도가 같이 만나는 곳에서 결정하는게 이상적이다.

2)       Choosing the Right Time to Start

3)       Selecting a Pilot Team

a)       다음과 같은 사람으로 파일럿 팀을 구성한다.

§  스크럼 로비스트

§  자발적인 낙관 주의자

§  공정한 회의론자

b)       What if a Pilot Isn’t a Success?

§  한번의 대형 파일럿 프로젝트에 원하는 모든 희망을 걸지 않는다.

§  여러개의 프로젝트를 진행하고 파일럿 프로젝트의 목표가 스크럼 프로젝트가 가야하는 길을 조명하는 것이라는 사실을 이억하자.

 

4)       Setting and Managing Expectations : 새로운 시스템에대한 기대치가 너무 높은경우 매달 스프린트 리뷰에서 그들이 기대하는 것에 매번 충력을 받게된다.

a)       Expectations About Progress

§  대부분의팀은 첫번째 스프린트에서 얼마나 달성 해야하는지에 대한 과도하게 예측하는 경향이 있다.

§  대부분 팀은 더 유능하다.

b)       Expectations about Predictability

c)       Expectations About Attitudes toward Scrum

d)       Expectations About Involvement

                   참조 : 스크럼 사용자 스토리

                           

                           

                            

                   참조 : 스크럼 사용자 스토리

                            

---

2      Part Two: Individuals

구성원들의 저항을 어떻게 효과적으로 극복할 것인다.

2.1          Overcoming Resistance

§  Anticipating Resistance : 직원과 관리자가 변화에 저항하는 이유

	직원	관리자
1	인지부족	권한을 잃는 것에 대한 두려움
2	모르는 것에 대한두려움	시간부족
3	고용보장에 대한 두려움	기존 방법의 편안함
4	스폰서쉽의 부족	No answer to “What’s in I for me?”
5		해결책을 제시할 방법이 없음

 

a)       Who Will Resist? : 저항이 어디서 발생할지 예상해 볼때 다음 질문들에 대한 답을 생각해본다.

§  스크럼이 성공적으로 도입되면 누가 힘이나 명성, 권력을 읽어버리는가?

§  스크럼 도입에 반대하기 위해 어떤 그룹들이 형성될 것 같은가?

 

b)       변화에대한 개별적 성향 분석 : 보수주의자, 실용주의자, 진보주의자

§  다음과 같이 성향별로 변화에 대한 이런 세 가지 성향을 인지하는 것은 구성원 중에 누가 반감을 가지게 될 것인지 구분하는 데 유용하다.

 

c)       Waterfallacies and Agile Phobias :폭포수 모델 프로젝트에서 오랫동안 일하면서 굳어진 애자일이나 스크럼에 대한 잘못된 믿음이나 생각을 말한다.

 

2)       Communicating About the Change

누군가의 메시지를 이해하고 공감하기 위해서 여러번 다양한 방법으로 전달 받는게 필요하다. 같은 메시지를 듣더라도 리더에게 듣는것이 나을 때가 있고 동료에게 듣는것이 나을때가 있다.

a)       Hearing from Leaders

b)       Hearing from Peers

 

3)       The Hows and Whys of Individual Resistance

저항을 하는 이유를 보통 “현 상황을 만족하는 사람”, “스크럼을 싫어하는 사람” 과 같이 두개의 그룹으로 나눌수 잇다.

또 어떤 이유때문에 어떻게 저항하느냐에 따라 저항하는 사람을 4가지 유형으로 나눌수 있다.

 

a)       Skeptics : 회의론자

§  충분한 시간허락 하기

§  교육 진행하기

§  동료의 경험담으로 유인하기

§  챔피언 회의론자를 임명하기

§  이슈를 던진다

§  문제를 알아낸다.

b)       Saboteurs : 방해공작원

§  성공사례

§  결정사항을 반복하고 강조하기

§  방해공작원을 다른 팀으로 보내기

§  방해공작원을 해고하기

§  성공한 사람들의 이야기를 주지시키기

c)       Diehards : 보수주의자

§  인센티브 정비하기

§  현재 상황에 불만을 가지게 하기

§  두려움을 인지하고 맞서기

d)       Followers : 추종론자

§  팀 구성 변경하기

§  타당한 행동은 칭찬하기

§  추종자들이 관여하게 만들기

§  먼저 본보기를 보이기

§  진짜 장애물을 식별하기

 

2)       Resistance as a Useful Red Flag

저항이 보이면 이를 극복해야할 대상으로 보면 안된다. 대신 뭔가 잘못되고 있다는 신호인 유익한 붉은 깃발로 생각하는 것이 최선이다. 고통처럼 저항도 무엇이 잘못되었다고 말해 주지 않는다. 저항이 들어나면 무엇이 문제인지 주의 깊게 귀를 기울여야한다.

2.2          New Roles

1)       The Role of the ScrumMaster

팀원에게 권한은 없지만 프로세스에대한 권한을 갖고있다. 즉 프로세스를 통해 스크럼마스터는 권한을 행사한다.

a)       Attributes of a Good ScrumMaster

§  책임감, 겸손함, 협업, 약속이행하기, 영향력, 박식함

b)       Tech Leads as ScrumMasters

§  기술 리더였던 사람이 훌륭한 스크럼마스터가 될수도 있겠지만 과거에 이런 역할을 맡았다는 이유로 스크럼 마스터를 지정하지 말자. 팀원에게 명령하는 습관이나 사람을 다루는 기술이 부족할 수 있기때문이다.

c)       Internal or External ScrumMasters

d)       Rotating the ScrumMaster

e)       Overcoming Common Problems

§  부적합한 사람이 스크럼 마스터를 맡는 경우

§  스크럼 마스터도 팀에서 프로그래머, 테스터 등의 다른 역할을 해야 되는 경우.

§  스크럼 마스터가 팀에서 의사 결정을 내리는 경우

2)       The Product Owner

회사마다 제품책임자가 자신의 역할을 수행하는데 있어 전후 관계가 큰영향을 미치기 때문에 제품 책임자의 책임이 무엇인지 알려주는 스프린트 계획 회의에는 꼭 참석해야 한다.

제품 책임자의 또 다른 일은 팀에 비전과 범위를 알려 줘야한다.

a)       Responsibilities of the Product Owner

§  비전제공하기

§  다음과 같은 범위 제공하기

·         제품은 6개월까지 완료해야 합니다.

·         단위 모듈당 가격을 50%할인 해주세요

·         속도를 두배 빠르게 해주세요

·         현재 버전이 사용하는 메모리의 절반으로 동작해야 합니다.

b)       Each Team Needs Exactly One Product Owner

c)       Attributes of a Good Product Owner

§  팀이 필요할때 도움을 줄 수 있는가

§  업무 지식에 정통한가

§  커뮤니케이션을 잘 하는가

§  결단력

§  권리 위임

d)       The ScrumMaster as Product Owner : 두개의 역할을 합칠경우 진지하게 고민필요

e)       Overcoming Common Problems

§  제품 책임자가 의사결정을 했지만 그 의사결정자의 결정을 기각한다.

말도 안되는 결정만 아니면 그 결정에 맞서기보다 오히려 해당 스프린트가 끝날때까지 그 결정을 유지하도록 하자. 그러고 나서 변경할 사항인지 아닌지 판단하자. 결정을 반복함으로써 발생하는 비용을 제품 백로그에 다른 가치있는 작업들과 비교해보면 그렇게 나쁜것만은 아니란 사실을 알게될것이다.

§  제품 책임자가 너무 팀을 궁지로 몰아 세운다.

제품 책임자는 종종 재무적인 압박을 받지만 가능하면 팀에게 명확한 목표를 주는게 팀의 스트레스를 줄여준다.

§  제품 책임자가 품질 수준을 낮추려고 할때

시간은 스크럼 마스터 편이다. 품질을 낮추자는 결정이 수면위로 떠오르게 할 수만 있다면 최후의 승자는 스크럼 마스터다. 품질을 낯추는 힘들수도 있지만 전체적인 상황르 따저봐야 한다.

§  우리의 제품 책임자는 개발팀과 같이있는게 아니라 다른 도시에 있다.

3)       New Roles, Old Responsibilities

2.3          Changed Roles

스크럼 프로젝트의 자기조직적인 특성때문에 팀에 기술 리더와 같은 역할이 없어지기도 하고 개개인은 자신의 전문분야를 넘어서 팀을 도울 수 있는 방안이 있는지 찾아보게 된다. 이런 특성과 변화 때문에 기존 역할변경과 같은 조직이 부딪히는 어려움을 극복하기 위해 노력해야 한다.

1)       Analysts

팀보다 살짝 앞서 나가면서 현재 작업중이거나 곧 작업을 시작할 기능에 대한 쓸모있는 정보를 팀에게 제공하는 것이 분석가의 새로운 목표가 된다.

분석가는 목표 달성을 위해 요구사항 작성보다 대화를 강조하게된다.

전반적으로 대부분의 분석가들이 고객이 원하는 바를 홀로 파악하는 역할에서 멀어짐에도 스크럼이 주는 변화를 즐긴다.

2)       Project Managers

스크럼을 도입하는 조직에서 대부분의 PM이 맡게되는 새로운 역할이 스크러머 마스터이다. 이 새로운 역할은 팀이 문제점을 해결하고 의사 결정하는 방법을 스스로 배워가도록 지켜봐야 하기 때문에 PM 역할을 수행했던 사람들에게 어려울 수 있다.

PM에서 스크럼 마스터로 역할이 바뀐 사람들은 종종 본인들 스스로가 애자일하지 못하면서 팀을 코칭해야 하는 일이 생긴다. 이러한 상황에 처한 스크럼 마스터들을 위한 최고의 전략은 다음과 같다.

a)       교과서 적으로 스크럼을 수행하기

b)       가능한 많은 다른 스크럼 마스터와 대화하기

c)       최대한 빠르게 배우기

 

d)       Why the Title Change???

3)       Architects

스크럼 도입에 직면한 아키텍트들의 두가지 걱정 유형

a)       앞으로도 사람들이 내가 말한 기술 구조에 따라 구현할까?

b)       초반에 아키텍처를 검증하고 않고 어떻게 견고한 아키텍처를 가진 제품을 만들수 있다고 확신할 수 있을까?

c)       애자일 개발 시 아키텍트는 변화와 복잡성을 주로 고민하는 반면 개발자들은 주로 다음 배포에 집중한다.

d)       The Non-Coding Architect : 코딩하지 아키텍트는 문제를 일으킬 소지가 많음.

e)       스크럼에서는 아키텍트가 더 이상 명시적으로 기술 문제에 대한 해결책을 강요하는 일이 없어진다. 아키텍트는 조언자이면서 진행자가 되어야한다.

4)       Functional Managers

스크럼에서는 자지조직화라는 근본적인 측면에서 팀 자체의 몫이기 때문에 이러한 역할이 더이상 존재 의미가 없다.

5)       The Leadership Role of the Functional Manager

 

스크럼을 사용하고 있는 조직의 기능 관리자들은 사분면의 우상단 부분에 해당한다. 이 사람들은 업무에 대한 깊은 이해와 상향식 스타일을 겸비한다. 역할 관리자는 그룹의 구성원자들에게 가이드라인과 코칭을 제공해야하는 책임이 있다.

6)       Personnel Responsibilities : 주기적으로 평가하고 기록할 책임/이 있다. 고용 해고의 책임권한.

7)       Programmers

a)       기꺼이 팀 전체효율을 높이기 위해 수단과 방법을 가리지 않고 기여한다.

b)       더이상 파티션에 둘러싸인 작은 공간에서 무엇을 개발하면 되는지 말해주길 기다리지 않게 된다.

c)       개발자는 제품 요구사항을 이해하기 위해 능동적인 참여자가 되어야한다.

8)       Database Administrators

a)       데이터 전문가, DB관리자, DB엔지니어 또는 이와비슷한 직함을 가지 사람들은 스크럼 도입에 저항이 가장 심한 편이다.

b)       이전에는 완전하고 정확한 분석이 이루어 저야했다.

c)       어플리케이션은 변하지만 데이터는 영원하다는 생각이 사전에 완벽한 분석을 해야 한다는 생각에 치중하게 만들었다.

d)       하지만 진화하는 어플리케이션을 지원하려먼 DB역시 진화해야한다.

9)       Testers

a)       테스트의 접근 방식은 요구사항에 부합하는 가다. 이점때문에 지나치게 완벽한 요구사항 문서를 작성하는데 집착하게된다.

b)       문제는 그보다 더 좋은것이 사용자의 필요성에 부합하는가다.

c)       모든 사용자의 필요성을 완벽하게 예상하는것은 불가능하다. 따라서 개발자는 완벽한 스펙문서를 제출하시고 요구하신 대로 정확히 동작하도록 개발하는 동안 건드리지 말아주세요”라고 스크럼에서는 말할수 없다. 이런태도는 결국 책임감의 결여로 이어진다.

d)       완벽한 스펙이 사전에 정의되어 제시되어야 한다는 사회통념을 깨뜨리는 일외에도 테스터들이 직면하는 가장 큰 변화중 하나는 점진적으로 일하는 방법을 배우는 일이다.

10)       User Experience Designers : 스크럼에서는 개발활동이 시작되기전에 UX디자이너가 모든작업을 진행하길 원치않는다.

11)       Three Common Themes : 점진적/반복적/전문성을 초월해서 일해라.

2.4          Technical Practices

스크럼팀이 정말 성공하려면 스크럼의 기본적인 높은 가시성을 넘어 제품을 개발하는 실제 작업을 실질적으로 바꿔야한다. 즉 기술적인 실천법의 변화가 요구된다. 그렇다고 스크럼에서는 구체적으로 엔지니어링 실천법을 규정하지 않는다. 가령 스크럼은 테스트가 필요하다고 명시적으로 말하지 않는다. 스크럼팀에 요구하는 것은 스프린트 마지막에 높은 품질의 전달 가능한 코드이다.

 

1)       Strive for Technical Excellence

a)       Test-Driven Development : 짧은 주기의 실패하는 테스트를 작성하고 해당 테스트를 통과할 만큼만 코드를 작성한 뒤 필요한 만큼 코드를 개선하는 과정을 반복

b)       Refactoring : 행위 변경없이 구조 변경

c)       Collective Ownership

d)       Continuous Integration

e)       Pair Programming : 가장 위험한 부분에 도입 추천, 공수대비 완료시간 고려

2)       Design: Intentional yet Emergent

스크럼 팀은 설계에대한 모든 의사결정을 미리할수 없다는 점을 인정한다. 즉 스크럼 프로젝트의 설계는 계획적이면서도 그때그때 맞춰한다.

어떠한 조직이 애자일 하게 되는데 중요한 부분 한 가지는 예측과 적응간에 적절한 균형을 찾는 것이다.

 

예측과 적응간에 균형은 양쪽과 관련있는 활동과 산출물간의 균형과 관련이 있다.

 

a)       Getting Used to Life Without a Big Design

§  스크럼의 기술적인 실천법에 익숙해지면 고객 요구사항을 예측하는 방식에서 고객에게 적응하는 방식으로 자연스럽게 전환하기 시작한다.

§  과도한 사전 설계와 분석 방식은 높은 변경 비용이 발생한다.

b)       Guiding the Design

3)       Improving Technical Practices Is Not Optional

---

3      Part Three: Teams

의도하지 않아도 시스템의 구조는 시스템을 설계한 조직의 구조를 그대로 반영한다. 이 같은 요인을 기회로 생각하고 원하는 시스템 구조를 만들기위해 지속적으로 조직의 구조를 설계해야한다.

1)       Feed Them Two Pizzas

a)       Why Two Pizzas Are Enough

§  사회적 태만이 적다.

§  효과적인 상호작용은 규모가 작은 팀에서 더 많이 일어난다.

§  팀 편성에 더 적은 시간이 든다.

§  조용히 묻어가는 사람이 없게된다.

§  규모가 작은 팀은 팀원들에 대한 만족도가 더 높다.

§  과도한 전문화에 따른 악영향이 더 적게 일어난다.

b)       Small Team Productivity

2)       Favor Feature Teams

a)       Use Component Teams Sparingly

b)       Who Makes These Decisions?

c)       What’s Right Today May Be Wrong Tomorrow

3)       Self-Organizing Doesn’t Mean Randomly Assembled

a)       Getting the Right People on the Team

4)       Put People on One Project

a)       Time on Task Decreases with Too Many Tasks

b)       When Multitasking Is OK

c)       The Corporate Form of Multitasking

d)       Stopping the Treadmill

5)       Guidelines for Good Team Structure

3.1          Teamwork

애자일 선언에는 프로세스와 도구보다는 개인과 상호작용을 선호한다. 여러선수가 하나가되어 공을 운반하는 럭비 팀처럼 개발 팀도 움직여야한다.

1)       Embrace Whole-Team Resposibility : 팀 전체의 책임으로 받아들이기

a)       Nurture Whole-Team Commitment : 약속한 일을 팀 전체가 달성하도록 해야한다.

팀 목표 달성을 위해서는 책임 공유와 함께 약속에대한 공유가 이루어 저야한다.

2)       Rely On Specialists But Sparingly : 모든 팀원이 전문가 또는 전문가가 너무 많으면 다음 단계 일을 전달 받을 때 대기시간이 너무 길 가능성이 높다. 샌드위치 가계에 샌드위치 만드는 사람이외 제너럴리스트가 있는것 처럼 스페이셜리스트가 스페이셜리스트답게 일하도록 하는 사람이 바로 제너럴리스트이다.

3)       Do A Little Bit Of Everything All The Time

a)       Don’t Wait Until the End of the Sprint to Finish Everything

b)       Mix the Sizes of the Product Backlog Items You Commit To

4)       Foster Team Learning

a)       Ensure Learning Conditions Exist

b)       Eliminate Knowledge Waste : 버려지는 지식을 막자

5)       Encourage Collaboration Through Commitment

6)       All Together Now

 

3.2          Leading a Self-Organizing Team

1)       Influencing Self-Organization

자지 조직화는 효과적인 행동이 무엇인지 미리 알려주는게 아니라 사람들이 독립적인 행위 주체로 서로 상호작용하게 하므로써 행동의 발전이 이루어 지도록 관리자가 인도하는 것을 의미한다.

자기 조직화를 이루는 세가지 조건: Containers, Differences, and Exchanges

 

2)       Influencing Evolution

a)       Select the External Environment

b)       Define Performance

c)       Manage Meaning

d)       Introduce Vicarious Selection Systems

e)       Energize the System

3)       There’s More to Leadership than Buying Pizza

자기 조직화에는 피자를 사는것 이외 다른 것들도 있다. 리더는 드러나지 않는 간접적인 방법으로 팀에 영향을 줄 수 있다.  모든것에 리더가 정확하게 예상하는 것은 불가능 하다. 리더라고 모든 해답을 가지고 있는 것은 아니며 그들에게 정말 필요한 건 조직이 더 애자일 하게 되도록 조직의 마음을 움직일수 있는 능력이다.

3.3          The Product Backlog

프로젝트 시작시 가장 도전적인 질문은 정확히 우리가 만드는게 무엇이냐는 질문이다.

1)       Shift from Documents to Discussions

요구사항을 적어 놓으면 사용자는 정확히 원하는 것을 받게 된다고 믿는데 이것은 잘못이다. 정말 원하는 것일 가능성이 있는 무엇인가를 받는 것이다.

 

문서보다 대화를 더 선호해야 하는 이유

·         작성된 문서는 판단을 못하게 할 수 있다.

·         문서로 작성되면 대화할 때 처럼 숨겨진 의미를 다시 물어볼 수 없다.

·         문서 작성은 전체 팀이라는 책임감을 떨어뜨린다.

 

a)       Don’t Throw the Baby Out with the Documentation

§  문서화 때문에 중요한것을 잊으면 안된다. 요구사항 문서를 버리라는 의미가 아니라 문서를 적정선에서 잘 활용하라는 의미이다. ‘동작하는 소프트웨어가 포괄적인 문서보다 우선한다.’

§  문서가 인수인계를 위해 쓰이는 경우가 대부분이지만 이는 결국 해가 된다. 잊지 말아야할 것은 대화를 기록하기위해서 쓰일때 가치 있는 것이 된다.

b)       Use User Stories for the Product Backlog

§  사용자 스토리는 기능에 대해 작성하는 게 아니라 기능에 대해 이야기하게 만드는  최고의 방법이다.

§  사용자 스토리는 새로운 기능을 원하는 사람의 관점, 즉 사용자나 시스템을 사용하는 고객의 관점에서 어떤 기능을 간결하고 단순하게 설명한 것이다.

§  사용자 스토리는 기능에 대해 이야기하게 만드는 강력한 힘이 있다.

 

사용자 스토리 작성 형식 : 첫번째 선호

o    <고객의 유형>로서, 나는 <어떤이유 때문에> <어떤목표>를 원한다.

o    <달성가치>를 위해,<고객의 유형>로서, <어떤목표>를 원한다.

 

2)       Progressively Refine Requirements

a)       Emergent Requirements : 사전에 식별할수 없는 기능, 모든것을 미리 예측할수 없다.

b)       The Product Backlog Iceberg

c)       Why Progressively Refine Requirements?

d)       Progressive Refinement of User Stories

 

3)       Learn to Start Without a Specification

스크럼 팀은 요구사항을 문서로 작성하기 보다는 대화로 해결하고 프로젝트 전과정 동안 점진적으로 요구사항을 정제한다. 스펙문서가 가진 위험 중 하나는 업데이트를 거의 하지 않는다는 것이다.

a)       Specify by Example : 실 세계의 사례를 활용하면 사람들이 더 쉽게 자기 자신과 연관지어 생각할수 있기때문에 커뮤케이션하기 더 수월해 진다.

b)       Cross-Functional Teams Reduce Documentation Needs

4)       Make the Product Backlog DEEP

a)       Detailed Appropriately : 적절한 상세화

b)       Estimated : 작업의 크기가 잘 추정되어 있다.

c)       Emergent : 유연함, 제품 백로그는 정적이지 않다. 계속 변경된다.

d)       Prioritized : 우선순위

5)       Don’t Forget to Talk

제품 백로그가 프로젝트의 전통적인 요구사항 문서나 유스케이스 모델을 1:1로 대체하지는 못한다. 실제 제품 백로그에 적혀있는 내용만큼이나 중요한것은 그와 관련된 대화이다.

 

 

3.4          Sprints

동작하는 소프트웨어를 강조하는 이유

ü  피드백을 활성화 한다. 동작하는 기능을 보여주면 팀에게도 좋고 더 양질의 피드백을 얻을수 있다.

ü  팀의 성과를 측정하는데 도움이 된다.

ü  필요한 순간에 제품을 조기 출시할 수 있게 한다.

 

1)       Deliver Working Software Each Sprint

a)       Defining Potentially Shippable

b)       Identifying Potentially Shippable Guidelines

§  ‘전달가능한’상태는 테스트가 완료된 상태를 의미한다.

§  잠재적으로 출시 가능한 수준이 응집력 있는 높은 수준을 의미하는것은 아니다.

§  잠재적으로 출시가능하다는 의민는 통합되었음을 의미한다.

2)       Deliver Something Valuable Each Sprint

3)       Prepare in this Sprint for the Next

a)       Billiard Ball Sprints

다음 스프린트가 준비되어있지 않은채 스프린트가 종료되어 딱!하고 다음 스프린트가 시작되면 일정이 밀려난기때문에 스프린트마다 다음 스프린트를 위한 준비에 약간의 노력을 기울일 필요가 있다.

b)       Only Pull into a Sprint What Can Be Completed

완료할 수 있는것만 스프린트 개발 범위로 정하기

 

4)       Work Together Throughout the Sprint

a)       Avoid Activity-Specific Sprints

b)       Replace Finish-to-Start Relationships with Finish-to-Finish Ones

c)       Overlapping User Experience Design

d)       Think Holistically, Work Incrementally

e)       Architecture and Database Design

5)       Keep Timeboxes Regular and Strict

스프린트를 고정하므로서 생기는 이점

a)       규칙적으로 일하는 방식은 팀에게 득이된다.

b)       스프린트 계획이 더 쉬워진다.

c)       릴리즈 계획이 더 쉬워진다.

d)       리차드 파인만처럼 하자 : 리차드 파인만은 매일저녁 무엇을 먹을것인지를 선택하다 지처서 그는 항상 초코렛 아이스크림을 선택하는 방법으로 단순화 했다는 이야기.

a)       Never Extend a Sprint

6)       Don’t Change the Goal

적어도 초기에는 스프린트 중간에 변경을 수용하지 말고 스크럼의 강경입장을 고수하라.

a)       Break the Habit of Redirecting a Team

7)       Get Feedback, Learn, and Adapt

 

3.5          Planning

1)       Progressively Refine Plans

a)       시간투자를 최소화할 수 있다.

b)       진행 방향의 변경이 가능하다.

c)       계획을 믿는 함정에 빠지는 일을 막아준다.

 

2)       Don’t Plan on Overtime to Salvage a Plan : 초과근무는 프로젝트에 심각한 문제가 있다는 징후다.

a)       Learning the Hard Way

b)       Getting There : 지속적으로 유지가능한 속도로 일하는 것이 더 많이 일할수 있다.

c)       If Not Overtime, What? : 시간은 유한한 자원이자만 에너지는 다르다. 에너지와 생산성이 넘치는 경우 시계를 보는 일이 줄어든다.

 

3)       Favor Scope Changes When Possible : 가능하면 범위 변경을 선호하라.

스크럼을 이행한다는 측면에서 본다면 핵심 이해관계자나 개발자 그리고 제품 책임자는 범위 변경이 첫 번째 선택이어야 함을 알아야 할 필요가 있다. 가용한 자원이나 일정을 확고히 하기 위해서라도 범위를 조정하는 쪽으로 가야한다.

a)       Considering the Alternatives

b)       Project Context Is Key

범위 변경이 과거에 생각했던 것에 비해 훨씬더 실현 가능하고 철의 삼각형을 조정하기에 가장 좋은 요소라는 것을 조직이 깨닫는 것이 제일 바람직 하다.

 

4)       Separate Estimating from Committing

예를 들어 “7개월 정도 걸릴 것으로 추정합니다”가 “7개월 안내 끝낼 것을 약속합니다”로 바뀐다.

a)       The Right Data to Do This : 좋은 추정을 위해서는 제품책임자가 팀에대한 올바른 자료를 갖고 있어야 한다.

§  수행할 수 있는 작업의 크기

§  작업을 진행하는 팀의 기대 진척률

b)       Going from Estimate to Commitment

c)       Historical Velocity Forms the Basis for Committing

개발 속도에 관한 과거 데이터가 약속의 근간이 된다.

§  함께 일해본 적이 없는 팀

·         이런경우 과거 데이터가 없기때문에 팀원을 프로젝트에 투입하되 약속을 하기전에 적어도 한번의 스프린트를 진행하도록 한다.

·         스토리 점수나 이상적인 소요일로 추정된 제품 백로그를 가지고 스프린트를 진행하면서 스프린트 동안 얼마나 일할수 있는지 관찰한다. 이상이 발생하면 왜 이런 상황이 벌어졌는지 확인할수있는 좋은 기회로 봐야 한다.

§  팀 크기가 자주 변하는 경우

·         팀을 최대한 변경하지 마라

·         데이터 수집을 반복하는 것이다.

 

 

3.6          Quality

1)       Integrate Testing Into the Process

a)       왜 마지막에 진행하는 테스트가 효과가 떨어질까

§  기존 제품의 품질을 개선하는 일은 어렵다.

§  실수가 계속 간과된다.

§  프로젝트 상황은 측정하기 힘들다.

§  피드백을 얻을수 있는 기회를 잃어버린다.

§  테스트 기간이 줄어들 수 있다.

2)       Automate At Different Levels

a)       The Remaining Role of User Interface Tests

b)       The Role of Manual Testing

c)       Automate within the Sprint

d)       Sampling the Benefits

3)       Do Acceptance-Test-Driven Development

a)       The Right Level of Detail

4)       Pay Off Technical Debt : 부채는 빨기 값는게 좋다.

a)       Paying Down Testing Debt in Three Steps

§  출혈을 멈추고

§  현재에 머무른채

§  따라 잡아라

5)       Quality Is a Team Effort

제품의 품질이 낮아 모든 고객이 고통을 겪듯 테스트가 프로세스에 통합되지 않거나 적적ㄹ한 수준에 미치지 못하면 전체 팀이 고통을 겪게된다.

---

4      Part Four: The Organization

4.1          Scaling Agile

1)       Scaling the Product Owner

a)       Sharing Responsibility, Dividing Functionality

2)       Working With a Large Product Backlog

a)       One Product, One Product Backlog

b)       Keep the Product Backlog to a Reasonable Size

3)       Proactively Manage Dependencies

a)       Do Rolling Lookahead Planning

b)       Hold a Release Kickoff Meeting : 릴리즈 킥오프 미팅

c)       Share Team Members

d)       Use an Integration Team

4)       Coordinate Work Among Teams

a)       The Scrum of Scrums Meeting : 스크럼의 스크럼 미팅

b)       Synchronize Sprints : 스프린트 동기화 하기

5)       Scaling the Sprint Planning Meeting

a)       Stagger by a Day : 하루씩 시차두기

b)       The Big Room

6)       Cultivate Communities of Practice : 실행공동체 구축

a)       Formal or Informal

b)       Creating an Environment for Communities to Form and Flourish

c)       Participation

7)       Scrum Does Scale

 

 

4.2          Distributed Teams

1)       Create Coherence

a)       Acknowledge Significant Cultural Differences : 문화적 차이 인정하기

5개 주요 지표 : 각 국가의 문화적 특성을 고려하여 대화하는데 참조 할수 있다.

§  권력거리지수 : PDI

§  개인주의 : IND

§  성취도 : ACH

§  불확실성 회피 지수 : UAI

§  장기 지향성 : LTO

국가	권력거리	개인주의	성취도	불확실성회피	장기지향성
네덜란드	38	80	14	53	44
노르웨이	31	69	8	50	20
덴마크	18	74	16	23
러시아	93	39	36	95
미국	40	91	62	46	29
브라질	69	38	49	76	65
스웨덴	31	71	5	29	33
스페인	57	51	42	86
영국	35	89	66	35	25
이스라엘	13	54	47	81
인도	77	48	56	40	61
일본	54	46	95	92	80
중국	80	20	66	30	118
폴란드	68	60	64	93	32
핀란드	33	63	26	59

                                           이 지표는 참 흥미롭다. 자주 접하게될 나라별 엔지어들의 성향을 대략 파악할수 있어 많은 도움이 될것 같다.

                                           (호주는 대충 영국과 견주어서 비교하면 될것 같다.)

 

b)       Acknowledge the Small Cultural Differences

c)       Strengthen Functional and Team Subcultures : 컴퓨터 하위문화가 민족문화보다 강력해서 모스크바에 있는 프로그래머가 다른 러시아인보다 미국 프로그래머 동료와 더 동질감을 느낀다. 즉 프로그래머가 사교성이 없다는 고정관념은 진실이다.

d)       Build Trust by Emphasizing Early Progress

2)       Get Together in Person

a)       Seeding Visits

b)       Contact Visits

c)       Traveling Ambassadors

3)       Change How You Communicate

a)       Adding Back Some Documentation

b)       Adding Detail to the Product Backlog

c)       Encourage Lateral Communication :수평적 커뮤니케이션 장려하기.

4)       Meetings

a)       General Advice

b)       Sprint Planning Meeting

c)       Daily Scrum

d)       Scrum of Scrums

e)       Sprint Reviews and Retrospectives

5)       Proceed with Caution

 

 

4.3          Coexisting with Other Approaches

1)       Mixing Scrum and Sequential Development

a)       Three Scenarios of Interaction

b)       Three Areas of Conflict

c)       Can Scrum and Sequential Coexist Forever?

2)       Governance

a)       Running Scrum Projects with Non-Agile Governance

3)       Compliance

a)       ISO 9001

b)       Capability Maturity Model Integration (CMMI)

c)       Achieving Compliance

4.4          Human Resources, Facilities and the PMO

1)       Human Resources : 대부분 조직은 본질적으로 개인의 책임을 선호한다.

a)       Reporting Structures : 스크럼이 성공하면 보고체계는 없어도 된다.

b)       Periodic Performance Reviews

c)       Removing Team Members : 팀 자체적으로 누구를 내보내는 권한을 가져서는 않된다.

d)       Career Paths

e)       With People Involved, There Will Always Be People Issues

2)       Facilities : 팀의 물리적 환경은 팀이 얼마나 애자일하게 되는지 많은 영향을 미친다.

a)       The Space

b)       The Furniture

c)       Items That Should Be Visible in Your Workspace

§  크고 눈에 띄는 차트

§  추가적인 피드백 장치

§  팀에있는 모든 사람

§  스프린트 백로그

§  제품 백로그

§  적어도 큰 화이트보드 한개

§  조용하고 사적인 장소

§  먹을것과 마실것

§  창문

 

3)       The Project Management Office

a)       People

b)       Projects

c)       Process

d)       Renaming the PMO

4)       The Bottom Line

 

---

5      Part Five: Next Steps

5.1          Seeing How Far You’ve Come

1)       The Purpose of Measuring : 목적은 불확실성을 줄이는데 있다. 측정은 정확할 필요는 없다.

 

스크럼 도입의 성공에관한 가장 공통적인 질문

a)       스크럼 도입이 투자할 가치가 있나요?

b)       다음에 더 잘하기 위해서는 무엇을 해야하나요?

c)       계속 스크럼을 사용해야 하나요?

d)       이전보다 더 나은 소프트웨어 개발을 하고 있나요?

e)       더 나은 제품을 만들고 있나요?

f)        제품 결험이 더 줄었나요?

g)       이전방식보다 더 빠르나요?

 

2)       General-Purpose Agility Assessments

a)       Shodan Adherence Survey

b)       Agile: EF

c)       Comparative Agility Assessment

3)       Creating Your Own Assessment

4)       A Balanced Scorecard for Scrum Teams

어떤 지표에대한 수치나 숫자하나를 제공하는 것보다 더 균형잡힌 시각이 필요하다.

균형성과 기록표를 위한 추천하는 관점

a)       운영효율성

b)       사용자 지향

c)       사업적 가치

d)       미래 지향

 

e)       Constructing the Balanced Scorecard

f)        Favor Simple Metrics

5)       Should We Really Bother with This?

 

5.2          You’re Not Done Yet

얼마나 애자일하게 되었는지나 스크럼을 얼마나 잘 하고있는지는 중요하지 않다. 오늘 하루 얼마나 좋았는지도 아무 상관없다. 하지만 만약 다음달에 더 나아지지 않았다면 당신은 더 이상 애자일하지 않다고 볼 수 있다. 당신은 언제나, 항상, 늘 나아지려고 노력해야한다.

 SucceedingWithAgile.docx

Implementing RUP - Agile Style v1.0.ppt

ScrumAndXpFromTheTrenchesonline07-31.pdf

ScrumIn5Minutes.pdf