Agile项目管理的终极指引

Posted 2021-05-02 Danny话你知

Agile项目管理并非是新的东西，我们所知道的Agile项目管理真正是来自1990年代，作为对项目管理严格计划反应、传统方向的定义。

 

软件开发人员巳经厌烦了对微管理的感觉，并且开始利用新的方向了，就像是快速的程序开发、统一的行为、动态的系统开发方法、Scrum、以及极限的编程。这些方向构成了一个Agile原型的框架，同时现在就考虑归入到大型的Agile项目管理定义中去了。

 

直到2001年所撰写的《Agile软件开发宣言》（"Manifesto for Agile Software Development"），这个新框架就有了它的名称，同时就是在这里我们开始给出对Agile项目管理的终极指引。

 

1.  Agile宣言及12条Agile原则

关于完整的Agile项目管理定义，让我们查看一下Agile宣言，那是由17位相信他们是「通过进行和帮助他人揭露软件开发更好方法」的软件开发人员撰写出来的。

 

有4个核心价值概括在Agile宣言里面：

1. 行为和工具上的个人和互动

2. 详尽文件上的工作软件

3. 合约争论上的客户协作

4. 依随计划上对变化的反应

要帮助团队对这些核心价值保持真诚，群组在Agile框架内为管理项目定义了12条原则：

i.        我们最优先的就是要通过尽早和不断的交付出有价值的软件来满足客户。

ii.      即使在开发的后期，都欢迎改变需求，Agile的行为就是利用改变，来获得客户的竞争优势。

iii.    从数星期到数月，优先以较短的时间刻度，频繁的交付出工作的软件。

iv.     商务人员和开发人员必须每天一起工作在整件个项目中。

v.      围绕着积极的人们建立项目，给他们提供环境，并且支持他们的需要，同时相信他们能把工作做好。

vi.     最有效率和最有效向开发团队，及在其中传达讯息的方法，就是面对面的交谈。

vii.   工作软件就是进度的主要量度标准。

viii.  Agile行为会促进可持续的发展，发起人、开发人员、以及用户都应该能够无限期维持一个稳定的速度。

ix.     对优秀技术和良好设计持续的关注会促进Agile性。

x.      简化—最大化未完成工作量的艺术—是基本的。

xi.     最好的架构、需求、以及设计，都是由组织好的团队所产生。

xii.   在定期的时段中，团队反映出怎样变得更为有效，然后相应地调整和适应其行为。

这就是基线，而大部份的Agile项目管理的支持者，都会同意这些对Agile理解种子的。无论怎样，随着行为增长，争执也同样在增长。真实就是Agile作为框架并非是规定的，这并没有严格的系统来跟随，就像是传统的方法，譬如是Waterfall项目管理，Agile更多的是一种工作哲学。

2.  Agile项目管理对Waterfall项目管理

如之前所述，Waterfall是个管理项目更为传统的模型，它亦被称为线性排序的生存周期，那是难以口述的。那意思就是Waterfall会依随着具体的次序，一个步骤跟着另一个的，而下个步骤是不会开始的，直至之前的一个已经完成。

 

无论怎样，Agile项目管理全都是关于灵活性，并且会依随一套持续重复逐渐增长方向的。Agile项目通常会在整个开发阶段进行测试，同时在任何需求出现时，都会接受其变化。

 

a.   使用Waterfall项目管理的好处

Waterfall和Agile两者项目管理都有它们的好处和坏处，利用Waterfall方法一个清晰的好处，就是它是很直率的，它的每个阶段都有交付物，在继续下去之前都会进行检查，模板也很容易跟随。

 

这是个有着易于理解需求，有好处的行为，并且会为那种性质的项目创建出更快速的交付速度。它亦会作出十分详细记录，对未来的项目，以及保持相关者在循环中非常有用。

 

因为Waterfall是很架构性的，当新团队加入到项目中去的时候，会让它们很轻松的融入。项目经理亦会喜欢它的，因为它会在管理它们项目的依赖性上往往工作得更好。

 

线条图就是个Waterfall和架构性计划的典型项目管理工具，线条图会把项目分拆为里程点和较小的任务，当加上了开始和结束的日期，就填到项目时间在线。依赖的任务可以链结起来，以避免在生产中的樽颈。就像你可以看到那样，时间线最终会制作出像Waterfall般的设计来。

 

b.   使用Agile项目管理的好处

然而Waterfall在项目的开始就专注于收集需求，这样架构性计划就会被创建出来，Agile项目管理会收集整个项目客户的回馈，并且欢迎更改的。Agile相信会让客户不断的更新在项目中发生的事情，这就会产生满意的客户，尤其是因为他们在对项目不管甚么的需求都已经得到了实施，即使那是意味着在回旋。

 

定义上的Agile团队，都是自我导向的，这就给了他们其它使用传统方法团队没有的自主性。自主的团队通常都是更为积极和有生产力，以及快乐的。很自然，项目就可以从中获益了。

 

质量是Agile项目管理的关键，而Agile框架就把太多的注意力专注在尽可能保持产品的高质量上。这是通过渐进的进度来完成的，这不只让出现的事件得到解决，同时交付物也得到改善，而让团队和客户都意见一致（stay on the same page），这就减少了开发中的风险。

 

在Agile的环境中，团队就更为自主的了，像是Kanban板这种可视化的工作流程工具经常会被使用。当工作在像是Scum这样的Agile框架中，它们会把冲刺（sprints）分拆为3列：要做的、进行中及完成了（在列的标题上可以订制以适合任何项目）。任务会以卡来标示，团队成员在他们工作和完成了任务时，从一列转移到另一列。这就提供了透明度，并且让团队成员只专注在他们冲刺的任务上。

 

Kanban板其中有着多个项目视图，它们用上了简单拖放的接口，以及当状况更新后，数据就会在软件整体中反映出来。

 

c.    使用Waterfall项目管理坏处

因为使用Waterfall这些不利之处，它并不太适合动态的项目。当项目的需求一开始就没有好好铺排时，这就同样有问题。然后又会有重回一个阶段的欲望了，这并非是Waterfall模式的部份。所以，如果在之前的阶段有问题，就必须处理，这可以是很困难的。

 

Waterfall的另一个问题就是测试了，在保持方法架构性的一致上来说，项目的测试阶段是直到开发结束后才开始的。当错误展示出来时，开发已经结束，这样必须修补那些错误就会很昂贵和花时间的了。

 

d.   使用Agile项目管理的坏处

Agile项目管理也并非是完美的，Agile项目管理一般会要求有一位专家来帮助重要的决策，让它能与Agile的价值保持一致。因此，没有专家，项目就会遭受折磨了。

 

这亦有使用Agile项目管理的成本方面，它比其它像是Waterfall的传统方法更为昂贵。这是因为太多的变化会出自一个项目了，这很难准确知道项目是会花费多少的。同样，因为团队是自我导向的，如果它们在需要甚么成果上，没有得到清晰的方向，项目就会很快发觉本身脱轨的了。

 

3.  混合性的项目

无论怎样，项目并非是只有黑与白的，很多都会和像是Waterfall这样更为传统的方法混合在一起的，项目经理和IT团队通常会喜欢的是一个Agile框架，这是更适合自我导向团队和开发人员的。

 

它有着在两个世界中都是最好的，更为架构性方向的线条图，以及Kanban板，并且有着给予团队成员更有生产力自由工作的协作工具。同样有着任务列表和记事录，这样每个人都可以找到更有生产力的方法了。

 

4.  典型的Agile框架

在解决问题，或者在项目中工作的时候，是有很多使用Agile框架方法的。让我们看看一些实践Agile项目管理更为流行的方法吧。

 

a.   Scrum

Scrum是所有软件开发中最流行的方法，作为一个Agile的框架，Scrum实际上比「Agile」这个词汇出现的时间还要长。Scrum是在1986年被介绍出来的，作为产品开发的一篇文章称为《崭新的产品开发游戏》（"The New Product Development Game"）中一部份（这个并非手误，重复是有意的）。

 

作者是Hirotake Taskeuchi和Ikujiro Nonaka，声称这个崭新的产品开发会比现时所使用的，更快速和更灵活。他们说他们的意念是来自遍历制造厂商案例研究的。

 

Scrum在1995年发展成为了一个正式的行为，而那些人当中亦有的是2001年中提出Agile宣言的群组成员。

 

但甚么是Scrum呢？这是个框架，想要成为Agile团队的就可以用来工作在复杂的、有适应能力的问题上。它有助于提高生产力和促进建设性的解决方案，同时专注在交付出高价值的项目上。

 

Scrum对于负责复杂任务的协作团队来说，是个简单和有效的框架。那就是说，虽然很容易理解，但Scrum是可以难以掌握的。

 

b.   Scrum团队

Scrum团队是由产品拥有者、开发团队、以及Scrum大师所组成的。产品拥有者负责管理产品的积压工作，这是一份工作的清单，就像是待办事件清单。开发团队是由那些负责把交付物转化为完成产品的人所组成的。Scrum大师就只是一位Scrum框架的大师，他会作为确保每个人都能在Scrum框架中正确工作的权威和领导者。

 

c.    冲刺（Sprints）中工作

在Scrum中的工作会被分拆为称作的仪式，限制太多会议的需要。Scrum仪式包括了冲刺（sprint）、冲刺计划、每天的Scrum、冲刺审查、以及冲刺回顾。

 

在Scrum指引中把冲刺定义为一个月，或者更少时间内任务完成的「时间框」。冲刺计划事件听起来就是，整个Scrum团队在工作的协作计划。每天的Scrum是很短的，通常是个在每天结束时不多于15分钟的会议，在那里开发团队会为下一天建立起一个前进的计划。

 

在冲刺后，还有一个冲刺审查，那是根据需要用来编辑产品积压工作的。最后，冲刺回顾就是一个给Scrum团队，解决上一个冲刺中的事宜，以及为下一个创建改善的方法。

 

所有这些都是为Scrum要点服务的，那是让团队一起更为有生产力的工作，就像是运动团队。Scrum的名字来自于棷榄球，Scrum就是scrummage的简称。它亦被设计来帮助团队从他们的经验中学习，并且不断的改进，所有都符合Agile的思维模式。

 

d.   Kanban

Kanban来自丰田汽车公司（Toyota Car Company）的生产车间，它是从Lean生产而来的，减少了进行中的工作（Work-In-Progress），并且专注在正好及时（Just-In-Time）的材料交付，以优化空间和保持专注在实时的任务上。

 

最简单的说，Kanban就是列上标记着待办、进行中、以及完成的一块板，在这些列的下面，卡迭了起来。每张卡代表着一个具体的任务，那是之后当它在生命周期中移动时，在板上横向移动的。

 

在Agile的思维中，Kanban板就是一套可视化的工具，有助于控制功能或者卡的流程，这样就不会有樽颈了。任务是不可以移到另一列的，除非有能力去做。虽然是Agile框架的一部份，Kanban是不需要重复的，就像是Scrum。无论怎样，它都是渐进的。

 

同样，不像Scrum，它是没有严格规则的。因此在那些更为习惯在Waterfall的，和传统管理方法之间，有着一条很有吸引力的桥梁，那就是想转变成Agile思维了。

 

e.   极限编程（XP—Extreme Programming）

XP是由Kent Beck在《极限编程》（"Extreme Programming"）这本书中介绍出来的，不像Scrum，XP顾名思义，更多是用在怎样高质量的撰写和测试中。

 

根据Extreme Programming.org，有4种特质使XP能架构成Agile行为的适当方法。

1. 在不断改变着软件的需求时

2. 在项目中的新技术和固定的时间中导至更高的风险时

3. 在开发团队规模较小、分布广、以及扩展性强时

4. 在所使用的技术中允许自动化单位和功能性测试进行时

 

这是有5个与XP有关的价值观：沟通、简化、回馈、鼓励和尊重。

 

以下有12种XP的实践列了出来：

i.        计划的游戏、达成下一步完成所需要的东西

ii.       小量发布交付出客户的价值

iii.      团队的隐喻或者共同的愿景

iv.      简单的设计

v.       测试

vi.      移除重复及增加商业价值的重构

vii.    两个程序员做一份工作作出更佳产能的成对编程

viii.   集体拥有权

ix.      持续的整合

x.       40小时的一周

xi.      在场的顾客

xii.    编码标准

 

XP是在利用Agile思维来改善软件的质量，它是开放给顾客和他们的变化需要。它从传统软件工程意念的好处中的得名，在这个框架中发挥到了极致。

 

5.  Agile项目管理的工具及词汇

在一个我们还没有涵盖的Agile框架内，有一定数量有助于管理项目不同的工具，以下就是选出来的一些。

 

a.   息灭图（Burndown Chart）

息灭图就是一个图形，展示出还有多少工作还未完成，以及还有多少时间去做。这在要完成积压工作时，就有助于作出估算了。如果事情并不顺利，它就以红旗来警示，同时它是另一套展示进度沟通的工具，并且能估算完成工作要花多少时间。

 

b.   消耗图（Burnup Chart）

消耗图就像是与息灭图相匹配的东西，它是用来追纵已经完成了工作的数量，同样展示出项目或者冲刺（sprint）的全部工作。再者，这会用在追纵团队的进度，并且有助于他们管理范筹，同时避免范筹的延慢。这是另一个有助于透明度，容于阅读的图形。

 

c.    用户叙述（User Story）

这个Agile项目管理工具是用来收集软件功能最终用户的描述，所以它是来自他们观点的。毕竟，这是为最终用户设计的产品，同时Agile项目管理全都是为客户服务的。

 

用户叙述亦在描述用户，它不只是他们所想的，还是他们为何想这样的。这就会带出产品需求的简单描述，这亦是史诗式的叙述，这就是大型的用户叙述掌握大局，它们会分拆为更为易于管理的用户叙述。

 

d.   叙述要点（Story Points）

叙述要点是用来确认，实施用户叙述会有怎样的困难。它会用数字来表示，告诉团队困难的程度。它有助于搞清楚工作量有多少，并且避免浪费时间在尝试作出过于精细的估算上。

 

e.   叙述标记（Story Mapping）

这是有助于团队建立产品积压的一个协作行为，它被称为标记，因为它是用在捕捉顾客在产品开发中的旅程。因此，它会以目标来开始，然后分拆为用户叙述，这全都是为了增加顾客的价值。

 

6.  结论

对于项目重复和递增的方向已经从软件领域中迁移出去，并且差不多触及了每个行业。Agile项目管理的哲学，是根据多年来项目管理成功与否的经验建立起来的。很明显，那些喜欢在Agile环境中工作的人，已经接受了自适应、重复、以及进化的方向来在项目上工作。这个Agile项目管理的终极指引，或许会把你带进他们的营地中。即使你不完全适应这种哲学，也要采用其某些或许能改善你项目的原则。