我们先来看看情节吧。 情节现在回想起来。 做人事的时候，那被称为悲惨。 我记得有一次，客户的需求被修改了。 另外，我们本来对业务不太了解，所以又加了三个上将(响、强大豆、亚光)参加。 我眯着眼睛的鞋和完成一些功能的应该是V1.0版吧。 之后，客户的需求发生了变化，功能开始增加，内容开始变得复杂。通过对现有变更业务需求的总体分析，大家一致做出的决定还是重新制定吧。 因为如果在V1.0上继续修改，修改的成本将远远大于重新开发的时间。 大家说，重新开始吧。 这个过程中我们讨论的问题，如果文本文档不是全部的话，他们三个人是做不到的。 (业务不熟悉，业务结束后代码不熟悉，他们三个很难下手)、UML图、数据库等随着不断修改
那时，我们头脑中的开发理念是，如果有文档、数据库和UML，我们的开发人员会不会基于文档驱动开发进行学习？ 很简单啊。 照着打就行了吧。 毕竟有合作的经验。 大家最吐槽的是文档不完备、文档书写不畅、文档……，数据库设计不完善、数据库文档也不好吗？ 等等！
我们的开发理念是软件功能中的经典瀑布模型，我一直想遵循它。 我知道最后大致上还没有遵循。 如果不适合这个需求持续变化的时代，或者那个开发模式太旧了，或者传统的开发模式没有在文档和时间表上花很多时间，最终可能会因为需求的变更而翻船。 大家也因为文档的开发而遇到问题和吵架……整个团队的影响果然不小啊
至今为止，我深切感受到，如果在现在的软件开发过程中需求持续变动的项目，保持传统的瀑布模型，“越甜”，软件越往下开发，越想让自己去死……。
敏捷开发的相遇很晚呢
最近准备了软件测试，所谓需求主要是影响沟通，在我们的小组中推进者正在推进敏捷开发的方法。 其实我们平时也一直这么做，但我没有体会到这已经形成了比较高效科学的软件开发方法。 我和影响带着4个人做项目的话，总体上感觉很好。 我还交流了敏捷开发的书、博客、追求的流沙们，努力把敏捷开发的指导思想用到我们的人事两个人身上
Scrum概述
Scrum是一个兼具计划性和灵活性的敏捷开发过程，原语来自橄榄球“持球人”。 橄榄球比赛的每个冲刺前都有一个制定计划的过程，冲刺开始后xhdl会根据原计划随机应变。
瀑布模型将开发过程分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代(称为Sprint、冲刺)，一般为2~4周。
在日常工作中，产品负责人维护按优先顺序排列的“产品开发预定项目”，即从顾客价值理解并说明的产品功能项目。
在每次迭代的第一天举办迭代计划会(Sprint Planning Meeting )。 产品负责人逐一选择优先顺序高的部分进行说明。 小组可以就需求详细情况、完成标准等进行提问，逐条估算，并将其列入这次反复开发任务，直到任务量饱和。 迭代开始后，这些任务不会有很大的变化。
argin:0in; font-size:10.5pt"> 在迭代期内，团队将决定任务分配、所需的技术等，逐一完成任务。每天团队会进行一个简短的站立会议即每日立会 Daily Stand-up Meeting，沟通当前进度、下一步任务和当前存在的问题，以借助团队的力量解决。团队还维护一张“燃烧图”（Burn Down Chart），即所有任务的累积剩余时间随开发进程与日递减的图形，以观察和预测所有任务是否会按期完成。
在每个迭代的最后一天，团队会召集评审会(Review Meeting)，邀请产品负责人等参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈。当天还会召开反思会(Retrospective Meeting)，对本次迭代中的成功与失败之处做出总结，并在以后迭代中进行改进。
我们的迭代期为一周（每周三给客户增加一个新的版本），同时向客户展示我们快速开发的能力。在掌握整体紧急重要的需求之后，根据时间由响确定需求之后分出单个合适的小模块、颗粒，分配工作时之后再让大家自己类似抢小米一样枪功能（自己愿意做的，一种是自己很熟悉的；一种是自己确实想锻炼练习、拓展、挑战的），极大了提高了小组成员的兴趣和友好性、工作的效率。
当然在制定任务和抽象颗粒的时候会和组员一起商量制定，这样更加结合大家自己的情况来完成，避免颗粒过于大、过于小，更加的接近人性化吧，最主要是整体Team团结大家开心有干劲哈。
由于每次会议只持续10～15分钟，人们习惯在工位附近的四楼楼道上站着开会，所以被叫做“每日立会”，每天10:10-10:25为晨会时间每日立会上每个人汇报三个问题：我昨天做了什么，我今天要做什么，我遇到了什么困难。
由于小组曾经共同估算任务，所以如果出现偏差，可以沟通解决出现的问题……
主要是大家展示自己的成果（成就感啊！），检查大家做出来的效果和用户提出的要求的是否一致性？是否满足需求？
代码规范、注释规范，都要查！
尽管有正式的评审会，但很多团队习惯在单个故事完成时，就让产品负责人进行单个故事评审，以确保交付时不会有“惊喜”
Scrum过程-反思会（RetrospectiveMeeting）
怎样开展反思会？
☺反思会是Scrum中最难以实施的活动之一。
☺反思会上讨论三个问题：我们上个迭代有哪些事情做的好希望继续，那些事情做的不好希望改进，有何改进计
划。
☺经常出现一些问题多次被提到，但却始终没有解决。应该每次仅就1～3个关键问题做出可行的解决方案，在
下一个迭代执行改进。“可行”的概念包括两个含义：第一是方法简单，影响面小，见效快；第二个是目标不
要激进，而要现实可行，积少成多。
☺如果必要可以执行领导回避制度，即具有管理职能的人不参加反思会，即使这些人是产品负责人，项目经理，乃至baddp。
大家共同思考近期出现的问题（调试出现问题）、交流少、效率低下的原因，大家相互分析共同把项目做好，客户满意。
由响确定需求之后分出单个合适的小模块、颗粒，之后再让大家自己类似抢小米一样枪功能（自己愿意做的，一种是自己很熟悉的；一种是自己确实想锻炼练习拓展挑战的），极大了提高了小组成员的兴趣和友好性、工作的效率
现在来说当初他们四个（徐娇、文哲、一清、仁爱的大地）接触了解、上手，整体上还是很快的，在一周之内完成了客户提出的急需的功能还是很满意的哈。
作为项目组长的我们可以及时了解组员的进度情况、心情、遇到的难题、功能的实现过程中遇到的好的实现思路都实时跟进了解，为他们做好服务、尽量让他们站在巨人的肩膀之上来快速成长，当然也有碰壁他们接触锻炼，为我们项目的后续持续的迭代有了明确的方向指南。
每日的日报记录详细记录，每天都有目标、有收获；为今后个人的学习总结提供了好的日志、总结；共性问题解决方法和大家及时的共享，避免重复做重复性的工作，记录着每个人的成长脚印。
面对这样需求持续的变更，根据客户实施情况及时完成客户需要的功能，敏捷开发很好的做到了这一点，当然这个过程中会遇到各种各样的问题，只要我们以一颗平常心对待，把它当做我们成长的桥梁，剩下的事就都好办了，在整个项目管理中我们还是最注重关心组员的个人心态、情绪、每天是否有所收获等等毕竟这才是一个人是否可以持续战斗下去的最关键因素，良好的沟通、及时的解决遇到的问题、给予方向性的指导、亲和力都是重要的、。
我们在敏捷开发理念在指导下前进，整个Team快速的成长、尽情的体验软件开发带来的愉快的体验，加油，My Team，Good Team!
接下来会和大家分享
项目管理---敏捷开发---到底要不要写文档？
敏捷开发之结对编程带来的不一样的体验？
等等……敬请期待吧！