vlambda博客
学习文章列表

前段时间参加了为期半个月的Scrum敏捷训练营，一不小心被邀请在训练营做学习分享，又一不小心获得了优秀学员证书，hhhh。

好了 不臭显摆了，下面分享一下如何把敏捷知识活灵活用到实际项目中。

不得不说，敏捷Scrum框架看上去一张图就可以解释清楚，实际上覆盖的知识点很庞大。

老实讲，目前我也无法将敏捷的方法论完全复刻到我现在的项目里，只是提取了敏捷思想中的其中一个重点“过程适应性”，并在实际项目中，进行适当裁剪。

抛开敏捷开发，单从“敏捷”两个字的字面意思来理解的话，我们都知道“敏捷 = 灵活”，好比形容一个人身手敏捷，身体灵巧，速度快。

在敏捷开发过程中，也有异曲同工之处 -- 灵活，敏捷的思想是拥抱变化，既然拥抱变化，那么就需要项目有很强的适应性。

敏捷开发生命周期中需求是动态的，不断变化的需求才能满足市场环境 为客户创造价值，由此敏捷过程的适应性就显得尤为重要。

下面就通过近期我负责的一个项目《工号规范制定》来拆解一下，是如何通过项目过程的实施来体现敏捷过程的适应性的。

在规范制定之前，我打算先分析一下当前业务数据，但是我发现甲方没有一个人对业务熟悉，也没有人能给出准确的答案。。。

这个时候，我只能从后台的数据入手，挖掘数据之间的关系。

思路是有了，但是如果想要数据，表头怎么设计呢？按照以前的做法是，自己冥思苦想，把能想到的字段都列到Excel里。

最后导出数据分析完成后，甲方说不是他们想要的，甚至付出的工作量甲方也不认可。

下图是我在和甲方沟通，确定模板字段的沟通过程截图。

前期确认数据导出的模板字段时，范围不要大而全 要小而精，并且数据范围可以“先简后繁”，这样的好处：

敏捷方法中，非常注重面对面沟通，面对面沟通是提高沟通效率的最直接的方法。

在前面的第一步骤“先简后繁”的数据模板定完后，后面遇到疑问，要随时和甲方咨询。

如果甲方有空的话，直接去工位找甲方，面对面沟通。

上面提到，遇到问题后及时和甲方沟通，条件允许的话，直接和甲方面对面沟通。

一旦沟通完成后，我这边就及时修改了数据字段，并且修改完成后，发送给了甲方。

这个时候的数据不是最终版，还需要甲方持续确认，于是发完数据之后，我又找到了甲方，继续进行数据沟通，最终修改到v1.1的版本后才算版本迭代结束。

上面的v1.0和v1.1两个版本的输出，均在同一天，我采用了小步快跑的方式，每个小任务、事项完成都和甲方进行确认，不断的修改，最终达到用户想要的结果。

但是此时输出数据后，并不代表事情就做完了，因为数据之间的关系，别人很难从表里面看出各字段的对应关系。

这时候E-R图就显示出了巨大的作用，通过E-R图，将各字段（实体）进行可视化，而这才是我们和甲方进行关系确认的「开始」。

关于E-R图的绘制方案和技巧，在之前的文章内有详细讲解，可查阅下方往期推荐[1]

从上面的四个步骤，显而易见，繁杂的文档，很难适应短期的环境变化。

所以最好的解决方案就是：小步快跑，每个小阶段任务的达成都和甲方确认。

小步快跑的同时我们要保持着思路方法的连续性，不能随着任务的切片化而让思路中断。