这就是敏捷的美妙之处：非常灵活，速度非常快，它要求开发人员将每项任务分解为尽可能小的单元。重点是快速发布，不断回顾，并根据需要改变方向。 我对敏捷非常感兴趣。敏捷是从哪里来的？敏捷的目标又是什么？ ...
“敏捷欺骗了开发人员”
记得第一次接触敏捷是我在图书馆工作期间。我的工作是从无到有建立一个新的数字化奖学金中心，有时我需要与图书馆的软件开发团队合作，构建支持项目的工具。当时开发团队有六名成员，我发现他们的工作方式与非技术人员截然不同。开会时，他们讨论的不是产品功能，而是“用户故事”（描述功能的小段文字），而且他们还会分配“故事点”来衡量完成相关任务所需的工作量。每天早上，他们会举行“站立会议”，实际上就是站着开会，据说站着是为了加快会议的速度。他们的办公空间内，白板必不可少，开发人员会移动白板上的便利贴以表示工作的完成状态。他们按照“冲刺”划分工作周期，一般一个“冲刺”为期两周，他们需要在这两周内专心完成特定任务。 在与图书馆的工作人员开会时，开发团队的负责人会使用软件报告进度，其中包括表示每个项目状态的仪表板。经理还可以向我们展示团队的“速度”图表，即开发人员完成任务的速度，以及历史数据比较和预测。 后来，我了解到这就是敏捷，一种管理软件开发的方法，这种方法在各大技术公司非常受欢迎，而且在非技术办公场所也越来越流行。老实说，敏捷给我留下了深刻的印象。其实，在日常工作中，我经常感觉很迷糊，不确定自己的工作有没有进展，或者有没有做真正有价值的工作。相比之下，开发人员似乎非常清楚自己在做什么。即便他们遇到困难也没关系，只要解决困难就可以了。他们的需求会不断变化，而两周为单位的工作周期，可以让他们迅速在各个功能之间切换，甚至可以采用新框架，而无需从头开始。 这就是敏捷的美妙之处：非常灵活，速度非常快，它要求开发人员将每项任务分解为尽可能小的单元。重点是快速发布，不断回顾，并根据需要改变方向。 我对敏捷非常感兴趣。敏捷是从哪里来的？敏捷的目标又是什么？ 于是，我开始探索敏捷的历史。我发现长期以来，经理想要的软件开发过程与开发人员实际编写软件的过程之间一直存在矛盾。各大组织一次又一次地引入新的管理风格，就是希望控制软件开发面临的最大问题：超出时间与预算限制。后来，各个公司发现敏捷解决方案不仅可以让开发人员愉快地完成任务，而且还能保证开发速度。不过，最近一些迹象表明敏捷的力量正在衰退。人们正在酝酿新的方式，而且很有希望取代敏捷。 软件工程师 软件开发的危机在“软件”这个词发明之前就存在了。1954年，行业、政府和学术界的领袖们在美国底特律韦恩州立大学召开了一次会议，与会的专家表示，我们缺乏接受过一定培训的程序员。直到四年后，“软件”这个词才首次出现在统计学家 John W. Tukey 的一篇文章中，用于表示应用程序编程。到了20世纪60年代中期，美国有至少 10 万人从事程序员的工作，但据估计至少还有5万的缺口。 在编程行业刚刚起步的几十年里，大多数专家认为，编写计算机可读的代码并不是很难。毕竟系统分析师（高级架构专家）已经完成了设计程序和硬件的艰苦工作。而程序员的工作不过是将设计转化为可供计算机运行的代码。然而，事实证明这个翻译过程是一项难度很高的脑力工作。 这项工作需要强大的脑力支持，而且更大的疑问是软件开发究竟是什么样的工作，时至今日这个问题依然困扰着管理人员。在计算机诞生初期，在某些人看来，编程是（或者说应该是）纯粹的逻辑问题。毕竟，机器只能按照指令工作。因此，我们需要告诉计算机正确的运行方式，而程序员的工作就是找到这种方式。 然而，实际的编程经验表明，编程既是艺术又是科学。2019 年，Clive Thompson 在《程序员》一书中指出，最先进的编程工作都是由一群大学实验室的技术怪人完成的，他们认为自己既是工匠又是逻辑学家。软件本身是看不见摸不着的（你只能看到存储软件的介质），因此与其他工程领域相比，软件开发的工作更加抽象且神秘。其他领域都有一定的物理定律可循，但软件似乎建立在流沙之上，因为硬件的参数和能力在不断变化。 然而，电子数据处理领域（办公自动化，如考勤卡和工资单）得到了迅速发展，因此这些任务使用的机器也迅速地成了技术的最前沿。但我们需要运维团队来设计程序、准备打孔卡并将数据输入系统。老牌经理们看不惯年轻的专业团队日益壮大，也看不惯软件项目的成本和复杂性经常不可控。计算机科学家 Frederick Brooks 曾将软件项目比作狼人：这些项目刚开始的时候就像小狗一样天真无邪，但最后往往会演变成“不遵守时间计划、预算超支且有缺陷产品的怪物”。20世纪60年代后期，软件开发面临三大危机：迫切需要更多的程序员；必须提高可预测性；开发人员必须配合管理层的工作。 本着这种专业化的精神，行业领导者鼓励程序员接受“软件工程师”的概念，这个概念是在 1968 年北约软件工程会议提出的。许多组织领导都指出，软件开发的规模庞大、组织难度高，而且很难管理。那么，为什么不借鉴一些其他工程领域的方法呢？将编程工作发展成为一门科学，并建立一套有秩序、有影响力且可靠的方法。组织者希望，降低软件开发行业的管理难度，软件工程师可以学习其他学科工程师的模式，更好地融入企业文化。历史学家 Nathan Ensmenger 写道，“为了提高制造软件的效率，编程的黑魔法必须让位于科学的软件工程方法。 瀑布式软件开发 软件工程似乎的确有效。各个大学都采用了这个术语，鼓励学生在学习编程时，练习完善的工程方法，例如使用数学证明等。计算机科学家 Tony Hoare 声称，这些技术将“改变晦涩难懂且容易出错的计算机编程工艺，以满足工程专业的最高标准。” 另一方面，经理们也花费了大量心思来组织软件开发人员，并建立了多种不同的组织方法。其中一种方法是 IBM 推出的主程序员组（Chief programmer team，CPT）框架，该框架由一名主程序员负责监督一组核心专家成员的工作。还有一种流行的做法是，由多级管理者负责管理程序员，管理者们制定决策并将工作分配给麾下的程序员。 随着这些新技术的出现，程序员的管理也冒出了很多新方法，其中之一就是“瀑布式软件开发”。从理论上来说，瀑布式开发非常合理：有人为软件产品设定目标，并将生产分解为一系列步骤，必须确保当前步骤的所有工作都已完成并通过测试，才能继续下一个任务。换句话说，开发人员只需要按部就班地执行管理层定下的计划即可。 然而，充满讽刺意味的是，首次提及“瀑布”一词的文章指出这种方法不切实际，但这个名称和思想却依然流行起来了。瀑布式开发与采用这种方法的公司的层级结构非常契合，正如 Nathan Ensmenger 写道：“软件工程运动的本质是控制：控制复杂性、控制预算和日程计划，而最重要的恰恰是控制劳动力。”而这正是瀑布式开发最擅长的领域。 但不久之后，软件开发再次陷入危机。部分问题是计算机科学家的供不应求。在20世纪80年代，各个大学没有足够的师资力量来培养大量立志成为软件工程师的学生。美国计算机协会表示，“这种情况十分严重，甚至威胁到了计算机科学部门持续培养信息处理行业以及科技日新月异的社会所需的技术人才的能力。” 缺乏开发人员并不是软件行业面临的唯一难题。软件开发本身似乎也深陷泥沼。瀑布式管理承诺的严格控制管理化成了海市蜃楼。再多的文档、再多的流程、再多的程序也拯救不了软件开发的不可预测性。软件项目规模巨大、成本高昂，而且经常会失控，由于需求的不断变化，项目团队之间在细节问题上争吵不休，所有的计划都无法按时完成。管理人员使出浑身解数，想让软件开发变得更可靠、更可预测，但结果却愈演愈糟。正如计算机科学家 Jeff Offutt 所说，“20世纪60年代，程序员建造的都是‘小木屋’，而到了80年代，程序员团队建造的都是办公楼”，而到了90年代，他们建造的都是摩天大楼。然而，技术专家团队似乎无法协调他们的工作。根据技术行业顾问 Peter Varhol 的估计，20世纪90年代初期，从构思到产品问世，每个应用程序所需的开发时间平均为三年。高科技本应让各大企业更智能、更快、赚取更多利润，然而很多公司的项目都未能顺利完成。 “工程师”的头衔、层级管理结构、周详的计划和文档，所有这些都是为了给新兴的软件开发领域带来秩序和控制，但最后的结果却适得其反。瀑布并没有为软件开发人员扫清障碍，相反大量的文书工作和无休止的会议加重了他们的负担。 工程师对各种苛刻的管理怨声载道。他们只想构建软件，结果却不得不疲于应付大量文书工作。Douglas Coupland 的小说《Microserfs》（微农）以及Mike Judge的电影《上班一条虫》（Office Space）中描绘的绝望的开发人员就是那个时代的写照。 敏捷宣言下一次危机
近期文章
推荐阅读
热门问答
 达内教育：成立于2002年。致力于面向IT互联网行业，培养软件开发工程师、测试工程师、系统管理员、智能硬件工程师、UI设计师、网络营销、会计等职场人才
达内使命：缔造年轻人的中国梦、缔造达内员工的中国梦
达内愿景：做管理一流的教育公司
|
0