想要每周都能交付一些有价值的东西，需要在哪些方面付出努力呢？通过让客户亲眼见证软件交付的正确方式，我们就会发现以前提供给客户的服务是多么徒劳无益，并且还不止一次错过了最重要的东西——定期交付可工作的软件。
每周交付一些有价值的东西
暂时忘记一会儿敏捷,假设你就是客户。资金和项目可都是你自己的，你已经雇用了顶尖的团队去交付你想要的软件。怎样才能让你相信所雇用的团队正在进行实际交付？ 是一摞摞的文件、计划和报告，还是每周都定期交付了你认为具有最重要特性并且测试过的可工作软件呢? 所以当开始以客户的视角来审视软件交付时，你也就步入正轨了。
(1)要将大问题拆分为许多小问题。
一周时间相对较短，你不可能在一周内完成所有任务。要想搞定一切，就得将棘手的大问题分割为更小、更简单、更易于管理的小问题。
(2)要将注意力集中于最重要的事物，心无杂念。
我们所交付的传统软件项目对于客户很少有或者说几乎没有什么价值。当然，你需要文档，也需要计划。但是它们仅支持一样东西——可工作的软件。每周都交付一些有价值的软件迫使你更精益，放弃任何不能增值的工作。这样就可以只带上必需品轻装前进了。
(3)确保正在交付的东西可以工作。
每周都交付一些有价值的东西意味着你要交付更好的软件产品，也就意味着你要进行很多测试——尽早而且经常性的测试。不断摒弃一些东西，直到项目截止，这时日常测试会成为你的一种生活方式。你就是问题的终结者。
(4)寻求反馈。
你要定期停下来，向客户征求一下你的目标是否正确，否则怎会知道是否达到预定目标?反馈好比是汽车的大灯，能够穿透前方的雾霭，即使在高速公路上把车子开到100公里/小时也仍然会安然无恙。没有它，客户就会失去对汽车的控制，而你也会栽在沟里面。
(5)必要时可以改变过程。
项目会有偶然情况发生，事情也会发生变化。一周中最重要的事情也可能被移到下一周。如果创建一个计划后只是循规蹈矩，那么当实施计划时就无法做到收放自如、随需应变。当现实破坏了计划，你要改变的是计划而不是现实，其原因也正是如此。
(6)要勇于负责。
如果你承诺每周都交付一些有价值的东西,然后向客户展示将他们的钱用在了哪方面，那么你要勇于负责。
需要控制质量。
需要控制进度。
需要设定期望值。
需要花钱时就像在掏自己的钱包，要格外吝惜。
那我的意思是大家都要以这种方式工作? 不可能! 这就好比多数人有不良饮食习惯同时还懒于运动。每周都交付有价值的东西并不适合胆怯者。它会让你成为万众瞩目的焦点，这在以前你是想都不敢想的。你会无处可藏。你要么做出些有价值的东西，要么什么都别做。但是如果你喜欢可见性，专注质量并且对执行有着非常强烈的渴望,那么在敏捷团队中工作会让你个人受益匪浅，乐趣多多。如果每周交付让你觉得压力过大，那也不要担心，这没什么关系。多数敏捷团队开始时都是每两周交付一些有价值的东西(大团队会每三周一次)。这只是个比喻，让你设想一下要定期给客户提交可工作的软件，然后得到一些反馈,必要时再改变进程。就这些。
敏捷计划如何生效
计划一个敏捷项目与为一个忙碌的长周末假期准备东西没什么两样。我们不用待做事项列表和任务这两个词，换两个有趣的名字:总故事列表和用户故事。
在敏捷项目中，总故事列表就是项目待做事项列表。它包含了所有的高级别特性(用户故事)，而这些正是客户希望在他们的软件中能见到的。客户对其设定优先级，开发团队会对其进行估算，而这正是形成项目计划的基础。
敏捷项目中的核心就是迭代,在一周至两周内选取客户最重要的故事，然后将其转化为可运行的、测试过的软件。团队成员通过测算团队速率来决定需要承担多少工作(每个迭代周期可以完成多少)。通过追踪速率并预测未来所能完成的任务量，你的计划就可以实事求是，从而避免团队夸下海口。如果你和客户面临的任务过多，那就先做唯一能做的事———少做一些。在范围方面要灵活处置，也就是要学会平衡计划，并将承诺变为现实。当现实与计划相悖时，就应该改变计划。适应性强的计划是敏捷交付的基石。敏捷计划也就以上这些了，我们将在第8章对其进行更深入的阐述。
如果牺牲不可避，你还是顺其自然吧。不过要确认牺牲物有所值，而不是因为你在一年前的业务评估中所做出的不切实际的承诺。
确实，人们会做出不切实际的承诺,也经常要求团队尽力而为。但这并不能解决问题。“靠奇迹去管理”这种假象如果一直持续下去，会成为一种糟糕的项目运行方法，而如果这个期望值是你和客户一起设定的，那就更糟糕了。有了敏捷，你就不需要这些奇迹了,因为从开始阶段就会与客户开诚布公地配合工作，对客户直言不讳,让他们自己做出范围、资金和数据方面的明智决策。这要看你的选择了。你可以欺骗自己，幻想着事情会有奇迹性的转机，要么你就与客户共同制定出双方都认可的计划。
“完成”的意思就是“完成”
假设你的爷爷奶奶雇用邻家小男孩去将草坪里的落叶打扫干净并装进袋子。当这个小孩完做了如下工作后，爷爷奶奶会认为他就把活干好了吗?
制作了一份如何打扫院子的计划报告。
做一份漂亮的设计。
制作了一份详尽、面面俱到的测试计划。
不可能！ 这个小孩要是不把树叶扫干净、装袋并且在屋后给叶子找个归宿的话，他一个子儿也得不到。在敏捷项目中，我们使用同样的定义。这时,交付一个特性就意味着要完成所有必需的任务才能生产出可交付的代码。
分析、设计、编码、测试和用户体验(UX)，东西都在这里了。这不是说必须要把首个版本特性搞得花里胡哨，也不是说要将最新版本的作品放在每个迭代的最后才可使用。但是我们的态度是：要做就得做好。如果作品还不能交付，那就是没有完成。
然后，你就能够集中清晰的思路去思考和创新了，而这正是我们行业最缺乏的。要牢记于心：方法不止一个!
就像不会存在终极口味的冰激凌一样，也不存在终极口味的敏捷。
你拥有了Scrum———项目管理包装器，用于管理敏捷项目。
你拥有了极限编程———有高度纪律性、核心的软件工程实践,这些对于每个敏捷工程来说都是不可或缺的。
你拥有了精益———从持续改进的丰田公司的“丰田生产系统”总结出的超高效率方法。
你还拥有了自己的敏捷方法,就像你和家人开车恨不得穿过了半个国家，到头来却发现计划游览的娱乐公园由于要翻新而关闭了，你只能随机应变。每个项目都是不同的，虽然一些原则和实践永远不会出错，但是具体应用仍然取决于特有的情况和环境。
本文节选自《敏捷武士︰看敏捷高手交付卓越软件》
