敏捷，想说爱你不容易（2）

看到论坛中这篇帖子， “Scrum之成败——从自身案例说起，仅供参考 ”。

有感于作者细致的剖析，于是提笔顺便整理了一下自己几年来的感触，今年确实有些懒惰。

 

前期我的一些总结：
2008年的体会：敏捷，想说爱你不容易－－从CMM向敏捷过渡的一点体会（1）
2010年的体会：后CMM时代的思考

下面是我的一些理解，没想到一下子写了这么多，看来憋了很久了，共大家探讨：
1、什么流程并不十分重要（我们这里就不讨论CMM和敏捷的是非了，好吧），关键是流程应用要契合项目现状，产品目标、团队能力。
  发挥一个流程的优势，进行一些必要的调整，关键还是树立正确的价值观和团队导向，让流程为产品和团队服务，而不是倒过来。
  不过很多时候是倒过来的，因为领导和质量工程师已经脱离了实际工作，更为信任流程、指标，而不是团队和实实在在的产出。盲目的“以数据说话”，对于软件工程而言其实就是在欺骗自己，我见过太多过程数据漂亮，但是产品问题较多的项目了。
2、敏捷之后，一个很大的挑战是所谓的“领导的控制力”。
  CMM中，有一个较为成熟和相对合理的指标体系，这是管理者的拐杖；敏捷之后，sorry，请领导来感受真实产品，数据离散在各个迭代中，该看什么数据？这些数据意味着什么？领导慌了。。。然后质量工程师也慌了，拉着项目利益相关人，赶快针对敏捷制定度量指标。
  结果，一堆并不科学的着指标满天飞，团队成员比以前更麻木的应付更多的指标数据。。。
3、人是最重要的因素，结合者项目管理者对于流程的驾驭能力，将会较好的完成项目。

•   一个团结的团队、积极的团队，效率将会很高，对此管理者的主要工作是通过自己的协调，降低流程对于项目的干扰。这种团队很难碰到，只有相对接近的完美团 队。多年来我就碰到一个有点接近的类似团队，这个团队的骨干都是我一手带出来的，设计能力一流、编码能力一流、沟通配合上已经有了较好的基础。新版本在诸 多困难情况下，依旧顺利的完成了部分前面迭代的开发……

•   如果一个团队尚未形成团队合作的习惯，不要贸然敏捷。在这种团队来看，敏捷崇尚的集体负责、代码集体所有制，是“吃大锅饭”，体现不出成员的“独特价 值”。文化的问题，还要从文化上解决。树立正确的团队导向，形成骨干间互助，骨干与新人间的新老协作的氛围，人尽其用，大家都一心将项目做好，不要过多计 较个人。这样团队会更为成功，成员反而得到了更多，尤其是贡献较多的骨干。

•   如果一个团队的成员能力中等或者偏下，不要完全抛弃现有流程全盘敏捷，这是对于团队的摧残：
  • 没有流程的保护，团队会被“随心而动”的需求严重冲击
  • 没有流程的指导，团队茫然迷失方向，不知道该做什么，直接面向对中目标--交付代码，迅速退化为“裸奔”（拿着需求直接开发，不做任何设计）
  • 没有流程的约束，设计能力迅速退化、测试能力很开就会瓦解，出现一个典型的窘境：
    • 设计简化了，模块级设计没有了，异常分支无人考虑了，开发交付的东西脆弱无比
    • 开发不再UT、IT、ST，直接给测试人员ST，所谓开发和测试融合；
    • 不高的开发质量导致测试太容易发现bug了，大量的问题单导致开发测试无法正常有效的运转
    • 每个迭代的包袱越滚越重，然后更为“简化”，以交付基本功能的代码为最高目标
    • 有个比较流行的词叫“带病迭代”，很贴切。但是有时我们尽量避免这种情况的措施有些问题，如“问题单解决率要达到XX%才能进入下一迭代”，这种做法类似“在别处丢了钥匙，反而在路灯下寻找，因为那里有灯，看得见”。
  • 敏捷的各种实践要求人员和团队具备很高的能力和一定的基础:
    • 简单设计、测试驱动、持续集成、自动测试、持续重构、迭代验收、循环。上述每个实践环环相扣，任何一个环节的断裂都会让迭代无法有效运转、轮回。
    • 简单设计。说着太容易了，但是有几个人搞得清楚“简单”到什么程度比较合适？
      • 这种简单要契合开发团队的能力，正所谓“看人下菜碟儿”，多一分浪费，少一分说不清。
      • 设计人员足够了解现有架构、实现和各种约束，以便提前识别风险？短时间内完成需求确认后就启动开发，苦了我们后面的开发人员。
    • 测试驱动。有多少团队做到了设计、开发、测试的融合？各个环节相互配合，相互促进确实很有受益匪浅，但是要打破固有限制
    • 持续集成需要理清各个系统间关系，前期投入较大，不是一个简单的版本可以承受的，“起步价”很高。
    • 自动测试，需要领导的战略眼光、团队的共同认可、成员的持续努力、每个版本的传承和坚持，否则前期投入很容易付之东流。就像在在海边堆积沙堡，在 没有形成一定规模时，一点懈怠就会被一个浪冲垮。自动测试的收益要从1到2个版本的长度来衡量，不能太急功近利仅看到1、2个月的收益。
    • 持续重构，是简单设计的必然结果。说实话，重构对于成员能力要求很高，并且强依赖于自动测试能力。没有完善的自动测试能力作为后盾，谁敢在项目中后期开展些许的重构？结果呢，代码腐化严重，1、2个版本后马上就走不下去了。正所谓“技术债务”太多。
    • 迭代验收。看起来很容易，但是需要魄力和执行力、应对力的。验收后，用户迸发了新的想法和要求，如何处理？如果用户要求合理，团队能否承受得住？ 能够搞定的前提都是，前面介绍的实践执行到位，没有太多技术债务，否则此时团队可能生存都成为问题，谁来“拥抱变化”？另外团队owner的规划能力、客 户协调能力很重要，要控制好客户期望，无人可以交付完美的软件。

写了很多了，自己眼睛都看花了，辛苦各位了耐着性子看完：），后面有机会再聊。