篇外------最近家里事情太多，自我学习目前中断状态，为什么不能用敏捷的方式来改变自己忙碌低效的生活？这是最近在反思的问题，进而引发了对于自我感受和真实情况的比较，为什么我会觉得生活是低效的？是真的低效还是自我情绪问题？任何评价都要基于依据，大部分对于个人生活，我们的依据都是主观随意的，所以给自己的生活定义一个DOD，做生活的观察者、实践者、持续的改进也是敏捷精神的实践，有可能这个更有价值，我想周金根老师的敏捷个人终极目标也是让我们更了解和完善自我能够享有幸福的生活，在我的意识里说到底工作是生活必要非充分的子集。
回到正题，讲一讲我们团队正在主导实践的敏捷案例
背景：这是一个非常复杂的团队，技术开发团队大概25人左右是由外包公司提供的驻场，我司派了4名技术负责人带领这个外包团队，有3名本项目的产品人员，同时该项目还涉及到我司核心业务因此也需要外部3个团队配合提供基础服务能力。
现状：已经做了2期，第1期没有设计没有评审只赶进度，无pmo参与，如期上线bug数数不胜数最后宣告失败，紧接启动2期做了完善的评审，但是需求和设计阶段延期了1个多月，整个项目在后期只好制定了力保主流程允许出现非严重bug的目标，pmo后期参与，第2期整体上线延期一个月，上线后问题可控，结果相较1期相对较好。接下来3期怎么干的问题？我们作为pmo也是一个极具挑战的项目
问题：1、团队人员开发能力问题；2、外部团队协作问题；3、内部各节点界限不清晰；项目组总结经验大家一致认为最大的问题是对于目标的理解不一样，问题都需要反复沟通和确认。
方案：由于这个团队组成的特殊性，从一开始就不具备敏捷的先天条件，外包团队人员不够稳定，目标价值观很难协调一致，同时项目的特殊性有内部创业的感觉，各个岗位人员都是临时抽调配合很难密切，pmo在2期介入之后采取的传统项目管理模式，明显效果甚微，我们把目光投向了敏捷
具体落地实施：由于本次敏捷scrum的学习，让我很清楚一个原则，搞敏捷最大的问题是人，需要把人都捋顺了才能真正落地，所以我们制定了分阶段实践的方案，第一个阶段敏捷铺路；第二个阶段小范围小团队敏捷；第三个阶段再推广。之所以制定这样啊的方案，就是怕一上来就推敏捷，无法取得效果对团队来说容易丧失对敏捷的信心，所以要循序渐进，先把环境铺垫出来，为了避免因为改变项目管理模式给项目组带来额外的恐慌，pmo并没有直接跟项目组宣布我们要进行敏捷的准备了，而是在三期开始之前我们开始给大家灌输敏捷的思想，以及按照敏捷的思路制定问题的解决方案，其中定义DoD就是一项重点工作。
Definition of Done（DOD）完成标准，常见用于退出标准 , 完成条件，成功标准，等等，在敏捷软件开发中，存在多级的不同的完成定义。
为了让过程更顺理成章，我们把DoD的引入直接落实到了实践问题解决的过程中，而不是先去跟大家宣讲过多的概念，在前期总结时，针对项目团队技术能力薄弱的环节，我们引入了每日DoD标准，规范大家的行为，尽早的发现问题：
1，搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一日构建和测试发现的缺陷和问题。
2，下班前必须检入当天书写的代码
3，当天的代码必须在当天或者第2天邀请同伴进行代码评审
4，搭建持续集成环境，当天上下午必须至少各检入代码一次
项目组内需求和设计反复讨论确认的问题，究其根源发现是由于一些需求本身就还不够明确，如果前期一次性要讨论完很容易出现变更调整的情况，针对这个问题我们把原来一次发布周期1个月的情况，调整为缩短发布周期迭代发布的方式，把明确确认的需求放在一个迭代周期，并且制定了发布的DoD：
1，完成发布规划所要求的重点内容
2，通过发布的全量测试，回归测试范围是全范围，回归比率不低于50%
3，修复所有等级为1、2、3的缺陷，4级及4级以下缺陷不超过20%。1、2级缺陷必须修复，3级缺陷经过带缺陷发布审批后可以发布。
由于有明确的标准，项目组的执行过程顺畅了很多，项目还在进行中，未完待续。。。
