《精益产品开发》老翟读后感

image.png
image.png

传统软件开发方法

传统软件开发方法的共同特点是强调计划、管控和结构化的工程方法,并遵循严格的生命周期概念,把软件开发分割为顺序阶段构成的过程,瀑布式开发方法是其中的代表之一。
到了上世纪90年代初,CMMI和PMI项目管理知识体系成为传统产品开发管理方法的典型代表。

我个人认为,传统软件开发方法的假设是:需求确定后就不会变了。然而,时代变了,这个假设是否还站得住脚?

从另一个角度看,我们也就理解了为什么项目经理会对需求变更如此痛恨。你想嘛,项目经理的职责是让项目按时完成(想想KPI怎么定的?),立项后,工期就定死了,我一开始把项目计划做好了,需要变更了,你让我的项目如何按时完成?

所以,具有这样思维模式的项目经理面对敏捷和精益这样的概念时,第一念头就是:它们能帮助让项目按时完成吗?

当然,我并不是说项目按时完成不重要。而是想表达:我们应该清楚自己最终追求的是项目按时完成,还是做好的产品服务用户。

那么,如果“需求确定后就不会变了”这个假设不成立,我们的产品开发应该如何应对呢?

《精益产品开发》 从原则,方法,实施三个方面来说明我们应该如何应对。

产品开发与生产制造的不同

产品开发相对生产有两个最本质的不同:其一,价值的不确定性,它决定我们无法一开始就明确定义价值,或者说“价值定义”的过程应该是一个持续探索的过程,因此才有了精益创业、精益数据分析等实践体系;其二,过程的不确定性,如每个任务的处理时长不等,且可能在过程中发生变化,它决定了价值流动的管理和改进方法不同,如产品开发中看板方法就与生产中的十分不同。

在软件行业,产品开发与生产的本质不同,深有体会啊。生产常常有批量的含义,而产品开发没有,你听说过“批量生产软件”的说法吗?

部署与发布的区别

为更好地管理发布,团队应该区分发布和部署。部署属于技术范畴的概念,发布是属于市场范畴的概念。它们具有如下意义:

  • 部署(deployment):将软件安装到一个特定的环境
  • 发布(release):让一个或一组特性对应用可见和可用。

上家公司时,我们每周会部署两次,没做完的新功能,我们同时会部署上去,只不过,用户是看不到这些功能的,应该feature toggle是off的,偶尔也会向部分用户打开。

等我们确定功能完全OK了,就会把相应的feature toggle完全打开,所有用户就可以看这个新功能了。

这是区分了部署和发布两个概念的做法。

而现在所在家公司由于历史原因,服务器要跟着APP的版本走。APP端的人每个月发布一次,以至于管理人员也认为服务器端也必须一个月发布一次。导致的问题之一就是服务器端一次性部署大量的服务,不论这些服务是否有变更接口外在行为。

这是没有区分部署和发布两个概念的做法。

看板系统的设计、站会的设计

  1. 看板系统能全面地反映需求交付过程吗?
  2. 瓶颈和问题能在看板墙上得到即时体现吗?
  3. 团队可以根据看板墙上的信息协作和做决定吗?

只要问这三个问题,你就知道你的看板系统设计如何。

何勉老师在书提到了一个案例:一家企业网盘的需求被两端——前端和后端——分别实现。团队也按前端和后端来区分。每个团队还有各自的测试人员。

面对这样的情况,我们如何处理,才能更好的交付产品价值呢?我目前所在公司也遇到同样的问题,一个产品的开发甚至涉及到服务器端、APP端、Web端、硬件端。

一个需求同时涉及这么多的端。看板系统如何设计?如何站会?如何测试?好问题。

从这本书里,我得到的答案是:

  • 只要这个需求的涉及人员的任务卡片都应该放在同一个看板上,有时甚至包括市场人员。
  • 站会时,只要这个需求的涉及人员都应该在一起站,有时甚至包括市场人员。

小结

这些只是一部分,书中的很多想法击中了我。因为现实,我就遇到这样那样的问题,苦于不知如何解决。

另,回过头来看,不管传统软件开发方法,精益,还是敏捷,我们都应该始终记得不论开发、测试、项目管理人员,公司决策层,我们的最终目标:为用户提供更好的服务。按时完成任务只是我们达到这个目标的手段。

但是如何才能达到这个共识呢?留给读者一个问题。

你可能感兴趣的:(《精益产品开发》老翟读后感)