애자일 이야기2015.01.06 14:57
내부 개발팀의 교육용으로 사용한 자료를 공유합니다.


  • 1. 박경훈 애자일 의 모든 것 http://blog.hoons.net
  • 2. 진행순서 - 애자일 선언문의 원칙들 - 애자일의 오해 - 스크럼(Scrum) - User Story - Estimation - XP(eXtreme Programming) - XP Practice #1 – TDD와 테스트 자동화 - XP Practice #2 – Refactoring, CI - 애자일 사례 소개 1일차 2일차 3일차 4일차 5일차
  • 3. 왜 프로젝트는 실패하는가? 올바른 커뮤니케이션의 부재
  • 4. 프로젝트 매니저 개발자 디자이너 코드의 양이 만만치 않은데 디자인 하기 어려운 기능인데 무조건 빨리 끝내야 하는데 새 요구사항 팀들의 잘못된 목표
  • 5. 애자일의 등장 배경 S/W 개발 환경의 변화 - 결과물의 배포시기가 중요해짐 - 개발 생산성 저하 기존 방법론의 한계 - 문서 및 절차 위주의 방법론 (변화에 대응이 어려움) - 개발자의 개발능력의 차이 불안정 Waterfall model의 문제점 - 불명확하고 변화하는 사용자의 요구사항 - 개발된 모듈들의 통합의 어려움 - S/W 품질의 하락(충분한 테스트가 어려움)
  • 6. Agile 방법론의 정의 더 나은 의사소통 지속적인 변화 관리 우선순위에 따라 중요한 것 먼저
  • 7. - 어떻게 누가 잔디를 깎을 것인지 계획서 - 섬세하면서 포괄적인 청소 계획서 - 청소 도구 리스트 잔디 청소업체의 사례
  • 8. 애자일 선언문의 원칙들
  • 9. 원칙 #1 우리의 최우선 순위는, 가치 있는 소프트웨어를 일 찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다. - 고객이라는 하나의 동일한 목표를 가지는 것 - 자주 보여주는 것이 피드백을 받고 반영할 수 있는 최고의 방법이다.
  • 10. 원칙 #2 작동하는 소프트웨어를 자주 전달하라. 2-4주 간격으로 하되 더 짧은 기간을 선호하라. - 일정 주기를 통해서 팀에 리듬감을 더할 수 있다. - 주기를 통해서 평가하고 다시 계획한다.
  • 11. 원칙 #3 작동하고 있는 소프트웨어를 보여주는 것이 진척을 확인할 수 있는 길이다. - 고객에게 신뢰를 전달할 수 있는 방법이다. - 결과물 없이 커뮤니케이션이 어렵다.
  • 12. 원칙 #4 비록 개발의 후반부일지라도 요구사항 변경을 환영 하라. 애자일 프로세스들은 변화를 활용해 고객이 경쟁력 에 도움이 되게 한다. - 프로젝트의 공통된 목표는 고객을 만족시키는 것이다. - 변화를 통해서 결과를 만들어 가는 것이 애자일 방법론이다.
  • 13. vs
  • 14. 원칙 #5 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체 에 걸쳐 날마다 함께 일해야 한다. - 커뮤니케이션의 퀄리티를 높여야 한다. - 잘못된 지시나 생각의 전달을 줄여야 한다. - 날마다가 아니여도 바로 피드백이 가능하면 좋다.
  • 15. 원칙 #6 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라. - 프로젝트들은 사람을 통해서만 성공할 수 있다. - 안좋은 환경과 빨리하는 개발의 강조는 협업과 소통을 저해한다.
  • 16. 원칙 #7 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가 장 효율적이고 효과적인 방법은 얼굴을 보며 할 수 있는 대화이다. - 이메일이나 문서로 충분한 내용을 다루기 어렵다. - 시간을 절약하는 길이다.
  • 17. 원칙 #8 최고의 아키텍처, 요구사항, 설계는 스스로 움직이 는 조직적인 팀에서 탄생한다. - 최고의 설계는 팀에 연결된 사람으로부터 나오는 것이지 특정한 역할 로부터 나오는 것이 아니다. - 일을 하면서 쌓인 작고 큰 지식들이 결국 구조를 만들기 마련이다.
  • 18. 원칙 #9 기술적 탁월성과 좋은 설계에 대한 지속적인 결과 물의 전달이 민첩함을 높인다. - 좋은 설계는 한번에 정의 내려질 수 없다. - 우리는 지속적인 결과물을 만드는 것과 동시에 기술적으로도 충분히 탁월함을 유지해야 한다. - 잘 캡슐화된 디자인이 민첩함을 높일 수 있다.
  • 19. 원칙 #10 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다. - 일에 지친 사람은 실수를 만들 확률이 높다. - 단기간 높은 성과보다 길게 꾸준한 성고가 좋다.
  • 20. 원칙 #11 단순함, 안 해도 되는 일은 최대한 안 하게 하는 기 교, 이것이 핵심이다. - 사용자와 개발자 그리고 모든 사람들 입장에서 일을 단순화 시킬 수 있어야 한다. - 아직 안 끝난 일들을 계속 돌아보며 필요없는 일들을 지워나가야 한 다.
  • 21. 원칙 #12 팀은 정기적으로 더 효과적으로 일할 수 있는 방법 을 숙고하고 그에 따라 자신의 행동을 조율하고 수 정한다. - 커뮤니케이션의 퀄리티를 높여야 한다. - 잘못된 지시나 생각의 전달을 줄여야 한다. - 날마다가 아니여도 바로 피드백이 가능하면 좋다.
  • 22. 애자일의 오해
  • 23. 애자일의 오해 애자일 개발 방법론은 새로운 개발 방법론이다. 애자일은 스크럼/XP/칸반 등 하나의 개발 방법론만 이용해야 한다. No, 가장 큰 차이는 가치와 철학 No, 대부분이 원하는 기술과 프로세스들을 연결하여 사용한다.
  • 24. 애자일의 오해 만약 애자일을 도입하면 100% 프로세스에 따라야 한다. 애자일 개발팀들은 시니어 개발자들로 구성되어야 한다. No, 작은 것부터 시작해야 한다. 어떤 변화를 주기 전에 충분한 동기가 필요하다. No, 슈퍼 개발자 집단보다는 능력이 고루 섞인 팀에서 더 큰 장점을 발휘한다.
  • 25. 애자일의 오해 작은 프로젝트에서만 가능하다. 새로운 프로젝트에서만 도입이 가능하다. No, 가장 큰 차이는 가치와 철학 No, 이미 존재하는 소프트웨어를 확장하고 개발하는 프로젝트에서도 도입이 가능하다.
  • 26. 애자일의 오해 애자일 개발 방법론으로 전환하면 많은 장점을 가 져다 준다. No, 전환만으로는 어렵다. 팀 전체가 애자일의 가치와 원칙을 공유해야 한다.
  • 27. 커뮤니케이션
  • 28. Exercise - Drawing Communication Game
  • 29. 스크럼(Scrum) Ken Schwaber & Mike Beedle
  • 30. 작은 목표를 주기적으로 전달하는 것(Baby Step) 진행을 모니터링 하고 결과에 따라 계획을 조 절하는 것 비즈니스 목표가 변경되는 것과 개발팀이 민 첩하게 대응하여 완료할 수 있는 것들의 밸런 스를 조정하는 것
  • 31. Values Commitment Focus Openness Respect Courage
  • 32. Scrum Team
  • 33. 스프린트(Sprint) “The team works for a fixed period of time called a Sprint” - 1~6주 범위 내에서 특정 기간을 선정 - 일반적으로 2주 or 4주를 가장 많이 사용함 - 스프린트 기간 동안에는 분석, 설계, 코딩 그리고 테스트와 배포까지의 모든 과정을 포함함 — Schwaber et al, Agile Software Development with Scrum, Prentice-Hall, 2002 (pp 50)
  • 34. Sprint Planning Meeting “Customers, users, management, the Product Owner and the Scrum Team determine the next Sprint Goal and functionality at the Sprint Planning meeting. The team then devises the individual tasks that must be performed to build the product increment” — Schwaber et al, Agile Software Development with Scrum, Prentice-Hall, 2002 (pp 47) Input: 백로그, 수용 가능한 시간, 과거의 퍼포먼스 Output: 스프린트 목표, 스프린트 백로그
  • 35. Output Example Sprint Goal: A non-developer can create a basic invoice on their machine Sprint Backlog: – Create basic invoice (no tax etc) – Generate VAT invoice – Deploy application to a non-developer Scrum team member’s PC – Set-up automated test environment
  • 36. Daily Scrum Meeting “Software development is a complex process that requires lots of communications. The Daily Scrum meeting is where the team comes to communicate” — Schwaber et al, Agile Software Development with Scrum, Prentice-Hall, 2002 (pp 40) 매일 짧은 미팅(15분): - 내가 한 일 - 오늘 할 일 - 있었던 이슈들
  • 37. Sprint Review “The Sprint Review meeting is a four-hour informational meeting. During this meeting, the team presents to management, customers, users and the Product Owner the product increment that it has build during the Sprint” — Schwaber et al, Agile Software Development with Scrum, Prentice-Hall, 2002 (pp 54) 만든 결과물이 제품 책임자가 원하는 기능인지 확인 진행된 프로그레스의 리뷰 (비즈니스 & 기술적 이슈 공유) 다음 스프린트의 효율을 높이기 위한 아이디어 공유
  • 38. Burndown Chart
  • 39. Scrum Board
  • 40. User Stories
  • 41. User Story? …understandable to customers and developers, testable, valuable to the customer and small enough so that the programmers can build half a dozen in an iteration. …A user story is nothing more than an agreement that the customer and developers will talk together about a feature. — Beck et al, 2001, p. 45-6 개발자와 제품 책임자와의 소통을 위한 요구사항 정의서
  • 42. 개발 문서에 의존하면? 변화를 받아 들이지 못한다. 고객이 원하는 것이 아닌 적혀있는 명세에 따라 개발한다. 실제 20%만 제대로 된 요구사항이다. 잘못된 추측과 가정이 난무한다. Ex) “나는 그가 설계서를 안 만들었다고 말하지 않았습니다."
  • 43. 사용자 스토리 규칙 1. 다른 스토리에 종속적이지 않아야 한다. 2. 너무 세세하게 적지 않아야 한다. 3. 추정 가능해야 한다. 4. 적당한 크기로 작성해야 한다. - 한 스프린트 안에서 개발이 가능한 5. 테스트 가능해야 한다.
  • 44. Template As a I … < role> … I want … <short description of feature> … So that … <value or why need functionality> … Example: As a regular traveler I want my cell-phone to wake me up at a set time so that I don’t need to pack an alarm clock. 스마트폰 이용자는 내가 있는 지역의 날씨를 알기 위해서 날씨 앱을 이용하고 싶다.
  • 45. Acceptance Criteria Given … <some initial context (the givens)> … When … <an event occurs> … Then … <ensure some outcomes> … Example: Given my cell-phone is switched off When the time for my alarm is reached Then turn the cell-phone on and sound the alarm 다른 나라를 여행하고 있는데 인터넷이 되는 환경에서 날씨 앱을 실행했더니 그 해당 지역의 날씨의 정보를 가져와 보여주었다. => 통합 테스트(IntegrationTest) 조건
  • 46. Example
  • 47. Example
  • 48. Example
  • 49. Example Snapshot As a user, I want to take a snapshot of any part of the book where I don’t understand so that the snapshot can be uploaded to the program. Criteria Verify that user is able to take a picture in the application. Estimation 8
  • 50. Exercise – User Story
  • 51. Estimation
  • 52. About Estimation 누가? 왜? 일과 관련된 모든 사람들 스프린트를 계획하고 일들의 우선순위를 정하기 위해서 측정 단위 : 시간 (날짜 or Hours) 복잡도 (포인트) 사이즈 (SS, S, M, L, XL)
  • 53. Planning Poker
  • 54. Exercise – Planning Poker
  • 55. XP(eXtreme Programming)
  • 56. About XP 1999년 켄트 백의 저서인 'Extreme Programming Explained - Embrace Change‘ 에서 처음 발표 10-12 개의 실천법(Practices)들로 구성
  • 57. Values Communication Feedback Simplicity Respect Courage
  • 58. XP Practices Small Release Simple Design Refactoring Testing (unit and acceptance) Pair Programming Collective Ownership Continuous Integration 40-hour week On-site customer Coding Standards
  • 59. XP Anti-practice
  • 60. AntiPatterns of XP Practices  Introduced by Yoshihito Kuranuki(TIS, Inc.) and Kenji Hiranabe(Eiwa System Management)  Japanese XP Community  Various XP AntiPracties
  • 61. Brownie's Works – “The boss refactored our code!”
  • 62. [story 1. Brownie's Works] WR WR a freshman, began to learn the fun of programming. CR CR also a freshman, had quite a good experience of programming in the university.
  • 63. [story 1. Brownie's Works] AF (Coach) This is the first “freshman pair”. Can you guys finish this task? Yes, sir
  • 64. [story 1. Brownie's Works] Late in the evening, they checked in their code to their code base. The "fanfare" sounded nicely (their auto- build/test batch played fanfare if it is successful). It worked! It was a hard one, thank you for your help. Thank you... let's go home.
  • 65. [story 1. Brownie's Works] RG -Senior Developer Late at the night, the senior programmer RG was working alone. What's this messy code!!!? This supposed to be like this... He refactored all the code the freshman pair had just checked in.
  • 66. [story 1. Brownie's Works] Our code is gone. Yes, I refactored the code. That’s collective ownership. The next morning…
  • 67. [story 1. Brownie's Works] The boss refactored our code! CR and WR were really depressed…
  • 68. Let’s discuss [story 1. Brownie's Works]
  • 69. What if they are not there? Mail to the list why and how you refactored. I think you should have pair programmed when you refactored their code. [story 1. Brownie's Works]
  • 70. This kind of thing would happen repeatedly, so it would be easier to teach them once. [story 1. Brownie's Works]
  • 71. [story 1. Brownie's Works] RG’s action made a new move in the team dynamics. CR andWR learned a lot from RG with pair programming.The team got back its normal or even better condition. [After]
  • 72. Anybody Syndrome - “I’m not necessary here”
  • 73. [story 2. Anybody Syndrome ] One morning, WR got a bad cold. He called in to the office and said to the coach. "I think I have a cold. May I take a day off?" Sure, it was a tough iteration. Don't worry about the team. Take a rest
  • 74. [story 2. Anybody Syndrome ] After four days' off, he came to the office and saw the team working just as well as the day he left. He was happy that everything was fine, but felt some loneliness. What is my value for the team? I’m not necessary here… After that, he began to stay away from his work quite often.
  • 75. Let’s discuss [story 2. Anybody Syndrome ]
  • 76. [story 2. Anybody Syndrome ] The coach had an interview withWR face to face You are frequently absent from the office these days, is anything the matter with you? when I took some days off and came back, I found that the team did not have any trouble at all.
  • 77. [story 2. Anybody Syndrome ] “Yes, that's a good thing! That means the team is fine without me.
  • 78. [story 2. Anybody Syndrome ] That’s not quite right. Everybody wants to work with you, and you have your own goal in the project. You participate in the project with that goal, don’t you? The coach and WR talked about his goal in the project and his career plan. WR was grateful to the coach for giving an opportunity to talk over these kinds of things in a big picture.
  • 79. The project members found that they had their own goals as well as the project goal and they were free to talk about them anytime. That became a grand rule set by the coach. They now talked about their dreams, plans, and families.They started acting more autonomously, and the fresh energy came back to the team. [story 2. Anybody Syndrome ] [After]
  • 80. Pairing Prison – “I'm always under observation!”
  • 81. [story 3. Pairing Prison ] CR was a senior programmer with three years of experience in waterfall type development environment. He had been interested in XP, and this was his first XP experience in a real project. He had wanted to try pair programming, so this was a wonderful opportunity for him.
  • 82. When he paired with juniors, he got serious so he become a good example. [story 3. Pairing Prison ]
  • 83. With seniors, he felt like he was taking an examination. Pair programming made him feel observed in a prison. [story 3. Pairing Prison ]
  • 84. He could not stand the situation anymore, and consulted the coach. He said [story 3. Pairing Prison ] I'm always under observation!
  • 85. Let’s discuss [story 3. Pairing Prison ]
  • 86. The next day, the coach told the team that he recommended to take breaks more often. The team adopted this as a ground rule. In addition, they doubled the lunch time for their personal time. [story 3. Pairing Prison ]
  • 87. 테스트 자동화와 TDD
  • 88. 소프트웨어의 소스는 복잡하게 연결되어 있다.
  • 89. 작은 한 부분이 수정된다면?
  • 90. 모든 기능을 다시 테스트 해야 한다.
  • 91. 소스코드는 시간이 흐르면 녹이 슨다.
  • 92. 끊임없이 OOD(Object Oriented Design)와 패턴 구문들을 적용해가며 리펙토링 해야 한다.
  • 93. 하지만 리펙토링이 어려운 이유
  • 94. 모든 기능을 다시 테스트 해야 한다.
  • 95. 자동화 된 테스트가 없다면?  자체 버그 검출 능력 저하 - 모든 기능을 테스트 하기 어려움  소스 코드의 품질 저하 - 어디서 버그가 생길지 모르기 때문에 잘못 된 코드도 고치지 않으려 하는 현상  자체 테스트 비용의 증가 - 작은 수정에도 모든 기능을 다시 테스트 해 야 되는 문제
  • 96. 자동화 된 테스트란?  모든 테스트 케이스를 코드 스크립트로 변환 한 집합체
  • 97. 3rd party testing tools  http://www.youtube.com/watch?v=qsh4zWa 6bE8  http://www.youtube.com/watch?v=4TGkGQo nmy4#t=64
  • 98. 누가 테스트 스크립트를 만드는가? Software Engineers QA Engineers Software Architect
  • 99. 개발 프로세스 요구사항 Software & QA Engineer 테스트 케이스 수립 - 공백입력 하면 오류 메시지 띄우기 - 사용자가 여러 개의 비디오를 옮길 수 있게 개발 Software EngineerQA Engineer 통합 테스트 코드 작성
  • 100. TDD란 무엇인가?  Test-Driven Development - 요구사항의 테스트 요건을 먼저 고려  Test-First Development - 개발 전 테스트 코드를 먼저 작성하여 개발  1999년 XP라는 애자일 기반의 개발 방법론과 함께 소개 됨
  • 101. TDD란 무엇인가? 기존 개발방식 TDD의 개발방식
  • 102. TDD의 장점  높은 소스코드 품질 - MS와 IBM사의 조사 결과 TDD 약 15~35% 정도의 개발시간 증가 결 함율(버그)은 약 40~90% 정도 줄어듬 - http://research.microsoft.com/en- us/groups/ese/nagappan_tdd.pdf  재설계 시간의 절감  손쉬운 테스트 근거 산출 및 문서화 (test coverage, performance)  디버깅 시간의 절감
  • 103. TDD의 단점  all about 개발 생산성!
  • 104. 1부터 10까지의 수를 출력하는 프로그램 만들기! - 단, 3의 배수에서는 숫자대신 “HOONS”를 출력 - 5의 배수에서는 “JAEDAM”을 출력
  • 105. 통합테스트와 유닛테스트 Dependency Injection = AOP
  • 106. 편의점 카운터에서 물건을 스캔한 뒤에 고객에게 최종 가격을 알려주는 프로그램이 필요합니다. 물건들의 가격은 데이터 베이스에 있으며, 한가지 특별한 것은 현재 모 든 물건을 2개 사면 하나 더 주는 이벤트를 하고 있기 때문에 이 로직을 반영해주세요.
  • 107. 데이터 레이어 => 가격정보 비지니스 레이어 => 할인점검 유닛테스트 유닛테스트 통합테스트
  • 108. Test Automation /TDD AOP Repository Pattern MVC, MVP, MVVM Dependency Injection SOLID, DRY, KISS ORM - Entity CI Pair programing Git – code review BDD/DDD Agile – XP/Scrum Daily Standup User Story & Estimation 패턴 문화
  • 109. 결과 중심적 개발 프로세스 Project Manager Software Engineer Tester 요구사항 결과물 개발
  • 110. 품질 중심적 개발 프로세스 Project Manager ① 요구사항 Architect / Lead developer Software Engineers ② 분석/설계 전달 개발 결과물 ③ 코드리뷰 요청 (pull request) Architect / Lead developer Tester 테스트 요청 결과물 피드백 코드 리뷰
  • 111. Continuous Integration
  • 112. Continuous Integration “팀원들이 작업한 결과를 자주 지속적으로 통합하 고 그것을 자동화 하는 것”
  • 113. Why CI? 구현 기능의 가시화 (작업물의 공유) 프로젝트의 결함 조기 발견
  • 114. CI를 넘어
  • 115. Developer vs Operator
  • 116. Devops tools
  • 117. 코드 리팩토링
  • 118. 소스코드는 시간이 흐르면 녹이 슨다.
  • 119. 그 이름은 스파게티,,
  • 120. 좋은 코드란? “기계가 아닌 사람이 이해 할 수 있게 작성된 코드”
  • 121. 리팩토링(Refactoring) 이란? “소프트웨어 디자인을 개선하고 코드를 쉽게 사용하 고 이해할 수 있게 만드는 작업”
  • 122. When to refactor? 새로운 함수를 추가할 때 버그를 수정해야 할 때 코드 리뷰를 수행할 때
  • 123. 리팩토링이 무의미한 경우 리팩토링을 실행해도 복구가 어려울 정도로 망가져 버린 코드들 데드라인이 너무 가깝고 리팩토링한 검증할 테스트 코드가 없을 때
  • 124. 나쁜 코드 스멜 복사된 코드 로직 너무 긴 메서드 굉장히 긴 클래스 너무 많은 파라미터 리스트
  • 125. Before Refactoring 테스트 코드의 작성
  • 126. 나의 규칙을 따르라!
  • 127. #1 메서드 추출 void PrintOwing(double amount) { PrintBanner(); //print details WriteLine("name:" + _name); WriteLine("amount" + amount); } void PrintOwing(double amount) { PrintBanner(); PrintDetails(amount); } void PrintDetails(double amount) { WriteLine("name:" + _name); WriteLine("amount" + amount); }
  • 128. #2 인라인 메서드 int GetRating() { return (MoreThanFive()) ? 2 : 1; } bool MoreThanFive() { return _number > 5; } int getRating() { return (_number > 5) ? 2 : 1; }
  • 129. #3 임시변수의 중복 사용 double temp = 2*(_height + _width); WriteLine(temp); temp = _height * _width; WriteLine(temp); double perimeter = 2*(_height + _width); WriteLine(perimeter); double area = _height * _width; WriteLine(area); 임시 변수는 한번만 할당
  • 130. #4 파라미터의 값 할당을 피해라 int Discount (int inputVal) { if (inputVal > 50) inputVal -= 2; … } int Discount (int inputVal) { int result = inputVal; if (inputVal > 50) result -= 2; … } 파라미터를 변경하려면 임시 변수를 이용하라
  • 131. #5 메서드를 객체로 class Order... double price() { double primaryBasePrice; double secondaryBasePrice; double tertiaryBasePrice; // long computation; ... } 한 메서드 안에서 진행되는 작업이 너무 많은 경우
  • 132. #6 복잡한 수식의 표현 if( ( platform.toUpperCase().indexOf("MAC") > -1 ) && ( browser.toUpperCase().indexOf("IE") > -1 ) && ( wasInitialized() && resized > 0 ) { // 작업... } bool isMasOS = platform.toUpperCase().indexOf("MAC") > -1; bool isIEBrowser = browser.toUpperCase().indexOf("IE") > -1; bool wasResized = 0; if( isMacOS && isIEBrowser && wasInitialized() && wasResized ) { // 작업... } 복잡한 수식을 이해하기 쉽게 변수를 적절히 이용
  • 133. #7 Single Responsibility class Customer { public void Add() { try { //DB 접근코드 } catch (Exception ex) { System.IO.File.WriteAllText( @"c:Error.txt", ex.ToString()); } } } class FileLogger{ public void Handle(string error){ System.IO.File.WriteAllText(@"c: } } class Customer { private FileLogger obj = new FileLogger(); public void Add() { try{ // DB 접근코드 } catch (Exception ex) { obj.Handle(ex.ToString()); } } } 하나의 클래스에서는 하나의 책임만 할당
  • 134. “나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전량에 의거해 철저히 처리한다.” — 이야네 스트룹스트룹(Bjarne Stroustup), C++창시자 의존성 줄이는 것 = 객체간의 강한 참조를 줄이는 것 = Loose coupling = 클래스 참조 대신 Interface를 이용
  • 135. class FileLogger{ public void Handle(string error){ System.IO.File.WriteAllText(@"c:Error.txt", error); } } class Customer { private FileLogger obj = new FileLogger(); public void Add() { try{ // DB 접근코드 } catch (Exception ex) { obj.Handle(ex.ToString()); } } } File Logger가 아닌 DBLogger도 구현해야 한다면? #8 의존성 제거
  • 136. interface ILogger { void Handle(string error); } class FileLogger :ILogger { public void Handle(string error) { System.IO.File.WriteAllText(@"c:Error.txt", error); } } class DBLogger : ILogger { public void Handle(string error) { //DB 저장 로직 } } 인터페이스의 도입
  • 137. class Customer { private readonly ILogger _obj; public Customer(ILogger obj) { _obj = obj; } public virtual void Add() { try { //Some codes } catch (Exception ex) { _obj.Handle(ex.ToString()); } } } var customerDB = new Customer(new DBLogger()); var customerFile = new Customer(new FileLogger())); Customer의 loose coupling
  • 138. 리팩토링 추천도서 리팩토링 : 코드 품질을 개선하는 객체지 향 사고법 - 저)마틴 파울러 xUnit 테스트 패턴 : 68가지 단위 테스트 패턴을 통한 테스트 코드 리팩토링 기법 – 저) 제라드 메스자로스
  • 139. 애자일 도입사례
  • 140. 세일즈포스 – 대규모 개발팀에서,, CRM 끝판왕 (클라우드 기 반, SaaS) 87,200여 회사에 이용 200만명 이상의 사용자 3개월 기간 동안의 30개의 대규모 개발 팀에 애자일 도입
  • 141. 도입 배경 - 정확하지 않은 전체 개발기간 (일찍 산정하고 평가하는 것은 결국 각 기능별 정학한 완 성일자와 완전한 테스팅 스케줄을 제공할 수 없었다.) - 실제 릴리즈의 모든 단계별로 눈에 보여지는 결과물의 부재 - 거의 릴리즈 끝에 이루어지는 기능들의 늦은 피드백 - 길고 예측이 어려운 릴리즈 스케줄 - 팀이 확장될수록 줄어드는 생산성
  • 142. 도입 결정 KISS(Keep it Simple Stupid)개발 원칙과 빠른 반복 주기, 고객들의 의견이 중요 -> 애자일 원칙과 유사 시범적 팀에 도입 vs 일부 팀에 도입 =>대부분의 팀 원들이 같은 시간에 같이 도입을 원 함
  • 143. 도입 과정 - 상당수의 개발자들에게 외부 스크럼 교육을 지원 - 스크럼 마스터/개발자 자격증 응시 지원 - 애자일 TF팀이 꾸려져 사내 팀에 Lean과 XP 교육
  • 144. 성공요인 #1 - 개인의 생산성 보다는 팀의 처리량에 초점을 맞추는 것 - 각 기술 별로 나뉘어진 팀들은 매일 만나서 진행하는 미팅 - 공통으로 사용하는 언어의 정의와 간단한 애자일 프로세스 - 모든 팀 별로 일들의 명확한 우선 순위 리스트 - 사용자 스토리와 새로운 업무 측정방법의 정의 - 빌드 속도와 유연성에 초점이 맞추어진 자동화 팀 - 제품과 릴리즈의 완성도를 하루 단위로 확인할 수 있는 도 표
  • 145. 성공요인 #2 - 스크럼을 이용한 제품 라인과 주별로 모든 팀이 볼 수 있는 어떤 결과물 - 넓은 분야의 스프린트 리뷰와 매달 진행하는 회고 - 제품 책임자(Product Owner)와 스크럼 마스터 (ScrumMaster)들의 주기적 미팅 - 큰 릴리즈를 앞두고 정확한 시간 단위로 정확하게 만들어지는 작은 릴리즈 - 약 1500개 이상의 버그의 감소 - 매달 진행되는 잠재적인 제품들의 릴리즈
  • 146. 일찍 알았으면 - 일찍 애자일 도입 피드백에 귀 기울이는 것 - 제품 책임자를 일찍 교육 시키는 것 - 외부의 코치들을 일찍 섭외하는 것 - 자동화 부분을 보다 일찍 시작하는 것 - 경영진들에게 애자일 도입에 대한 구체적인 업무 들을 요청하는 것 - 조금 더 클리어하게 애자일의 역할이 무엇인지를 전달하는 것
  • 147. 세일스포스 사례를 통한 교훈 - 애자일을 도입을 진행할 헌신적이고 모든 권한을 가지고 있는 팀을 만드는 것 - 전문가의 도움을 얻는 것 - P2P처럼 개개인이 서로 코치할 수 있게 하는 것 - 여러 개의 팀을 뛰어나게 만드는 것 - 회사 레벨의 스프린트를 만드는 것 - 일찍 필요한 도구를 만드는 것 - 진행사항을 눈에 볼 수 있게 하는 것과 최대한 많 은 커뮤니케이션을 만드는 것 - 실수를 인정하고 그것에 관대해지는 것
  • 148. BBC – 제품 책임자의 역할 영국 방송국 (British Broadcasting Corporation) iPlayer 프로젝트 진행 대규모 프로젝트에서 프 로젝트 진행
  • 149. iPlayer 프로젝트 목표 - 1. 홈페이지 개발 - 2. “다운로드”, “지금 보기” 와 같은 사용자 기능 제공 및 액션 의 처리 - 3. 내려 받은 미디어를 관리하기 위한 애플리케이션 - 4. 내려 받을 수 있는 컨텐츠를 검색하고 내려 받을 수 있는 환 경 제공 - 5. 웹 기반의 프로그램 스케줄과 사용자 가이드 - 6. 프로그램 제목, 방영날짜 등과 같은 메타데이터의 정보 관리 - 7. 기존의 인증 시스템과 연동하여 자동로그인 기능 (SSO:Sigle Sign On) 제공 - 8. IP 체크를 통한 위치 기반의 사용자가 맞춤 환경 분석 - 9. 사용자 경험과 인터렉션
  • 150. iPlayer 프로젝트 - TV 프로 다시보기/실시간시청 기능 제공 - 9개의 컴포넌트 팀 & 중앙 관리팀 (80여명) - 2개 팀은 이미 스크럼 경험 - 2주 간격의 스프린트 - 일일스크럼미팅 / “스크럼”의 스크 럼 미팅 진행 - 각 팀별로 스크럼 마스터, 제품 책 임자는 중앙팀에 배치
  • 151. 9개의 팀 = 각 팀병1명의 스크럼마스터 + 팀원들 중앙 관리 팀 제품 책임자
  • 152. 무엇이 잘못되었을까? - 진행 속도가 2주차 부터 현저히 감소 - 1명의 제품 책임자가 너무 바쁨 - 제품 책임자가 어떤 결정을 혼자서 내리기 어려움 - 백로그에 우선순위가 없어서 자신이 원하는 항목 부터 처리 - 제품 책임자가 결정을 내리지 못하여 미팅이 잦아 짐 - 스크럼으로는 성공할 수 없다는 목소리들
  • 153. Let’s discuss
  • 154. 처음 시도 중앙 팀을 2개로 나눠서 관리
  • 155. 하지만 이전과 비교해서는 좀 나아짐 하지만 여전히 각 팀들의 스크럼을 중앙에 동기화 하 는 것이 어려움 각 팀 별로 가지고 있는 의존성 때문에 잦은 미팅 두 책임자들의 잦은 충돌과 비효율적인 결정
  • 156. 자기 주도적으로 일하기 각 9개의 팀 별로 제품 책임자의 역할을 하는 제품 프로듀서를 다시 임명 9개의 팀 = 각 팀병1명의 스크럼마스터 + 팀원들
  • 157. 효과 • 각 팀들은 보다 분명한 제품의 책임 의식 고취 • 프로젝트 요구사항이 명시적으로 정의 가능 • 질문에 대한 빠른 답변 가능 • 각 팀들이 명확한 제품 백로그를 생성 & 스프린트 계획수립 가능 • 해야 할 업무의 배분이 적절이 이루어졌고 새로운 기능들을 매 스프린트마다 고객에게 전달 • 각 팀의 제품 책임자들은 각자 맡은 분야의 전문가 가 됨 • 일관성이 없었던 제품 백로그 항목들이 각 팀들에 의해서 완화됨
  • 158. BBC의 팀 • 프로젝트 안에서 각 팀을 구성할 때 제품 책임자와 함께 할 수 있는 시간을 고려해야 한다. • 한 명의 제품 책임자에 의존하다 보면 결국 일 진 행이 늦어지고 프로젝트의 올바른 방향을 설정하는 것이 어렵다. • 제품 책임자들의 역량은 팀이 크거나 여러 팀의 목 표를 동시에 고려하다 보면 줄어든다. • 조직적이지 못한 팀이 하나의 프로젝트에서 같이 일하면 비즈니스 목표와 다른 제품이 만들어 질 수 있다.
  • 159. 대규모 스크럼 프로젝트의 성공조건 • 스크럼의 스크럼 • 같은 공간에서 일하는 개발 팀들 • 팀 안에서 적절한 역할의 사람들 • 권한이 있는 스크럼 마스터



저작자 표시
신고
Posted by 박경훈