图灵社区按:TEAP是什么?
TEAP是什么?TEAP是Turingbook Early Access Program的简称,即早期试读,它公布的是图灵在途新书未经编辑的内容。一本书的翻译周期约为3到6个月,在这么长时间内,译者与读者没有沟通和交流是一件不可想象的事儿。通过TEAP,读者可以提前阅读将来才能出版的内容,同时译者也能收获宝贵的反馈意见,以便改进翻译,提高质量。

本书为《敏捷武士:看敏捷高手交付卓越软件》,有问题可以在这里留言,也欢迎@译者E路向前--北京,本篇内容选自书中第1章。

想要每周都能交付一些有价值的东西,都要做哪些方面的工作?

通过让客户亲眼见证软件交付的正确方式的寻找过程,我们就会发现以前所提供给客户的服务有多少是徒劳无益的,并且我们还不止一次错过了真正重要的东西—定期交付可工作的软件。

enter image description here

读完本文,你会更深刻地理解敏捷计划,并了解我们是如何衡量敏捷项目成功与否的,以及你如何只用三条简洁的准则就能从容而优雅地应对最紧张的期限和最艰难的项目。

每周交付一些有价值的东西

暂时忘记一会儿敏捷,假设你就是客户。资金和项目可都是你自己的,你已经雇佣了顶尖的团队去交付你想要的软件。

什么东西能让你相信你所雇佣的团队正在进行实际交付?是一摞摞的文件、计划和报告?还是每周都定期交付了你认为具有最重要特性并且可工作的、测试过的软件呢?

所以当你开始以客户的视角来审视软件交付时,你也就步入正轨了:

1. 你要将大问题拆分为许多小问题:

enter image description here

一周时间相对较短,你不可能在一周内完成所有任务。要想搞定一切,就得将棘手的大问题分割为更小、更简单、更易于管理的小问题。

2. 你要将你的注意力集中于最重要的事物,心无杂念。

我们所交付的传统软件项目对于我们的客户很少有或者说几乎没有什么价值。

当然,你需要文档,也需要计划。但是它们仅支持一样东西---可工作的软件。

通过每周都交付一些有价值的软件,你会逼迫自己变的更精益,放弃任何不能增值的工作。这样你就可以只带上必需品轻装前进了。

3. 确保你正在交付的东西可以工作。

每周都交付一些有价值的东西意味着你要交付更好的软件产品。这也就意味着你要进行很多测试——尽早、经常性的测试。

不断摒弃一些东西,直到项目截止,这时日常测试会成为你的一种生活方式。你就是问题的终结者

4. 寻求反馈

你要定期停下来,向你的客户征求一下你的目标是否正确,否则你怎会知道是否达到预定目标?

反馈好比是汽车的大灯,能够穿透你前方的雾霭,即使你在高速公路上把车子开到100公里/小时也仍然会安然无恙。没有它,你的客户会就会失去对汽车的控制—而你也会栽在沟里面。

5. 必要时你可以改变过程

enter image description here

项目会有偶然情况发生,事情也会发生变化。一周中最重要的事情也可能被移到下一周。如果你创建一个计划后只是循规蹈矩,那么当实施计划时你就无法做到收放自如、随需应变。当现实破坏了你的计划,你要改变的是计划而不是现实,其原因也正是如此。

6. 你要勇于负责

如果你承诺每周都交付一些有价值的东西,然后向你的客户展示你将他们的钱用在了哪方面,这时你要勇于负责。

  • 你需要控制质量。

  • 你需要控制进度。

  • 你需要设定期望值。

  • 你需要花钱时就像在掏自己的钱包,要格外吝惜。

enter image description here

我这样说是否表明每个人最终都应该以这种方式工作呢?不可能——这道理就好比多数人的饮食习惯并不恰当,并且还缺少运动。

每周都交付有价值的东西并不适合胆怯者。它会让你成为公众注意的焦点,这在以前是不可能的。你会无处可藏。你要么做出些有价值的东西,要么什么都别做。

但是如果你喜欢可见性,专注质量并且对执行有着非常强烈的渴望,那么在敏捷团队中工作会让你个人受益匪浅,乐趣多多。

如果每周一付让你觉得压力过大,那也不要担心—这没什么关系。多数敏捷团队开始时都是每两周交付一些有价值的东西(大团队会每三周一次)。

这只是个比喻,让你设想一下要定期给你的客户提交可工作的软件,然后得到一些反馈,必要时再改变进程。就这些。

enter image description here

现在让我们先审视一下敏捷计划

敏捷计划如何生效?

计划一个敏捷项目与为一个忙碌的长周末假期准备东西没什么两样。我们不用待做事项列表和任务这两个词,我们换两个有趣的名字:总故事列表和用户故事。

enter image description here

在敏捷中,总故事列表就是你的项目待做事项列表。它包含了所有的高级别特性(用户故事),而这些正是你的客户希望在他们的软件中能见到的。你的客户对其设定优先级,你的开发团队会对其进行估算,而这正是形成你项目计划的基础。

敏捷项目中的核心就是迭代—在一周至两周内选取你客户的最重要的故事,然后将其转化为可运行的、测试过的软件。

你的团队成员通过测算团队速率来决定需要承担多少工作(每个迭代周期你可以完成多少)。通过追踪你的速率并预测未来你所能完成的任务量,你的计划就可以实事求是,从而避免你的团队夸下海口。

如果你和客户面临的任务过多,那就先做你唯一能做的事——少做一些。在范围方面要灵活处置,也就是你要学会平衡你的计划,并将你的承诺变为现实。

当现实与你的计划相悖时,就应该改变计划。适应性计划是敏捷交付的基石。

敏捷计划也就以上这些了,我们将在第八章中对其进行更深入的探讨。

enter image description here

如果牺牲不可避免,你还是顺其自然吧。不过你要确认你的牺牲物有所值,而不是因为你在一年前的业务评估中所做出的不切实际的承诺。

确实,人们会做出不切实际的承诺,也经常要求团队去尽力而为。但这并不能解决问题。“靠奇迹去管理”这种假象如果一直持续下去,会成为一种糟糕的项目运行方法,要是这个期望值是你和客户一起设定的,那就更糟糕了。

enter image description here

有了敏捷,你就不需要这些奇迹了,因为从开始阶段你就会与客户开诚布公地配合工作—对客户直言不讳,让他们自己做出范围、资金和数据方面的明智决策。

这要看你的选择了。你可以总是想着“奇迹总会出现”来工作,或者你也可以与客户一同制定出双方都认可的计划。

还有一些事你要知道:敏捷是如何定义“完成的事情”

“完成”的意思就是“完成”

假设你的爷爷奶奶雇佣你邻居的小男孩去将他们草坪前的叶子打扫干净并装进袋子。当这个小孩完做了如下工作后,爷爷奶奶会认为他就把活干好了吗?

  • 制作了一份如何打扫院子的计划报告?

  • 是否有漂亮的设计?

  • 是否制作了一份详尽、面面俱到的测试计划?

不可能!这个小孩要是不把树叶扫干净、装袋并且在屋后给叶子找个归宿的话,他一个子也得不到。

在敏捷中,我们使用同样的定义。在敏捷中,交付一个特性就意味着要完成所有必须的任务才能生产出可交付的代码。

enter image description here

分析、设计、编码、测试和用户体验(UX)—东西都在这里了。这不是说我们必须要把首个版本特性搞的花里胡哨,或者我们要将最新版本的作品放在每个迭代的最后才可使用。但是我们的态度是:要做就得做好。

如果作品还不能交付,那就是没有完成。这也是为什么作为敏捷开发者,我们必须要坚持敏捷原则并要接受如下三条简单准则。

enter image description here

三条简单准则

下面就是三条简单的项目准则,一旦接受这些准则,我们就可以去除多数我们在软件项目中常见的戏剧性效果和机能障碍。

  1. 在项目的初期不可能收集到所有的需求。
  2. 不管你收集到什么需求,最终它们肯定都会发生变化。
  3. 需要做的事情太多了,总会超出时间和金钱的允许范围

接受第一条准则意味着即使没有万事俱备,你仍大胆地开始了你的旅途。你意识到要自己去发现需求,如果等着一切都收集完毕才开始,那永远也开始不了

接受第二条准则意味着你不再惧怕变化或者刻意避免变化。你知道变化无法避免;你只能承认它。必要时你会调整你的计划后再继续下去。

接受了第三条准则,当你的待做事项列表超出你的交付时间和资源时,你不会再有压力。对于任何有趣的项目来说,这都是正常状态。你只是做了你唯一能做的事—你设置了一些优先级别,先完成最重要的任务,将最不重要的留到最后。

一旦你接受以上这三条简单的项目准则,大部分软件交付方面的紧张和焦虑感都会消失。

然后你就能够以集中而清晰的思路去思考和创新了,而我们的行业多数都失去了这种能力。

你要记住,没有任何书籍或方法是万能的,你仍需自己去思考。每个项目都是不同的,虽然一些原则和实践永远不会出错,但是如何对其进行应用仍然取决于你特有的情况和环境。

相关阅读:好书短评之《敏捷武士:看敏捷高手交付卓越软件》