企业总是希望能够提升自身能力,从而在更短的时间内向其客户传递价值。现在,许多企业正在采用敏捷软件开发,以便能够迭代开发并交付软件解决方案。但要想判断业务需求,并决定应该开发什么产品,并不是一件容易的事情。精益创业方法正是瞄准了支撑开发新业务和产品的需求。对于如何将敏捷与精益创业方法结合能够带来何种帮助的话题,多位作者分享了各自的观点。
在博客文章针对精益创业开发者的敏捷开发简介中,Startup Tucson 描绘了敏捷和精益创业如何互补:
敏捷是一套原则,而我们的软件开发方法论正是基于这些原则;精益创业则是有关如何驱动我们的业务和产品开发的。二者可以很好地结合在一起。毫无疑问,我们不必采用敏捷(或类似方法)也能够运用精益理论,但同时使用二者,它们将如同巧克力与花生酱一样,能够非常融洽地搭配在一起。
这篇博客文章阐述了敏捷软件开发与传统瀑布模型之间的区别,并介绍了敏捷开发的指导原则、发布周期(冲刺)和用户故事。该文章还通过若干例子,描绘了敏捷和精益创业如何适应彼此:
- 在面对客户时,我们将尝试弄清他们的问题是什么(并且将针对这些问题准备解决方案)。
- 我们尝试解决的问题,将包含一系列有待测试的假设,而且我们应该为每条假设分配各自的优先级(从业务角度)。我们应该运用这些优先级来估算并承诺交付(如果测试这些假设需要进行开发工作的话)。
- 每个发布版本,都应该聚焦于当前正在测试的假设;同时,根据需要,使用最新的测试结果来重新安排优先级。
- 通过版本回顾来检查可交付成果,以确保它们符合用户故事所定义的内容。
Laurence McCahill 撰写了一篇题为我从精益创业中学到的 10 件事的博客文章,其中提到了从敏捷与精益创业的结合中,我们所能得到的若干好处:
产品发布之前的时间越长,与之关联的风险就越大。在暗室中花费六个月来开发,并不是创建创业的最佳方式。在大部分情况下,更好的方法是采用更敏捷或更精益的方式来进行发布,例如尽早、尽量频繁地发布。这有助于减轻风险,而且意味着我们关注的焦点在于学习和确认,而不是单纯地开发。
Laurence 介绍了他对精益和精益创业中的关键原则的看法。这些原则与敏捷宣言背后的那些原则是相关联的,例如它们都要求满足客户需求并及早交付工作软件:
(……)精益提倡创造价值的概念,这体现在针对用户需求的数字产品上。任何不满足用户需求的东西,都可以看作一种浪费。
另一个减少浪费的方法,是少写文档多做事。无论是研讨会、原型、方法还是其他什么工作,精益都要求研究模型以辅助理念的沟通。与其使用概念性描述或是在纸上空谈,不如向人们展示点真东西。例如草图、线框或引导性原型——任何测试我们对用户假设的最经济、最快捷的方式。
在适合你的敏捷工具箱的精益创业中,Sergey Shishkin 介绍了精益创业理念如何补充敏捷软件开发,以及如何帮助聚焦在客户需求上。首先他解释了如何将用户故事中的用户角色,与精益创业连结在一起:
“作为 [什么样的角色],我想要 [什么样的特性],从而 [会有什么样的价值]。”用户故事中最重要的部分并不是特性,而是用户角色以及想要实现的价值。
我们必须了解客户部门,以及他们必然会遇到的问题,以便为用户提供价值。如果我们的用户故事没有提到某个特定的客户群体以及某个问题(已经过我们定性地确认的问题),那么我们正在进行的构建工作,很有可能是在做无用功。
接下来,他解释了如何用管理产品待办事项列表的方式,来使用源自精益创业的理念:
一种科学的分配优先级的方法,是首先消除那些风险最高的条目,从而加速学习。在定性地确认了最大的假设之后,就该对这些假设进行定量验证了。因此构建一个实验,来对风险最高的假设进行定量验证,毫无疑问是此时最重要的事情。而如果构建该实验最简单的可能途径,正是把工作软件放到用户手中,那就太棒了。
他还描述了在使用精益创业的过程中,是如何定义“完成”的:
完成,是指当我们已经确认、验证或否定了某个假设。确认与验证之间的区别,在于我们定性地“确认”,而“确认”则是定量操作。在与人们对话时,捕捉其正面或负面的信号,这是定性确认。将 10% 的时事通讯接收者转变为付费用户,这是定量验证。
Sergey 表示,敏捷的成功,很大程度上取决于产品所有者对客户需求的管理,并以此作为总结:
我们可以假装只是在 IT 方面实践 Scrum 或其他敏捷方法,但局部优化将会不可避免地让我们自食其果。客户开发技术是一件强大的工具,能够在产品所有者的工作中——对待办事项列表进行整理并排定优先级——起到帮助。
评论