产品迭代开发 迭代发布
迭代开发和增量改进
迭代开发是您迭代发布软件的过程-逐渐改进的小版本软件。 人们通常只考虑首先启用最有价值的功能,然后再考虑下一个最有价值的功能 。
如果您的产品是新产品,那就很好。 最终(或很快!)您将到达一个下一个最有价值的改进,即不添加新功能,而是使现有功能更有价值 。
一切都是升级
在之前有关组织迁移项目和迁移项目 需求的几篇文章中,我写了关于迁移如何有点用词不当的文章。 一切都是迁移。
我在前几篇文章中的观点是,您使用“新”解决方案解决的问题并不是新问题。 您的客户当前以不同的方式解决它们。 迁移项目的相关问题是您的用户正在改变他们解决问题的方式。
[作为一个小问题,如果不了解这种区别,可能会导致您基于错误的问题陈述进行项目 。]通过迭代开发为产品提供增量改进时,就是在升级软件。 您正在将用户从他们的旧解决方案迁移到他们的新解决方案。 当您将自己从旧版本迁移到新版本时,您正要替换自己。
对我个人而言,一个可行的策略是在别人之前不断创新, 打乱您的市场 。 使用这种方法,您将有意重新发明您的解决方案,从而使其他人难以创新。 这是一种策略性地制定路线图的好方法。
您的市场将会改变 。 很快 您是想对竞争对手做出React,还是在您站着脚踩球时让他们紧随其后?
“新” Twitter的回响仍未解决,许多Twitter竞争对手紧随其后-其中一些竞争对手直到现在才意识到Twitter一直是竞争对手,而不仅仅是“平台”。 新的Twitter并没有真正改变人们使用Twitter的方式,只是使其(明显)变得更好。
避免胎儿炎
与让用户使用您的软件完成更多工作相比,何时才更有价值的是改进您的软件已启用的功能? 凯西•塞拉(Kathy Sierra)向我们介绍了胎儿炎的概念,即太多 太多了 。
在一篇有关病毒性产品管理的文章中,我建议通过改善软件质量,可以利用一种利他主义的机制,人们可以通过这种机制来推广您的产品。 例如,我建议改善软件的可用性,以此来突破病毒临界点。
关键思想之一是使其对用户更好,使您的产品对公司也更好。
管理“改进”要求
现在我们都同意,有必要使软件更好(如果您不同意,请在下面的评论中注释),问题变成了“ 如何 ?!”。
用例可以用作需求架构的基石。 有时, 用户案例比用例要好 ,但用例却非常敏捷 。 当您开始一个项目时,您想采用一种由外而内的方法来定义该项目的范围,或者更具体地说,是要定义您要在路线图中解决的问题的范围 。 本文将以用例语言进行讨论,但是在使用用户案例时也适用相同的概念和方法。
在将用例确定为“下一个最有价值的功能”之后,可以将其添加到sprint的待办事项列表中。 然后,实施团队会提供有关用例“太大”的反馈,您必须将其分解。 重要的是, 不要以仅解决一半问题的方式拆分用例 。
您也不应该交付“不良”产品。 事实上,理想的方式引入新的功能是能够satisfice ,而不是介绍你的第一次迭代的“完美”的解决方案。 使您的第一个解决方案“足够好”。 现有技术的一部分定义为“足够好”,但请放心,这与“您可能做到的最好”并不相同。
从上面总结一些关键要素说明了您将要面对的最终现实:
- 用户所面临的每一个问题*已经得到解决,您只是在提供更好的解决方案。
- 向产品添加更多功能的收益递减,最终会产生负面影响。
- 首次发布给定功能只会“足够好”。 这留下了改进的空间。
* 是的,您可以将“问题”定义为“现有解决方案不够好” –但是您仍然会停留在同一个地方,那么为什么要打扰呢?
最终,改进已经发布的内容的价值将大于发布新内容的价值。
你是做什么? 您将 再次 实现相同的用例 。
如果您的产品是软件即服务(SaaS),则您绝对应该以这种方式考虑问题。 变得更好是SaaS产品经济学中所隐含的持续改进目标 。
回顾用例
不要与用例的重用相混淆, 重新审视用例是指重新审视( 旨在改进)产品中已经存在的实现。 这是一个移植项目的一种特殊情况-你从旧的解决方案,新的和改进的解决方案迁移用户。
您可能正在迁移到相同的过程,其性能可能比以前的版本要快。 或者您可以在不影响流程的情况下改进流程(提高可用性,交互设计,视觉设计等)。 通常,“使之变得更好”的用例改进工作只会对流程产生较小的影响。 您的用户仍在做同一件事,他们只是在享受它,或者更有效地做它。
在对用例进行切片以使其适合单个sprint时,您可以在第一个发行版中为单个用户角色设计它们 ,因为您要等到下一个发行版才能满足不同用户角色的期望。 在这种情况下,您的非功能性要求,约束或接受条件将有所不同。 您的用例在外观上相同时也可能有所不同(在细节上)。 也可以使用相同的方法解决这种常见情况。
找到那个旧的用例(从几个迭代之前开始),并将其放回积压中。 记住,敏捷是关于对话,而不是工件。 如果您需要在用例中添加解释,因为您的团队关注“已经在工作”这一事实,请添加一个限定词,以使其变得“更好”。 然后进行对话,并说明如何使其更好。
设计是实施的一部分吗?
一些团队进行组织,以使设计人员(在这里解决设计代码的架构师和设计接口的设计师)成为实施团队的一部分。 其他公司则将设计师视为利益相关者,为产品经理和产品所有者提供指导和意见。
当团队外部要求“新设计”时,应通过工件和/或澄清,将该设计指南作为对实施团队的投入的一部分。
当团队要求“新设计”时(设计师是团队的一部分),请向团队表达新的接受标准。 请注意,如果将它们视为良好需求 ,则这些需求必须是可衡量的 需求 。
摘要
有时候,您可以做的最有价值的事情就是改善用户体验,以使您的产品已经体现出一种功能。 到那时,再次使用相同的用例,并用新的约束,非功能性要求和接受标准进行更新。
翻译自: https://www.javacodegeeks.com/2012/09/use-cases-for-iterative-development.html
产品迭代开发 迭代发布