２０１４年１２月２７日下午３点，老师听完ＩＴＯＯ的Java和.Net项目的延期原因，总结了以下三点：１．没有全局观，统筹没有做好 ２．如果遇到问题，没有去找相应的理论支撑 ３．没能很好的使用工具
我们新生入学，作为ＩＴＯＯ的子项目，开发起来也遇到了重重困难。想起了老师说的第二点，寻找理论支撑，我翻阅了之前推荐给我们的电子书《轻松Ｓｃｒｕｍ之旅》，它给项目的管理起到了很好的指导性作用。通过这本书的引导，我对敏捷开发的常用的知识做了详细的整理。
瀑布模型的开发模型固定，可行性分析——＞需求分析——＞设计——＞编码——＞测试——＞运维。优点：提供了各个阶级的检查点，一个阶段完成，只需考虑下一个阶段（跟贪心算法是不是很像？）适合于迭代。缺点：文档多、开发末期才能见成果，不适合用户需求的变化。程式化的东西难免让人觉得假大空，死板。
敏捷开发最大的特殊就是应对客户变更的需求，以人为核心，采取迭代的方式，循序渐进的开发软件。一听到这个名字，感觉开发的过程比较迅速！优点：能很好很快的给用户提供满意的产品。缺点：工作汇报，如果没有完成任务，会害怕暴漏自己能力不足。另外对沟通能力，业务理解能力要求比较高，全能型开发者。总之一句话：门槛高啊！
产品负责人：确定产品的功能和时间，优先级。人员一般是市场部或者开发部使用该产品的人员来担任，主要目的是根据需求确定功能。
Scrum Master:监督整个项目，调整项目计划，促进团队成员的沟通，扫除障碍。掌握产品开发进度，参与每日Scrum会议、Sprint计划会议和Sprint评审会议。
Scrum Team:5-10个全职工作成员。
燃尽图：总剩余时间的燃尽图，就是本次迭代中所有拆分任务的剩余时间总和，随日期的变化而逐渐递减的图，它为敏捷开发提供了可视性。
通过它能帮我们发现以下问题：
1.团队计划制定情况如何？
2.在一个Sprint中，团队对计划的的故事执行情况如何？
3.团队是自我管理的吗？作为“团队”来说，工作步调一致吗？
4.团队能进行哪些改进？
时长：站着，不应该超过15分钟。
内容：昨天我完成什么任务？今天我打算做什么？我遇到了什么障碍？
内涵：大家同步信息的平台，而不是交流问题，讨论问题的渠道。而且制定计划也要按照大家的实际情况来制定，不能项目组长武断做决定。
注意：1.团队成员间的交流，承诺，不是汇报进度。2.不是解决技术问题的会议。
Sprint评审会议：
Scrum团队在会上用Demo的形式来展示他们在这个Sprint上做的工作，与会人员评价它的新功能。
用Demo的原因：1.直观，及早发现问题，利益相关者可直接反馈 2.为完成功能，团队会努力并发布这些功能 3.减少99%的也许完成的数量。
Sprint回顾会议：
Scrum Master首先给大家看Scrum Backlog,总结这个Sprint,大家讨论比较重要的一些事件。认为哪方面做的好，哪方面需要改进，如何改进。讨论成果，如何在下一个Sprint中做的更好。
不应该有理由和借口抛弃团队。
不应该隐瞒团队的技术实力，否则很难做切合实际的计划和评估。
善于寻求帮助是个好习惯，不仅仅是针对敏捷开发。
敏捷思想，团队里面没有绝对的权威，每个人都有可取之处，要避免少数服从多数。
项目文档管理工具Confluence。
单元测试是不可避免的一环。
代码复审＋结队编程可以提高效率。
四、总结
项目开发仍在继续中，总有新的问题出现，老师说的很对，你做过的每件事肯定有其他的人做过，学会站在巨人的肩膀上是一种能力。欲带皇冠，必承其重。开始学习的不适是必然的，但是使用工具带给我们的效益远远超乎我们的想象。
如果您觉得我写的东西有些帮助，敬请期待我的下篇博客轻松Scrum之旅（下）。
原文地址：http://blog.csdn.net/wangmei4968/article/details/42394685
