【IT168 分析评论】

    Scrum实施过程中遇到的典型问题，答案综合了网络中的借鉴和自己实践中的体会。

    Q1：技术负债在敏捷团队中会快速的膨胀。

    A1：由于敏捷开发过程没有充足的事前（up-front）设计，技术负债是不可避免的，虽然可以通过TDD、连续集成、重构减轻症状。同时敏捷开发者提倡的原则(比如S.O.L.I.D原则，Clean Code,Implementation Patterns )都能帮助敏捷团队避免过多的技术负债。传统的瀑布式开发技术负债是较少的，敏捷开发不是瀑布式开发的对立面，必须在实践中结合两者的优势。根据国外专业网站的调查，在敏捷实践中超过60％的团队都会进行一些事前设计以减少技术负债。Agile Modeling个人觉得是可以借鉴的办法之一。

    Q2：敏捷软件开发团队会想当然地认为每个团队成员都专业，称职并富有责任心。如果事实不是如此，项目开发很快会变得举步维艰。

    A2：敏捷开发团队的气氛应该是：勇于承诺；团队成员互信互助，不断追求进步，需要的时候寻求团队成员的帮助。责任心不是每个人都会有，这和性格、素质和既得利益有关。在实践中团队成员不可能都专业，称职并富有责任心，所以实践中的做法是：首先努力找到专业有责任心的人，其次是创造团队气氛，再次是建立绩效考核（见6-25文章：如何对Scrum团队进行绩效考核），能力较弱的的团队成员会感受到来自其他成员的压力，要不然尽力做好，要不然只有走人。

    Q3: 由于对敏捷开发实践的错误理解，导致团队不合理地频繁交付，疲于奔命。

    A3：我们导入敏捷也是受种种因素（客户环境，团队对敏捷的认识程度，成员的能力）限制的，只能是逐步导入。很多敏捷项目确实存在过于频繁的交付，那是由于人们迫于各种压力，“好大喜功”的天性而忽略了敏捷其实一直在强调的“根据每个迭代能够实际发布量”（也就是真正能够达到Done标准的工作量）来调整下一个迭代工作量。如果团队不能自主调整工作量，这其实已经偏离了敏捷。公司和团队对敏捷开发的正确理解是解决这个问题的根本。

    Q4: 实施敏捷的门槛太高，敏捷开发需要更强的团队和个人的纪律性，勇于承诺和高度的公开性，但对一个不成熟的组织来说这个门槛太高。

    A4：在不成熟的组织中导入敏捷实践只能是逐步地导入，同时应该是在敏捷宣言的原则下找到适应组织目前状态下的做法。具体的做法，我的实践体会已经在博客中有共享，例如（5-8：没有自动化测试，没有TDD，没有连续集成，如何保证质量？，5-19：没有自动化测试，没有TDD，没有连续集成，如何保证质量？续）等。

    Q5: 绩效差的团队成员很难在高度公开的敏捷团队中掩饰自己能力的不足。好的团队往往能够采取一定的措施来帮助这类成员。但如果没有采取措施，这些成员往往会想方设法通过消极怠工来掩饰自己能力的不足。

    A5：态度决定一切！敏捷团队所不能容忍的是那种故意偷懒的成员。团队成员应该承认个体差异，努力帮助较弱的团队成员，但较弱的成员必须表现出：a)主动 b)努力 c)对结果负责。这三点同样重要，“主动”包括主动需求帮助，如果有delay主动沟通等。如果不是这样，只能走人。

    Q6: 敏捷团队容易过份关注眼前的短期目标，而忽视长期的战略目标。尽管在短期内能够取得成功，长期注定还是会失败。

    A6：过分强调了YAGNI（You Aren't Gonna Need It），因而在早期忽视了一些战略性的目标，尤其是业务需求目标，从而导致后期重构十分困难。这其实在很大程度上是一个平衡的问题，怎样在YAGNI与预先设计之间做平衡。预想开发是个迷人的陷阱，在编码时时刻提醒自己：它究竟是会让代码变得更好，还是平添复杂度？同时，需求设计时也必须要考虑某个功能虽然在目前是不需要的，但可能在可以预计的时间商业价值很高。最好的方法是在产品开始之初做好Roadmap，而不是想一步做一步。设计也要根据Roadmap做一些预先设计。

    Q7: Product Owner承担了太多的责任，不堪重负，从而成为团队的瓶颈。

    A7：敏捷极大地缩短了从需求到软件的周期。再也不会出现Product Owner等上6个月或者更长的时间，结果发现做出来的并不是自己想要的东西的情况。Product Owner可以在短时间内就能看到软件，及时作出调整，因此敏捷极大地减少了开发成本以及相应的机会成本。公司高层的支持也是十分必要的。没有高层的承诺和授权，不可能组成全功能的团队。的确，和传统开发相比，PO需要更大的热情和精力，同时也需要更好的沟通能力。在实践中，往往PO是由两个人Peer组成的。

    Q8: 敏捷的效用被过度夸大，大家的期望值太高，很多人认为导入敏捷能以最小的投入解决实际开发中的所有问题。

    A8：实际上，敏捷开发不是以最小的投入解决开发问题，也不是使开发效率大幅提高，而是快速地得到可以工作的产品（功能较少，但核心），快速的得到反馈以改进产品，始终以市场/客户的要求为每一次推出产品的原始驱动力，这样产品的ROI（Return of Invest）才是最高。客观的说，和传统开发方法比较，Invest不见得是最小的，但Return却是较高的。

    Q9: 可能出现另一种形式的“相互诟病”。成功的敏捷开发团队一般不会成为产品开发的瓶颈，因此其他部门不能以这个为借口来指责开发团队，但是这有可能进一步演变成为政治游戏。

    A9：尽早与其他部门沟通，大家的最终目标是一致的，各个部门应当一起寻找生产系统的瓶颈，然后努力突破瓶颈。基于这个共同目标，各个部门一起对流程进行修改，就会减少相互诟病。要想最终的目标是一致的，公司的绩效考核中的KPI就应该以此为中心。

    Q10: 当Product Owner开始决定开发的方向，他就会被过度授权。敏捷开发中缺乏足够的审查和平衡机制。

    A10：Product Owner应该控制产品发展的方向。Product Owner应当熟悉业务，明确他最终想要什么。尽管开发团队要利用技术手段，提供解决方案，满足业务需求。但作为开发团队不应该对业务方面干涉太多。需要说明的是，在实践中公司的管理层/老板其实是最大的Product Owner，所以被任命的PO在产品的决定方面必须和公司的管理层/老板有充分的沟通，这里的沟通技巧主要是和上层的沟通技巧。

    Q11: 敏捷理论很吸引人，但失败的案例非常多

    A11：敏捷理论很美好，但是实践起来还是会有各种各样的问题，也有可能失败。其实理论描述的是理想情况，实际情况往往不尽相同。这需要有更多实践经验的培训师进行培训或者直接加入到团队中。