Agile SW 개발

1. SW 개발 OPENSNS 권혁 Agile

2. - 어느 출근길(feat. 권혁 부장)

3. What’s the Problem

4. | Traditional Practices Requirement • Requirement Doc. • Prepare Use Cases Design • Software architecture • Map the stakeholders Implementation • Construct the software • Data storage & retrieval Verification • Install • Test and Debug Maintenance • Check errors • Optimize capabilities 초기에 모든 요구사항/일정/ 자원에 대한 정의 개발이 들어가기 시작하면 변경사항은 계획에 위협 마지막 단계에서 고객에게 이 익을 전달 Waterfall Methodology

5. 어이쿠 | Waterfall 방법론의 문제점

6. 자!! 이제 오픈 했으니 요구사항 추가다!

7. 개발기간이 얼마 남지 않았어. 모두 주말 출근이다!

8. | Agile 방법론의 등장 배경 – 패러다임의 변화 Time to Market Budget Risk Cancellation Cost Scope Creep Requiremen ts Error Technology Risk Testing Risk

9. Why?Agile

10. | Why Agile Constraints Estimates Waterfall Agile 계획 중심으로 일정/비용 산정 비전/가치 중심으로 기능 산정 Features Cost Schedule ScheduleCost Features Michelle Slinger in “Relating PMBOK Practices to Agile Practices” Value/Vision Driven Plan Driven

11. | Core Value Better Software 중요한 것 먼저 지속적인 변화 관리 더 나은 의사소통

12. | Agile 방법론의 가치제안(VALUE PROPOSITION) VISIBILITY ADAPTABILITY BUSINESS VALUE RISK Agile Development Traditional Development

13. What is Agile

14. | Agile 선언문 http://agilemanifesto.org/

15. | Agile 선언문 http://agilemanifesto.org/

16. 공정과 도구보다 개인과 상호작용을 Agile Value #1 I’m EXCEPTION • 소프트웨어는 기계가 아닌 사람이 만들고 사람이 사용 • 애자일은 소프트웨어의 중심인 사람에 더욱 큰 가치를 두고 있다는 것

17. 포괄적인 문서보다 작동하는 소프트웨어를 Agile Value #2 어떻게 잔디를 갈퀴질 할 것인지 에 대한 계획서 작성 우아한 잔디 무늬에 대한 디자인 제시 섬세하면서 포괄적인 청소 계획 수립 고객에게 가치 있는 결과물은 무엇일까?

18. 계약 협상보다 고객과의 협력을 Agile Value #3 • 프로젝트 시작도 전에 초기에 계약과 스펙, 요구사항을 확정 짓는 것보다 • 개방적이고 적극적인 커뮤니케이션을 통해 고객과 더 나은 솔루션을 찾는 것 • 내가 스스로 그리고 먼저 나의 모든 가시적, 잠재적 고객들에게 적극적으로 노력 고객님 원하시는 게 뭐에요?

19. 계획을 따르기보다 변화에 대응하기를 Agile Value #4 • 플랜A가 실패한다고 걱정하지 말라. 25개의 알파벳이 더 있으니 • 외부 환경이나 현실에 대한 변화만이 아니라 스스로의 변화도 필요 • 모든 내적 외적 변화를 이해하고 반영하고 발전해 나가기 위해 노력

20. 소프트웨어의 12가지 원칙 Agile

21. PLAN Analysis Design Develop Test Deploy Operate PLAN Analysis Design Develop Test Deploy PLAN Analysis Design Develop Test Deploy PLAN Analysis Design Develop Test Deploy Operate 이익 비용 이익 비용 투자 투자 회수 회수 Late ROI Early ROI TraditionalAgile 우리의 최고 우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달함으로써 고객을 만족시키는 것이다.

22. 비록 개발 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

23. | 불확실성의 뿔(Cone of uncertainty) 0.25x 0.5x 0.67x 0.8x 1.0x 1.25x 1.5x 2x 4x Variability in the Estimate of Project Scope (effort, cost, features) Time Initial Concept Approved Product Definition Requirements Complete UI Design Complete Detailed Design Complete Software Complete Software Project Survival Guide (Steve McConnell 1997)

24. 작동하는 소프트웨어를 자주 전달하라. 약 2주에서 2개월의 정도의 간격으로 전달하되, 간격이 짧을수록 좋다.

25. | The Agile Mona Lisa (http://www.yoomee.com/about-agile) Women in Pastoral Setting

26. • 15,000+ developers in 40+ offices • 4000+ projects under active development • 5,500+ submissions per day on average • All Builds from source • 20+ sustained code changes per minutes with 60+ peaks • 50% of code changes monthly • 75+ million test cases run per day | How Google Tests Software(2012) • 구글은 애자일 개발과 Scrum의 Early adopter • 오래 전부터 엔터프라이즈 레벨에서 Agile Testing 기법을 사용 • 15,000명 이상의 개발자가 매일 7,500만 테스트를 실시

27. 비즈니스 영역 사람들과 개발자들은 프로젝트 전체에 걸쳐 매일 함께 일해야 한다.

28. 동기가 갖추어져 있는 개인들로 프로젝트를 구성하라. 그들에게 그들이 필요로 하는 환경과 지원을 제공하라. 그리고 그들이 일을 끝낼 수 있도록 신뢰하라.

29. Project Manager “나를 따르라” Self- Organizing Customer Leader Tester AA/DA/QA Developers Coach Facilitator Cross Functional Teams • 작업은 팀을 중심으로 구성 • 대부분의 작업은 PM에 의해서 할당됨 • Functional silos(자기부서의 이익만 추구) • 팀은 작업을 중심으로 구성 • 같이 참여하는 고객 • 책임감과 자율성/자기 조직화/자기 관리 • 직위나 역할에 상관없이 누구나 프로젝트에 필 요한 일을 함, 품질은 팀 모두의 책임 Product Owner Traditional Team Agile Team

30. http://pleaseenjoy.com/projects/personal/10-levels-of-intimacy-in-todays-communication 어떤 다른 개발팀을 상대로, 혹은 개발팀 내에서, 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 보고 하는 대화이다.

31. 작동하는 소프트웨어가 진척 측정의 주된 척도이다. PLAN Analysis Design Develop Test Deploy Operate PLAN Analysis Design Develop Test Deploy PLAN Analysis Design Develop Test Deploy PLAN Analysis Design Develop Test Deploy Operate 이익 비용 이익 비용 투자 투자 회수 회수 Late ROI Early ROI TraditionalAgile

32. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자 그리고 사용자들은 일정한 속도를 계속 유지할 수 있어야 한다.

33. [기업이 변해야 김대리가 산다] <6> 근로시간 단축 효과 야근 않고 회의 줄이니 매출 쑥쑥·고용 껑충 “우리도 야근을 없애고, 직원들 휴가도 자주 보 내주고 싶습니다. 그런데 당장 시행하기에 겁이 나네요. 매출이 떨어지거나 필요한 업무를 제대 로 처리하지 못하진 않을지 걱정이 앞섭니다.” 반도체 부품을 만드는 중소기업을 운영하는 A씨 는 2013년 근로시간을 단축하겠다는 계획서를 고용노동부에 제출했다. 하지만 갑작스러운 주 문 물량 증가 등 경영환경 변화로 결국 계획을 이행하지 못했다. A씨는 “야근이나 회식을 줄이 고 회의를 짧게 하는 등 업무효율성을 높이면 직 원들의 만족도가 높아지는 것을 모르는 것은 며 “다만 생산성 상승이 담보되지 않는 상황에서 섣불리 시행하기는 어렵다”고 털어놨다. 기업 입 장에서는 근로시간 단축과 업무 방식 개선이 일종의 모험인 셈이다. 오랜 시간 자리잡아 왔던 장 시간 근로 관행을 하루아침에 고치는 것이 쉽지 않은 데다 단기간 시행으로는 효과가 나타나지 않 는 경우도 있기 때문이다.

34. 기술적 탁월함과 좋은 설계에 대한 지속적 관심이 기민함을 향상시킨다.

35. 간결함-하지 않아도 되는 일의 양을 최소화하는 기술은 필수적이다.

36. 최상의 아키텍처, 요구사항 그리고 설계는 자기조직화 (self-organizing)되어 있는 팀에서 나온다.

37. 팀은 정기적으로 더 효과적으로 일할 수 있는 방법을 숙고하고, 그에 따라 자신/팀의 행동을 조율하고 조정한다.

38. 에 대한 오해Agile

39. A specific methodology Agile Software Development Agile Method Practices Scrum Crystal Adaptive XP FDD RUPKanban Time-boxing User-stories Daily scrum Reviews Continuous Integration Test-driven Development Visual Management

40. Glorified hacking

41. Working without planning

42. A silver bullet

43. Suitable for all types of projects

44. Need

45. PRACTICES AGILE VALUES Working Deliverables Human Interactions Customer Collaboration Responding to Change AGILE PRINCIPLES Simplicity Human Transparency Frequent Delivery Customer Involvement Technical Excellence Team Work Self Organisation Emergent Design Working Deliverables Continuous Improvement Sustainable Pace AGILE TEAM PRACTICES AGILE TECHNICAL PRACTICES Test-Driven Development Continuous Integration Automated Deployment Incremental Design and Architecture Acceptance Test-Driven Development Refactoring Technical Spikes Exploratory Testing Collective Code Ownership Deﬁnition of Done Colocation Daily Stand Ups Iteration Planning Customer Showcase Retrospective Adaptive Release Plan Cross-Functional Team Requirements as Stories Planning/Story Wall Informative Workspace Burn Up/Down Charts Parking Lot Diagrams Success Sliders Planning Poker PRINCIPLES VALUES | Agile Foundation

46. | Agile Delivery Approach 제안된 아이디어의 기술적 가능성과 비즈니스 가치를 평가 제안된 아이디어를 정제하고 구체화 개발준비를 위한 계획 준비 반복적 개발을 통 해 고품질의 동작 하는 소프트웨어를 전달 동작되는 소프트웨어를 운영환경에 배포 ITERATION ITERATION ITERATION ASSESS PLAN DELIVER DEPLOY 05% 10% 80% 05%

47. 프로젝트Agile Inception

48. 운전 기사 어떤 놈이야~ 오른쪽으로 갔어야지 바보야! 아직 멀었나? 에어컨 좀 틀어주세요 AC 전 전거장에서 내렸어야 했는데 잔말 말고 그냥 따라와 시끄럽다 조용히 좀 가지! 대부분의 프로젝트는 시작도 하기 전에 실패한다.

49. | Inception Deck • 대부분의 프로젝트가 실패하는 이유는 • 성공의 의미가 서로 다르게 해석되는 경우가 많다. (동상이몽)

50. | Inception Deck • 프로젝트 성공 확률을 높이기 위해 • 프로젝트 시작 시점에… • 프로젝트 관련자들이 함께 모여… • 프로젝트에 대한 기대하는 바가 동일하도록… • 적절한 질문을 통해 생각을 공유 • 추정하지 말고 명쾌하고 진술하고 질문하기 • 꼭 물어야 하는 10가지 질문으로 구성 • ~couple days, a week • 1~6 months of planning • 프로젝트 초기 단계에 고객과 개발팀이 서로를 알아가는 과정. “Inception Deck” 이 시기에 사용하는 도구

51. Enter Inception Deck 1. 우리가 왜 여기 모였는가? 2. 엘리베이터 피치 만들기 3. 제품 박스 디자인 하기 4. 하지 말아야 할 리스트 만들기 5. 프로젝트 관련자 알아보기 6. 해결책을 보여주기 7. 무엇이 야근거리가 될 것인가? 8. 규모 정하기 9. 기회비용 파악하기 10.우선 순위 파악하기 모두가 함께 버스에 안전하게 탑승 목적지까지 성공적으로 운행

52. • 고객, 프로젝트 구성원 모두 같은 목표와 비전을 공유 • 더 많은 정보를 공유함으로 • 서로 대립하는 세력과 Trade-off이 균형 유지 • 자율적으로 생각하고 판단하는 능력으로 혁신적인 해결 책 모색 • 우리가 이 프로젝트를 해야 할 이유는 무엇인가? 1. 우리가 왜 여기 모였는가? (Ask why we are here)

53. 2. 엘리베이터 피치 만들기 (Create an Elevator Pitch) Pitch me the Wii.

54. 2. 엘리베이터 피치 만들기 (Create an Elevator Pitch) For [어린 자녀를 분 부모들] Who [전통적인 게임 콘솔을 지루해하는 ] The [닌텐도 위] is a [패밀리 엔터테인먼트 시 스템] That [온 가족이 함께 즐길 수 있는] Unlike [XBOX, PS3은 복잡한 조이스틱과 컨 트롤러를 가지고 있음] Our Product [온가족(심지어 할머니도)이 함께 즐길 수 있는 자연스러운 제스쳐를 기반으로 한 게임기] • 프로젝트의 핵심을 분명히 이해 (Seeing the big picture) • 팀원으로 하여금 고객의 입장에서 생각하도록 함

55. 2. 엘리베이터 피치 만들기 (Create an Elevator Pitch) For [target customer] Who [statement of the need or opportunity ] The [product name] is a [product category] That [key benefit, compelling reason o buy] Unlike [primary competitor] Our Product [statement of primary differentiation] • 프로젝트의 핵심을 분명히 이해 (Seeing the big picture) • 팀원으로 하여금 고객의 입장에서 생각하도록 함

56. • 제품의 기능을 고객에게 일일이 설명하려는 바보 같은 짓은 절대 하지 말자. (Features) • 고객이 정말 알고 싶어 하는 것은 과연 이 제품이 자신의 삶의 질 을 더 낫게 할 수 있는지에 있다. (Benefits) • Step 1. List the benefits • Step 2. Create a slogan • Step 3. Draw your creation 3. 제품 박스 디자인 하기 (Design a product box)

57. 4. 하지 말아야 할 리스트 만들기 (Create a NOT list) • 범위 내 – 프로젝트 진행 시 꼭 해결해야 할 중요사항 • 범위 외 – 다음 릴리즈나 이 프로젝트에서 해결 할 수 없는 것들 • 미해결 – 더 고민 한 후 결정해야 할 사항

58. 5. 프로젝트 관련자 알아보기 (Meet your neighbors) • 언제나 관련자들은 생각하는 것보다 크다 • 이 프로젝트에 관련된 사람들이 누구인지 파악하는 것이 중요

59. 6. 해결책을 보여주기 (Show the solution) • 팀을 고르기 전에 아키텍처를 결정 • 해결책을 이야기 함으로써 얻는 이점들 • 어떤 도구나 기술을 사용할 지 추축할 수 있다. • 프로젝트의 제약사항이나 범위를 시각화 할 수 있다. • 리스크에 대해 상의할 수 있다.

60. 7. 무엇이 야근거리가 될 것인가? (Ask What Keeps Us Up at Night) • 리스크를 미리 파악하면 좋은 점 • 프로젝트를 하는 동안 감수해야 할 문제점들을 일찍 파악 • 납득할 수 없는 이야기에 대한 반론의 기회 • 팀의 결속력을 강화, 서로의 경험을 배울 수 있는 기회

61. 8. 규모 정하기 (Size It Up) • 프로젝트가 얼마나 걸리는지 예측해보는 것으로, 정확하지 않아도 언제쯤 소 프트웨어가 출시될 지 알아야 한다. • 작고 다룰 수 있는 크기로 나누어야 한다. (Iteration based) • 현재 상태의 가능한 정보를 기반으로 합리적인 기간을 예측하여 관련자에게 알려주어야 한다.  상황이 변경되면 계획은 수정

62. 9. 기회비용 파악하기 (Be Clear on What’s Going to Give) • 프로젝트의 제약을 파악하고, 이에 대한 대책을 생각하라 • 프로젝트에서 집중해야 할 대상에 대한 토론을 통해 위기상황 발생 시 가이드 라인 마련

63. 10. 우선 순위 파악하기 (Show What It’s Going to Take) • 계획을 세웠으면, 이를 구현하기 위해 필요한 것과 비용을 알아 내야 한다. • 최고의 팀 구성 • 최종 결정권자 파악 • 비용에 대한 예측 • 모든 정보의 수집

64. Inception Deck 정리 • 프로젝트 시작 전에 이 프로젝트가 가지는 가치와 비전에 대해 기틀을 잡고 시 작할 수 있음. • 10가지 질문에 대한 결과는 모든 팀원과 이해관계자와 공유해야 한다. • 반드시 수행해야 할 도구는 아니다. • 하지만 프로젝트 시작 전에 껄끄러운 질문/이슈에 대해서 자연스럽게 토론할 수 있도록 지원 • Pcolla sub project는 inception deck을 작성해보자!

65. 개발 프로세스Agile Scrum

66. What is Scrum • 스크럼이란 단어는 럭비(혹은 미식 축구)에서 유래 1. 게임의 기본 단위가 정해진 시간이 아닌, '공이 땅에 떨어질 때 까지'라는 유동적인 단위로 진행되며 (이 단위를 스프린트::도약 라고 함) 2. 개인에 의해 정확히 정해진 포지션보다는, 한 스프린트마다 상황과 전략에 따라 팀원들의 위치와 역할이 유동적으로 정해짐

67. | Scrum이란 • 스크럼은 프로젝트 관리를 위한 애자일 방법론으로서 추정 및 조정 기반의 경 험적 관리기법의 대표적인 형태 • 럭비스타일의 두 가지 특징을 소프트웨어 엔지니어링에 적용한 것이 스크럼 개발 방법론 • 커다란 프로젝트를 작은 단위로 나누고, 그 작은 단위를 하나의 팀이 모두가 집중적으로 파고들어 끝낸다는 것

68. | Scrum이란 • 스크럼은 프로젝트 관리를 위한 애자일 방법론으로서 추정 및 조정 기반의 경 험적 관리기법의 대표적인 형태 • 럭비스타일의 두 가지 특징을 소프트웨어 엔지니어링에 적용한 것이 스크럼 개발 방법론 • 커다란 프로젝트를 작은 단위로 나누고, 그 작은 단위를 하나의 팀이 모두가 집중적으로 파고들어 끝낸다는 것

69. | 가치 있는 소프트웨어를 일찍 그리고 자주 전달하라 • OBJECTIVE: • Deliver a Product Increment in a fixed time period • Called a “SPRINT” Commit & Deliver Commit & Deliver SPRINT LENGTH SPRINT LENGTH Potentially shippable product increment Potentially shippable product increment

70. Process

71. | Scrum의 역할 Product Owner Scrum Team Scrum Master • 제품 기능목록에 해당하 는 제품 백로그(product backlog) 생성 • 우선순위 조정 • 스프린트 계획 수립 • 스프린트 시작 시에는 팀 운영에 관여하지 않음 • 스크럼의 원칙과 가치를 지키면서 스크럼 팀이 개 발을 진행할 수 있도록 지원 • 스크럼 팀의 업무를 방해 하는 요소를 제거하기 위 해 노력 • 보통 5~9명으로 구성되며 하나의 스프린트 기간 동 안 구현해야 할 기능을 사 용자스토리로 도출/구현 • 스프린트 동안 구현해야 하는 기능을 완료하기 위 해 노력

72. | 제품 백로그 (Product Backlog) • 제품에 담고자 하는 기능의 우선순위를 정리한 목록, 고객을 대표하여 제품 책 임자가 주로 우선순위를 결정 • 제품 백로그에 정의된 기능을 사용자 스토리라고 부르며 사용자 업무량에 대 한 추정은 주로 스토리 포인트라 불리는 기준을 이용

73. User Story • 사용자 스토리란 서비스 고객에게 가치를 줄 수 있는 기능을 서술 • 좋은 사용자 스토리는 다음 요소를 갖춰야 함 (INVEST) • 독립적이다. (Independent) • 다른 스토리에 종속되지 않아야 한다. • 협상 가능해야 한다. (Negotiable) • 너무 세세하게 작성하지 말아야 한다. • 가치가 있어야 한다. (Valuable) • 추정 가능해야 한다.(Estimable) • 적당한 크기여야 한다. (Sized right) • 하나의 이터레이션에서 개발할 수 있어야 한다. • 테스트 가능해야 한다. (Testable)

74. User Story 앞면 뒷면 As a <role>, I want to <shot description of feature> so that I can <value or why need functionality> Given … <some initial context> When … <an event occurs> Then … <ensure some outcomes> 통합테스트 조건 만족 <스토리 포인트>

75. User Story Point 앞면 As a <role>, I want to <shot description of feature> so that I can <value or why need functionality> <스토리 포인트> • 사용자 스토리 중에서 추정 가능한 적 당한 스토리를 3으로 정하고 스토리 포인트 단위 정함 • 기준을 기점으로 상대적인 크기 계산 • 3보다 2배정도 큰 일이면 5 • 3보다 절반정도면 1,2 • 플래닝 포커 게임과 결합하여 사용

76. | 스프린트 계획 (Sprint planning) • 각 스프린트에 대한 목표를 세우고 제품 백로그로부터 스프린트에서 진행할 항목을 선택 • 각 항목에 대한 담당자를 배정하고 태스크 단위로 계획을 수립 • 각 스프린트에 해당되는 스프린트 백로그 생성 • 플래닝 포커(Planning Poker) 등의 기법을 활용하여 추정

77. Planning Poker 1. 모든 팀원들이 카드를 한 벌씩 나눠 갖는다. 2. 태스크 하나를 두고 자신이 생각하는 작업 시간 카드를 선택한다. 3. 모두가 동시에 카드를 뒤집어서 일치하는 시간이 나오면 그 시간을 확정 4. 일치하지 않으면 가장 큰 값과 가장 적은 값을 선택한 멤버가 이유를 설명 5. 충분한 토의를 거쳐 다시 한번 카드를 선택

78. | 스프린트 백로그 (Sprint Backlog) • 제품에 담고자 하는 기능의 우선순위를 정리한 목록, 고객을 대표하여 제품 책 임자가 주로 우선순위를 결정 • 제품 백로그에 정의된 기능을 사용자 스토리라고 부르며 사용자 업무량에 대 한 추정은 주로 스토리 포인트라 불리는 기준을 이용

79. | 스크럼 대시보드 (Scrum dash-board)

80. | 스크럼 대시보드 (Scrum dash-board)

81. | 일일 스크럼 (Daily scrum) • 매일 진행하는 15분간의 프로젝트 진행상황을 공유하는 회의 • 모든 팀원이 참석하며 매일매일 각자가 한 일, 할 일, 문제점 등을 논의 Daily stand up meeting, EBAY

82. | 번다운 차트 (Burndown chart) • 개발을 완료하기까지 남은 작업량을 보여주는 그래프, 각 이터레이션 별로 남 아있는 작업량을 스토리 포인트라는 것으로 나타낸 것

83. | 스프린트 리뷰 (Sprint review) • 스프린트 목표를 달성했는지 작업 진행과 결과물을 확인하는 회의 • 스크럼 팀은 스프린트 동안 작업한 결과를 참석자들에게 데모하고 피드백 받음 • 가능하면 해당 스프린트 동안 진행된 모든 작업에 대한 데모를 진행 Customer showcase(고객이 참여하는 것이 좋음) Commit & Deliver Commit & Deliver SPRINT LENGTH SPRINT LENGTH Potentially shippable product increment Potentially shippable product increment

84. | 스프린트 회고 (Sprint review) • 스프린트 리뷰 이후, 그 다음 스프린트 계획 전에 수행 스프린트 리뷰는 제품에 대해 되돌아보고-개선을 하는 시간인 반면에, 스프린트 회고는 절차(프로세스) 에 대해 되돌아보고-개선을 하는 시간 • 개발팀, 스크럼 마스터, 제품소유자는 스크럼에서 수행한 것과 그렇지 않은 것 을 토의하고 관련된 기술적인 이슈를 이야기함 더 나은 스크럼팀이 되는데 도움 이 되는데 필요한 지속적인 프로세스 개선(continuous process improvement)에 초점

85. | 스크럼의 특징 • 투명성 Transparency • 스크럼은 스크럼 회의, 소멸차트, 스프린트 리뷰와 같은 기법을 이용해서 다른 방법론에 비해 프로젝트의 상태나 문제점을 잘 드러내줌. • 타임박싱 Time boxing • 일일 스크럼은 매일같이 15분이라는 짧은 시간에 진행해야 하며, 스프린트 리뷰는 매 이터레 이션 마다 주기적으로 진행. 스크럼 자체를 진행하는데 들어가는 시간을 엄격하게 제한함으로 써 프로젝트 진행에만 집중 • 커뮤니케이션 Communication • 일일 스크럼에서 각 개발자들이 어떤 방해물(blocker)로 인한 문제를 겪고 있는지 공유하고, 흔히 플래닝 포커라는 방식으로 진행되곤 하는 각 사용자 스토리의 구현 난이도/시간을 토론 하는 절차는 프로젝트 내 커뮤니케이션을 원활하게 해줌 • 경험주의 모델 "Inspect & Adapt" model • 스크럼은 고유의 프로세스 모델을 가지고 있지만 많은 기법들이 프로젝트에 참여하고 있는 개 개인의 경험에 기반. 스크럼은 기본적인 구조만 같을 뿐 실제로 일을 진행하게 되면 팀마다 달 라지는 것을 허용

86. 을 목적이 아닌Agile 수단으로

87. 모든 프로젝트는 고유하다. 끼워 맞추기 보다 맛있게 골라먹자

88. - 어느 출근길(feat. 권혁 부장)

89. 늘 하던 대로만 한다면, 늘 얻던 그만큼밖에 얻을 수 없다

Agile SW 개발

혁 권

Agile SW 개발