【项目管理】二、貌似是“银弹”的敏捷开发,为什么“只闻其名不见其人”?

2019/11/17 posted in  胡写 comments

从第一堂软件工程课,如同比较C/S架构和B/S架构一样,老师也一定要比较一下瀑布开发和敏捷开发。
随着移动互联网统治世界,C/S、B/S之争已经销声匿迹,然而,每当研发团队组建、亦或是开发过程遇到流程困境,敏捷就会每每提及,敏捷开发已经成为大多软件开发从业者心中的“银弹”。
但是,又好像没有几个人能真的说出自己经历过敏捷开发。

1、什么是敏捷开发?

敏捷宣言

先看一下敏捷宣言(http://agilemanifesto.org/principles.html),如同希波拉低誓言一样,敏捷开发也有自己的准则:

  • 个体和互动 高于 流程和工具
  • 工作的软件 高于 详尽的文档
  • 客户合作 高于 合同谈判
  • 响应变化 高于 遵循计划
    这些原则对于在字节跳动的优秀的工程师来说几乎是常识,其实就是一种以赋能和信任个人为中心的文化。

产生原因

敏捷开发基于一个这样的假设:
客户不能够在需求阶段就给出完整、准确的需求,很多需求都是在开发中“涌现”出来,无法在项目初期就明确定义它。

服务场景

敏捷开发的最初产生其实就是用于所谓“定制软件开发”(Custom Software Development)搞出来的概念,说白话,就是处理软件外包工作。在这种情况下,客户其实是组织的外部人员,因为他们会为开发来付费,所以他们占完全的主导地位,可以在任何情况下改变主意。

一般实践

落地到实践,敏捷的流程几乎和Scrum流程紧密结合在一起,特征是在于通过不断的story完成项目的滚动推进。改变传统的以流程为核心变为以人为核心。

  • 迭代式开发。
  • 增量交付。
  • 开发团队和客户反馈推动产品开发。
  • 持续集成。
  • 开发团队自我管理。

2、为什么我们好像没见过敏捷开发?

正如上面描述的“敏捷宣言”,敏捷的思想,或者说“精神”其实在实际的开发中是无处不在的,但如果落地到应用层面,就显得尤其的水土不服。

从起源来讲:

敏捷开发产生是源于企业软件交付的诸多难题,比如变更、缓慢、高成本等。这类交付大多以项目形式组织、以产品为结果。

项目有两个核心特征“为客户服务”、“一次性”:

  1. 项目的发起是从客户需求出发的,这隐含了客户必定是存在的,而且是明确的,通常客户是一个人或一个公司的需求提出人。通常是一对一服务的。他们的需求一般也是明确的,至少方向是明确的。
    问题:
    这并适用于我们互联网公司的产品研发。
    我们的产品通常是自主研发的,它是有企业对市场的分析,洞察出一个普遍性需求,进而研发出产品,然后寻找购买者进行销售。通常是一对多服务的。因为面对大量用户,他们会存在各种各样的个性化需求,因此便不能想做项目一样有明确的需求,这就需要主创者对产品方向进行判断和把控。
    所以敏捷开发中“客户合作”、“客户现场”等都是对客户重要性的确认,一旦客户不存在,例如自主产品研发早期还没有用户的时候,需求的挖掘、产品的验收就都成了问题。

  2. 项目一般是为一个确定目标所完成的一次性活动,所以项目是以客户验收为结束标志的。
    问题:
    互联网产品因存在大量用户,是持续交付的,再加上产品的更新换代,还要对老用户升级。
    敏捷开发中强调“客户验收”的重要性,要求与客户频繁验收,从而尽早发现问题,尽早调整,减少返工浪费,同时收敛项目范围。但互联网产品的功能是越做越多的,不断发散,同时还无法快速与用户验收,甚至无法验收,因为用户太多,不知道以谁为准,或者用户拒绝对未成形产品验收。这都让敏捷开发更多的局限在项目交付范畴之内。

从过程来看:

Google工程师David Jeske的回答:从敏捷开发的理念和精神上看,和我们的看法是比较接近的,它鼓励激发个体能力,强调合作与沟通,强调始终拥抱变化,但如果把其落地到具体的开发工作却并不能带来奇效。

敏捷开发过程其实更适用于特定类型的开发,最显著的是面向咨询或合同的软件编程(也就是软件外包),在这种情况下,客户是组织的外部人员,因为他们为开发付费,所以客户占主导地位操纵局势,可以在任何时候改变主意。但是,短期的规划、直接与客户接触和持续迭代的风格,非常适合具有简单核心和大量客户可见特性的软件,这些软件的可用性可以增量的方式上升。

如果在互联网产品中严格执行敏捷的Sprint的周期工作,每个Sprint并不一定都可以有可demo的进度,产品设计者也不会根据sprint的反馈澄清不清晰的需求,每个team的燃尽图都可以做的很漂亮,但release却还是会又delay。

所以:

  • 一方面,我们需要在产品最开始就把握好最终的形态,而不是傻呵呵的看每个demo结果再想新需求(eg:如果做图集发布器,产品在你们把上拉动画完成后,体验下说后面我们这样“巴拉巴拉”,你会不会骂人)
  • 另一方面,也不能要求各自为政的Scrum team可以自我完整运行好,需要有更高层的机制来协调各自的进度关系,而且,一个又一个的sprint并不能做好产品,产品必须现有一个长远的计划。

总结和启示:

在互联网公司,产研团队是一个紧密的整体,一个需求开发时间短则3、5天,长则1、2个月,需求内聚而不可分,只有在开发周期的尾声,整个项目相对完整时才具有可用性。或者可以认为,每个需求只是一个敏捷过程,我们始终无法看到全貌,我们可以用敏捷原则来指导我们思考,却没法依赖敏捷流程来做项目。
由此,我们引出了第三部分,我们的项目管理经验:团队的敏捷管理(Scrum Master)和项目的Owner负责制。