敏捷开发:用户故事_敏捷发展：过去，现在，未来

最新推荐文章于 2024-02-05 09:53:30 发布

dfsgwe1231

最新推荐文章于 2024-02-05 09:53:30 发布

阅读量220

点赞数

文章标签：大数据编程语言 python 人工智能 java

原文链接：https://hackernoon.com/agile-development-past-present-future-7851d0d77ebc

版权

敏捷开发:用户故事

阿里巴巴工程师在该领域拥有十多年经验的观察结果

阿里巴巴物联网业务部高级工程师陶震：

大约十年前，我的产品开发团队开始实施敏捷开发模型。 也许我们成为了中国第一支敏捷团队。 这样，我的行业经验可能会启发人，尤其是考虑到当今敏捷开发的状态。

失控

在当前有关敏捷开发的讨论中，您可能会遇到以下两种极端观点之一：“这是出色的”或“这是可怕的”。这代表了软件公司在推广ISO 9000和后来的功能成熟度模型（CMM）以来的发展。

对于大多数公司而言，ISO 9000的引入意味着需要收集各种文档并将其保存在文件柜中。结果，工程师对他们的内容一无所知。此外，ISO 9000是在机器生产时代创建的，不再适合有效地衡量当今新兴和发展中的软件公司。

CMM是一种用于衡量软件功能成熟度的模型，曾一度被广泛使用，但程序员对此并不感兴趣。他们认为，没有任何改变。锁在文件柜中的那堆文件只是变成了与软件行业有关的一堆文件。

ISO 9000和CMM无效的核心在于控制。

为了获得对未来产品的安全感，管理人员经常尝试在软件开发过程中控制行为并限制信息，并采用各种规则和流程来实现这一目标。

但是软件世界已经改变，Linux很好地体现了这一点。

人们长期以来一直认为操作系统是最复杂的软件系统。毫无疑问，要建立这样一个复杂的系统，就需要使用严格的流程管理系统，在像IBM或Microsoft这样的领先全球公司中，大量程序员的工作。但是Linux的工作方式有所不同，吸引了世界各地的成千上万的程序员。没有繁琐的过程，严格的规章制度或严格的项目经理。在几乎没有所有传统管理手段的情况下，创建了软件行业中划时代的产品。这是前所未有的壮举。

如今，网络技术可以更快地链接个人创建的信息，然后将其作为新产品呈现。组织模型越符合这种趋势，组织就可以更有效地将内部和外部信息的价值结合起来，形成自己的信息和产品价值。

这就引出了一个问题，即产品开发团队应使用哪种模型来更有效地完成此信息链接。

对于传统的和敏捷的开发模型，最终目标是相同的：开发好的产品和服务。但是，方法有所不同，传统模型控制尽可能多，而敏捷模型控制尽可能少。这种对比在包括教育在内的其他领域也可以看到。应该允许孩子选择走哪条路，还是我们作为父母或教育者为他们做出选择？灵活，更敏捷的方法还是传统模式更合适？当然，这两个问题的答案都是有见地的。

展平

早在1960年代，美国军方就建立了世界领先的C4I系统（代表指挥，控制，通信，计算机和情报），通过计算机和网络通信技术帮助指挥和控制武器和士兵。该系统及其组织模型引入了高效灵活的信息流，使总统可以在1-3分钟内指挥作战部队，并使士兵能够轻松获得军事情报。结果，尽管现役部队较少，但美国仍能够Swift有效地应对世界范围内的各种威胁和挑战。

部分由于C4I，政府能够使用信息技术来使军事体系更加扁平化，从而最大程度地发挥各个级别的团队成员的潜力。自然，下一步就是延迟技术创新和产品开发。

在2007年初，我遇到了Scrum软件开发过程的发明者Jeff Sutherland。

Jeff最初是一名士兵，曾在越南服役，在军队工作了11年后，他参与了IT系统开发。但是战争需要机智，组织和胆识，您可以在他的Scrum方法论中看到他的兵役的影响。通过鼓励产品开发的扁平化组织来最大化工程师的潜力是Scrum的本质。

苹果公司是敏捷，扁平的组织模型的另一个例子。虽然乔布斯（Steve Jobs）以控制事物的热爱着称，但他让员工在工作中享有很大的独立性，并且公司结构中没有微观管理。乔布斯施加的控制权远比控制开发人员更能拒绝平庸。

尽管互联网软件产品开发的风险很多，但它们都植根于同一件事：不确定性。但是，更多的控制并不一定会使不确定性变成确定性。确实，不确定性可以带来更大的创造力。这就是为什么Donald Knuth和Eric S. Raymond将编程描述为一种艺术形式的原因。

价值差异

当然，扁平化组织并不是敏捷开发的专利，您仍然会遇到障碍。中西文化之间的价值差异仍然存在。

我记得有一次我领导的一个团队中的一位中国工程师私下找我并要求获得更正式的职位。他没有像西方许多人那样要求加薪-他只是想要一个新的职位。他担心，经过这么多年的工作，缺少“正式”头衔会使他的父母感到尴尬。那时，中西方之间的对比不可能如此鲜明。

差异也有历史渊源。例如，欧洲和北美有着深厚的工程和Craft.io文化。从英国的工业革命及其对经济的影响，到美国的开国元勋和举世闻名的发明家本杰明·富兰克林，直到今天-每个镇上至少都有一个家装或五金店每个家庭都拥有一个工具箱-这种文化根深蒂固。

在中国情况并非如此，中国工程师对此概念并不熟悉。西方工程师从很小的时候就被教导如何重建和改进，他们可能比中国工程师更适应敏捷发展。

信息流

我曾经参与一个敏捷开发项目，在该项目中，超过200名参与其中的软件工程师均被告知产品设计的任何更新，以使他们了解并关注其开发。有一次，发布了一种架构设计，其中一名初级工程师发现了一个缺陷。没有一个技术专家可以预见到这一点，因此他们无法提出快速有效的解决方案。最后，是同一位初级工程师通过她自己的研究提供解决方案。

由此可见，扁平化组织创建了一支更负责任，信息更灵通的员工队伍，上层组织倾听并理解了下层组织在说什么，反之亦然。有才华的工程师更有机会为产品增值，并且更有可能通过直接参与而受到启发。跨层次的通信对于敏捷开发至关重要。信息流必须畅通无阻。

拥抱变化就是拥抱不确定性。许多雇主可能没有接受过无法编码的年轻大学毕业生，但后来他们放弃了乔布斯（Steve Jobs），他是当时最伟大的发明家。一直为寻找工作而奋斗的马云（著名的肯德基被拒之门外）后来成立了世界上最大的电子商务公司。简而言之，一个实施敏捷开发的扁平组织可以为那些被认为不太可能在传统等级体系中取得成功的人提供繁荣的机会。信息壁垒只不过限制了您自己的能力和竞争力。

未来是什么样子的

计算中有一个简单但有效的算法，称为冒泡排序，该算法会通过一个未排序的列表比较各个项目，如果顺序错误则将它们交换出去。之所以这样称呼，是因为不合时宜的项目实际上冒泡到顶部，这与扁平的组织结构中每个团队成员的创新和价值很容易浮出水面一样。

在当今不确定的IT世界中，无论您是否采用敏捷模型，信息的流畅传递都是工程师团队成功的关键。管理作为价值的链接器和传递者，为这种信息和创造力流程提供服务。

敏捷开发是基于对某种工作场所的愿景而形成的。它是否有效取决于员工是否认同该愿景并接受其旨在支持的文化。在阿里巴巴，倡导开放和平等的公司文化，并最大限度地降低等级和优势。每个人都不要用正式语气互相称呼，而是用英文名或昵称互相称呼。但是，敏捷开发（或其他方法）的成功最终取决于员工是否参与并拥护所在组织的精神。

（陶振陶震原创）