敏捷开发在团队落地的总结反思及改进建议

以前，当讲到我们团队采用敏捷开发进行APP迭代的时候，我会把“敏捷”二字打上引号。但是最近总结、反思、参加TAPD分享会、公司组织的敏捷培训以及系统的学习了敏捷的理论知识后，我觉得应该把这个引号给去掉。
本文将从 什么是敏捷、待优化的地方及建议 及 总结 三个方向阐述。

什么是敏捷，我们敏捷吗？

个人认为，敏捷的核心就是：“小步快走、迭代优化”。
“小”：指Stroy要小、落地开发的Task要小，要可独立提测。这个APP团队逐步做到了。
“快”：当落地开发的Task足够小，对于整体工作的评估会更加准确，团队对于需求的考虑会更充分，需求变更的可能性会更小，当开发的兄弟专注于开发的时候，快是水到渠成的结果。这个我们有一定进步，但是没有找到方法去衡量速度。
“迭代优化”：这个是核心中的核心，一直抱着优化的心态对待迭代制度、对待我们的产品、对待我们的代码。。。我们的迭代由两周优化调整成为三周；我们通过持续沟通，需求变更的频率有所减少；开发基本每个迭代都有优化重构的任务规划落地；晨会效果不是很理想，但一直在调整优化方案。。。经过17及18年的持续优化，我们迭代的可控性、可预期性是有很大进步的，开发对于18年迭代的满意度是比17年更高的（没有跟产品、设计聊过这个话题）。
综上，我认为我们是在落实敏捷开发的。
是，并不代表好，实际上我们有很多地方需要提升，且提升空间非常大。其主要原因在于，大家对于敏捷的理论并没有深入系统的学习，对于其背后的本质更没有了解。

待优化的地方及优化建议

团队互信、团队负责

• 问题
  当产品、设计不完善、或者产品、设计发生变更的时候，开发的兄弟往往会抱怨PM、设计师的输出质量差，PM、设计师也会质疑开发的开发效率、开发质量。
• 目标
  产品、设计有问题的时候，开发应该主动去帮忙完善，提建议，一起提高产品、设计的质量；PM、设计师觉得开发效率低、质量差的时候，需要的是帮忙一起分析，差在哪里，能做什么去帮助开发得到提升。出现问题的时候，没有产品、设计、开发、测试，只有我们。这是我们需要构建的核心文化。
• 如何做
  任何时候，我们不应该强调 产品、设计、开发、测试，而应该强调 我们，我们一起对这个Story、对这个产品负责。如果违背，可以请喝奶茶、或者罚划一周的船等等

产品目标及价值

• 问题
  很多兄弟对于产品的整体规划了解不多，PM团队也没有给出便于查阅的年度规划、季度规划，以及做这个产品、需求的价值到底在哪
• 目标
  有方便查询的年度规划、季度规划，对于PM、设计师、开发、测试，看到之后，知道自己开发产品价值所在，提升大家的价值感
• 如何做
  • 持续维护的产品目标及价值文档，重点说明产品、需求价值所在。
  • 对于实现了的产品，持续补充维护产品已经体现出来的价值

敏捷是适应变化的

• 问题
  很多人认为，敏捷是适应变化的，那我们在迭代中对于需求变更支持不够好，就是不够“敏捷”，这是对于敏捷的误解，对于变化一词的误解。
• 目标
  • 明确 “敏捷是适应变化的” 含义：在当前需求确定的情况下，我们快速迭代交付产品，根据用户反馈调整产品、优化产品。进入迭代后是不允许有、也不应该有需求变更的。
  • 三周一个迭代，刚进入迭代的需求，就提需求变更，说明该需求质量还达不到进入开发的阶段，该需求应该被打回，而不应该误解“变化”，要求迭代很好的支持这种“变化”。这种“变化”，会导致极大的资源浪费（会影响后端、Android、iOS、测试等），还会让大家的士气受到影响。我们应该一起努力，在进入迭代前优化、完善这类需求。
• 如何做
  • 加强敏捷理论学习，明确变化的含义。
  • 团队一起努力，提高各阶段交付物的质量（需求文档、设计稿、开发产品、测试质量）

需求评审会

• 问题
  我们现在需求评审会，过分强调这个需求是什么样子的，很少说明需求的价值，而说明需求价值的重要性不亚于说明需求是啥
• 目标
  需求评审会后，大家对于需求有比较清晰的认识，对于需求的价值非常了解
• 如何做
  需求评审会要明确两个目标：需求是什么 和 需求价值。这个会上不讨论需求该如何实现类问题。

晨会

• 问题
  APP团队开晨会，所有人加在一起，差不多15+，如果有产品、设计师参加，得超过20人，这明显是有问题的。而我这样安排的初衷是，APP业务间基本都有交叉，不希望团队开发资源上出现单点问题。升哥有建议过分 阳光物业 和 社区 两块，但是我觉得不合适。只是在晨会频率上做变化调整，很多问题也确实通过晨会沟通尽早发现、尽早解决了。但始终无法改变效率低下的问题。
• 目标
  晨会中，每个人需要说明的三个核心问题是：1. 昨天做了什么推进迭代 2. 今天准备做什么去推进迭代 3. 在推进迭代过程中遇到了什么问题。核心是参与晨会的人要对其他人的这三个问题听进去，如果有就给出自己的建议，帮助其他人更好的推进迭代。
• 如何做
  研究表明，一个人同一时间，最多记住七件事情（后来进一步研究表明是四件），为了达到晨会高效的目的，建议晨会人员在 7-2/7+2，即5-9个人。比如APP迭代，结合结对编程思路，后端2人、Android2人、iOS2人、测试1-2人 组建一个迭代落地小组，每个迭代周期，有两个开发迭代小组，推进二者形成良性竞争。

迭代速度

• 问题
  我们通过 小步快走中的小 提高了评估的准确性，对整个团队的速度有了一定提高，对于团队按期交付产品有了更好的把控。但是对于如何持续提高团队的迭代速度，持续提高团队迭代产出，是没有衡量标尺的。而Scrum中是采用点数去描述Story/Task的工作量，点数是工作量的一个标准度量单位。通过关注一个团队在一个迭代中能够完成的点数，反应团队的迭代速度。通过持续提高一个团队在一个迭代中完成的点数来提高团队的迭代速度
• 目标
  • 找到自己团队/小组的标尺：点数
  • 可度量的持续提高团队的迭代速度
• 如何做
  • 需求池中需求优先级是唯一确定需求开发先后顺序的标准（和老板达成一致，老板需求也要纳入这个需求池）
  • 采用统一标尺 点数（类似长度“米”）来评估需求的点数
  • 信任大家，按优先级主动领取需求，通过晨会跟进落实，经过三、四个迭代，大家就知道咱们团队的速度了
  • 有了度量速度的标尺，持续改进影响速度的点，提高迭代速度

透明

• 问题
  在整个团队层面，APP团队在透明度方面做的工作是最多的。每个迭代基本都会给全员发 需求评审会通知、需求启动通知、迭代周总结、迭代总结（一两个迭代发一次）。团队所有成员通过查看邮件，基本可以知道当前迭代的进展情况。
• 目标
  透明的目的在于大家时刻能知道自己团队当前的状况，增加自主意识。通过透明，不同小组间可以相互促进，持续提高。
• 如何做
  以PDCA或者Scrum的思路推进工作，并透明化所有相关事项，小组内部实现良性循环，小组间、团队内相互学习、实现良性竞争。所有事项包括但不局限于（所有事项都欢迎任何感兴趣的人查看、参加）：
  • 产品年度规划、季度规划
  • 产品预期价值、以上线产品已实现价值
  • 团队技术规划、所有技术分享
  • 团队各种会议

迭代总结会

• 问题
  迭代总结会的核心是总结好的经验继续保持，总结问题并落实解决，实现持续优化。APP迭代总结会我们做到了把所有问题拿到台面上讲，但是在落实解决上我们做的不好。
• 目标
  • 总结好的经验，作为团队文化进行传承
  • 总结问题，并讨论落实方案，在新迭代中落实到位，持续优化迭代
• 如何做
  • 高效发现问题：下个迭代团队做什么，可以让你效率更高。每个人必须回答。
  • 讨论确定最高优先级的问题，并讨论决定可执行的落实方案，以及落实计划、验收计划
  • 讨论问题，绝对禁止针对个人（老板除外），要针对流程、制度去讨论

关于团队成员技术成长

• 问题
  我们有很多“大佬”，但我们的大佬基本都是在某方面业务开发中做得出色或者大家认为其技术比较厉害而被称为大佬的。但是我们有哪些大佬在团队层面去持续帮助其他人提高技术的呢？在营造团队技术氛围上有贡献的呢？把一个人的技术提高一倍所需的时间 远超 把团队的能力提高一倍的时间
• 目标
  “大佬”们要把自己的一部分精力放在持续提高团队成员水平的事情上，营造越来越浓厚的互助氛围
• 如何做
  • 持续的、有广度的、有深度的 分享坚持下去
  • 打造持续追求更高、更好的氛围
  • 我们有基于产品的开发团队，如APP、Python业务、Python平台、友邻、装修、公共资源等; 也需要有基于职能的团队，如Android、iOS、H5、Java、Python等。基于产品维度和基于职能维度的团队交流同等重要。

制度上如何保障

公司大的制度环境，对于 Scrum 并不是完全合适的，那如何在制度上去保障我们团队落地？明确KPI考察方向、采用OKR。。。这个问题需要大家和HR一起思考，“We are a term”，我们一起去解决！

总结

敏捷开发，其实就是PDCA方法在软件开发领域的应用，以期实现高质量、可控、可预测的交付产品。其核心在于一个持续优化的闭环。让我们-主动-迭代优化。

参考

• PDCA: plan-do-check-adjust
• 《敏捷革命》 提取码: 3vff
• 《Scrum实践步骤》