敏捷开发实践体会_开发工具_编程开发_程序员俱乐部

      在前面一篇博客《敏捷Scrum培训有感》中曾经介绍了我参加InfoQ在紫竹组织的敏捷活动，其中记录了一些我在那次活动中的体会。我所在的开发团队采用敏捷中Scrum方法已经有些日子了，对此也有颇多的感触，曹操几笔在此简单总结一下其中的难点：

1. 敏捷不是一种具体的技术，而是一种组织素质以及成员素质

      搞技术的人偏爱于从技术的角度来理解敏捷，技术总要是个有形的东东，是具体的流程或一个具体的工具。其实不然，敏捷并不是靠某个特定流程和工具所能“正真”实现的。流程和工具可以辅助团队进行敏捷，或者看起来像敏捷，但要能够真正从骨子里是敏捷，需要的是组织素质和人员素质的积累和培养，这些都是无形的（更像是西游记中最无价的《无字真经》），这也是往往被人所忽视的。对于初试敏捷的团队而言，有形东西可以很快帮团队上手入门，但也很容易让人误认为这就是敏捷。

2. 好的敏捷开发团队是自组织的，而不是被敏捷的   

      但是如何来衡量你的团队是否从骨子里已经是敏捷的了呢？看看你的燃尽图是否准确、及时、真实地反映了项目的进展，所以不要小看这张燃尽图，它背后所蕴藏的东东远不止某个项目。我记得在Scrum培训的时候，吴穹博士曾经说过：“初始的创业团队总是最敏捷的。”道理也很简单，对目标和过程的认同感，使得这样的团队是自组织的。

3. 对于初始的敏捷团队Do Agile是必要的，对于成熟的团队Be Agile是需要努力奋斗的目标。

       Be Agile Rather Than Do Agile

4. Scrum团队不宜过大，超过8人就应该考虑分为更小的团队

       这是因大的团队管理成本会更高，需要交互的内容更多，合理控制团队规模是有益的。

5. Scrum的一个Sprint到底多长合适，取决项目的性质以及管理成本/总时间

       一周？两周？还是三周？需要探索和磨合来寻找的Sprint长度。

6. Scrum每日例会不是工作汇报 

7. 敏捷起于草根运动、生命力来源于团队成员的敏捷意识、成败或走向决定于上层

敏捷中的测试人员

• 敏捷方法中测试人员的价值?
• 测试人员与开发人员的比例究竟多少是合理的？