本文共 1930 字，大约阅读时间需要 6 分钟。
在前面一篇博客《》中曾经介绍了我参加的InfoQ在紫竹组织的敏捷活动，其中记录了一些我在那次活动中的体会。其实，我所在的开发团队采用敏捷中Scrum方法已经有些日子了，对此也有颇多来自实际实践中的感触，草草几笔在此简单总结一下，就当是个备忘录：
0. 敏捷方法改变是一种工作方式
如果要在你的开发团队中引入敏捷，首先要明白的是：敏捷方法带来的是一种工作方式和意识的改变，而不是简简单单地流程改变，或者多了两个三个会议或文档。如果没有能真正上升到工作方式和意识的认识高度，那敏捷对你团队而言只会是一种“现代的装饰”而已 - 看起来很酷，用起来很累。此外，就如同生活方式的改变一样，敏捷也需要有个不适应到适应的转变过程，需要一定成本和代价，往往这是一种隐性成本，不是像买台机器或者搞个培训那么可见和可度量。工作方式的改变不是看看书和参加个培训就能够一蹴而就的，需要真实的工作中去实践和尝试，更需要管理者的智慧和参与者的热情。
1. 敏捷不是一种具体的技术，而是一种组织素质以及成员素质
搞技术的人偏爱于从技术的角度来理解敏捷，技术总要是个有形的东东，是具体的流程或一个具体的工具。其实不然，敏捷并不是靠某个特定流程和工具所能“正真”实现的。流程和工具可以辅助团队进行敏捷，或者看起来像敏捷，但要能够真正从骨子里是敏捷，需要的是组织素质和人员素质的积累和培养，这些都是无形的（更像是西游记中最无价的《无字真经》），这也是往往被人所忽视的。对于初试敏捷的团队而言，有形东西可以很快帮团队上手入门，但也很容易让人误认为这就是敏捷。
2. 好的敏捷开发团队是自组织的，而不是被敏捷的
但是如何来衡量你的团队是否从骨子里已经是敏捷的了呢？看看你的燃尽图是否准确、及时、真实地反映了项目的进展，所以不要小看这张燃尽图，它背后所蕴藏的东东远不止某个项目。我记得在Scrum培训的时候，吴穹博士曾经说过：“初始的创业团队总是最敏捷的。”道理也很简单，对目标和过程的认同感，使得这样的团队是自组织的。
3. 对于初始的敏捷团队Do Agile是必要的，对于成熟的团队Be Agile是需要努力奋斗的目标。
Be Agile Rather Than Do Agile。这有点类似于第0点，强调从骨子里去接受敏捷的思想，并将其落实到实际的开发活动中。敏捷对每个团队而言都是一个需要实践和摸索的过程，Be Agile Rather Than Do Agile应该是一个最高层次的方向和目标。
4. 单个Scrum团队不宜过大，超过9人就应该考虑分为更小的团队
这是因为大的团队（〉9）的管理成本会更高，例如：每日例会时间需要更长时间，需要交互的内容更多，所以合理控制团队规模是有益的和必须的。Scrum不只是用于小项目和团队，其实早期的Scrum项目就已经有在500多人的大型项目中成功实施的案例。Scrum Scaling强调是把大项目团队多个小的Scrum项目团队，每个团队负责一个或多个相对独立的功能。在通过Scrum of Scrums（各个团队Scrum Master参加，每周一次在需要的时候开）等实践，达到沟通各个团队之间的进展和问题的目的。
5. Scrum的一个Sprint到底多长合适，取决项目的性质以及管理成本/总时间
一周？两周？还是三周？这没有固定的答案，应该更具团队和项目的实际需要而定，这需要不断地探索和磨合来寻找的合理的Sprint长度。此外，还要需要考虑的是管理和过程成本问题，如果 “管理成本/Sprint长度”的比例太高，那么就需要考虑要增加Sprint长度，或者减少不必要的管理环节和开销。
6. Scrum每日例会不是工作汇报、更不是工作检讨和任务分配会议
这是Scrum每日例会中最常遇到的问题，大家往往把它当作是向领导汇报工作，最简单的判断方法是看看大家在汇报的时候面向谁。理想的情况是，每个人都应该面向大家来汇报的，如果是向领导汇报工作，则大家都会面向领导。Scrum例会的目是为了简明扼要交流进度、将要进行的任务以及遇到的问题。而汇报工作，多半只会报喜不报忧，起不到充分交流、尽早暴露问题的作用。所以建议领导不要参加，或者在参加的时尽可能的只听不要过多的参与，或者发表长篇意见，要给团队充分的自主权，培养团队成员尽早暴露问题的勇气和习惯，使它成长为自管理型的团队，充分尊重的成员主动性、调动他们积极性和主动参与，这才是敏捷的核心意义所在。
一片关于Daily Stand-up meeting的好文章 - 。
7. 敏捷起于草根运动、生命力来源于团队成员的敏捷意识、成败或走向决定于上层
参考资料
转载地址：http://ngrki.baihongyu.com/