《纯粹的敏捷》一书。灵活性的基础

图片您好,habrozhiteli!我们已经把另一个新奇的东西交给了印刷厂!自从《敏捷宣言》出现以来已经过去了近二十年。传奇人物罗伯特·马丁(Robert Martin)(鲍勃叔叔)意识到,是时候摆脱敏捷原则的尘埃了,并且再次向下一代编程人员以及其他行业的专家讲述这种灵活的方法。受到IT人员喜爱的“清洁代码”,“理想程序员”,“清洁体系结构”一书的作者是敏捷的起源。 Pure Agile消除了由于Agile的存在而导致的误解和困惑,这些误解和困惑使原始计划变得更加难以使用。本质上,敏捷只是方法和工具的一小部分,可帮助小型程序员团队管理小型项目,但是却能带来巨大的成果,因为每个主要项目都包含大量积木。经过数十年与各种可以想象的类型和规模的项目合作,鲍勃叔叔展示了敏捷应如何实际工作。如果您想了解敏捷的好处,请不要寻找简单的方法-您需要正确使用敏捷。 Pure Agile告诉您如何为开发人员,测试人员,经理,项目经理和客户执行此操作。

摘抄。首先要知道


关于该项目,您首先需要了解什么?在找到项目名称或项目要求之前,在进行任何更改之前,您需要获取更多信息。当然,这些是最后期限。选择日期后,需要对其进行固定。讨论这些术语毫无意义,因为它们是根据客观业务原因而设置的。如果9月到期,不仅如此。也许计划在9月进行某种形式的展览或股东大会,或者可能只是资金用完了。无论出于何种原因,它都有一些重要的背景。原因不会仅仅因为某些开发人员的任务量庞大而无法改变。

同时,需求会不断变化,无法固定。

这也是有原因的-客户通常不知道他们到底想要什么。他们似乎知道他们需要解决什么问题,但是将此类知识转化为项目需求始终很困难。因此,需要不断重新评估和重新考虑需求。添加了新功能。

一些旧的消失了。用户界面快速更改-数周(如果不是几天)。

这就是软件开发世界的样子。在这个世界上,截止日期是固定的,需求也在不断变化。而且,在所有这些方面,开发人员需要成功完成项目。

采集


级联模型为我们提供了一种绕过此任务的方法。为了说明同时具有诱人性和无效性,我举一个会议为例。

那是五月一日。大老板叫下属到会议室。

老板开始说:“我们有一个新项目。有必要在11月1日之前完成。我们还没有要求。他们将在接下来的几周内向我们宣布。分析该项目需要多长时间?”

我们开始怀疑地互相看着对方。每个人都保持沉默,不敢说太多。没有人知道该怎么回答。有人喃喃地说:“所以我们没有要求,我们应该从什么开始?”

“想象一下他们是!大吼大叫。 “你知道一切如何运作。”你是专家!我不需要确切的日期。我只需要以某种方式填写时间表。请记住,如果花费两个多月,您可以放心地忘记该项目。”

有人怀疑地喃喃道:“两个月?”老板认为这是对条件的同意:“太好了!就是我在想的现在告诉我设计需要多少钱?”

每个人再次迷惑不解,房间里充满了死寂。我们算。而且我们意识到,直到11月1日才只有六个月。结论表明了自己。 “2个月?” - 你问。

“那就对了! -大老板笑容灿烂。 - 和我想的一样。我们还有两个月的实施时间。多亏大家,您有空!”
许多读者可能记得他们已经发生了类似的事情。谁没有这个,好吧,你很幸运!

分析阶段


因此,假设我们离开会议室并分散在办公室周围。接下来做什么?分析阶段开始-这意味着您需要分析一些东西。但是,我们究竟称什么为分析?

如果您阅读有关软件开发中分析主题的书籍,您会发现每个作者都给出了自己的定义。关于什么是分析尚无共识。它可能是需求的结构分解的结果。也许-检测和规范需求。可能是创建基本数据模型或对象,等等。分析的最佳定义是:分析师所做的。

当然,有明显的事情。我们需要评估项目的规模,以预测主要技术,经济和人力资源的指标。您需要确保工作计划是可行的。这是该公司对我们的最小期望。无论所谓的分析,这都是我们接下来两个月要做的事情。

这是该项目的有利阶段。每个人都可以从容地浏览Internet,进行小额交易,与客户和用户会面,绘制精美的图形,简单地说,玩得开心。

然后,7月1日发生了奇迹。分析完成。

为什么会这样呢?因为已经是七月的第一天。如果根据计划,分析阶段应在7月1日完成,那么此阶段将在7月1日完成。我们不迟到,是吗?因此,我们将安排一个气球和激烈演讲的小型聚会,庆祝我们从分析阶段过渡到设计阶段。

设计阶段


现在做什么?当然,我们会设计。但是,设计是什么

我们对软件设计阶段了解更多。在此阶段,我们将项目分为单独的模块,并设计这些模块之间的接口。在这个阶段,我们还假设我们需要多少个团队以及这些团队如何相互联系。总的来说,需要弄清工作时间表,以制定可行的可行实施计划。

当然,在这个阶段,某些事情出乎意料地改变了。添加了新功能。旧功能消失或调整。回顾并再次分析更改会很好,但是时间就是金钱。因此,我们正在尽一切可能对设计进行更改。

然后一个新的奇迹发生了。在9月1日,我们突然完成了设计。又为什么呢 是的,因为。9月1日。根据工作时间表,我们应该已经完成​​了。不用犹豫。

所以再开一个派对。气球和演讲。然后我们进入下一阶段-实施。

再次提出这样的计划将是很棒的。哦,如果以同样的方式,有可能完成实施阶段!但这不会解决。因为在完成实施后,需要完成整个项目。分析和设计不会以二进制形式取得成果。他们没有完整的标准。

没有客观的方法知道它们是否现实存在。因此,事实证明可以按时完成这些阶段。

实施阶段


但是该实现仅具有不同的完整性标准。在这里,不再可能准确无所事事,使虚构结果有效。
在实施阶段,完全没有任务的歧义。我们只是编写代码。而且我们不得不急着写代码,伸出舌头,因为四个月简直就是风头。

同时,项目要求不断变化。添加了新功能。旧功能消失或调整。我们将不得不回去,进行新的分析并对设计进行更改,但是...只剩两个星期了。并且,我们将所有这些更改以加速的速度驱动到代码中。

当我们查看代码并将其与设计结果进行比较时,我们意识到我们必须在设计阶段就不合适了,因为代码本身与原始图形中所描绘的内容没有什么共同之处。但是没有时间去思考,因为时钟在滴答作响,加班越来越多。

10月15日左右,有人说:“嘿,今天几号?”什么时候服用?”在这里,我们知道仅剩两个星期,到11月1日,我们将永远无法结束。突然之间,我们的客户第一次发现该项目存在一些问题。

想象一下他们的愤慨。“而在分析阶段,这不可能说吗?那不是您应该估计项目的规模并仔细计算工作进度表吗?他们为什么不在设计阶段说呢?那么是否有必要将项目分成模块,在整个团队中分配工作并计算人力资源吗?我们为什么要在截止日期前两周找出所有信息?”

他们是对的,不是吗?

生存马拉松


生存马拉松开始了。客户很生气。利益相关者走到了极端。压力正在上升。我们加班。有人离开了项目。真是的

大约在三月份,我们就感到悲伤了一半,结果只有一半满足了客户的需求。每个人都很沮丧。每个人都放弃。我们向自己保证,下次不会发生这种情况。下次我们将明智地做所有事情。下次将进行真诚的分析和设计。

我称其为膨胀失控过程。下次使用不可行的方法,我们将做得更好。

»您可以在出版商的网站

上进行预订在支付了纸质版本的书后,pdf会发送到电子邮件中本书的前105页。

All Articles