【恒生DBB】我所理解的敏捷开发

敏捷开发作为一种团队协作方法论，高效与清晰是两个特别明显的特点，保持敏捷开发的理念开始Sprint工作的团队，一定有正向的开发BUFF加成，我们需要面对的是如何将敏捷开发的流程执行到位，最大化的获取加成收益。我很认同敏捷开发对于精英团队的加成是最大化的，因为大家目标清晰，技术能力完善，执行力强，这是最理想的工作模型。

但是，对于现实中的非理想工作模型，我们可以从以下几个方面去加强这种团队加成效果：

• 产品BACKLOG的来源一定要尽可能的准确，最好是有明确的数据分析结果作为支持依据，Sprint BACKALOG的任务细化尽可能细致，保证在后续的Sprint迭代过程中，团队的工作目标清晰明确。因为没有人会希望自己的工作量最后转化为无用功，而不是KPI，这对于团队士气是一种相当沉重的打击。如果还是出现了这种情况，Sprint负责人也要积极转移大家的情绪，劝慰大家尽快投入下一个更加正确的Sprint周期中去。
• 团队成员之间要形成积极沟通的氛围，保证各职能团队之间的信息沟通准确对称。为了保证开发过程中灵活性，敏捷开发往往为了高效而不会过多的对成员做工作流程上的束缚，需求在迭代过程随时可发生变动，开发任务清单可由团队成员自主选择，任务面板由成员自主更新，是一种以沟通为主的工作模式。
• 对于中国特色社会主义建设的国内而言，非理想工作模型下，团队成员往往更愿意被动的选择工作分配。开发经理应该合理的根据团队成员的能力维度安排工作任务清单，尽可能避免团队成员因为能力失控导致进度延期、工作效率低、工作情绪泛滥等不利于团队建设的情况出现。
• 团队成员的组成结构在Sprint周期内尽量保证不变动，尤其是核心主导成员更不能做人事变动。在一个Sprint周期内，团队整体的开发关注力是需要高度集中的，如果这时团队的头部成员发生更换，一定会存在沟通成本损耗，影响整体迭代效率。
• Sprint开发过程，会议的频次与时长需要做适当的把控。笔者参加过蛮多工作会议，个人觉得有些会议的RIO并不成正比，耗时且没有正向的工作计划输出，这往往是蛮多人都吐槽且不喜欢参加会议的原因。每次最好由负责人主导会议，做好会议相关数据报表的输入输出，阶段性的展示成果，给予团队积极的正向会议反馈。
   

所以，这也是我为什么一直认为：敏捷开发的要求是很高的，特别是团队的整体素质的要求。