尝试伪敏捷

一、伪敏捷是指

         我想这个方法称不上是一个真正意义的敏捷，只是借鉴了一些敏捷的皮毛。主要目标是要做到：不要等，要快；不要过分关注文档，要关注产品；不要分配责任，要协作。

         不要再认为：需求就是产品的事、质量就是测试的事、缺陷就是开发的事。

 

二、为什么会有这种想法

         现在技术中心的常规做项目的方法是：先做需求，然后评审，然后等需求定稿，然后开发和测试并行做设计和开发，然后测试用例评审，这时候会发现有无数的需求待确认，然后这些待确认的东西一部分不了了之，开发做成啥样就是啥样了，然后开始测试，然后中间循环测试和改bug和测试和改bug…，然后上线。

         这中间有几个问题很影响最后的成果：

         （1）是需求的问题。我们老是在说需求未确认需求未确认，尤其是测试这边，在测试用例评审时，发现将近一半的东西未确认，由此还导致了一系列的矛盾（例如某同事的哭泣，囧）。想想看是做需求的人不负责或是偷懒或是怎么的，随便拿个文档来应付吗？应该不是这样的。面对繁多的功能，一个产品同事很难想得很全面。而我们的需求评审又安排得很集中，连续的大量的评审，很多评审中的意见和结论都没有被记录下来，导致后面不断的反复确认。

         （2）在这种模式下，越往后的工作，时间被压缩的就越紧张。矛盾最突出在测试这个环节。还拿XX说事，本次愚人版的测试时间压缩到1个月，某些系统或功能的时间只有半个月，能完成吗？上一次XX上线，仅仅是客户端的改造，从拿到第一个测试版本到上线，用了1.5个月。这次怎么办？通过加班或加人手就能来解决吗？纵观整个过程，测试工程师在前期“浪费”了很多时间，我们一直在等，等需求，等测试版。

         抛开时间不说，对于测试工程师还有一个负面的影响，就是作为最后一个环节，开始时间由不得自己，现在结束时间也由不得自己，但是整个产品的质量又要测试来负责。这对工作积极性的影响是很负面的。我们在前期提了很多问题，却得不到结论，一直拖着，到最后却要求测试工程师快！快！快！产品上不了线，全是一个原因“测试未完成”。

         （3）产品或功能的研发周期（注：这里的研发周期不是指编码这个开发周期，而是指功能从构思到上线的整个时间）长。竞争这么激烈，我们要靠这些功能来抢市场拼天下的，迅速出击才有效。结果被这个冗长的研发周期拖着，最后上线的质量什么的不说，时效性也差了。

 

三、怎么做？

         （1）立项，确定项目成员。

         （2）快速确定产品方向、功能框架、目标。此部分由产品人员主导，开发和测试需要知道结论。（这步可能在立项之前也已经完成了）

         （3）需求分析、测试设计、开发并行中。把需求拆分成很小的部分，以24小时为周期，每周期内都进行需求讨论、确认（仍以产品人员的文档为准）、测试用例设计、开发编码。每周期开始时确定本周期的目标，团队的所有成员都要致力于在本周期内完成这个目标。下一周期开始时先解决上一周期的问题，然后再确定本周期的目标，然后做事。循环。

         （4）后期进入测试阶段，也是同上，以24小时为周期确定目标并致力于完成。并且这个测试阶段可以和第（3）步是并存的，我们不需要等到完整的测试版再测试，可以拿一些中间环节的功能就开始测试。比如现在的XX客户端改造中，改进功能部分很早就开始测试了，能减少后面的测试压力。

         （5）这些小单元的工作结束后，只需要一个很短的时间做系统测试以及上线前的验证准备工作，就可以上线了。

 

四、带来的好处

         （1）在这种模式下，每天的目标是明确的，加起来，整体的目标就是明确的。大家是朝着同一个方向去努力的。不确定的东西，很快就有机会提出来，24小时内就能得到解决。需求不确定的问题应该在极大的程度上避免了。

         （2）测试时间延长了，测试工程师从一开始就可以工作。就算是最后算起来，最后的上线时间并没有提前，但投入在测试中的精力多了，整体的质量应该会更有保障。

         （3）我们最希望看到的效果是，这种方式下，产品的研发周期确实缩短了。

         （4）说点虚的。这种环境下，大家的团队感和目标感会更强烈，不像现在这么“散”。变化或决定都是全体参与来确定的，每个人都精确的知道我们在做一件什么事情。每天都有机会在一起沟通，有机会提出自己的问题，并且每个问题的都能迅速得到解决。不会再有问题被拖着，不被重视的感觉。

 

五、需要的支持

         （1）这不是一个人在战斗。这是一个团体的活，首先需要领导认同这件事，然后召集各个团队在一起。

         （2）对大家共同的挑战：在项目过程中，所有的人都要高度集中的来做这件事情，会有无数的讨论和会议，并且要求各方都要在结论确定后迅速调整自己的工作。每个人都要更负责、每个人都会更“忙”。

 

六、可能存在的风险

         （1）与传统模式相比，伪敏捷方法下我们要面对更多的变化。因为不再是全部都想好了再动手，而是走一步看一步了。预防的方法是不能太过于平铺整个项目过程，还是要先宏观再微观，先定大框架还是必须的。

         （2）上面说的很多是我从测试的角度来考虑的，从其它方面考虑的风险，欢迎大家补充。