标签：
阅读笔记
第六章：敏捷流程
第六章敏捷流程主要介绍了什么是敏捷流程及其原则，还有什么时候可以选择敏捷的开发方法，什么时候选择其他方法。
敏捷的流程是指一系列价值观和方法论的集合。介绍了一些敏捷开发原则，比如，经常发布可用的软件，业务人员和开发人员在项目开发过程中应该每天共同工作，面对面的交流始终是最有效的沟通方式，不断关注技术和设计，保持简明，团队要学会自我管理，时时总结如何提高团队效率，并付诸行动。
敏捷流程的方法论---Scrum方法论。首先第一步需要找出完成产品需要做的事情，然后决定当前的冲刺需要解决的事情，第三步就会开始进行冲刺，冲刺期间每天要开一个每日例会，大家依次报告昨天做了什么，今天要做什么，碰到了什么问题。同时还有做图表，可以是燃尽图，也可以是看版图，未开始，进行中，已完成三个板块。最后会得到软件的一个增量版本，进行发布。
当然开发过程中也会碰到一些问题，比如任务之间是有依赖关系的，怎么在计划中体现依赖关系？团队成员领取任务时，会出现问题；每日会议可能会流于形式。这就需要定义好任务究竟是什么。
当开发人员说项目完成的时候，只是说该写的代码写完了，但是还有剩下的最重要的20%的测试过程，当然都知道2/8原则，剩下的工作才是需要时间最多的工作。
敏捷流程成功的关键在于Scrum Master，不能随便挑一个人来做，事实上这是一个项目经理的位置。一个团队要进行敏捷流程，需要做到自主管理，自我组织，还有多功能型。
敏捷流程其实不特别，采取分而治之的方法，强调短时间的迭代，指出不同的人投入的时间和责任不同，鼓励团队交流，对团队成员提出很高的要求。
敏捷流程的经验教训：
1. 敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论。
2. Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的"经理"变成Scrum Master，大多行不通。
3. 一些项目需要很多暗箱操作和政治角力才能搞定，Scrum会把这些矛盾都摆到明处。这有好处，也有风险。
4. 在复杂的项目里，要让一线团队成员做决定。
5. 创业公司的团队其实经常是运行在Scrum 的模式中（只不过大家太忙，没工夫论证自己到底有多么Scrum）。
6. 在Scrum计划阶段的估计不是一个"合同"，领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint，这样即使不准的估计也不会有大的损害。
7. 不要和管理层谈"流程"，他们只关心"结果"。
8. 在大型团队、跨地区的团队，或者复杂项目中，Scrum并没有非常完美的答案，Scrum的创始人也承认这一点。
敏捷流程不是一蹴而就，一下子跳出来的，而是建立在许多行之有效的最佳实践方法之上的。敏捷有自己的适用范围，不是所有情况都适用。需要敏捷的流程，但是不需要匆忙或者说忙乱的开发流程。
?
过去的看法：
开发一个软件只是写代码，完成功能即可。
这样为什么不好：
如果不做测试，可能只是在自己的设备上好用，但是到了其他设备上，可能会出现很大问题。开发过程如果不讲究方法，只能是一团乱。
解决办法：
开发完成之后，多做测试，尽量保证bug的减少。当说完成一个软件的时候，只是把代码写完了，其实剩下的还有最重要的测试要做，需要花费更多的时间，并且开发过程的方法也是有很多的，要用比较适合的一种。
?
?
?
?
标签：
原文地址：http://www.cnblogs.com/diyunfei/p/5502237.html
