- How to Fail with Agile
Tweet
- Game Development
- 2008/08/18 14:02
- agile, 애자일
-
출처 : Agile Game Development Blog
성공을 피하기 위한 20가지 비책
(20 Tips to Help you Avoid Success)
성공을 피하기 위한 20가지 비책
(20 Tips to Help you Avoid Success)
- 관리 문제(Management Issues)
- 팀이나 애자일을 믿지 마라. 팀원 및 프로세스를 세부관리하라(Don’t trust the team or agile. Micromanage both your team members and the process).
- 애자일이 만병통치약이 되지 못하면 애자일을 탓하라(If agile isn’t a silver bullet, blame agile).
- '스스로 하는 관리'를 '스스로 하는 리딩'과 동일시 하여 팀에게 아무런 방향도 제시하지 말라(Equate self-managing with self-leading and provide no direction to the team whatsoever).
- 애자일 실천항목들을 무시하라. 관리에는 해당 사항이 없는 것들이다(Ignore the agile practices. They don’t apply to management).
- 애자일에 대한 팀의 믿음을 흔들리게 하라(Undermine the team’s belief in agile).
- 팀 문제(Team Issues)
- 이터레이션 계획 시 약속했던 산출물을 만들어 내는데 계속 실패하라(Continually fail to deliver what you committed to deliver during iteration planning).
- 호탕하게 작업을 다음 이터레이션으로 넘겨라. 무엇이 산출될지 제품 소유자가 계속 추측하게끔 하는 것이 좋다(Cavalierly move work forward from one iteration to the next. It’s good to keep the product owner guessing about what will be delivered).
- 통합 기능적 팀을 만들지 마라. 모든 테스터를 한 팀에 두고, 프로그래머는 모두 다른 팀에 두어라(Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on).
- 큰 프로젝트에는 큰 팀이 필요하다. 팀이 커질수록 소통 오버헤드의 증가로 생산성이 떨어진다는 연구들을 무시하라. 모두가 모든 것을 알아야 하므로, 50명 전원을 일일 스탠드업에 초대하라(Large projects need large teams. Ignore studies that show productivity decreases with large teams due to increased communication overhead. Since everyone needs to know everything, invite all fifty people to the daily standup).
- 제품 소유자 문제(Product Owner Issues)
- 제품에 대한 비전을 팀이나 다른 이해관계자와 공유하지 말라(Don’t communicate a vision for the product to the team or to the other stakeholders).
- 각 이터레이션의 진전에 관심을 두지 말고 그 진전의 가치를 측정하지 말라(Don’t pay attention to the progress of each iteration and objectively evaluate the value of that progress).
- 계획 문서는 필요 없다. 당신만이 알고 있는 당신 머리 속 계획이면 충분하다(Replace a plan document with a plan “in your head” that only you know).
- 한 사람이 스크럼마스터(애자일 코치)와 제품 소유자의 역할을 모두 맡게 하라. 또한 그 사람이 일반적인 작업자로서도 기여하게 하라(Have one person share the roles of ScrumMaster (agile coach) and product owner. In fact, have this person also be an individual contributor on the team).
- 프로세스 문제(Process Issues)
- 책대로 따르기도 전에 애자일 공정을 변용하기 시작하라(Start customizing an agile process before you’ve done it by the book).
- 완전히 이해하기도 전에 중요한 애자일 실천 사항들을 버리거나 변용하라(Drop and customize important agile practices before fully understanding them).
- 밑바탕의 원리을 이해하지도 않고 맹목적으로 애자일 실천항목들을 따르라(Slavishly follow agile practices without understanding their underlying principles).
- 지속적으로 개선하지 말라(Don’t continually improve).
- 기술적 실천 사항들을 바꾸지 말라(Don’t change the technical practices).
- 연봉, 직책, 승진, 인정 등이 애자일을 뒷받침 하기 보다는, 개개인이 팀웍 및 책임 공유를 와해하는 쪽에 인센티브를 두어라(Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility).
- 모든 일을 결국에는 다 할 것이므로, 일의 순서는 상관 없다고 믿으라(Convince yourself that you’ll be able to do all requested work, so the order of your work doesn’t matter).
'Game Development' 카테고리의 다른 글
| Code Drill #2 (0) | 2008/08/21 |
|---|---|
| C++0x == C++09 ? (0) | 2008/08/19 |
| How to Fail with Agile (0) | 2008/08/18 |
| the Ten Commandments of Debugging (0) | 2008/08/14 |
| Code Drill #1 (0) | 2008/08/12 |
| C++ guru's 2 recent articles on concurrency (0) | 2008/08/06 |
Recent comment