团队管理之敏捷开发
一、敏捷实践
敏捷开发中一直秉承的理念和宣言是：我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为：个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。分别解释一下这几个问题：个体和交互胜过过程和工具 是说一个团队的好坏，不一定是团队中的每个人的技术都是一流的。但是，这个团队必须在合作的时候能够有效的进行沟通。合适的工具才是好的，工具和项目一样，需要跟着业务的复杂度进阶; 可以工作的软件胜过面面俱到的文档 是说没有文档的软件是一种灾难。文档能够追溯项目的历史。但是编著众多的文档比过少的文档更糟。编写的文档需要和编码保持同步，就会花费更多的时间，如果文档和代码之间失去同步，文档就会说谎；客户合作胜过合同谈判 说的是成功的项目需要有序、频繁的客户的反馈。不是依赖于合同或者工作的陈述，而是让软件的客户和软件团队密切的在一起工作，并尽量经常的提供反馈；响应变化胜过遵循计划响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的并且适应商务和技术方面的变化，较好的计划策略是：为下两周做详细的计划，下三个月做粗略的计划，长时间的做一个大方向的目标。
二、原则
- 通过尽早的、持续的交付有价值的软件来使客户满意。
- 敏捷开发是不惧变化的，在任何时刻都欢迎改变需求。敏捷过程利用变化来为客户创建竞争优势。
- 经常性的交付工作的软件，交付的间隔时间可以从几周到几个月，交付的时间越短越好。因为交付的次数越多和客户沟通的就越多，这样来业务的方向上能够更好的把控方向。
- 整个项目开发期间，业务人员和开发人员必须天天都在一起。
- 围绕个人构建项目，提供所需要的环境和支持，并信任他们能完成。
- 在团队内部，具有效果并且富有效率的传递信息的方式是面对面的沟通。
- 通过代码功能的完成程度评估进度，而不能通过文档评估进度。
- 敏捷过程提倡可持续的开发进度。责任人、开发者和用户需要保持一个长期、恒定的开发速度。
- 通过高质量的代码来构建项目和需求，不会将变得更好放到下次，而是在当下。
- 将当下的工作做到极致，不考虑未来的威胁。
- 需求不会分配给具体的人，而是分配给组织，让组织去安排。
- 敏捷需要团队反省和自我反省，怎样才能让工作更高效。
三、极限编程
极限编程是敏捷方法中最著名的一个。它由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。一个项目的交付周期需要尽量的缩短，不要将战线拉的过长可以分为：1、迭代计划：每两周进行一次迭代，根据需求估算工作量，估算的总量不能超过预算。一旦迭代开始，任务就不能修改。 2、发布计划：需求团队经常创建一个计划，这个计划里面包含了大约6次的迭代任务。在每次迭代之前，按照需求的优先级，挑选出来。在项目验收时，测试人员应该根据客户指定的验收标准进行项目的验收。在研发的过程中不要让专职人员干专职的模块，需要所有人员都需要掌握项目的各个模块的地方。相当于AB备用岗位。研发的过程中应该给到开发人员足够的自由时间，在 XP 原则中时不允许团队加班的，只有在发布版本的之前是可以的。