敏捷的几条想法

1. 1. 所有开发流程都有共通的环节，因为软件产品的生产就像其他产品一样，不可能实现奇迹性的产出。
   2. 敏捷开发解决的是应对变化，本质是缩短周期，增加校对点。几天、一周、最长一个月的周期里，一般至少有一次校对机会，减少实际和预期的偏差。
   3. 即使采用敏捷方法，应对各种需求变更也只是理想的目标。因为代码和测试的调整要远慢于需求的改变。需求的变化仍然需要有一个截止点，在这个点之后则不能改变。
   4. 敏捷不代表没有计划，在具体操作中计划不断改变，但总有一个明确的目标。
   5. 敏捷不代表没有文档，需要的是高效的文档，而不是华丽的表面工作。
   6. 敏捷不代表无限制的变化，产品开发是收敛的过程，而不应发散。所谓收敛是指软件行为应越来越明确，需要做的工作应随backlog的完成而减少。
   7. 敏捷需要在每个sprint开始前定义将要完成的backlog和完成的标准。在sprint过程中不应改变backlog的定义，不应改变资源的投入。
   8. 应尽量在sprint开始完成依赖的条件，如开发环境、测试环境、第三方的接口等。避免在过程中出现阻止团队前进的障碍。
   9. 第一个sprint应搭建可测试的环境，完成自动构建、自动部署、自动测试的架构。即使只是最简单的环境，但保证可以满足真实产品的开发。
   10. scrum master的职责应为project manager和program manager的结合。带领团队的同时应定义产品的功能和行为。
   11. 敏捷定义的是团队的产出，不对个人做评估。在敏捷中团队的所有人都是平等的，这也代表所有人都应可以互换，开发可以做测试，测试也可以做开发，人人都可以是scrum master。但实际中，因为每个人的能力和知识领域的差异，很难做到互换。
   12. sprint计划时，应先定义backlog，团队一起评估时间，最后分配任务。首先以最擅长为原则分配，最后将剩余的backlog分配给空闲的人。如果没有人可以分配，则按照优先级减少backlog。
   13. 敏捷过程中最容易出现的是，被不断的变更打乱计划，最终被变更牵着鼻子走。坚持计划->实施->反馈的原则，避免只关注变更。
   14. 可以尝试让团队成员轮流担当scrum master，也许有意外的惊喜。