版本发布失败总结

1.团队对版本发布成功/失败的定义

1.1. 成功发布的依赖因素

1.1.1.明确的交付（范围）定义

对于每一个迭代Iteration，团队的每一位成员都需要清晰的知道，我们这一次迭代的目标是什么，即我们的Iteration Goal，我们要完成哪些Story，优先级顺序是怎么样的，每一个Story要达到怎样的状态才算是可交付的。

1.1.2.合格的质量

每次发布必须达到质量目标才算是成功的发布，简单的说也就是要通过我们的Sanity Test（冒烟测试）。

1.1.3.按时交付

每次发布必须按时，时程符合才是符合交付要求。

1.1.4.需求理解

做好需求理解是成功发布的前提，前期需求理解清楚了后期的麻烦就会大大减少，风险也会大大降低，包括质量的风险（需求理解做好了质量一定不会差），交付范围的风险（需求理解清楚了才有可能把范围彻底搞清楚），时间的风险（需求理解清楚了才可以估算更准确的时间）都会降低。

1.1.5.预发布动作

这点看似不重要，其实非常重要。这里说的预发布动作，意思就是提前做发布，不仅仅是要提前做，而且要比较完整和规范地做才对。

特别是对于第一次发布的时候，要做的事情其实非常之多，建议至少提前三天来做预发布动作。因为第一次做发布是需要准备的东西很多，比如说安装手册，安装手册不仅仅只是写文档，并且作为发布人还需要对照文档的每一步去严格执行安装的动作以保证发布的所有内容是可正常安装的。这个动作可能就要花上一天的时间。再一个很重要的内容就是发布人需要对要交付的所有内容做系统集成，并完成Sanity Test，以确保发布的版本是可被测试的，没有严重问题的。而这个过程是最容易引起返工，因为重大的缺陷必须得解。那么这两个主要动作完成了，就可以大大的保证第三天的发布动作能够一次成功。即使可能失败了，也可以拿前一天的预发布内容做发布动作，减少发布失败的可能性。

1.2. 可能导致发布失败的原因

这里与成功发布的依赖因素是一一对应的，做的好成功的机率就大，做的不好，当然就可能导致失败。

1.2.1.范围不清

不知道我们这次迭代Iteration要发布什么东西，包含哪些内容，交付哪些修复的问题。何谈发布成功？

1.2.2.质量太差

功能漏洞百出，业务流程阻碍性故障，完全不可被测试，即使发布了也会被退版。何谈发布成功？

1.2.3.无法按时

到了发布时间无法发布，对于我们纬创On Time率100%目标来说，同样也是失败的。

1.2.4.需求理解不到位

上面成功因素的部分也说到了，需求理解清楚了才可能范围清楚，才可能质量达标，才可能按时交付，需求理解是基础和前提，反之何谈发布成功？

1.2.5.没有预发布

预发布动作是为了让我们提前做好充分的准备，尽早发现问题并及时解决，实质就是为了提高发布的成功率。

2.什么导致我们的项目发布失败呢？

2.1. 对于发布要做什么不清楚

团队的每一个人都应该对发布要做什么有所了解，这样才能更好配合发布人进行发布动作，因为发布其实也涉及到了一个团队合作的问题，一边发布者在发布，而另一边开发人员继续开发或者修改缺陷，那么两者之间如何配合呢？如何找到合适的时机去做发布动作呢？这个需要大家去认真考虑。

那么作为发布者呢，更应该清楚并且熟悉发布需要做什么？在我们组织过程资产中其实已经对此过程做了很详细的定义，有PPT指南以及To Do List。希望发布者熟记。

2.2. 没有完成预发布动作

虽然PM有要求在发布截止日前三天做预发布动作，并且发布人也做了一些准备，比如编制安装手册，安装Oracle环境等动作，但是远远不够完整。很多动作都没有做到位，或者压根没做。从而导致了发布的风险增大。

那么如何做好预发布，在上面成功发布的依赖因素里的第5点里已经谈到，这里不再重复。

2.3. 发送邮件及相关Story无法按时交付

这一点在大家看来可能是最主要或者最重要的原因了。因为与邮件相关的多个Story无法交付，而导致整个Iteration无法发布。可是在我看来并非如此，这个问题其实只是我们最后一关关卡失守而使问题急剧爆发出来而已。

经过大家分析，得到以下几点主因：

2.3.1.计划任务时分解不彻底，可跟踪性差

我们在一开始做计划时，对于邮件部分的Story过于轻视，没有完成对整个Story完整的任务分解动作。没有拆分出我们可识别的所有的可能要做的任务Task。导致任务墙上我们对这些Story的Task存在遗漏，以至无法跟踪甚至遗忘了这部分的工作。

2.3.2.执行过程中Story的PIC问题

首先，对于Story的分配出现了衔接问题，邮件的Story的接收人澄清只负责邮件Story的部分开发工作，那么另一部分谁来做，story最终由谁来交付，不得而知。

对于这一点，建议对于每一个Story我们都应该有且只有一个唯一负责人。那么这个负责人的职责就是保证Story的完成，但并不一定全部需要他来做，可能是多人合作完成；保证Story的完整与可交付。所以他要hold住整个Story并负责集成与交付。

第二，在做邮件相关Story时，志刚生病请假了。在志刚生病时我们团队的衔接工作也没有做好。志刚生病了，那么志刚负责的部分谁来接手，谁继续对志刚的Story承担交付责任，我们没有及时定义。这也导致了工作上的遗漏。

对于这一点，我们总结很重要的一点就是，如果有人临时突发不在团队里了，而又等不及他回来，需要立刻更改Story的唯一负责人，以保证story的交付。

2.3.3.没有对Story进行有效的验收

这里大家可能都会认为是TM（TechnicalManager）没有做好验收工作，但我们认为TM只负次要责任。我们是一个团队，我们每一个人都应该对他自己交付或者别人交付的产品负责。对于自己交付的产品至少要保证单一“部件”没有任何质量问题，是完整可交付的。比如这次事件中，邮件相关的多个Story，只要第一个交付的Story严格按要求进行验收，检查其完整性，就会尽早地发现邮件功能尚未实现，其实现方案可能存在的问题及对其它Story的影响。而TM关注的更多应该是所有你们交付的“部件”集成到一起时是否仍然可按照客户的意愿正常工作。

2.3.4.遇到问题时的决策与执行力问题

在临近发布时，与邮件相关的多个Story仍未完成，对于实现邮件功能与Story其它部分的整合，我们面临技术困难。因为之前志刚有做过邮件这部分相关的另外两个Story，并且已经交付验收，但是志刚不在，无法及时联络，所以在临近发布的关卡上我们很难用志刚的老方案继续走下去。

此时我们想到的主要解决方式有两种：a) 继续研究志刚代码，并且寻求外界帮助找到解决方法。其他邮件Story继续沿用老方案。b) 推翻老方案，用新的Travelling的成熟方案代替。

其实选哪一种方案并没有绝对的对与错，只是想抛出这个问题让大家多考虑考虑我们以后如果还遇到这种境况的时候我们应该怎么处理，怎么处理才是更好的方法？

对于上面的问题，首先我们应该做一些分析：

1）大致了解志刚的方案，他的设计思路是什么，既然志刚已经交付了两个Story那一定是有他的设计的。那么他的设计是否适合其余的邮件Story，工作量多大？如果要攻克志刚方案的难点又需要多大的工作量？这里就不得不强调一下，在平时成员间应该多针对各自的任务进行交流，分享技术方案和解决问题的经验，这样在任务衔接时困难就会减小很多。

2）如果用Traveling的方案，那么Traveling的方案是否适合我们的目前WiLegal的构架呢？Traveling的方案运用到我们项目上的风险是什么？有多大？有什么预防措施可以采用？如果改用Traveling的方案，那么志刚交付的两个Story是否有影响？将来的可维护性又如何？工作量有多大？以及返工带来的工作量，包括集成测试与系统测试等等。

3）综合分析各自利弊，团队应该得到最后的决议。当有了决议后，团队所有成员应该坚决执行，并积极主动发现暴露问题、分析解决问题。团队的力量是项目成功的坚强后盾。

仅以以上内容作为经验教训分享给大家，希望以此为鉴，持续进步。