[敏捷开发实践] “敏捷之痛”谁的错？（更新中）

 “敏捷之痛”谁的错？

关于敏捷开发和Scrum过程模型，10年之前就已经被大多数软件开发团队采用了。现在可以说，哪个软件开发团队不懂得敏捷方法论，或不采用Scrum过程模型，好像就是“老古董”了。很多PM，Development Manager谈起敏捷，都会口若悬河，头头是道。可以实际情况是，大多数开发团队真的采用敏捷方法论时不能成功的按照既定目标交付产品。

所以，很多软件企业都有“敏捷之痛”。

上校分析了亲身经历过的敏捷项目和做过咨询的敏捷项目，几乎无一例外的都采用了Scrum过程模型开发。可是从实施效果看，大多数项目真的不尽人意，有的项目甚至不断延期，交付产品质量问题很多，产品上线后客户抱怨层出不穷。所以，上校经常和周围的PM，Scrum Master，开发团队的Manager讨论分析问题到底出现在哪里？

有的PM甚至对Scrum产生了很深的误解，认为Scrum只适用于小型的项目，还是固守Waterfall的模式，很难在Scrum和Waterfall之间做出选择。有的PM甚至认为Scrum根本就是“不靠谱”。很多Scrum Master也很迷茫，不知道如何改善开发质量问题和按期交付的问题。

Retrospective回顾会议上常见的“BAD ITEM”

欢迎对号入座，看看你的敏捷团队是否遇到过类似问题。

过程	存在的问题总结	问题现象
项目启动准备阶段 Sprint迭代开始之前	业务知识移交和理解	Product Owner和客户方人员在进行业务讲解和对产品希望达到的目的讲解时不够充分，Scrum团队对业务理解不深入。导致开发中，对User Story理解偏差。
	系统UI设计	缺乏UI规范 实际的Prototype UI设计和User Story描述不符（版本不一致） UI设计不能完全反映出核心的业务需求
Sprint迭代中	估算不足	User Story Point估算偏差超过50% User Story 延期开发完成 User Story Point 为 0.5 的超过30%
	进行中的Sprint 不能有效的控制变更	开发框架技术变更（致命的问题） Product Owner变更（致命的问题） 开发范围变更（变更率大于30%） UI设计变更（变更率大于50%） 功能不断变更（已经无法统计变更率了） 开发人员变更
	Showcase	Showcase活动流于形式，不能通过Showcase活动暴露“可工作的软件”的问题 Showcase活动Product Owner参与不足
	Scrum Team技术能力不足	框架、工具使用不熟练，解决技术ISSUE时间长，甚至不可控 Scrum Team清一色的程序员出身，团队结构不合理，缺少UI设计人员、测试人员 Scrum Team人员技术单一 代码规范性查 代码安全性查，不能通过安全工具检查 测试意识薄弱，测试技术和测试方法能力不足 不重视Unit Test 缺乏TDD的思想
	Scrum Master经验不足	缺乏敏捷项目管理经验 Scrum Master和Project Manager、Functional Manager职责不清 Scrum Master总是受到管理层或者 Project Manager、Functional Manager等角色的干扰（干扰过多），甚至Scrum Team的成员也收到干扰 不能有效的维护Scrum规则实施 与Product Owner和Scrum Team成员的沟通不足，信息不能及时共享
Sprint迭代结束时 （下一个Sprint迭代开始前）	Retrospective活动不能有效进行	Retro活动流于形式，不能暴露问题 Retro活动GOOD的总结项多于BAD的 Retro活动总结的改善事项不具体，可执行性不强 Retro活动缺少Product Owner参加 Retro活动的经验教训总结不能在下一个Sprint中有效改善

 

Scrum Master 职责不清，缺乏项目经验

• Scrum Master 缺乏敏捷项目管理和实施经验，尤其是敏捷项目成功实施的经验。
• Scrum已经对于开发技术生疏了，缺乏对于技术框架和开发技术应有的经验和判断能力。
• Scrum Master经常受到Project Manager的干扰；或者受到开发部门管理者（Functional Manager）的干扰；一天中40%以上的时间都在做着和Sprint迭代目标无关的事情，而是在整理各种数据用于写报告，给不同的管理者报告。看似每天很忙，但是对于Sprint迭代目标，交付软件价值没有太大的贡献。
• 有的项目Scrum Master是由Project Manager兼任的。同时管理者3-5个在开发中的项目。精力和时间明显不足。

Product Owner

• Product Owner不能有效的保证参与项目的时间
• Product Owner反馈慢
• Product Owner提出在进行中的Sprint中变更过多

Scrum Team结构不良，技术能力存在明显的短板

Scrum团队中有三种角色，分别是：Scrum Master、Product Owner、Scrum Team（开发团队），这个大家都知道。各自的分工和职责只要是参加过Scrum培训的人，都很清晰。（不知道的，网上一搜一大堆）可是在实际工作中，先不说Scrum Master和Product Owner，重点分析一下Scrum Team（开发团队），是什么情况呢？

• 组建Scrum Team时，技术差异化不明显。一个10人左右，甚至人数更少的团队，团队成员清一色的由程序员组成。缺少测试工程师、缺少UX设计工程师。这样的Scrum团队成员从功能上就存在缺陷。
• Scrum团队人员技术能力差距甚远。一个10人的团队，在敏捷开发看来是一个比较大的团队了。可以团队中有5年以上经验的开发者只有3人；另外的人员都是刚刚工作1-2年的程序员，开发能力、测试能力明显不足。
• 团队从过往的经验来看，业务理解能力很弱。团队成员之前的开发方式，基本上就是按照软件功能设计书按步就班的开发。对于设计书存在的问题，业务需求存在的问题，很难发现。说起来就是BA没有做好，分析的不够，对于业务流程不熟练；要么就是客户需求不清，缺少必要的沟通和讨论环节。

Scrum Team对Scrum过程理解相差甚远

• Sprint迭代过程中，缺乏有效的测试活动
• Scrum团队对于是否需要哪些文档认识不清，意识薄弱
• Sprint迭代过程中，需求不断变化，直至开发范围蔓延

（更新中……）