２０１４年１２月２７日下午３点，老师听完ＩＴＯＯ的Java和.Net项目的延期原因，总结了以下三点：１．没有全局观，统筹没有做好　　２．如果遇到问题，没有去找相应的理论支撑　３．没能很好的使用工具

　　我们新生入学，作为ＩＴＯＯ的子项目，开发起来也遇到了重重困难。想起了老师说的第二点，寻找理论支撑，我翻阅了之前推荐给我们的电子书《轻松Ｓｃｒｕｍ之旅》，它给项目的管理起到了很好的指导性作用。通过这本书的引导，我对敏捷开发的常用的知识做了详细的整理。

一、准备Scrum之旅

１．瀑布模型VS敏捷开发：

　　瀑布模型的开发模型固定，可行性分析——＞需求分析——＞设计——＞编码——＞测试——＞运维。优点：提供了各个阶级的检查点，一个阶段完成，只需考虑下一个阶段（跟贪心算法是不是很像？）适合于迭代。缺点：文档多、开发末期才能见成果，不适合用户需求的变化。程式化的东西难免让人觉得假大空，死板。

　　敏捷开发最大的特殊就是应对客户变更的需求，以人为核心，采取迭代的方式，循序渐进的开发软件。一听到这个名字，感觉开发的过程比较迅速！优点：能很好很快的给用户提供满意的产品。缺点：工作汇报，如果没有完成任务，会害怕暴漏自己能力不足。另外对沟通能力，业务理解能力要求比较高，全能型开发者。总之一句话：门槛高啊！

２．禅道的使用：

　　产品负责人：确定产品的功能和时间，优先级。人员一般是市场部或者开发部使用该产品的人员来担任，主要目的是根据需求确定功能。

　　Scrum Master:监督整个项目，调整项目计划，促进团队成员的沟通，扫除障碍。掌握产品开发进度，参与每日Scrum会议、Sprint计划会议和Sprint评审会议。

　　Scrum Team:5-10个全职工作成员。

       燃尽图：总剩余时间的燃尽图，就是本次迭代中所有拆分任务的剩余时间总和，随日期的变化而逐渐递减的图，它为敏捷开发提供了可视性。

通过它能帮我们发现以下问题：

1.团队计划制定情况如何？

2.在一个Sprint中，团队对计划的的故事执行情况如何？

3.团队是自我管理的吗？作为“团队”来说，工作步调一致吗？

4.团队能进行哪些改进？

 二、激动人心的Scrum之旅——第一站

　　每日Scrum会议：

时长：站着，不应该超过15分钟。

内容：昨天我完成什么任务？今天我打算做什么？我遇到了什么障碍？

内涵：大家同步信息的平台，而不是交流问题，讨论问题的渠道。而且制定计划也要按照大家的实际情况来制定，不能项目组长武断做决定。

注意：1.团队成员间的交流，承诺，不是汇报进度。2.不是解决技术问题的会议。

Sprint评审会议：

　　Scrum团队在会上用Demo的形式来展示他们在这个Sprint上做的工作，与会人员评价它的新功能。

 　　用Demo的原因：1.直观，及早发现问题，利益相关者可直接反馈 2.为完成功能，团队会努力并发布这些功能 3.减少99%的也许完成的数量。

Sprint回顾会议：

 　　Scrum Master首先给大家看Scrum Backlog,总结这个Sprint,大家讨论比较重要的一些事件。认为哪方面做的好，哪方面需要改进，如何改进。讨论成果，如何在下一个Sprint中做的更好。

三、Sprint计划与变化

１.思想

　　不应该有理由和借口抛弃团队。

 　　不应该隐瞒团队的技术实力，否则很难做切合实际的计划和评估。

　　善于寻求帮助是个好习惯，不仅仅是针对敏捷开发。

　　敏捷思想，团队里面没有绝对的权威，每个人都有可取之处，要避免少数服从多数。

２.工具和机制

　　项目文档管理工具Confluence。　

　　单元测试是不可避免的一环。

　　代码复审＋结队编程可以提高效率。

四、总结

　　项目开发仍在继续中，总有新的问题出现，老师说的很对，你做过的每件事肯定有其他的人做过，学会站在巨人的肩膀上是一种能力。欲带皇冠，必承其重。开始学习的不适是必然的，但是使用工具带给我们的效益远远超乎我们的想象。

如果您觉得我写的东西有些帮助，敬请期待我的下篇博客轻松Scrum之旅（下）。

轻松Scrum之旅（上）