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