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