Agile의 본질과 실천
- 1. 심형석 2021-10 Agile의 본질과 실천
- 2. • 7년째 Samsung Cloud 서비스플랫폼 개발 중 • 관심있는 것들 • 효과적인 학습법 (Learning how to learn) • 지속적으로 성과를 내는 개발팀 가꾸기 • 실용적인 S/W 설계, 개발, 운영 • 효과적인 커뮤니케이션, 티칭, 코칭 • 몸과 마음이 서로 좋은 영향을 주는 방법 발표자
- 3. 1. 배경 2. 본질 3. 실천 4. 현실 차례
- 4. 1. 배경 Agile이 등장했던 배경을 살펴보면서 Agile이 해결하려는 문제를 이해하자
- 5. • 증상 • 예산 초과, 일정 지연, 비효율, 낮은 품질, 요구사항 미충족, 유지보수 어려움 • 원인 • 소프트웨어의 대규모화, 복잡화 • 하드웨어 비용에 대한 소프트웨어 가격 상승폭 증가 • 유지보수 어려움, 개발정체 현상 • 신기술에 대한 교육 및 훈련의 부족 • 몇년도 소프트웨어 공학 학회 발표? - 1968년 나토 소프트웨어 공학 학회 Software 위기
- 6. Software 공학의 접근 방식 Engineering - Professional art of applying scientific principles to every day things to help make life easier Software engineering - Computer science 를 현실에 적용하는 Engineering • 개념 • Software에 Hardware 생산에 사용한 공학적 기법을 도입하자 • Software 생명주기 단계별 체계적, 정량적 도구, 방법, 절차 정의하고 관리 • 계획관리, 품질관리, 위험관리 • Hardware와 다른 Software의 특징 • 보이지 않음, 복잡함, 변경이 쉬움, 생산과정 자체가 고도의 지적 활동 • Hardware 분야의 Engineering 기법을 쉽게 적용하기 어려움
- 7. • 건축공학(Architectural engineering)에서 개발 방식을 가져옴 • Software 특성으로 인한 어려움은 “체계화”, “규격화”, “문서화”, “측정”의 강화로 해결하자 • 공학적 접근은 결과적으로 프로젝트 성공에 긍정적 영향을 줌 Software 공학의 접근 방식 건축계획 건축설계 시공 준공검사 S/W 계획 분석,설계 구현 검증
- 8. • 2000년 전후 Software 환경의 변화 • 일반 대중이 사용자가 됨 • 비즈니스 라이프 사이클이 짧아짐 • Software의 복잡도 증가 (소스코드의 크기 지수증가) Software 개발 환경의 변화 VUCA 소프트웨어 위기 심화 *VUCA : Volatility (변동성), Uncertainty (불확실성), Complexity (복잡성), Ambiguity (모호성)
- 10. • 소프트웨어 공학 도입 - 문서, 프로세스, 도구, 측정, 통제 강화 • 계약과 계획 준수 강조 • 갑과 을의 입장차이 - 비용/일정/품질 , 요구사항 변경 • 계약의 역효과 • Hardware와 다른 Software의 특징과, 더욱 복잡하고 불확실해진 환경을 고려 한 다른 해결책이 없을까? 환경변화에 대한 업계의 대응 ‘그들은 돈은 충분했지만 결코 소프트웨어를 잘 만든다고 할 수 없었다. 항상 납기가 지연되었고 납품된 소 프트웨어의 품질에 문제가 있었다. 그 결과 끊임없이 관리직에게 압력을 받으며 마치 벌레 같은 취급을 당 했다. 그들의 삶의 질을 바꾸는 작은 변화는 무엇일까? - 제프 서덜랜드 2012년 인터뷰 <애자일과 스크럼, 2014> 재인용
- 11. • 프로젝트 성공률을 높이는데 도움을 주는 경험적인 방법들 • 2001년 2월 17명의 Guru들이 유타주 스키리조트에 모여 2박 3일동안 기존의 무거운 방법론보다 상황에 빠르게 적응할 수 있는 가벼운 대체방법 론의 필요성에 대해 토론 • Agile Manifesto • Twelve Principles of Agile Software Agile의 등장
- 12. 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다: Individuals and interactions over processes and tools 공정과 도구보다 개인과 상호작용을 Working software over comprehensive documentation 포괄적인 문서보다 작동하는 소프트웨어를 Customer collaboration over contract negotiation 계약 협상보다 고객과의 협력을 Responding to change over following a plan 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다. Agile Manifesto
- 13. •우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다. •비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력 에 도움이 되게 한다. •작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라. •비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다. •동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝 내리라고 신뢰하라. •개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다 •작동하는 소프트웨어가 진척의 주된 척도이다. •애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다. •기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다. •단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다. •최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다. •팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다. 애자일 선언 이면의 12가지 원칙
- 14. • 자율성? • 수평적이고 자율적인 조직문화? • Iteration을 통한 개발? Agile의 목표 프로젝트 성공률 높이기 VUCA 환경에서
- 15. • 1968년 S/W의 위기! -> ‘공학’적으로 해결하는 방향으로 발전하고 있었다 • 2000년 전후로 S/W ‘불확실성’이 높아지고 위기는 더욱 깊어졌다 • 당시 S/W 업계의 방식과 다른 방식으로 S/W 위기를 해결하던 사람들 등장 • Agile Manifesto와 12개 원칙은 ‘해결책’이지 ‘질문’이 아니다 • Agile의 목표: ‘불확실성’이 높은 환경에서 ‘프로젝트의 성공률’ 높이기 배경 정리
- 16. 2. 본질 Agile의 핵심인 협력과 피드백이 무엇인지, 어떻게 소프트웨어의 위기에 도움 이 되는지 생각해보자
- 17. • 도구와 실천방법을 Agile이라고 생각하는 경우가 많다 • 본질을 이해하지 못하면 • 도구와 실천방법을 잘못 적용하거나 • 실천방법을 사용할때와 사용하지 않아야 할때를 구별하지 못한다. 왜 본질을 이야기 하나? ‘질문’을 그들의 상황에 적용한 ‘해결책’만을 습득할 것이 아니라 ‘질문’자체 를 이해해야 우리 상황에 맞게 ‘해결책’을 적용하고, 필요하면 새로운 ‘해결 책’을 찾을 수 있다
- 18. 본질 - 불확실성 (VUCA) 우리가 하고 있는 일은 불확실성이 높은가? 확실성이 높은가? 불확실성에 대응하여 적응성을 높이는 두가지 무기 “협력”과 “피드백” 확실성이 높은 환경 • 잘 알고 있는 것 • 잘 변하지 않는 것 • 단순한 것 • 맥도널드 조리법, 매뉴얼화 하기 쉬움, 혼자서도 자신있게 할 수 있 는 일 불확실성이 높은 환경 • 잘 모르는 것 (새로운 도메인, 툴) • 잘 변하는 것 (요구사항, 전술) • 복잡한 것 (복잡한 도메인) • 소프트웨어 개발, 매뉴얼화 하기 어 려움
- 19. Software 공학과 Agile • 소프트웨어 공학의 해결방식 • 기본 전제 : 계획, 문서화, 프로세스, 측정, 통제를 통해 품질, 성공률을 높인다. • 복잡성, 모호함, 불확실성에 더욱 체계적이고, 정교하고, 확실한 계획과 통제 를 통해 문제를 해결하려 함 • Agile의 해결 방식 • 사람들이 함께하면서 통찰을 극대화하고, 위험을 최소화 - “협력” • 계획(결정)과 실제의 시간과 양의 차이를 최소화 - “피드백”
- 20. Software 결함과 비용
- 21. 협력, 협업, 분업 협력 (Collaboration) : 특정한 목적을 달성하기 위하여 서로 힘을 합하여 도움 협업 (Cooperation) : 생산의 온 과정을 여러 전문적 부문으로 나누고, 여러 사람이 각 부문별로 맡아 서 일을 완성하는 노동 형태 분업 (Divide work) : 생산의 과정을 여러 부문으로 나누어, 각각 사람이 분담하여 일을 완성함
- 22. 협력의 효과 • 좋은 일은 곱하기가 되고 안좋은 일은 나누기가 된다 • 통찰을 공유해서 함께 성장 • 문제를 빨리 발견하고, 좋은 해결책을 함께 찾을 수 있다 • 동료압력 - 더 집중하고, 더 올바르게, 정확하게, 좋은 방향으로 행동 • 함께하면 하기 싫은 일도 할 만 하다 협력은 피드백을 촉진하여 팀의 역량을 극대화 한다. 협력은 팀의 시너지를 통해 개인과 팀의 성과 달성을 돕는다. 협력은 인간적인 욕구를 충족시켜 팀의 지속 가능성을 높인다
- 23. • 분업이 필요할 때는? 결정된 환경. 불확실성이 낮은 환경 • 협력이 필요할 때는? 불확실성이 높은 환경 • Team vs Workgroup • Team : 한 목표를 위해 협력하는 조직. 구성원들의 그래프가 네트워크로 나타남 • Workgroup : 분업하는 사람들의 집합. 구성원들의 그래프가 트리구조, 스타 구조 협력과 분업, 팀과 워크그룹 우리 TG, 파트, 그룹은 Team인가? Workgroup인가? 우리는 협력하고 있는가? 분업/협업하고 있는가?
- 24. • 각자의 목표가 아니라 팀의 목표 개인에게 미션을 부여하고, 개인의 목표를 중심에 두면 팀의 시너지가 낮아짐 • 다양성 비슷한 사람들보다 다른 사람들의 협력이 시너지와 통찰을 촉진한다. (다른 성격, 다른 직무, 다른 관점, 고객 참여) • 신뢰(심리적 안전감) 솔직해도 (반대해도) 상대방과 나의 관계가 손상되지 않을 것이라는 믿음 없이 시너지가 생길 수 없다 • 존중 “교양있는 마음가짐의 표징은 어떠한 생각을 받아들이지 않고도 즐길 수 있는 것이다 - 아리스토텔레스” 주장하고 설득하기 전에 궁금해 하기, 사람이 아니라 ‘생각’을 비판하기 • 솔직함과 용기 우리는 발견한 문제점, 일정변경, 감정, 모름에 솔직할 용기를 가지고 있나? 협력을 ‘잘’하기
- 25. • 피드백은 불확실성을 어떻게 극복하는가? • 우리가 어디에 있는지, 목표에 접근하고 있는지 알게 해준다 (메타 인지) • 피드백은 학습의 필수 조건이다 • 목표가 어디로 움직이는지 파악하고 추진력의 방향을 재설정 한다 • 우리가 목표를 향해 가는 방법에 대해 가설을 세우고 실험할 수 있는 환경을 제공 한다 • 리스크를 빨리 감지하고 대응할 수 있게 해준다 피드백 피드백 (Feedback) : 어떤 행위의 결과가 최초의 목적에 부합되는 것인가를 확인하고 그 정보를 행위의 원천이 되는 것 에 되돌려 보내어 적절한 상태가 되도록 수정을 가하는 일
- 26. 피드백을 ‘잘’하기 • 일찍부터 결정(계획, 상상)과 피드백(실제)의 (시간적, 양적) 차이가 클수록 수정 비용이 늘어난다 목표 결정, 설계 결정, 코드구현 결정이 실제에 가까운지 일찍부터 확인하고, 일찍 수정하기 • 자주 한달에 한번보다 일주일에 한번 하루에 한번 다 끝내고 나서 몰아서 하는 피드백은 배움으로 연결되지 않음. (포스트 모템보다는 주기적인 회고) 예) 10개 퍼팅 후 첫번째는 들어갔고, 두번째는 안들어갔고… • 구체적으로 피드백의 내용을 이해하고 어느 부분을 조정할지 알 수 있어야 한다. 예) Error log가 있는데, 어느 코드에서 어떤 exception이 발생했는지 모름. • 일관되게 일관성이 있어야 학습이 일어남. 예) 70% 정확도의 피드백 -> 의미 없다
- 27. 본질 - 움직이는 타겟에 접근하기 • 모호하고 불확실한 움직이는 타겟을 ‘고객’과 함께 ‘고객’의 피드백을 일찍부터, 자주, 구체적으로 받으면서 알아내기 • 타겟을 향해 어떻게 다가갈 지 ‘동료’와 함께 ‘동료’의 피드백을 일찍부터, 자주, 구체적으로 받으 면서 알아내기 • 움직이는 타겟과 우리가 가까워져 가는지, 가까워져 가는 속도는 적절한지 일찍부터, 자주, 구체 적으로 확인할 피드백 장치 만들기 • 타고 갈 자동차를 만들때 함께 만드는 ‘동료’들과 타고 갈 ‘동료’들이, 만들고 있는 ‘자동차’ 가 필 요한 조건을 만족하는지 일찍부터, 자주 확인하기 • 타고 가는 자동차의 상태가 적절한지, 정비가 필요한지 일찍부터 자주 구체적으로 확인하기 • 자동차를 버리고 헬리콥터를 구매해야 할지 주기적으로 확인하고 피드백 받기 “모호하고 불확실한 움직이는 타겟의 위치와 내 위치를 매순간 파악하면서, 그 타겟을 향 해 달려갈지, 아니면 타고 갈 자동차를 만들지, 살지를 결정하고, 그 결정이 원하는 효과 를 내는지 살펴보고 조정하면서 일정 내에 적절한 비용으로 타겟에 도달하는 것”
- 28. • ‘불확실성’이 높은 환경(VUCA)이 Agile을 적용하기 좋은 환경이다 • 협력은 배움과 통찰, 다양성, 즐거움을 통해 적응성을 높인다 • 신뢰, 다양성, 존중, 솔직함과 용기를 통해 협력을 ‘잘’할 수 있다 • 피드백은 메타인지를 통해 목표의 위치와 방향, 우리의 위치와 속도를 알려 주며, 프로젝트 전 기간 동안 실험하며 개선할 환경을 제공한다 • 피드백은 배움을 촉진하여 한 프로젝트의 성공 확률을 높일 뿐 아니라, 구성 원과 팀의 배움을 통해 그 팀의 성공률 자체를 높여 준다 • 일찍부터, 자주, 구체적으로, 일관되게 다양한 대상에 대해 다양한 소스에서 피드백을 ‘잘’받을 수 있다 본질 정리
- 29. 2.5. 예열 다음으로 넘어가기 전에 지난번 발표 내용을 다시 떠올려 보자 그 날 깜빡하고 말씀 못드렸던 이야기들도 몇가지 있어요
- 30. 지난주 복습 • Agile의 등장 배경이 어떻게 됐죠? • Agile의 본질이 뭐죠? • 솔직해도 (반대해도) 상대방과 나의 관계가 손상되지 않을 것이라는 믿음 -> 이게 뭐죠? • 계획(결정)과 실제의 시간과 양의 차이를 최소화 -> 이게 뭐죠? • 교양있는 마음가짐의 표징은 어떠한 생각을 받아들이지 않고도 즐길 수 있 는 것이다 -> 누구?
- 31. 깜빡 했던 이야기 • Agile 창시자들 둘러보기 (아는 사람들 많죠?) • Robert C Martin 에 대한 여담 (정치, 인종, 여성비하 문제) • 소프트웨어 공학을 다시 공부하시면 많이 얻으실 수 있을거에요
- 32. Agile Initiators 둘러보기 • Kent Beck - Extreme Programming, Smalltalk, TDD • Ward Cunningham - Extreme Programming, Wiki, Design Pattern • Andrew Hunt, Dave Thomas - Pragmatic Programmer • Je ff Sutherland, Ken Schwaber, Mike Beedle - Scrum, Enterprise Scrum • Martin Fowler - Refactoring, UML Distilled • Alistair Cockburn - Crystal clear > Hexagonal Architecture • Robert C. Martin - Clean Code, Clean Coder …
- 33. 3. 실천 ‘본질’에서 알아봤던 협력과 피드백의 관점으로 주요 Agile 실천방법들을 살 펴보자. 이 실천방법들을 ‘어떻게’ 하는게 ‘잘’ 하는 것인지 생각해보자.
- 34. 실천에 앞서 • 불확실성이 높은 환경인지 고정 불변의 상황인지 생각해보기 • 고객이 누구인지 알아내기 • 팀 내부의 신뢰(심리적 안전감)을 구축하기 • 프로의 자세를 갖춘 팀원들로 구성된 팀인지 확인하기 • 이해당사자들을 파악하고, 어디까지 솔직해도 될지 판단하기 • 실험한다는 자세를 갖기
- 36. 코드 공동소유 • 개인에게 일을 할당하는가? 팀에게 일을 할당하는가? • 구체적인 Task는 개인에게 할당(또는 개인이 사인)하고 함께 작업(Pair work) • Backup 담당자(주, 부 담당자) 와 vs 코드 공동소유의 차이가 뭘까? • 코드 공동소유를 강화하는 기법들 • Test • Refactoring • Pair programming • Martin Fowler의 Code Ownership (강한 소유권, 약한 소유권, 공동소유) “공동 소유권은 모든 사람이 프로젝트의 모든 부분에 새로운 아이디어를 제공하도록 권장합 니다. 모든 개발자는 기능 추가, 버그 수정, 디자인 개선 또는 리팩터링을 위해 코드 줄을 변 경할 수 있습니다. 누구도 변화의 병목이 되지 않습니다.”
- 37. Pair programming • 우리는 바빠서 Pair programming 할 시간이 없어요! • Pair programming을 하면 시간이 더 걸린다? • 개발시간 증가, 결함 감소, 통합시간 감소. • 개발시간이 15% 늘어나고 결함이 15% 줄어들었다면 본전? 이득? • 시니어가 주니어 가르칠때는 좋지만, 시니어끼리는 불필요한것 같아요? • 함께하면 즐겁다(적어도 덜 짜증난다) 또 집중이 유지된다 • 구성원간 문제가 일찍 발견된다 - Agile is fragile “익스트림 프로그래밍에서 코드를 작성할때 두 프로그래머는 항상 pair programming 한다. 운전사와 항해사의 역할을 자주 번갈아가며 하는 것이 좋다”
- 38. Pair programming - Tips • 신뢰, 사회적 관계가 큰 영향을 미친다. 시작이 어려움 • 관계의 대칭성 : 전문가 vs 비전문가 파워를 맞추기 (질문, 직접유도) • 운전사와 항해사의 빈번한 교체 (5~10분 마다) : 구체와 추상 > 통찰 • Programming 만이 아닌 Work에 적용하자 (특히 귀찮거나 두렵거나) • 두려움을 내려놓고 용기를 갖자 (몰라도 괜찮다. 취약함을 드러내자) • 자주 피드백을 주고받자. (일의 진행상태 또는 엉뚱한길 아닌지. 배운것. 지치 지 않았는지 … )
- 39. TDD • TDD는 결정과 피드백 사이의 Gap을 인식하고 조절하기 위한 테크닉 - 켄트 벡 • 결정 : ‘이 방법으로 해야지’, ‘이걸 이용해서 짜야지’ • 피드백 : 성공/에러 • 결정과 피드백 사이의 갭을 얼마나 빨리 인식하고 수정할 것인가? • 이 갭이 크게 벌어질수록 수정 비용이 크게 든다. (극단적 형태 : 매몰비용) • TDD에서 협력: • 고객과 개발자의 협력 • 개발자간의 협력 “매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스. 개발자는 먼저 요구사항 을 검증하는 자동화된 테스트 케이스를 작성. 그 테스트 케이스를 통과하기 위한 최소한 의 코드를 생성. 마지막으로 작성한 코드를 리팩토링”
- 40. TDD - 한걸음 더 • 인수테스트와 유닛테스트를 모두 TDD로 • Feedback 품질 (신뢰성, 구체성) 관점에서 인수테스트와 유닛테스트의 차이점 • Private method도 테스트해야 하나요? • TDD의 보폭은 나의 불안감의 수준(불확실함의 수준)에 맞춰서 • Code coverage의 올바른 의미 • “이 code는 버그가 없다” vs “이 code에 Test로 드러내지 않은 기능은 없다” • Testing의 귀납적 성질 - Test가 모든 상황을 cover할 수 있는가? • TDD 강조 > Coverage가 자연스럽게 올라간다 • Coverage 강조 > Test 품질이 좋아진다고 보장하기 어렵다 (Cover하는 테스트 넣기) • TDW(Test Driven Work) 로 확장 • 발표를 한다고 하면, 이 발표로 기대하는 것을 정한다. 청중이 A, B, C를 이해하는것. • A, B, C를 이해시키기 위해 발표 자료의 핵심 문장들을 잡아본다. • 실제 발표를 상상하면서, 청중입장에서 어떻게 느껴지는지 생각해본다.
- 41. 데모 • 고객과 ‘목표’를 주기적으로 맞추기 위한 협력과 피드백 활동 • 데모는 일하는 방식에 변화를 강요함 • 통합을 미루지 않고 일찍부터 하도록 강요 • 중요한 순서로 기능을 정렬하도록 강요 • 고객의 목표라고 ‘판단’한 것과 실제 고객의 ‘피드백’ 사이의 갭을 관리 • 데모는 협업 조직간 ‘우선순위’ 압력에 효과적인 도구로 활용 가능 “Demo (Showcase) : 개발팀이 동작하는 소프트웨어를 시연하는 것. Product owner, 고객, 이해관계자에게 피드백을 요청하는 체크포인트”
- 42. 지속적 통합 (Continuous Integration) “Pay me now or pay me more later” • 동일한 의미 다른 표현 • Joel’s test, Microsoft : 일일빌드 • Extreme programming : Integrate often 규칙에서 Continuous Integration 표현 • Martin Fowler : Continuous Integration • 코드 수정(변경)과 통합(피드백) 사이의 차이를 작게 유지하는 기술 • 동시 작업이 많을수록 보폭을 작게 • 통합에 문제가 없음을 어떻게 확인할까? • 단위테스트/통합테스트 • 비기능 속성(품질속성) 관리
- 43. 지금까지 한 이야기들을 한 장의 그림으로
- 44. 지속적 전달 (Continuous Delivery) “Continuous Delivery is the ability to get changes of types - including new features, configuration changes, bug fixes and experiments - into production, or into the hands of users, safely and quickly in a sustainable way.” • Continuous Delivery와 Deployment • Continuous Delivery: • Continuous Deployment: • 코드 수정(변경)과 Production(피드백) 사이의 차이를 작고 단순하게 유지하는 기술 • CD의 반대는 무엇일까? • 지속적 전달의 반대 : Deployable 하지 않은 상태가 (길게) 존재하는가? • 지속적 배포의 반대: 변경을 얼마나 묶어서 한꺼번에 배포 하는가?
- 45. 회고 행동이 성찰을 만나야 통찰을 얻을 수 있고, 통찰은 새로운 행동으로 이어진다. • 일 하는 방법을 개선하기 위한 협력과 피드백 장치 • 제품을 개선하는 것 vs 제품을 개선하는 방법을 개선하는 것 • ‘되돌아보기’에 그치지 말고 현재와 미래를 어떻게 바꿀지 결정하고 행동에 옮기기 • ‘기록’, ‘행동’이 중요하다 • 회고 자체는 가치가 없다. 회고를 통해 나온 실행이 가치가 있다 • 서로의 감정 공유와 이해로 문제를 드러내고 신뢰를 만들어 갈 수 있다 • 구성원들의 감정적인 문제를 발견하는 통로 • 솔직함, 취약성을 드러내면서 신뢰를 강화하는 장치 • 꼭 스프린트 회고만 고집할 필요 없다. 한시간 작업 중간 회고도 가능하다 • 하루만 지나도 수십개의 생각들이 도망가 버린다 • 잊기 전에 과거를 기록, 성찰하고 행동을 계획해서 과거, 현재, 미래로 이어지는 흐름을 만들어라
- 46. 두가지 다른 차원의 개선 • 제품을 개선하기 • 제품에 대한 정확하고 풍부한 배경지식 • 제품의 문제점, 경쟁 제품 파악 • 개선의 대상은 제품 자체 • 개선하는 방법은 개선의 대상이 아님 • 많은 조직의 모습 • 제품 개선 속도가 상수에 가까움 • 일하는 방법을 개선하기 • 제품 개선활동을 하면서 별도 시간을 할애함 • 프로세스, 협력방식에 대한 깊은 이해 • 지속적인 학습 • 개선하는 방법(일하는 방법)이 개선의 대상이 됨 • 학습하는 방법 역시 개선의 대상 • 제품 개선 가속도가 상수에 가까움 회고 의도적 수련 성장 가속도 (복리)
- 47. 여유 • 창의성이 가장 필요할 때 창의성이 필요 없다고 생각한다 • 지금 방식대로 일을 해도 충분히 시간내에 마칠 수 있는 여유가 있을 때 • 지금 방식대로는 아무리 해도 만족스런 수준을 달성할 수 없을 때 • 창의성이 가장 필요할 때 창의성을 발휘하기 어렵다 • 긍정적 감정 상태에서 창의성이 잘 발휘되고, 부정적 감정 상태에서는 어렵다 • 큰 기회와 큰 위기가 와도 알지 못한다 • 터널 비전 - 부정적 감정 상태에서 물리적으로 시야가 좁아지는 현상 • 우리팀 일이 바빠서 다른팀 요청에 대응이 늦다. 서로가 이렇게 움직인다 • 모두의 효율이 떨어진다 > 우리팀 일조차도 빨리 해결할 수 없다 > 더 여유가 없다 > 악순환 너그러울 때는 온 세상을 다 받아들이다가 한번 옹졸해지면 바늘 하나 꽂을 여유조차 없다 … 그래서 마음에 따르지 말고 마음의 주인이 되라고 옛사람들은 말한 것이다 - 법정 <무소유>
- 48. 여유 - Tips • 마법의 주문 - “That’s interesting!” • Every unexpected event is a path to learning for you - 워드 커닝햄 • 다른 사람 도움 받기 (디버깅, 안풀리는 문제) - 협력 • 즐거운 시간 보내기, 기분전환 • 즐거운 경험 후에 창의성이 높아진다. 완전히 다른 시각이 보임 • 급하면 제거할 수 있는 Story, Task를 스프린트에 넣기 (보통 10% 내외) • 다른팀의 input이 되는 작업의 우선순위 높이기 스트레스가 과도한 조직은 효율을 강조하느라 바쁜 나머지, 효과적인 조직이 되는 법을 잊어버리게 된다 이 둘은 완전히 다른 개념이다 - 톰 디마르코 <슬랙>
- 49. • 가장 먼저 ‘불확실성의 정도’를 판단하자 • ‘아기발걸음’으로 시작해서 점차 보폭을 늘릴 수 있다 • 데모, 진짜 고객 참여 실천으로 고객과의 협력, 피드백을 강화할 수 있다 • Pair programming, 회고, 함께 앉기 실천 > 동료와의 협력, 피드백. • TDD, CI/CD, Monitoring > 코드와 시스템의 피드백 • 적절한 지표, UT > 비즈니스 상황과 고객의 피드백 실천 정리
- 50. 4. 현실 Agile을 실천하면서 겪는 여러 어려움들을 살펴보면서 우리팀이라면 어떻게 할지 생각해 보자
- 51. 보고, 업무 진척 확인용 일일미팅 • 상황 • 중간 관리자가 업무 진척 확인 및 추가요구사항 전달 용도로 일일미팅 활용 • 매니저가 팀 목표달성을 위해 본인이 해야할 일을 찾고 수행하지 않음 • 매니저가 참석 안하면 일일미팅 안함 • 일일미팅 외 별다른 애자일 실천 없음 • 진단과 개선 • 상황 진단 (장/단점) • 개선 방향 (협력, 피드백 관점)
- 52. 빠른 개발을 위한 스크럼 활용 • 상황 • 경영진이 ‘애자일’로 개발하면 빠르다는 이야기를 듣고 도입을 결정. 2주마다 데모하자. • 검증 없이 개발팀이 데모하고 알파 발행해라 > 임원, 기획, 검증부서가 실시간으로 버그 리포팅 • 다음 스프린트 개발해야 하는데 쏟아지는 버그 리포팅으로 개발할 시간 없음 • 일정은 뒤로 미루지 못하고, 버그는 수정해야 하고 첫 데모 이후 줄기차게 야근 • 국내 IT 게시판에 단골로 등장하는 케이스 • 베댓 : “자네 아직도 애자일을 믿나?”, “뒤틀린 황천의 애자일” • 진단과 개선 • 상황 진단 (장/단점) • 개선 방향 (협력, 피드백 관점)
- 53. 프로세스와 툴에 집중 • 상황 • 스크럼, Jira, Github, Code Review, Test, 정적분석, CI/CD, 모니터링 등 주요 툴을 도입 • 업무는 철저히 개인이 진행, 성과의 책임도 개인의 몫 • 초기 산정한 function points 에 따라 개인별 업무량 측정 • 사족 • 국내외 유수 IT 기업들의 모습 • 유능한 개발자는 만족하며 지내고, 빨리 적응하지 못하면 도태되는 경우 많음 • ‘전문가들이 모여야 애자일이 되는거에요’, ‘애자일은 죽었다’ 이런말의 원천 • 진단과 개선 • 상황 진단 (장/단점) • 개선 방향 (협력, 피드백 관점)
- 54. 평소엔 애자일 한데 급해지면 안되는 팀 • 상황 • 바쁘지 않을때는 일일미팅, Pair programming, 공동 설계, 회고 등 협력과 피드백을 적극적으로 잘 활용 • 일정이 급해지거나 리스크가 심해지는 상황이 오면 개개인이 각자 작업하는 방식으로 회귀 • 긴급한 일 해결하고 나면 ‘우리 다시 잘 해봅시다’ 하면서 다시 시작 • 진단과 개선 • 상황 진단 (장/단점) • 개선 방향 (협력, 피드백 관점)
- 55. 팀원 개인에게 팀과 무관한 별도의 업무부과 • 상황 • 모범적으로 협력과 피드백을 활용하여 업무를 수행하며 성장하는 팀이 있는데, • 경영진이 이 팀의 구성원 개인에게 팀과 무관한 별도의 업무(몇달 이상 소요되는 장기 업무) 진행 지시 • 팀 업무에 50%, 별도 업무에 50%를 쏟아야 하는 상황 • 팀 내부에서 우선순위 조정 못함. 별도의 일에 팀이 관심을 가져야 하는지 말아야 하는지 혼란스러움 • 팀의 목표 달성은 지연되고, 이 구성원은 팀 동료들에게 미안한 감정으로 마음이 불편함 • 진단 및 개선방안 • 협력의 관점 • 피드백의 관점 • (글) Single-Threaded Ownership - Amazon
- 56. 팀 내부에서만 애자일하게 돌아가는 팀 • 상황 • 팀 내부에서는 애자일 실천을 잘 하고 있음 • 회고에 긍정적인 피드백이 많고, 성장하고 있다고 느낌 • 외부와의 커뮤니케이션이 별로 없음. (내부는 촘촘한 커뮤니케이션이 일어남) • 팀 분위기만큼 좋은 성과가 나오지는 않음 • 진단 및 개선방안 • 협력의 관점 • 피드백의 관점 • 닫힌 그룹 • 단기 피드백 집착
- 57. Layer 별 기능 팀 • 상황 • Layer별 기능조직 구성 • 고객참여 많지 않음. Layer별 팀에서 협력과 피드백을 활용 • 여러 Layer에 걸친 과제를 위해 별도 Part-time TF 구성 -> 여러 팀의 일정을 조율해야 함 • 팀 입장에서는 여러개의 목표가 동시에 진행되는 형태로 우선순위 판단이 어려움 • 진단 및 개선방안 • 협력의 관점 • 피드백의 관점 • (글) Single-Threaded Ownership - Amazon
- 58. 합의가 너무 어려운 팀 • 상황 • 결정에 합의하는데 지나치게 많은 노력과 시간이 걸림 • 중요성에 비해 과도한 논쟁으로 에너지와 시간이 소비됨 • 진단 및 개선방안 • 협력의 관점 • 피드백의 관점 • (글) Amazon의 신속 실행 비결 : 동의하지 않아도 헌신한다 (Disagree and Commit)
- 59. 소프트웨어 설계를 애자일하게 • 소프트웨어 설계의 불확실성 • 요구사항이 얼마나 복잡한가? • 요구사항이 얼마나 변경 가능성이 높은가? • 요구사항이 얼마나 모호한가? • 불확실성이 높은 상황의 소프트웨어 설계 • 협력(다양성, 고객, 동료) 과 피드백을 강화하는 방향 (아기 발걸음) • 추상(상위설계, 설계)과 구체(하위설계, 구현)를 자주 오가기 • 불확실성이 낮은 상황의 소프트웨어 설계 • 협력의 수준과 피드백의 주기를 낮추기 (한번에 잘 설계해서 구현하기)
- 60. 배움을 애자일하게 • 학습과 팀의 관계 • 빠른 학습, 고성과 팀: 학습을 팀의 중대한 목표, 기회와 가능성 강조, 실험하는 자세 • 느린 학습, 저성과 팀: 학습을 개인의 과제로 간주, 단기 성과 강조, 실패없이 한번에 성공해야 한다 • 의도적 수련 (Deliberate Practice) • 1만시간 법칙 • 업무 시간 중 불안함이나 지루함을 느끼는 시간이 대부분이다?
- 61. 부정적인 감정을 다루기 • 감정을 인정하기 • 우리 모두 두려움, 불안함, 슬픔, 좌절감을 느낄 수 있는 존재이다 • 우리는 감정 없는 존재가 될 수 없고, 감정이 없어야 한다고 믿어서도 안된다 • 감정은 보통 실재를 반영한다. 감정을 느끼고 인정하면 그 이면의 문제를 찾는데 도움이 된다 • 감정적이지 않기 • 우리는 짧은 시간동안 이 공간에 ‘짐작’을 채워 넣는다. • 자극 > 짐작 > 감정 > 반응이 순식간에 일어나면 감정적인 대응이 된다 • 짐작하지 않고, 사실에서 멈추고 질문하기 • 반응하지 않고, 감정에서 멈추고 짐작을 인지하고 질문하기 • 감정적으로 대응 했음을 인지하고 사과하고 질문하기 자극과 반응 사이에는 공간이 있다. 그 공간 안에는 우리의 반응을 선택할 수 있는 힘이 있다. 그 반응에 우리의 성장과 행복이 달려있다. - 빅터 프랭클
- 62. 부정적인 감정을 다루기 • 자극과 짐작 사이 ‘욕구의 좌절’ • 자극 > ‘욕구의 좌절’ > 짐작 > 감정 > 반응 • 숨어있는 욕구를 찾아내기 • 내 욕구를 이해하기 • 상대방의 욕구를 이해하기 • 비폭력 대화
- 63. • 수많은 문제들이 우리가 ‘제대로’ 지속적으로 성장하면서 성과를 내기 어렵 게 합니다. • 그래도 애자일의 본질을 이해하면 상황을 이해하는데 도움이 됩니다 • 지혜와 용기를 주는 문구 들로 긴 말을 대신합니다 현실 정리 그리고 마무리 주여, 우리에게 우리가 바꿀 수 없는 것을 평온하게 받아들이는 은혜와 바꿔야 할 것들을 바꿀 수 있는 용기 그리고 이 둘을 분별하는 지혜를 허락 하소서 - 라인홀트 니버 <Serenity Prayer> You can change your organization or change your organization. - Martin Fowler 지금 상황과 상관없이 여러분은 언제나 더 나아질 수 있다. 더 나아지는 일은 언제나 스스로부터 시작할 수 있다. 더 나아지는 일은 언제나 오늘부터 시작할 수 있다. - Kent Beck <익스트림 프로그래밍 서문>
- 64. 참고하실 문서, 책 • (책) Extreme programming - Kent Beck, 김창준 역 • (책) 함께 자라기 - 김창준 • (책) Slack - 톰 디마르코 • (책) 무소유 - 법정 • (책) 인사이드 아웃 - 강성천 • (블로그) 애자일 이야기 - 김창준 • (글) 창의성 아이러니 - 김창준 • (글) 뒤돌아보다 - 김창준 • (글) Code Ownership - Martin Fowler • (글) Continuous Integration - Martin Fowler • (Podcast) 애자일 키워드 - 김창준 • (Site) The rules of extreme programming • (글) Continuous Delivery - Martin Fowler • (책) 비폭력 대화 - 마셜 로젠버그 • (PDF) Je ff Bezos 2017 letter , 한글번역 • (글) Single-Threaded Ownership - Amazon • (글) Amazon의 신속 실행 비결 : 동의하지 않아도 헌신한다 (Disagree and Commit)