你的位置: 首页 开发,项目

多一点设计,少一点烦恼

2015-04-17 15:32:50

这是团队发生的一起事故。

需求是这样的,在用户个人中心,有一个将本地的视频上传到第三方存储库的需求,需求不复杂,但是出了很多岔子。 前后经过大概三个多冲刺,时间跨度一个月,仍然有很多问题,没有发布。

验证阶段: 开发人员是进行了前期验证的,将市面上的上传控件测试了一次,并有相关的demo,然而这个demo在后来 并没有起到加快任务进度的作用,实际上,实验的demo,后端接口并不是需求相关的第三方api,开发人员并没有对 api作验证

构建阶段: 没有相关设计,直接开始编码,开发人员对整个需求,所需要做的东西不了解,没有技术方案,只凭感觉 开始了切图,编码,随后陷入了地狱,demo不能直接拿过来用,因为上传的地方并不是业务服务器,而是第三方存储。 而第三方存储也没有api,几经沟通,给出直接用iframe嵌套页面的方案,这个方案验证也不行,因为有各种跨域, 交互等问题,在多次调试,耗费时间快2周的时候,终于调出一个勉强能用的方案。不过地狱还是没有结束,仍然有 一些需求没有确认,没有解决。

需求是会变的,这是铁律,产品人员的设计会根据市场的反馈发生改变,就算市场不变,整个团队成员对产品的理解会 在不断的沉浸中加深理解,更加的适应需求,就像开发人员写一些功能的时候,经常会有重构重写的情况发生,这是 好事,能提高代码的复用性,性能等,所以需求的变更是必然,有时候也是必要的。但不断变化的需求对开发人员来说, 是一个极度讨厌的恶魔,它延误了进度,增加了成本,消磨了耐心,降低了成就。这就需要一个平衡,尽量少的需求 变更来迭代更适应需求的产品。

敏捷是一个好方法,给了开发人员一个固定的冲刺时间,无打扰,无变更,所有的需求变更都在冲刺开始前确定, 在冲刺结束之前,无反悔机会。除非结束冲刺,重新制定冲刺计划。但这条护城河不是咒语,喊一声敏捷就抑制了 变更,这对开发提出了更高的要求:主动提前确认需求,提前做好架构,验证。否则,当发现技术方案有问题, 无法实现,实现成本过大等需要变更的时候,主动打破计划的就不是产品,而是研发人员。这同样对项目是危险。

在这个失控中学到什么:

  1. 对开发人员来说,在冲刺开始之前,需要明确这次冲刺的目标是什么,我如何实现这些目标,以及验证相应 技术方案,在方案仍然有疑问之前,绝不启动冲刺计划。在前期挣扎比在后期推倒对项目的影响要小得多。

  2. 对冲刺大师来说,大师是冲刺的守护,需要保证冲刺能正常顺利进行,尽量减少冲刺的风险,所以需要和开发 人员沟通,确认所有需求,技术方案细节,然后才能放行,开始冲刺。

  3. 对团队来说,需求变更的最小代价是需求刚开始的时候,越往后成本越大,所以尽量保持目标的简短很重要, 将大的需求,分解成小的冲刺目标,就算在冲刺周期内,也要保持持续交付,持续测试,继续验证的节奏。 如有条件,可以做到每日发布,每日验证。

  4. 沟通在冲刺过程中是非常非常重要的,在冲刺遇到障碍时,大师要及时发现问题,协助成员解决,当发现项目 失控,要想办法将冲刺拉到轨道上来,如有必要,重新评估任务,确认方案细节再重新开始冲刺。


©翟四岚 1989-2089