敏捷开发-Scrum和实践

先写一段我喜欢的关于敏捷开发的话：
如果30天内无法将Idea转换成具备商业模式及可操作性的项目，
如果2个月内无法找到团队核心并组成初创团队，
如果3个月内你的Idea还没被团队充分理解并预期付诸实践，
如果6个月内你还在筹划半年前的那个Idea，
这个Idea已经过时勒，请下一个，这里是互联网！

更迅捷的项目管理，
更快速的项目决断，
更舒适的用户体验，
更早地实现Idea，
好与不好交由公众来评断，
不要闭门造车以为一切尽在掌握。
— Reinhardt

 大概8年前接收Scrum联盟的培训，然后在项目组推行Scrum流程，先后带过多个团队。下面简要介绍一下Scrum流程，还有一些实践的总结。

  软件开发所面临的挑战和任务是在现有的时间和有效的资源范围内，寻找解决实际问题的切实可行的方案。在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要的原因，它比其他所有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢？

• 首先：我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设一切都将运作良好。
• 第二：我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
• 第三：由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
• 第四：对进度缺少跟踪和监督。在其他工程领域中，经过验证的跟踪技术和常规监督程序在软件工程中常常被认为是无谓的举动。
• 第五：当意识到进度的偏移时，下意识以及传统的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环

软件开发模式

瀑布开发

 传统的瀑布模式开发假定从项目开始需求就是明确的，严格把软件项目的开发分隔成各个开发阶段。主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。
 瀑布开发模式的项目周期往往比较长，一般为3-6个月，甚至更长时间，当项目开发完成后，最后交付成果往往不是产品经理或是客户真正想要的，最后只能重新从项目的需求开始，不可控的因素和风险很大。

敏捷开发

 2001年，十七位关于敏捷方法的发起者和实践者聚集到一起，发表了“敏捷软件开发宣言”。他们强调敏捷开发能够以一种更加简洁、可持续、短周期、高效率的方式进行软件开发，同时希望以敏捷联盟为形式的合作可以帮助到行业中的其他人，帮助他们以更加敏捷的新方式来思考软件开发、方法论以及组织架构。

敏捷宣言:

敏捷开发的一些思想

• 迭代式开发和增量交付
  把一个复杂且开发周期很长的开发任务，分解为很多小迭代周期可完成的任务；同时每一次迭代都可以生产或开发出一个可以交付的产品。
  

• 持续可用的软件
  这样用户能够参与到整个开发过程中，使需求变化和用户反馈能被动态管理并及时集成到产品中。
  

• 文档的沟通效率，不如面对面的沟通
  面对面，通过白板，是最高效的沟通方式。
  

  
  

敏捷项目管理和传统项目管理的对比