敏捷开发：采取灵活机动的战术来应对需求的不断变化

Posted 2021-04-25 知嘛健康研习社

敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。

换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

宣言原则

最重要的是通过尽早和不断交付有价值的软件满足客户需要。

我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。

经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。

业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，并相信他们能够完成任务。

在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

可以工作的软件是进度的主要度量标准。

敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。

对卓越技术与良好设计的不断追求将有助于提高敏捷性。

简单——尽可能减少工作量的艺术至关重要。

最好的架构、需求和设计都源自自我组织的团队。

每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

核心原则

◆主张简单

当从事开发工作时，应当主张最简单的解决方案就是最好的解决方案。不要过分构建软件。用AM的说法就是，如果现在并不需要这项额外功能，那就不要在模型中增加它。要有这样的勇气：现在不必要对这个系统进行过分的建模，只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统，尽可能的保持模型的简单。

◆拥抱变化

需求时刻在变，人们对于需求的理解也时刻在变。项目进行中，Project stakeholder可能变化，会有新人加入，也会有旧人离开。Project stakeholder的观点也可能变化，努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行，项目环境也在不停的变化，因此开发方法必须要能够反映这种现实。

◆第二个目标是可持续性

即便团队已经把一个能够运转的系统交付给用户，项目也还可能是失败的－－实现项目投资者的需求，其中就包括系统应该要有足够的鲁棒性（robust ），能够适应日后的扩展。

就像Alistair Cockburn常说的，当在进行软件开发的竞赛时，第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版，或是正在构建的系统的运转和支持。

要做到这一点，不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行。要考虑很多的因素，包括现有的团队是不是还能够参加下一场的比赛，下一场比赛的环境，下一场比赛对组织的重要程度。简单的说，在开发的时候，要能想象到未来。

◆递增的变化

和建模相关的一个重要概念是不用在一开始就准备好一切。实际上，就算想这么做也不太可能。而且，不用在模型中包容所有的细节，只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型，只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不再需要的时候丢弃这个模型。这就是递增的思想。

◆令投资最大化

项目投资者为了开发出满足自己需要的软件，需要投入时间、金钱、设备等各种资源。投资者应该可以选取最好的方式投资，也可以要求团队不浪费资源。并且，他们还有最后的发言权，决定要投入多少的资源。

◆有目的的建模

对于自己的产出，例如模型、源代码、文档，很多开发人员不是担心它们是否够详细，就是担心它们是否太过详细，或担心它们是否足够正确。你不应该毫无意义的建模，应该先问问，为什么要建立这个产出，为谁建立它。

和建模有关，也许应该更多的了解软件的某个方面，也许为了保证项目的顺利进行，需要和高级经理交流方法，也许需要创建描述系统的文档，使其他人能够操作、维护、改进系统。

首先，要确定建模的目的以及模型的受众，在此基础上，再保证模型足够正确和足够详细。

该项原则也可适用于改变现有模型：如果要做一些改变，也许是一个熟知的模式，应该有做出变化的正确理由。关于该项原则的一个重要暗示是应该要了解受众，即便受众是自己也一样。

◆多种模型

开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面，“要开发现今的商业应用，我们该需要什么样的模型？”考虑到现今的软件的复杂性，建模工具箱应该要包容大量有用的技术。

有一点很重要，没有必要为一个系统开发所有的模型，而应该针对系统的具体情况，挑选一部分的模型，不同的系统使用不同部分的模型。

◆高质量的工作

没有人喜欢烂糟糟的工作。做这项工作的人不喜欢，是因为没有成就感；日后负责重构这项工作（因为某些原因）的人不喜欢，是因为它难以理解，难以更新；最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望。

◆快速反馈

从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。和其他人一共开发模型，想法可以立刻获得反馈，特别是工作采用了共享建模技术的时候，例如白板、CRC卡片或即时贴之类的基本建模材料。和客户紧密工作，去了解他们的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这样，就提供了快速反馈的机会。

◆软件是主要目标

软件开发的主要目标是以有效的方式，制造出满足投资者需要的软件，而不是制造无关的文档，无关的用于管理的工件，甚至无关的模型。任何一项活动（activity ），如果不符合这项原则，不能有助于目标实现的，都应该受到审核，甚至取消。

◆轻装前进

建立一个工件，然后决定要保留它，随着时间的流逝，这些工件都需要维护。如果决定保留7个模型，不论何时，一旦有变化发生，就需要考虑变化对这7个模型产生的影响并采取相应的措施。而如果想要保留的仅是3个模型，很明显，实现同样的改变要花费的功夫就少多了，灵活性就增强了，因为是在轻装前进。

类似的，模型越复杂，越详细，发生的改变极可能就越难实现。每次要决定保留一个模型时，就要权衡模型载有的信息对团队有多大的好处。

千万不要小看权衡的严重性。一个开发团队决定要开发并维护一份详细的需求文档，一组详细的分析模型，再加上一组详细的架构模型，以及一组详细的设计模型，那他们很快就会发现，他们大部分的时间不是花在写源代码上，而是花在了更新文档上。

总结

当然，敏捷开发也绝不是解决一切问题的方式，它也有自己的适用场景，具体来说，敏捷开发特别适合互联网等市场竞争激烈，需要快速响应的场景。

但总的来说，软件首先是“软”的，要解决根本问题，还是要靠其中的人（产品、测试、开发）。因为软件是“软”的，则务必要求软件的从业人员也是“软的”，从这个角度出发，软实力是每个软件从业人员走向优秀的必备之道。

 

end