作者：ThoughtWorks中国著
出版社：信息技术第一出版分社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
软件开发践行录——ThoughtWorks中国区文集试读：
前言
关于本文集三年前因缘际会，我加入了ThoughtWorks中国公司。在这之前，参与线上和线下社区的我，已经认识了不少早期的TWer，而加入之后更是近水楼台，我跟他们在一个项目工作，听他们的分享，得以从更近距离学习和体会他们身上似乎与生俱来的价值观和对软件构建本身的独到认识。也是一直以“程序员中的编辑，编辑中的程序员”自诩的我，从一开头就认定，传播这群人的意识和经验对于我来说责无旁贷，而这样的贡献也权当是允许自己滥竽充数混迹其中的些许安慰。
这个群体最初聚集了一拨价值观鲜明、爱分享、在社区极具号召力、对软件构建有独特理解和洞察力的人。因为他们的热情、鼓励，甚至偏执和煽动性，在社区掀起了一阵阵潮流，而社区的反应则褒贬不一。但是我想，不该拒绝和否认的是，的确是他们在引领国内的技术和开发社区群体，积极地吸收国外先进的软件思想，对国内软件研发状况和质量多年停滞甚至倒退的状况进行反思。我甚至一度认为这群人这个组织，是国内社区和开发者关于软件构建方面的启蒙者。
需要有人记录这个时代和这个时代的人。我们很难现在就评价这拨人做的事情，这拨人的思想和所做的努力，对于国内软件开发境况的改善有怎样程度的影响，甚至在多年后依然会发现这是件很难的事情。但这些人这些事情的确存在过，他们的努力也一直存在着。关于本文集
本书适合的读者：
对软件构建过程进行持续思考和改进的人。
对技术新趋势持续拥有热情的人。
热衷于敏捷项目管理锻造优秀团队的人。关于本文集
从目录上你很容易看出这本文集分了四个部分：过程改进、工程实践、团队建设和体验设计。这也是遵循了ThoughtWorks全球文集的一贯体例。事实上，当你阅读其中某些文章的时候，你会对文章为什么会出现在这个分类下感到疑惑。
但请你相信，编者已经尽了最大的努力，希望把文章放在最适合的分类下，供读者查找和参考。这毕竟只是三十三篇文章，每一篇的标题都足以彰示内容和方向，所以请尽情享受文章的内容盛宴吧。关于本文集
感谢我的同事们，这一篇篇文章的作者，可以忍受我不停的威逼利诱和催稿，最后能交付高质量、足以流传的文章。虽然你们中相当一部分人已经离职，但见文如见人。
感谢我的市场部同事小菊和婷婷，你们为这本文集的出版设定流程和计划，帮助我从更多内容中遴选出这三十三篇入选文章，并和出版社反复斟酌合同，她们是让这本文集三年后得以面世的重要贡献者。
感谢人民邮电出版社的编辑陈冀康，继张松的《精益软件度量》之后，他继续为ThoughtWorks的软件思想在国内的传播贡献力量。
感谢InfoQ中文站的负责人霍泰稳，因为这本文集内的绝大多数文章，都曾经发表在InfoQ的中文网站上。谢谢泰稳予以优惠的回购价格，让这些文章具备了可以纸版发行的版权。第一篇 过程改进看板任务管理黄亮
作为一个开发团队的管理者，例如当你是一个团队的项目经理的时候，任务的完成情况通常是你最关心的内容之一，比如说分配的任务是否能够按时间完成，整个项目的进度是否尚在计划之中，团队内的人是不是都在高效地工作，大家有没有什么困难，等等。在软件开发团队中，任务的分配、跟踪和管理通常是这个团队管理者的一个重要的工作内容。
1．从问题谈起
我曾经碰到过一个项目经理，她管理一个团队开发一个Web应用，团队里开发人员大概10个，测试人员3个，业务分析师1个人。对于任务的管理她是这样做的。通常，她会将需求分析人员分析得到的需求给每个人分一些。然后每个人在领到任务之后会给她承诺一个大致的时间点。整个项目大致的交付计划用一个 Excel 表管理，根据客户要求的交付时间点，同时考虑到一些需求之间的集成测试关系，她定出了每个需求的大致交付时间点。只要每个开发人员承诺的时间点和期望的相差不大，她都可以接受，这样每个开发人员就知道自己应该在什么时间点交付什么东西。
一切本该很完美，但是不和谐的问题不断出现。最经常发生的事情就是大家在承诺的时间点到来的时候不能按时交付，每次她询问进度的时候，都会被告知还差一点就完成了。通常的说法是“底层部分已经做完了”或“还差页面部分就可以搞定了”，然而实际情况是又过了相当长的时间才真正完成。当然也有按时交付的需求，但是她发现也许是大家经常加班，已经开始疲倦了，有时候明明很简单的、可以提前完成的需求，大家还是到最后一刻才交给测试。
也有的开发人员拿到自己的那一批需求之后，会批量工作，把若干个类似需求的底层逻辑全部实现，然后再实现上层内容。她默认了这种做法，就像这位开发人员说的“这几个需求都差不多，只要底层做好了，基本上就都完成了”。虽然这部分工作早点和其他人一起集成测试会比较好，但是他这样做也只能推后集成测试的时间点了。还好她承诺给测试团队的交付时间点还在1个月之后，只要1个月之内能够完成这些需求就可以了。
项目执行过程中还有一些其他的问题，比如有的新人经常碰到问题，但是出了问题并不主动问其他人，而是在胡乱尝试中浪费了时间；还有个别开发人员非常激进，经常花时间去重构代码，追求完美的架构设计，进度很让人担忧。组内的开发人员还经常被其他项目的事情打扰，因为有几个人刚刚从之前一个项目中调过来，前一个项目的有些问题只有他们熟悉并有能力解决。她就不止一次发现有一个开发人员在修复其他项目的bug。
她会不定时地去询问每个开发人员的开发进度，当需求的计划交付时间点逼近的时候，这种检查会越来越频繁。开发人员感受到压力，有时候甚至需要加班来完成开发工作。尽管她花了很多精力去跟踪和检查每个需求的完成情况，还是有很多出乎意料的事情在不断发生。尽管她一直相信，只要开发人员能够完成任务，采用什么方式她都不干预，而具体的时间也是由他们自己分配的。但是她渐渐感觉到任务越来越不可控，计划通常无法按时完成，每天对大家的检查花费了大部分时间，然而却不能揭示出真正的问题。
运转良好的项目都差不多，而问题项目的问题各有各的不同。虽然每个团队的问题可能不完全相同，但是当我们审视这些项目的运作和管理方式的时候，不难发现一些诸如多任务并行等共性的问题，这些问题给软件项目带来了各种各样的浪费。当一个团队采用瀑布开发模式的时候，开发阶段全部结束之后测试人员才会介入，开展测试活动，在一个通常很漫长的开发阶段内，各种开发活动中的浪费、估计不准确以及成员自己的拖沓、被打扰、问题阻塞等，都被掩盖了。只要在最终时间点前能够全部开发完成，不管是前松后紧还是加班熬夜，都已经成了项目开发的常态。项目经理只能看到交付的最终时间点，问题不能及时地解决，而等到问题暴露的时候，可以使用的调整手段也非常有限。
这样的一种团队生存状态在外部环境要求短交付周期、需求允许经常变化的情况下显示出了极度的不适应。市场环境的变化驱动了软件需求的变化，这种变化催生了缩短交付周期的诉求，较短的交付周期使得人们不必去预期过于长远的需求，具备根据市场的变化快速地制定和调整软件需求的能力。而当交付模型由几个月的瀑布模型转变为数周甚至更短的迭代模型的时候，我们在前面谈到的团队中的各种浪费、低效、半成品堆积等问题，就会急剧地爆发出来。
熟悉敏捷方法的读者可能知道，敏捷方法包含一系列实践，来帮助团队实现短周期快速交付，更好地响应需求变化。比如说用户故事（User Story）方法将需求从用户价值的角度进行组织，避免将需求从功能模块角度划分。小粒度的用户故事可以在一两周的迭代内完成开发和测试（并行开发），从而可以缩短交付周期。问题是，在敏捷团队内，我们如何有效管理大量小粒度用户故事，同时避免上述项目管理中的问题呢？下面我们结合敏捷开发中的看板工具来看看敏捷团队是如何管理任务的。
2．可视化看板任务管理
看板源于精益生产实践，敏捷将其背后的可视化管理理念借鉴过来，经过一番改造，形成了有自己独特风格的可视化管理工具。曾有[1]人总结过scrum和kanban的使用，而很多时候，我们也将它叫作迭代状态墙。
我们先来看看怎样用这个状态墙来管理迭代任务。说起来其实是一个很简单的东西。
通常一个迭代的状态墙反映了某一个迭代的计划和任务进展情况。状态墙按照一个迭代内团队的典型开发活动分成几栏，例如“待开发”、“开发中”、“待测试”、“测试中”、“测试完成”等。在一个迭代之初，我们会将计划在本迭代完成的故事卡放到“待开发”这一栏中。可视化状态墙的一个好处就是所有团队成员都可以实时地了解本迭代的计划和进展情况。开发人员领取任务时，就将他领取的故事卡片从“待开发”移到“开发中”，同时贴上带有自己名字的小纸条。当他开发完成之后，就将故事卡片移到“待测试”一栏。测试人员看到“待测试”栏里有待测的故事卡，就取下一张，移动到“测试中”，然后开始这个用户故事的测试；测试完成后，就将故事卡移动到“测试完成”一栏。如果测试人员发现了一个 bug，那么他可以用红颜色的卡片记下这个bug，然后放到“待开发”这一栏中。状态墙上除了用户故事、bug 之外，还会有一些诸如重构、搭建测试环境这样的不直接产生业务价值的任务，这三类任务用不同颜色的卡片放到状态墙上统一管理。
这样一个简单的工具，是如何帮助我们消除浪费、解决项目管理中的问题的呢？让我们逐条分析一下看看。
2.1 如何减少返工带来的浪费
返工是软件开发过程中的一大严重浪费。比如说开发人员完成的任务交给测试人员测试的时候，关键流程不能走通，阻碍了测试进程；交付给客户的东西被客户说“这不是我想要的东西”；分析人员将还没分析透彻的任务交给开发人员，在最后验收的时候发现开发人员加入了自己的一些“发挥”。这些都会造成返工。返工意味着没有一次性将事情做对，意味着流程中的上游没有交付高质量的产品，也可能意味着团队成员间的沟通出了问题。
在传统的瀑布流程中，我们往往是期望通过前期细致入微的工作来确保一个阶段的工作被高质量完成之后才移交到下一阶段。后来我们慢慢从失败的经验中学习到，这种方法在变化的需求环境下实在是太脆弱，不仅不能如愿保证质量，而且会造成更大的浪费，交付周期[2]也不能满足要求。于是我们引入了迭代式开发方法，一个需求的分析、开发、测试、验收成了一个小粒度的更连续的过程，在这个小的交付循环中，看板帮助我们以更细节的粒度来管理一个任务每个阶段的工作质量。
通常我们是这么做的。当我们把一张故事卡从“待开发”移动到“开发中”时，这张卡片必须是已经分析完成的。也就是说，当开发人员准备真正开始开发这张故事卡之前，我们的需求分析师们必须保证这张卡片所包含的所有内容和细节都已经分析完成，不再有模棱两可的细节，不会留给开发人员过多的自我发挥和想象空间，而且这些细节必须和客户确认过，而不只是团队自己“设计”的结果。
这一道关看似很寻常，实际上很多项目会在这里出问题。很多时候开发人员开始开发的时候，需求还没有分析完成，很多细节尚须澄清确认，实现上的技术风险还没有被完全排除。也有的分析师善于给开发人员留有大量自我发挥空间，需求过于言简意赅。开发人员开始开发这样的需求时，要么做不下去，要么按照自己的理解做下去。做完后分析师发现不对，和想的不一样，于是开发人员返工。最糟糕的情形莫过于最后客户说这不是他当初想要的东西。
由此可见，开发人员挪卡的时候，确保这张待开发的用户故事已经被真正分析完成，是我们准确实现用户需求的第一步。通过规定这一挪卡的前提，同时辅以用户故事的澄清（由分析师向开发人员澄清）或者反向澄清（由开发人员向分析师讲述自己的理解），可以很大程度上减少返工。
还有一种浪费发生在测试过程中。测试人员经常会发现，处于“待测试”状态中的一些故事卡，在测试的时候主要的流程走不通，根本无法进一步展开测试，于是乎不得不将故事卡打回到开发人员手中。而往往这个时候开发人员已经在另一个用户故事上工作了。要么他需要停下手中的任务解决测试的问题，要么让测试人员等到这些问题修复过后再测。无论哪种都是不好的选择。
出现这种问题的一个主要原因是因为开发人员声称他已经“开发完成”，将故事卡从“开发中”挪到“待测试”时，实际上自己并没有对这部分功能进行测试，或者是因为疏忽，或者是因为懒惰，或者是因为过于自信。通过在这个状态转换阶段引入用户故事初验，分析师在挪卡之前先到开发人员机器上看看该故事卡包含的功能是否被实现了，可以很大程度上提升效率，减少浪费。如果分析师在初验过程中发现了问题，那么开发人员马上能以最小的成本进行修复，而不用等到之后测试人员发现时再来修复。而且，分析师初验也提供了一个判断实现是否良好的反馈点，这是我们能够看到一个需求是否被实现并能够真正工作的最早的时间点。
2.2 如何避免多任务并行
多任务之间的频繁切换是一个常见的问题。表现在团队里的成员身上，特别是开发人员，多为会在不同的任务间切换。就像前面的故事中提到的，开发人员可能这一刻还在实现某一个需求，而下一刻可能就会被叫走去修复某一个遗留版本的缺陷；又或者该开发人员手头被分配了多个任务，每个任务都在进行中，而没有一个处于完成状态。[3]任务切换是导致效率降低的一个重要原因。不同任务间的上下文的切换会导致将任务当前状态频繁地在头脑中“压栈”和“出栈”，这些操作会耗费时间。如果完成一个任务一个人需要一天时间，那么两天内这个人可以完成两个任务；但是如果他在第一天开始在这两个任务上并行工作，那么完成这两个任务会需要大于两天的时间。
大家可能已经注意到了，在前面的看板图中，处于“开发中”的所有任务卡片上都有一个小纸条，上面标记着正在这张卡片上工作的人的名字。如果说有两个人结对在一个卡片上工作，那么这张卡片上应该有两个名字。这个小小的实践可以帮助我们随时发现团队内某一时刻，每个人是否只在一个任务上工作。
如果这一简单的规则能够严格被遵循，那么当我们看到一个人的名字出现在多张卡片上的时候，我们就知道这个人此刻可能忙着在多个任务之间切换，而每一个任务都可能不会在估计的时间点内完成。如果我们看到有人的名字没有出现在任何卡片上，那么他目前大概处于休息状态。团队内的每个人的名字都应该对应在一个小纸条上，如果你此刻在某个任务上工作，那么就将自己的名字贴到相应卡片上，如果此刻在该任务上没有工作，就将自己的名字移去。
我们在领取“待开发”状态栏中的卡片时，应该保证每次每人只领一张卡片，不要多领，完成了这张卡片之后，再回来领下一张。当一张卡片被认领之后，我们就会对这张卡片进行跟踪，在站会上谈论它的完成情况，谈论实现过程中碰到的问题。当它的进度和估计的可能进度偏差较大时，我们能够及时察觉而不是在最后一刻才发现，这样可以提供需要的帮助，确保它能够顺利完成。这样一种方式让我们能够将注意力集中到小粒度的需求（例如用户故事）上，来更多地关注这些用户故事的流动速度。而当每个小的用户故事能够顺畅地流动起来时，整个项目的交付也就得到了保障。
当然这一实践并不能自动保证团队内不再出现多任务并发、拖延或者做和任务无关的其它事情等问题。可能有些人在做一个用户故事的过程中，突然中断去做了一些其他事情，但是却没有及时在状态墙上更新自己的状态。重要的是团队要有实现交付目标的共同愿景，能够透明地暴露问题，而且善于利用状态墙来发现和改进自身的问题。对于不成熟的团队，这可能需要一个转变的周期。
如果一个团队的职责共享较好，所有人集体拥有代码，鼓励每个人在代码的不同部分熟悉和工作，那么在这样的团队内就不容易出现把一大块任务事先就明确给某一个人的情况。相反，所有人的工作事先不具体确定，大家会更容易形成某一时刻只领取一张卡片的习惯，避免同时在多个任务上工作。实际上，状态墙的使用也可以帮助团队走向职责共享之路，只需要在领取任务的时候有意地给人们分配一些之前没做过的内容，同时安排好有经验的人与其结对工作，一段时间之后，团队内的人便会逐渐体会到和之前只是专注在一个模块内不同的工作方式。
2.3 如何减少半成品库存，缩短交付周期[4]
一个需求的交付周期（lead time）是从它被识别到最终交付给用户手中所耗费的时间。交付周期越短，意味着客户从提出想法到能够在软件中实际使用的时间越短。从客户的角度来看，更短的交付周期意味着自己的软件能够对市场变化更快地响应，因而获得更强的竞争力，同时也意味着能够更快地验证自己的想法。
任务管理的粒度太大会直接导致交付周期变长。最极端的情况是将属于某一模块的任务在一开始就全部交给负责这个模块的人，所有这个模块相关的修改都由他来实现。在一个按模块划分职责、每个人只负责自己具体模块的团队里，通常这个模块的负责人会实现这个模块的所有修改；不然，就是将一个可能需要做两周到一个月的任务分给某个人；或者更好一点的情况是，单个任务本身不大，但是会将相关联的任务成批地分配给某个人。如果你的团队内也是采用大篇的“规格说明书”等Word文档来组织需求的，那么要小心，这种问题很可能在团队内已经存在。整个团队没有小粒度频繁交付的概念，习惯了大批量长时间地交付方式，因为批量大，所以估计常常不准，而且时间跨度长，中间也会有更多地干扰因素出现，这些都导致任务不能在开始承诺的时间点交付。开发周期长同样导致测试活动的滞后，极端地滞后就演变为所有开发工作完成之后才能进行测试，这就是我们熟悉的瀑布模式。最终的影响就是需求的交付周期会很长。
传统团队的一个常见组织方式是按照功能模块划分团队成员，明确分离职责，这也会变相增长交付周期。这样的团队通常倾向于按照功能模块来组织半成品任务，而不是按照可以交付价值的完成品来组织任务。习惯按照功能模块来组织开发的团队通常会阶段性地“联调”，不同模块的人带着自己的代码合在一起调试，由于缺乏频繁地集成，这种联调活动的时间经常不可控。团队在大部分时间内通常只拥有一大堆半成品，后续的测试和验收活动都没有办法进行，而只能等到团队在某一刻组装出一个完整的功能后才能测试，所以交付周期也会比较长。
因此，如果我们的需求都是按照软件的功能模块划分，而不是按照面向用户的价值来划分的，那么我们在交付用户价值这一目标上，一开始就走错了路。采用用户故事能够把需求以用户能够理解的价值组织起来，这一点是我们缩短交付周期的一个重要基础。
我们的状态墙能够揭示需求的交付周期。让我们来看看这样几个场景。
如果我们的需求是按照软件的功能模块划分的，那么通常单个模块的编码完成不可测。例如有的团队喜欢将 Web 应用的上层页面部分和下层数据库逻辑部分划分到不同的模块组，一个用户的需求也会拦腰切成两截，一部分交给上层团队完成，一部分交给下层团队。这样，即使单个团队的任务完成也不能开展这个需求的测试，于是这些任务就会堆积在“待测试”这一栏。
如果我们的需求很大，以至于开发人员要花费很长的时间（超过 1 周）才能完成开发，那么这个需求会在“开发中”这一栏停留很久。大家可以猜到，当一个人同时进行多个任务时，这些任务也会比它们被单个依次开发时在“开发中”这一栏停留更久的时间。
任何一栏中的任务其实都是半成品，只有完成测试、交付到用户手中的需求才是完成品。状态墙上的每一栏都好比一个存放着各种零件的仓库，每一栏中的卡片越多，停留得越久，就说明当前半成品的库存越多，是该得到团队认真关注的时候了。状态墙将每个阶段的半成品数量可视化呈现出来，让虚拟的数量通过卡片这种物理介质的数量得以呈现。
通过状态墙，我们可以计算出每一个需求的交付周期大概是多久。状态墙上一个用户故事从放到“待开发”这一栏，到它被移动到“完成”这一栏，这一个时间段是需求的整个交付周期的其中一段，也是很重要的一段。通过优化从“待开发”到“完成”的这一个过程，我们可以缩短需求的交付周期。通过比较需求的交付周期和客户对交付周期的要求，我们可以量化之间的差距，然后指导我们进行改进。
在理解了状态墙是如何呈现一个需求的交付周期后，我们就不难理解瀑布方法是如何让交付周期变长的。在瀑布模型中，全部开发工作完成之后才会进行测试工作，相当于所有的任务卡片都堆积到“待测试”状态之后，才开始逐一测试。所有开发完成的半成品，都会留存在“待测试”这一仓库中，一直等到所有开发活动结束的那一刻。
出现库存堆积的时候，就是我们需要改进的时候。如果“待测试”这一栏有太多的任务卡片，那么就说明我们的测试活动没有跟上，有可能是我们的测试环境出了问题，或者是我们的测试人员人力不足。如果太多的卡片位于“测试完成”状态，说明我们的发布和最终交付过程出了某些问题。如果“待开发”这一栏中任务过多，说明我们的计划有可能超出了当前团队的开发能力，或者说反映了开发人员的不足。还有一种情况是“待开发”这一栏空了很久，这可能说明了另外一个问题，那就是我们的分析师的分析速度匹配不上团队的开发能力。一个良好的团队，必然是各种角色协调配合，并行工作，同时他们之间的任务衔接也能够比较流畅。
2.4 迭代产能的度量、计划及其他
团队在每个迭代所能完成的工作量，通常被称为迭代的速度（velocity），是衡量团队每个迭代产能的一个指标。这个指标能够帮助团队制定迭代计划。根据团队估计任务工作量的方法不同，迭代的velocity的单位也可能不同（例如故事点数）。通常，我们只需要在迭代结束的时候，数一数状态墙上完成的任务工作量就可以了。
当我们经历了若干个迭代以后，通常团队的迭代速度会趋于稳定，我们在做下一个迭代计划的时候，会参考以往迭代的数据。如果上一个迭代完成了15个点，那么下一个迭代我们通常也会计划15个点左右的工作量，将这些卡片放到“待开发”这一栏中。也就是说，每个迭代结束时，我们都会对状态墙进行更新，将即将到来的迭代的卡片放到墙上，而且将一些处于半成品状态的卡片进行适当的调整。
前面提到，状态墙上可能有三种卡片，除了需求，还可能有 bug 和技术任务。测试人员每次在迭代中测出一个bug，就会将bug 写成卡片，放到“待开发”这一栏。当bug不多的时候，团队可以在不太影响原有计划的情况下消化掉这些 bug，确保软件的质量持续地得到保证；如果bug太多，则需要做一些计划，将bug分散到几个迭代里去消化。然而到这个时候，团队可能更需要及时反省一下出现这么多bug的原因了。
另一类技术任务也需要和 bug 以及需求卡片一起被考虑到迭代计划中去。通常技术任务包括诸如搭建持续集成环境、准备测试环境、重构这样的任务。它们虽然不直接给用户带来价值，但是却是保证软件质量、确保团队效率的重要因素。比如重构类的任务，对于工作在遗留系统上的团队来说可能是需要一直考虑的事情，为了保障新需求的顺利实现，可能需要有计划地重构之前的一些遗留代码。
bug 和技术任务耗费团队成员的时间资源，但是不直接产生用户价值。如果我们衡量团队每个迭代的总体生产能力，需要在计算迭代速度时考虑这三类任务；但是如果我们只考察团队每个迭代交付的用户价值的量的大小，那么就不应该包含技术任务和 bug。当一个团队在迭代中花了过多的时间在技术任务或者修复 bug 上，那么这个团队就需要反省一下其中的原因，是不是团队的基础设施太差，或者是团队在开发时过于粗心导致太多的 bug，抑或是其他的一些原因。
3．总结
本文中我们从项目管理中常常出现的一些问题着手，分析了其中的一些原因，然后介绍了如何采用状态墙（看板）来可视化任务管理。在敏捷项目中，状态墙作为一种有效的迭代任务管理工具，已经被广泛地使用。团队利用状态墙这样一种简单的工具，将迭代开发中的日常工作透明实时地跟踪管理起来，能够帮助团队及时发现问题，消除浪费，快速地交付用户体现价值。希望这些文字，能够为渴望尝试敏捷、改善任务管理和日常运作的团队带来一些帮助。实战：持续交付中的业务分析夏洁
在需要频繁交付、不断收集用户反馈、拥抱变化、追求业务敏捷的项目中，软件的开发和交付是迭代式进行的。在这样的项目团队中，业务分析师（BA）通常需要在一个开发迭代开始之前完成该迭代开发任务的分析。但在特殊情况下，从收集客户需求到将功能细节传达给开发团队的周期会缩短到一至两天。BA可以用于思考和分析的时间远远少于可以预先做出所有设计的瀑布式项目。
那么在这样的敏捷项目中，BA如何能够适应这种交付模式、完成高质量的业务分析、协同团队为客户交付高价值的软件呢？
项目背景
ABC公司是一家知名的国际性会计师事务所，业务规模庞大，分支机构遍布全球170多个国家。
ThoughtWorks 受邀对公司“全球派遣服务（International Assignment Service）”业务部门提供IT解决方案以及软件系统的开发服务。该系统包括收集公司客户的全球派遣雇员的报税数据，同时管理ABC公司税务咨询师对这些数据进行审核、汇算和出具报告的业务流程；逐步替换它目前远远不能满足业务和性能需求的遗留系统。
该系统主要有两类用户，一类是ABC公司客户方被派往不同国家工作的雇员（以下简称Mary），这些雇员使用该系统填入报税需要的数据；另一类用户是ABC公司的税务咨询师（以下简称Kim），负责审核、处理Mary提交的数据。
BA在该项目中面临的主要挑战
• 该项目为分布式开发，ABC 公司的决策方在美国，而ThoughtWorks 的开发团队在中国，沟通反馈周期有时较长。
• 由于 ABC 公司对用户体验的重视，开发团队需要频繁交付软件，以便收集用户反馈并及时调整解决方案和后续开发计划。这大大缩短了从收集需求、开始分析到进入开发的周期，增加了分析中出现缺陷的风险。
• 当开发过程中发现问题时，开发团队无法马上与客户取得沟通，开发进度可能会受到影响。
识别业务价值
业务分析的重要性在于首先做正确的事情。理解客户的业务，关注需求背后的价值可以帮助项目团队在软件的设计方面做出正确的选择。
而我们面临的困难是，客户提出的需求往往都是直接的软件功能，而不是需要解决的业务问题。如果 BA 只专注于针对客户需要的功能进行系统分析，就丧失了帮助客户优化解决方案以及改进业务流程的机会。
如何寻找业务价值？
以敏捷开发方法中的用户故事为例，找出客户要解决的业务问题的一个简单办法是，用以下方式概括每个用户故事的内容。
As…（角色），I want to…（完成什么样的功能），So that…（解决什么问题，带来什么价值）。“So that…”说明了该故事的业务价值，即要解决的业务问题。准确地寻找业务价值将有利于我们设计出最适合的“I want to”，这很可能优于客户直接提出的功能要求。
需要注意的是，不要把解决方案或功能当成该用户故事的价值。以ABC公司业务系统中的一个用户故事为例，BA 对该需求业务价值的了解程度将直接影响到解决方案的优劣。
在该用户故事的两种不同表述中，由于第一种表述只说明了需要的功能，没有说明业务价值，在功能设计时，我们可能会将“行程统计数据”的内容设计得过于详细而造成浪费，使用户不明白此功能的意图；而第二种表述的业务目标就非常明确，可以帮助我们更加容易地设计出适合的解决方案。
此外，BA 在了解客户的业务问题时，最好请客户提供一些真实案例/场景来证实其观点并加深自己的理解。
避免分析错误
在实际工作中，我们发现 BA 容易忽略以下两个方面的分析工作，从而做出错误的决定。
1．客户要求实现某些现有业务流程或遗留系统的功能
例如，客户需求的功能，是当前遗留系统中已经使用多年并且未收到过任何抱怨的功能。因此客户和 BA 往往认为这个功能是合理的，忽略了深入的分析和思考。但是这种思考不全面而做出的决定可能会与可以预见的新功能产生冲突。
在ABC公司的遗留系统中，用来收集报税数据的问卷内容是通过Excel表来维护的，而Mary在前台也是通过下载Excel问卷，填写完毕后再上传。
在新开发的系统中，问卷被改为在线方式，同时辅助以其他必要功能提升Mary的用户体验和满意度。因为客户方的员工都是财务背景出身，非常喜欢使用Excel表，而之前用Excel表维护问卷内容也被证明是非常有效的，所以客户坚持在新系统中延用这种方式。经过仔细地分析，我们发现在针对提高Mary用户体验的新功能上线后，使用Excel表维护问卷内容将大大增加维护的工作量并且提高错误率，而这与项目的相关目标背道而驰。ThoughtWorks在列举了问题的细节后，说服客户采用了新的解决方案。
2．客户要求利用新的IT系统改变当前的业务流程
客户发现目前的业务流程有不合理的地方，希望在新的IT系统里直接改变这些流程。如果不经过仔细的分析，这种做法可能会很危险，业务流程的盲目改变可能会给一部分用户造成麻烦，为客户实施该软件形成强大阻力。那么了解清楚目前这些流程存在的价值和原因事关重要，从而可以帮助我们为客户提供科学的、逐步优化其流程的IT解决方案。
在ABC公司的业务流程中，Kim和Mary之间的一些交流是通过邮件来完成的。这里存在两个业务风险：第一，Kim和Mary交流的重要信息被散落在各自的邮件里，系统无法记录，在遇到法律问题时，难以划分责任；第二，Kim和Mary可能会使用邮件发送一些保密性较强的内容，如果发错，后果不堪设想。
在开发新系统时，客户要求我们增加了一个消息功能，使Kim和Mary之间的交流可以方便地在系统内部完成。该功能上线后，很好地化解了这两个业务风险，同时收到了Mary这类用户的良好反馈。然而这却给该会计师事务所在某些国家分支机构里的 Kim 这类用户的工作带来了不小的影响。由于之前使用邮件系统，Kim可以将Mary的邮件转发给相关的同事并利用邮件丰富的功能进行结果的跟踪；而新上线的消息功能达不到邮件的所有要求，所以增加了他们的工作难度。此外，由于Mary对这个功能的青睐，发送消息的数量远远超过了在使用遗留系统时发送邮件的数量，超出了客户想提高Mary的满意度而在短期内所能承受的代价。
在遇到以上问题时，我们与客户一同分析，提出了折中的解决方案，付出了较少的代价将消息系统和客户的邮件进行集成，同时帮助客户制定了对此项业务流程改进和配套IT解决方案的蓝图。
理清需求优先级
在频繁上线的项目中，其中一个重要的实践是确定需求的优先级，使得重要的功能能够先得以开发出来投入使用，以便及时收集用户反馈。一般的做法是要求客户排好需求优先级，然后与项目相关成员一同制订迭代开发和上线计划。但是由于客户决策方所处角色以及思维角度的局限性，对优先级的评定可能存在盲目性。建议BA参照以下价值维度帮助客户对优先级进行评定。
从客户价值维度分析需求优先级
需求价值维度分析图如下所示。
技术风险对优先级的影响
除了来自客户方面的决定因素，我们还应该考虑技术实现方面的影响。如果一些技术风险较高的功能可以先进入开发阶段，那么问题会尽早地暴露出来。开发人员在项目早期解决这些问题会有利于开发成本的节约。所以除以上客户价值维度外，我们应该再参考以下矩阵来权衡需求的优先级。
1．需求优先级矩阵
客户价值维度和需求优先级矩阵并不是优先级高低的计算器，而是与客户以及团队沟通交流的工具。不同项目的影响维度也会有所不同。由于各项因素的复杂性，客户价值维度和技术风险因素需要综合考虑，不可以用权重来计算。BA可以与客户对以上因素的内容达成一致，使得客户在评定需求优先级时可以快速、准确地做出判断。同时，通过对价值维度的分析，我们将有机会清晰地了解到功能优先级高或低的原因，以便我们能够准确地编制上线计划和项目开发，而且合理地划分用户故事范围。
2．借助价值维度分析管理客户期望值
有些客户的决策人可能会依据自己的喜好划分优先级，这对项目能够按目标成功交付造成一定的风险。此外，客户在功能的设计和验收阶段也容易对单个功能追求完美，产生额外工作量，增加项目范围。而这部分额外工作可能并不合理或者价值较低。长期如此，团队在开发过程中将逐渐偏离项目目标。如果能借助优先级维度对这些额外需求进行分析，则可以提供更有说服力的依据，帮助客户做出正确决定，达成 BA 和项目经理对客户期望值的有效管理，从而降低交付风险。
发挥团队其他成员在业务分析中的作用
在频繁交付的项目中，如果BA独自承担业务分析工作，难免会出现疏漏。ThoughtWorks曾与ABC公司的IT部门合作完成其业务系统的一些集成工作。在合作过程中发现，ABC公司IT部门的开发人员在业务分析中参与度很低，由此造成了如下问题。（1）BA需要写大量需求文档，所以从需求分析到软件交付的周期较长。（2）设计缺陷的发现滞后。（3）在需要频繁交付的情况下，解决方案质量较差，方案优化能力较弱。
而ThoughtWorks的开发人员在业务分析中的参与度较高，因此有效地避免了以上问题。
开发人员如何参与分析
开发人员是软件功能的实现人员，对方案的实现工作量有较准确的估计。在明确项目目标或业务问题后，BA如果能够和开发人员一同分析解决方案，将会更有效地为客户找到兼顾成本和效果的方案。
在收集到客户需求后，BA可根据业务价值对需求进行分析，判断客户提出的功能或解决方案是否能很好地满足该业务价值或要解决的业务问题；或者按照自己的理解设计出满足该业务价值的功能实现或解决方案。
完成上述工作之后，BA应与开发人员就需求和业务价值进行充分沟通，验证功能实现的可行性，同时积极探寻更优方法。如果开发人员提出符合业务价值的不同方案，BA则可以要求开发人员提供一些关于开发工作量、方案优劣、技术风险方面的比较数据，从而帮助自己有效地与客户沟通并挑选最佳方案，甚至可以根据分析结果帮助客户调整该需求的优先级。对于技术难度和风险较高的功能点，建议邀请资深开发人员参与讨论。
与开发人员沟通中遇到的挑战与解决方法
由于上述方法需要与开发人员大量沟通，有些BA在应用以上实践时也遇到了以下挑战。
1．开发人员缺少参与业务分析的热情
在ThoughtWorks，大多数开发人员都喜欢积极思考、主动为业务分析提供帮助，大大减少了需求分析上的漏洞。然而在ABC公司的IT部门中，开发人员很少主动为业务分析出谋划策，尤其是团队中资历较浅的成员，甚至不愿意参与解决方案的讨论。团队成员的优势没有得到充分发挥，开发人员只管按需求埋头苦干，结果功能和解决方案中的问题往往在测试或者验收阶段才暴露出来，不可避免地造成了浪费。
站在开发人员成长的角度，从ThoughtWorks实践来看，积极地理解业务、思考解决方案能够更快地提高技术能力。因此 BA 可以找出一些实际案例，协同项目经理与团队各成员进行沟通，鼓励大家积极参与业务分析，逐步形成开发人员与BA协作的良好氛围。
2．开发人员容易就客户需求或解决方案产生争论
开发人员在积极参于分析的过程中，有时会对软件功能的价值吹毛求疵，在细节上与BA产生较多争论，使BA在应付开发人员的问题以及与客户求证答案之间疲于奔命。
解决此类问题，BA可采取以下方法。
• BA 在收集需求时，尽可能充分地了解客户要解决的业务问题，以便能够快速回答开发人员的问题。
• 面对开发人员对解决方案的质疑时，应保持良好的心态，清楚地了解开发人员顾虑的问题和原因。
• 如果自己掌握的信息确实不能证明现行方案的合理性时，协同开发人员，找到更优方案并与现行方案进行优缺点比较。
• 将新旧方案与客户沟通，则可快速帮助客户做出判断。
不要忽略测试人员在业务分析中的贡献
由于测试人员所处角度和对细节的关注，他们往往可以发现一些功能细节的设计漏洞。所以在用户故事进入开发前，BA与质量保证人员对相关业务价值进行充分沟通，可以在功能进入开发之前为BA创造更正某些设计缺陷的机会。
作为质量保证人员，如果充分了解功能背后的业务价值，对比于只了解功能需求，将可以写出更加完善的测试用例，提高测试覆盖率。这会为交付高质量的软件把好最后一道关。
结语
业务分析是困难的，特别是当我们面对未知领域的时候。如果只是简单地按照客户的具体需求进行软件开发，那么我们交付给客户的产品价值将非常有限。然而识别业务价值、帮助客户分析需求优先级、保障团队协作，将有效提升团队的软件设计能力，解决客户真正的业务问题，实现更大价值。
作为一名业务分析人员，当您在尝试以上实践时，可能会发现自己对客户业务的理解变得更加深刻。在与客户的沟通中，也能够更加容易地提出有价值的问题以及建议，从而提升客户对项目团队的信任，为成功交付项目打下良好基础。
*注：“客户价值维度”的概念由ThoughtWorks咨询师李光磊提出，在此对李光磊表示感谢。建设DevOps能力，实现业务敏捷熊节
当软件行业进入互联网时代，市场对软件产品和服务的交付提出了更高的要求：不仅要快速实现需求，而且要快速发布上线，同时必须保证业务可靠、高效运行。为了满足这些要求，IT组织需要强有力的流程、技术和人员作为保障。
ThoughtWorks 很早就认识到发布与运营对于成功交付的重要性。我们的创始人 RoySingham在《走完业务软件的“最后一公里”》[5]一文中提出以下观点。
所谓[软件开发的]“最后一公里”，是指软件满足了功能需求之后，尚未投入实际运行并创造业务价值的阶段。软件开发者──尤其是面对交付压力的软件开发者──常常对“最后一公里”视而不见。但它确实正在成为业务软件交付中最大的压力点。
本文将分析大型软件组织在软件发布与运营维护阶段常见的典型问题并介绍一种行之有效的解决对策。
问题
众多大型软件组织在软件的发布、运营和维护过程中体会到以下两方面的压力。
快速响应
传统观念中规模庞大、发布周期长达数月乃至数年的软件产品研发方式正在发生变化。在“快鱼吃慢鱼”的互联网时代，上市时间（Time To Market）成为衡量软件组织能力的重要因素：能快速接纳需求、快速完成开发、快速上线投入使用的软件产品，才能有效占领市场、吸引用户。
在以迭代式开发为特征的敏捷开发方法和以Ruby on Rails为代表的一批高效开发工具帮助下，很多软件组织在实现功能性需求方面的能力得到了显着提升。然而从业务负责人的角度来说，仅仅提升开发阶段的效率还不足以实现端到端的快速响应。很多软件组织虽然以迭代方式进行开发，但发布和部署仍然按照从前的节奏，每隔几个月才进行一次。这时从客户与最终用户的视角看来，这些软件组织的交付仍然是以瀑布方式进行：客户与最终用户并没有直接感知到开发能力提升所带来的利益（如图1所示）。
不能有效缩短部署上线的周期，就无法真正实现快速响应业务需求、快速实现业务价值。如何缩短发布和运维工作的周期，已经成为困扰很多软件组织领导者的问题。[6]图1 迭代式开发+瀑布式发布
大型软件组织通常都很重视产品质量，而且在开发/测试阶段投入大量成本与精力进行质量保障活动。但软件产品的质量问题不仅是在开发阶段引入，靠传统意义上的测试工作也不能完全发现。有相当比例的质量问题是在开发/测试阶段之后引入或发现的。造成这一现象的原因有以下几点。
• 开发人员对生产环境缺乏了解，在代码中引入了只有在生产环境才会暴露的缺陷。
• 开发人员对非功能性需求缺乏关注并且没有相应验证环境，导致非功能性缺陷。
• 生产环境和测试环境缺乏有效管理，因为环境差异引入缺陷。
• 部署和维护工作缺乏自动化，在发布过程中手工操作引入缺陷。
• 缺乏针对生产环境的回归测试，导致缺陷不能及时被发现。
通过引入自动化测试、测试驱动开发、持续集成等敏捷实践，开发/测试阶段的质量保障活动能够得到有效改善。然而对于客户和最终用户来说，不论哪个环节引入的缺陷都同样会给业务造成损失。如何在部署上线的紧迫压力下保证质量，这也是众多软件组织领导者关注的一个问题。
敏捷拉通的尝试
一些软件组织意识到这些问题的存在，希望以敏捷开发方法为出发点，将下游的发布、部署、运维等工作环节拉通，从而提升整体响应能力。但是由于软件开发与运营之间存在一些固有的差异，这样的拉通活动往往困难重重。
• 开发团队与运营团队的关注点不同。开发团队重视以功能性需求实现业务价值；运营团队重视以非功能性需求（稳定性、性能、安全性等）实现业务价值。
• 开发团队与运营团队的技能结构不同。开发人员通常缺乏服务器管理的技能，运营人员通常缺乏软件编程的技能。
• 开发团队与运营团队日常使用的工具不同。针对开发阶段引入的配置管理、IDE、测试工具等很少为运营团队所使用。
• 开发团队与运营团队日常工作的环境不同。开发人员通常在公司内的桌面电脑上工作，运营人员经常在客户现场、在服务器上工作。
• 开发团队与运营团队通常属于不同的部门。
由于存在这些固有的差异，单纯从开发团队的角度出发、将敏捷软件开发的实践推广到运营团队，很难有效帮助运营团队改善；需要从运营维护工作本身的特点出发，引入符合客观情况的流程、技术和工具，才能有效改善运营维护工作的质量和效率。
对策
针对现代大型软件组织在软件发布、运营与维护过程中面临的种[7]种挑战，ThoughtWorks建议在软件组织中建设DevOps能力，从而提升整个组织的IT融合程度，改善软件交付“最后一公里”的质量和效率，为实现业务敏捷打好基础。
DevOps是一组流程、技术与工具的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。“DevOps”这个名称即是指开发（Dev）与运营（Op）的无缝融合。具备 DevOps 能力的组织能够开展快速、反应灵敏同时又稳定可靠的业务运维，使其能够与开发过程的创新保持同步，从而使得敏捷开发的优势在组织层面上
试读结束[说明：试读内容隐藏了图片]