敏捷开发

敏捷开发在很多IT公司实践已经有些年头了，并不是新鲜事物，实际上敏捷宣言并没有创新，只是许多软件开发实践经验的荟萃，挖掘和总结软件管理中包含最优方案。

敏捷开发的目的：

带给客户价值，是所有敏捷实践的主要动力来源。

从产品的角度来说：是为了缩短产品上市时间，提高产品质量和服务生命周期，增加产品的业务和市场价值。

从管理的角度来说：提高管理项目沟通中的便捷性，增强透明度，节约软件开发成本。

敏捷开发实践模式：

通过项目启动会，确定产品具体功能目标，启动会通过规划扑克打牌来对工作进行评估，将软件开发周期拆分成2-6周迭代。每天的项目组成员通过站会，互相交流当前迭代进度.在每轮迭代完成后，向项目的相关负责人进行系统功能展示。

敏捷开发辅助实践模式：

1、融入敏捷社区，参加敏捷讨论组或论坛，或进行在线交流。这种方式可以对敏捷过程中出现的问题提供解决方法和思路。

2、组织读书会，通过定期会议讨论、分析和学习，定期组织会议挑选一个读书主题进行相互交流。

3、组织研讨会，研讨会是一个推进会议，相关成员一起做练习、讨论，创建文档。这种方式必须依赖多个人的输入。

4、组织课程培训，通过知识分享练习，引导和帮助学生学习相关方法，帮助项目成员快速成长，从知识中获益。

敏捷开发工具：

1、每日站会：昨天工作中遇到的几个小问题，今天需要做的任务，简洁有效的小团队沟通方式。

2、白版：直接反应工作的具体进度。比如日常开发的进度、测试缺陷的进度。

3、演示、评审、反思会：项目团队成员相互协作沟通交流，对系统的功能设计等方面进行优化。

4、用户故事：站在用户的角度去梳理用户具体业务场景，BA在需求文档中可以通过小故事的角度帮助开发和测试梳理业务功能。

5、持续迭代：通过版本的周期性迭代，高质量的交付产品，以相应市场的需求变化。

关于敏捷：

敏捷开发绝对不是一套固定的标准化流程，而是根据项目团队需要，可以自我梳理出来的一套敏捷流程.不一样的项目经理会有不一样的流程，一样的项目经理，不一样的团队也会有不一样的流程。所以没有最好的流程，只有适用并且持续优化流程是最好的。

其次敏捷开发中对个体的要求很高，在敏捷宣言里面第一行这样写道：个体与交互重于过程和工具.个体敏捷性的主体是人，责任心是个体敏捷性的基石，如果没有积极负责，团队从敏捷开发中获得显著成效的可能性都微乎其微。个人感觉敏捷特别适用大神，大神知道自己自己在干嘛、别人在干嘛、别人的专业领域、本身技术等方面也很厉害，因为这样在敏捷开发里面通过沟通能更好的解决问题。

敏捷的收获：

1.更快的版本发布：缩短了软件开发的时间，敏捷里面强调的是快和周期性，以前我们产品组2周一轮迭代，客户的需求和功能经过产品组评审后，能快速满足客户的软件开发需要。

2.项目进度可控：以前我们会基于产品进行定制化，定制化过程我们会对项目进行周期评估，通过敏捷开发按合同约定的周期去交付产品。整个产品团队通过敏捷开发，在固定周期内交付某个功能模块，迭代功能进度完全可控，项目组成员目标也更明确。

3.产品团队有条不紊：通过设定的敏捷流程，每个成员工作目的很明确，项目进度不会出现阻塞，整个团队在一起作战，步调一致。

敏捷的影响：

1.频繁的会议：敏捷里面最需要的就是沟通机制，项目组频繁的沟通会议机制是必须的，但是特别对于开发的来说，会议意味着时间，尤其是产品需求功能迭代、晨会、版本发布、用例评审的时候会占用很多时间，如果项目成员参与产品也参与项目这会比较头疼，唯一的方式只能说提高会议效率。

2.频繁的迭代：频繁的需求迭代，超负荷的工作.虽然产品的迭代是必须的。但是我们会发现其实项目组成员一直处在超强度的迭代中，一周可能有6天时间都在加班，大家总是很忙，项目组成员也是疲惫不堪，总是忙着做，而停下脚步去思考。只有执行力，没有创造力。所以项目经理需要更好的前期参与项目评估，多维度的统计项目周期，进行长跑迭代，合理的考虑下面员工的感受，实施弹性制度等等。

3.其它方面：迭代意味着执行，会发现项目组成员会更多的像机器一样工作，没有特定提升自己学习的目标和想法。更多的是为了工作而去学实现起来.沟通过程也更多的是工作方面，而且开发和需求这边有些技术的实现存在分歧，容易产生分歧。有的时候，为了盲目的追求周期性产出，缺少测试环节，就是迭代工作虽然已经完成了，但是总是感觉做的不是很细很到位。