敏捷开发之团队级经验分享

1.团队核心实践

在我们目标模糊时，到达终点没有最短路径，只需要将阶段性目标变得清晰就可以把目标最终效果可视化，也可以将最终目标可视化，这就需要正式进入产品研发前，产品经理，交互设计师，视觉设计师，主程，共同制作高保真的原型，它可以代替需求文档，并让所有人理解这种目标，并提出改进意见。为了使组织转型过程具有敏捷性和弹性，我们需要创建一个有持续改进特性的核心实践。这些实践需要敏捷工程实践来实现。

1.1时间盒短迭代

即迭代周期固定，不超过4周，每个迭代都会交付具有商业价值的潜在可发布的功能。团队以商业价值重要性，风险级别和架构对特性进行优先级排序，高优先级先处理。且迭代开发包括所有必要活动，如计划，分析，设计，编码，测试，集成，验证。

1.2优先级产品代办事项列表（Product Backlog PBL）

1.3持续交付

建立在持续集成基础上，本身需要持续改进。保证每次构建成功，一旦有bug,要即使修复，不能拖到第二天。它是一种心态和开发时间。保证开发人员在提交代码前，检查他们的商业代码和测试用例，同时，要保证新代码的测试高覆盖率。

1.4自管理跨职能团队

这点比较难，因为它要求管理者足够信任团队成员，让团队自我管理能力逐渐提升，管理者权利逐渐下降。打造学习型团队，通过内部学习和团队间学习来促进组织协作。

1.5检测与调整

即每次迭代之后，要思考如何改善他们的工作，并将具体的改进意见落实到下个迭代。

Bas Vodde 敏捷度量，即诺西测试或者叫诺基亚测试。

结合公司实际，总结如下实际问题

1.同一个时间多个项目，人员缺口，客户拒绝支付前期项目款，交付的产品不能满足客户业务需求，究其根本原因在于，没有对客户需求按商业价值来排序。

2.项目延迟，实际工作量大于计划工作量，究其原因，上层看不到进度，这还包括拍脑袋承诺。

3.很久集成一次，导致出现问题来不及修复，典型的瀑布模型，

4.测试，业务，开发，独立，几乎无沟通。

5.测试手动

6.bug过多，开发人员认为缺陷检查是测试人员的责任

7.验收通过率低，没有及时反馈。

解决方案：

需求管理，文档应该被简化，尽快开发出可用的软件

1.PBL管理，列出用户故事表，包括ID，需求描述，重要性，评估值，满意条件，状态，备注等。

2.故事强，即整体全貌，若是产品，则为最初产品愿景，或者客户原始需求。

3.高/低保真原型

即变更要发生的前期，即要将变更杀死在摇篮里。尽早在迭代周期给客户演示客户看中的部分，这样，可以减少变更成本。

4.实例化需求，即做好如何演示，提高满意度，以一种对开发团队有所帮助的方式（活动文档）描述计算机系统的功能和行为，让不懂技术的利益关系者也可以理解。

5.质量管理，让开发者具有归属感，即我不完全是写代码的。要求每次迭代之后，交付可用软件，不要产生过度的技术负债。产品要有足够好的架构。

6.可视化管理，即让团队成员都清楚当前进度，更加关注整体优化，例如看板等。

7.团队协作，最好一个团队，都在一起

8.流程改进，由团队来驱动，而不是强制命令方式。

关于开会

很多时候，发现公司会议，经常会出现相互炫耀自己在一些认识上的独到之处，当然这些独到之处只是相对于我们这些人而言，其来源可能是某个人的博客，媒体的宣传，小众群体的推广等，会议主题会被扯到很远很远的地方。

关于重构

虽然，表面上看起来，重构要要花大量的时间和经历去做已经实现的功能，但其实不然，它是一种态度，表明我们愿意为产品的持续集成而努力！

重构，可以让代码保持干净，虽然在公司执行实时重构很困难，但它考验您的态度和意志力。

从某种程度上看，敏捷更像是走走看看的样子，但它对探索性东西更加实用。但是，我们也要注意到底是否适合真的用敏捷，在漫天铺天盖地的敏捷潮流中，某个人对敏捷都有自己的认知，但很少有人真正去分析团队，分析项目类型，交付类型，就盲目引入敏捷，结果未必比瀑布开发好。

在我们团队没有达到期望值时，凡是类似军工，航天，制造业等这写前期需求就很明确，并且业务类型基本没有变更的项目和产品，传统开发方式更适合。

而在前期需求不明确，在开发过程中需要不断演示，不断改进，不断反馈，功能不断变化的，才适合用敏捷开发。

而培养我们的沟通，互助，主动，责任，谦虚等这些工作态度的，则是任何方法论都是适用于团队的。

以下是来及敏捷一千零一夜这本书的其中一个故事，讲诉主人公作为leader的经验分享，我剽窃过来了，哈哈，因为作为初学者，我感觉他讲的很有道理：

1.团队好奇心，通过分析技术方式，调动团队成员好奇心。

2.团队惯性，或者叫团队文化，作为一个主管，你要设法建立一种机制，让团队从惯性中挣脱出来，办法就是走在前面，让别人愿意跟随。

3.镜子，当你想要改变团队文化，或者某些自我感觉良好的成员，你所要做的事情，就是找出一面镜子，让对方看到自己。

4.从一开始，就要高标准，对团队设置高期望值，团队才会拥有持续改进的动力和愿景。

5.程序员文化，反思自己职业，只有从过去中反思，才能知道下一步怎么做。

6.程序员与建筑工人，是不同的，编译器才是建筑工人，程序员是设计师。

7.代码重构，团队崇尚代码重构

8.让实践落地，即要不断总结，复习

9.权威，有职业赋予的权威，也有专家权威，前提是，要无私，用于说不知道。

10.点燃程序员的激情，即成就感。

11.排除技术障碍，建立和谐舒适的技术环境。

12.功能，以回报率为主

13.让领域模型解耦，降低模块耦合度。

14.做正确的事，即使再正确的做事，做的事不正确，也失去意义。

15.不要沉迷于解决方案，最终要的是用户问题，如何实现，只是你自己的解决方案，用户压根不在乎。

16.每做一件事情，多问为什么。

17.估算的意义，在于揭示大家的理解和所拥有的知识的不一致，而非估计工作量。

18.有些规则，不懂为什么，就照做，有一天，你会懂，懂了再改进。

19.测试有先

20.建立分享环境。

敏捷，不是一种状态，而是一种持续改进的姿态。

OK，这本书收官，获益匪浅。。。