敏捷项目管理终极培训-Scrum.ppt

最为突出的例子是美国IBM公司于1963年～1966年开发的IBM360系列机的操作系统。该软件系统花了大约5 000人一年的工作量，最多时，有 1000人投入开发工作，写出近100万行的源程序。尽管投入了这么多的人力和物力，得到的结果却极其糟糕。据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。 从1968年，软件界借鉴其它工程领域的经验提出了软件工程，其中最重要的问题之一是解决软件的生命周期问题，出现了经典的瀑布模型，把每个阶段的规格说明，严格的评审后进入下一阶段等 * * 可见性：影响最终结果的因素必须可见，比如说功能是否完成 检查：只有通过检查才能 有中国特色的社会主义，躺着石头过河，白猫黑猫抓到老鼠就是好猫 *  * * 这里的交互就是强调了团队的价值，好的团队能够形成一种默契省去很多复杂的交互问题。 也以交响乐团来举例子，指挥要指挥几十名乐手，一个手势就能表达节奏、强弱等等 好的团队，交互起来也是很简单的，复杂的问题可能几句话就交代清楚了 * 什么才是必要的文档？这很重要。就像居家过日子花钱一样，再吝啬的人对于他觉得值的东西也会很慷慨。 有些文档你现在觉得不必要，可是未来可能很必要；另外分工的情况决定文档的必要性；项目是否有推广价值 再说说什么是无用的文档？为了应付验收后补的文档，COPY/PASTE出来的文档，不提供信息的文档，不一致的文档 关于文档的重要性我有一个亲身经历，广西电费算法文档 * 痛苦也是一天，开心也是一天，我们为什么开心地面对生活 既然变化不可避免，我们何不坦然面对 * 1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意 规划迭代故事时必须按照优先级安排，为客户先提供最有价值的功能。通过频繁迭代能与客户形成早期的良好合作，及时反馈提高产品质量。敏捷小组关注完成和交付具有用户价值的功能，而不是孤立的任务。以前我们都用需求规格说明书或者用例来编写详细的需求，敏捷使用用户故事来罗列需求。 ? 2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 敏捷过程参与者不怕变化，他们认为改变需求是好事情，因为这些改变意味着我们更了解市场需求。 ? 5. 业务和技术是引起不确定的二个主要方面，人是第三个方面。而业务和技术又必须由人来执行，所以能够激励人来解决这些问题是解决不确定性的关键。只要个人的目标和团队的目标一致，我们就需要鼓舞起每个人的积极性，以个人为中心构建项目，提供所需的环境、支持与信任。? ? 6、在十几或者二十几个人组成的大团队中，文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人（大团队实施敏捷时也会分成多个小的敏捷团队），所以大量的文档交流其实并不是很经济的做法。此时面对面的交谈反而更快速有效。 * 7.一般的工作都比较容易衡量任务进展，比如让你去搬运1吨的石头，我只要去称一下你已经搬运的石头重量就知道你完成多少了。而对于软件来说，在软件没有编码、测试完成之前，我们都不能因为代码编写了多少行，测试用例跑了多少个就去度量这个功能是否完成了。衡量这个功能是否完成的首要标准就是这个功能可以工作了，对用户来说已经可以应用了。 8.很多人都认为软件开发中加班是很正常的，不加班反而不正常，我对此有点不理解，这个可能是国情所致吧。敏捷过程希望能够可持续的进行开发，开发速度不会随着迭代的任务不同而不同，不欣赏所谓的拼一拼也能完成的态度，开发工作不应该是突击行为。我们不能指望说突击这个项目后就可以轻松了，因为完成一个项目后会接踵而来下一个项目，而只要还是拼拼的态度，下一个项目依旧会让你的组员再次突击。这时不知道有人会不会说，那我们就一直加班，也是“持续的开发速度”啊，这时可要注意了，持续加班智慧导致人疲劳、厌倦，保持长期恒定的速度也只是一种理想而已。 9.敏捷过程有很多好的技术实践可以加强产品敏捷能力，很多原则、模式和实践也可以增强敏捷开发能力。 10.我们不可能预期后面需求会如何变化，所以不可能一开始就构建一个完美的架构来适应以后的所有变化。敏捷团队不会去构建明天的软件，而把注意力放在如何通过最简单的方法完成现在需要解决的问题。这时有人会说，我已经预计到了肯定存在哪些需求扩展点，我们在一开始是否需要考虑呢？这时团队需要根据自己的理解去决定是否考虑，如果深信在明天发生了这个问题也可以轻易处理的话，那么就最好先不考虑。 11. 在自组织团队中，管理者不再发号施令，而是让团队自身寻找最佳的工作方式来完成工作。要形成一个自组织团队其实比较难。自组织团队的第一个要素就是必须有一个团队，而不仅仅是一群人。在经历了初期的磨合后，成员才会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩，而且这些