详情
本书是ThoughtWorks中国区文集，是ThoughtWorks公司针对软件的思想和方法的精华体现，是公司在软件开发方面多年的践行和实践总结。全书包括了ThoughtWorks中国的咨询师和开发人员所写的33篇精华文章。分为工程技术、过程管理、交互体验、敏捷实践和团队建设5个主题和方向。
书名：软件开发践行录——ThoughtWorks中国区文集
ISBN：978-7-115-35881-3
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 ThoughtWorks中国
责任编辑 陈冀康
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
ThoughtWorks是一家全球软件设计与定制领袖企业。ThoughtWorks首席科学家Martin Fowler先生是当今世界软件开发领域最具影响力的几位大师之一。在中国，ThoughtWorks已经成立了北京、西安、成都、上海、武汉五个分公司，聚集了大量高水准的软件专业人才，为各类企业、政府部门和非营利组织提供全球品质的专业服务。
本书是ThoughtWorks中国区软件技术人员的文章合集，挑选和收录了包括胡凯、熊节、徐昊、郑晔、张逸等人的33篇精彩文章，涵盖了过程改进、工程实践、团队建设和体验设计4大领域。这些曾经以各种形式在网络、报刊、社区发表或分享，有些文章还曾引起积极的反馈和热烈的反响。本书可以说是一群极有天分的软件精英的思想和观点的汇聚，是他们多年的宝贵实践经验的凝结。
本书适合软件行业的各类从业人员阅读和参考。对于想要对软件构建过程进行持续思考和改进的人，本书具有启迪思想和激发灵感的作用。软件开发人员可以通过阅读本书，吸收作者们在工程实践中的宝贵经验；项目经理则可以窥得团队建设和管理的奥秘。
在ThoughtWorks中国公司成立十年之际，人民邮电出版社汇编了公司中国区员工最近几年发表的文章，推出了这本文集，算是ThoughtWorks中国区厚积薄发之作。
在中国的软件社区，ThoughtWorks一直顶着敏捷开发方法的领先者形象，并由于给不少知名企业做过咨询而为业界所了解。在跟社区朋友聊天的时候，我发现不少人都不知道其实这家公司其实只有不到10%的人在做咨询，而其他大多数人都工作在各类软件开发项目上。
ThoughtWorks服务的客户中有规模巨大的金融、电信、物流企业，也有快节奏的互联网公司，还有资源严重受限的NGO公益组织。ThoughtWorks的团队在产品开发生命周期各个环节，从概念、思路的产生，到用户体验设计，开发实现，再到生产环境的上线，甚至是直到产品、服务的推向市场，都常常承担着关键的职责。客户和产品的多样化，以及全生命周期的参与，使得团队有机会接触不同类型的系统，面对不同类型的约束和挑战，从而获得难得的阅历和视野。
这本书的作者都是我身边的同事，他们撰写文章，活跃在社区行业会议的讲坛上，通过分享各自在实战经历当中积累，致力于为社区和行业产生正面的影响力，并赢得了尊敬。我非常荣幸能与这样一群人一起工作。
本书涉及内容非常广泛，包括从用户体验到开发、测试和运维、从技术到管理等诸多方面的点点滴滴，虽然不见得非常系统和全面，但都是来源于一线。读者既可以选读感兴趣的章节，也可通读全书，一览ThoughtWorks团队的实际开发全貌。
《精益软件度量》作者
ThoughtWorks中国公司总经理
张 松
很难形容当我看到这一篇篇实践经验时的感受。不光因为这些文章中所描述的经验也有我参与讨论的共鸣，我更是被这不停探索技术卓越的状态所感动。
回想2001年我在《程序员》杂志看到那一页描述极限编程的文章，震撼之后我深深相信这就是软件的未来。你可以想象一下连讲J2EE的书籍都充满错误的年代，找到关于敏捷软件开发的资料是多么困难的一件事情。在实际工作中，这些书籍更是缺乏最后一公里的力量。为了更加拉近信念与现实的距离，我加入了ThoughtWorks中国公司。在交付与咨询之余我们不停思考、不停质疑、不停总结。所以在你面前的这本书充满了最后一公里的力量，虽然有些内容在文字和理论方面略显单薄，但我相信你在阅读本书之后会更有信心地面对日常软件开发过程，也会再次注入更多的软件热情到你的身体之中。
过程改进部分，你可以理解以过程为形式的改进，所以重音应该在“改进”之上。
看板任务管理：看板方法已经成为企业渐进式变革的一套方法论，其核心观点是把管理职责交还给知识工作者本身通过可视化的方法实现渐进式的管理。对于看板理论我非常留意我们说的是Kanban还是kanban（大写K哦），可以说文章更多地触及kanban落地的一些具体实践，并详细说明背后意图。
实战：持续交付中的业务分析：虽然业务分析的套路现在已经被“精益创业”，“商业模式画布”，“设计思维”等高大上的词语或概念所占据，但如果仅仅回到价值交付而言，看完这篇文章你会有一些基本思路来面对眼前的问题并引发更多的思考。
建设 DevOps 能力，实现业务敏捷：我认为熊节这篇文章是一篇非常好的宣传性文章，整体思路清晰，我看完之后有想动手实践的冲动。如果读者你也和我一样，建议你先拿文中的几个工具开始试验一下，我相信你的收获会更多。
自我成长时考虑精益的方式：熊子川这篇文章是精益画布的一个精简版本，看完之后我在思考我们是否需要商业画布上的这么多的部分，还是用这个精简的版本确定思路之后就着手制作第一个短裤版本的软件扔向市场。我个人感觉很多情况之下第二个选择就已经足够。
运用系统思考，走上改善之路：这篇文章非常切“改进”这个题目，强烈推荐。
分布式开发：敏捷的实践对于本地团队基本上是有一些最佳实践的，但是如何在分布团队也能实现敏捷呢？看看ThoughtWorks中国的经验吧。
精益创业和敏捷：两个都是大词，虽然当今的敏捷已经包罗万象，但如果给敏捷一个小一些的帽子并思考与精益之间的关系还是非常有必要的。
我和敏捷团队的五个约定：短短文章包含了很多内容，我个人觉得覃其慧可以用更多的笔墨来描述背后的故事。但这种留白也可以让读者思考自己环境下测试人员的状态与挑战，体会这五个内容背后的故事。
工程实践部分，此部分我认为是本书含金量最高的部分。如果你对其中的某些知识领域不感兴趣，建议你推荐给喜欢相关领域的朋友，相信他们会非常感谢你的推荐的。
团队建设，人始终是敏捷的关键挑战，读者可以在这里看看ThoughtWorks如何面对这个挑战的。
建设全功能团队——实践篇：看看胡凯是如何带好新人的。
建设全功能团队：看看胡凯是如何进行人员配置的。
高杠杆敏捷团队中的团队建设实践：看看ThoughtWorks的新人是如何快速提高技能的。
全功能团队——数据篇：看看跨职能团队的数据吧，如果你在乎“产能”的话。（虽然我个人非常反对使用这个词）
体验设计，好的开始是成功的一半，这也就不奇怪现在这篇文章放在本书最后一篇的重量。我非常认可纸质原型Paper Prototyping而非Visio或Axure此类原型工具这种观点。我相信这篇文章会给那些UX或UI人员以更多的弹药来面对敏捷转型的挑战。
羡慕你拥有这么多支持与资源之余，我开始有些担心你是否能承受这一软件经验的饕餮盛宴了。
敏捷教练 王宇
当ThoughtWorks市场部的同学来询问，是否可以将以往其同事发布在InfoQ中文站上的内容结集出版时，我的第一反应是Why not？大好事一桩啊，这不也是在践行InfoQ的“促进软件开发领域知识与创新的传播”的理念吗？虽然在沟通的过程中，由于版权使用的原因多了一些小插曲，“好事多磨”，看到排版好的电子文件，还是很欣慰的。
也许不像现在的BAT那么光鲜，但是ThoughtWorks自进入中国以来，就一直保持着自己的影响力。其中很重要的一点就是ThoughtWorks的同学们好像都特别能写和能说，不过也难怪，要不然怎么能做咨询师呢。这也是我一直很敬佩和尊敬ThoughtWorks的原因之一，要知道分享知识是很费时间的，写东西和演讲都需要花费大量的时间准备。如果抠门一点的老板会想，将这些时间放在给客户提供咨询上，不是更能产生收入吗？从目前这本书的出现来看，ThoughtWorks显然没有这样做，而且很可能在背后努力推动大家去分享。有这样的推动力，对技术社区的价值自然是善莫大焉。
看到这本书里很多熟悉的篇章，有些还是我亲手编辑过的，不敢想象，原来一件事情长期坚持下来会有如此美好的结果。而且这次通过过程改进、工程实践、团队建设、体验设计等几个维度将这些文章分门别类，读者会更容易按图索骥找到自己的所需。借着这个机会，我还特地去InfoQ中文站上又找到几个热门的话题，比如云计算、运维、大数据等看了看，每个话题下面都有许多国内外技术专家的辛勤之作。想来也给国内的技术人员带去许多创意和思考，陪伴着大家一起度过漫漫架构设计和编码之路。
分享总是那么让人幸福，也总是会促进社区的进步。站在InfoQ的角度，我感谢我们的这些作者；站在读者的角度，我感谢这些可爱的“知识传播者”。祝各位读者阅读愉快。
InfoQ中国创始人兼CEO
霍泰稳
三年前因缘际会，我加入了ThoughtWorks中国公司。在这之前，参与线上和线下社区的我，已经认识了不少早期的TWer，而加入之后更是近水楼台，我跟他们在一个项目工作，听他们的分享，得以从更近距离学习和体会他们身上似乎与生俱来的价值观和对软件构建本身的独到认识。也是一直以“程序员中的编辑，编辑中的程序员”自诩的我，从一开头就认定，传播这群人的意识和经验对于我来说责无旁贷，而这样的贡献也权当是允许自己滥竽充数混迹其中的些许安慰。
这个群体最初聚集了一拨价值观鲜明、爱分享、在社区极具号召力、对软件构建有独特理解和洞察力的人。因为他们的热情、鼓励，甚至偏执和煽动性，在社区掀起了一阵阵潮流，而社区的反应则褒贬不一。但是我想，不该拒绝和否认的是，的确是他们在引领国内的技术和开发社区群体，积极地吸收国外先进的软件思想，对国内软件研发状况和质量多年停滞甚至倒退的状况进行反思。我甚至一度认为这群人这个组织，是国内社区和开发者关于软件构建方面的启蒙者。
需要有人记录这个时代和这个时代的人。我们很难现在就评价这拨人做的事情，这拨人的思想和所做的努力，对于国内软件开发境况的改善有怎样程度的影响，甚至在多年后依然会发现这是件很难的事情。但这些人这些事情的确存在过，他们的努力也一直存在着。
本书适合的读者：
对软件构建过程进行持续思考和改进的人。
对技术新趋势持续拥有热情的人。
热衷于敏捷项目管理锻造优秀团队的人。
从目录上你很容易看出这本文集分了四个部分：过程改进、工程实践、团队建设和体验设计。这也是遵循了ThoughtWorks全球文集的一贯体例。事实上，当你阅读其中某些文章的时候，你会对文章为什么会出现在这个分类下感到疑惑。
但请你相信，编者已经尽了最大的努力，希望把文章放在最适合的分类下，供读者查找和参考。这毕竟只是三十三篇文章，每一篇的标题都足以彰示内容和方向，所以请尽情享受文章的内容盛宴吧。
感谢我的同事们，这一篇篇文章的作者，可以忍受我不停的威逼利诱和催稿，最后能交付高质量、足以流传的文章。虽然你们中相当一部分人已经离职，但见文如见人。
感谢我的市场部同事小菊和婷婷，你们为这本文集的出版设定流程和计划，帮助我从更多内容中遴选出这三十三篇入选文章，并和出版社反复斟酌合同，她们是让这本文集三年后得以面世的重要贡献者。
感谢人民邮电出版社的编辑陈冀康，继张松的《精益软件度量》之后，他继续为ThoughtWorks的软件思想在国内的传播贡献力量。
感谢InfoQ中文站的负责人霍泰稳，因为这本文集内的绝大多数文章，都曾经发表在InfoQ的中文网站上。谢谢泰稳予以优惠的回购价格，让这些文章具备了可以纸版发行的版权。
作为一个开发团队的管理者，例如当你是一个团队的项目经理的时候，任务的完成情况通常是你最关心的内容之一，比如说分配的任务是否能够按时间完成，整个项目的进度是否尚在计划之中，团队内的人是不是都在高效地工作，大家有没有什么困难，等等。在软件开发团队中，任务的分配、跟踪和管理通常是这个团队管理者的一个重要的工作内容。
我曾经碰到过一个项目经理，她管理一个团队开发一个Web应用，团队里开发人员大概10个，测试人员3个，业务分析师1个人。对于任务的管理她是这样做的。通常，她会将需求分析人员分析得到的需求给每个人分一些。然后每个人在领到任务之后会给她承诺一个大致的时间点。整个项目大致的交付计划用一个Excel表管理，根据客户要求的交付时间点，同时考虑到一些需求之间的集成测试关系，她定出了每个需求的大致交付时间点。只要每个开发人员承诺的时间点和期望的相差不大，她都可以接受，这样每个开发人员就知道自己应该在什么时间点交付什么东西。
一切本该很完美，但是不和谐的问题不断出现。最经常发生的事情就是大家在承诺的时间点到来的时候不能按时交付，每次她询问进度的时候，都会被告知还差一点就完成了。通常的说法是“底层部分已经做完了”或“还差页面部分就可以搞定了”，然而实际情况是又过了相当长的时间才真正完成。当然也有按时交付的需求，但是她发现也许是大家经常加班，已经开始疲倦了，有时候明明很简单的、可以提前完成的需求，大家还是到最后一刻才交给测试。
也有的开发人员拿到自己的那一批需求之后，会批量工作，把若干个类似需求的底层逻辑全部实现，然后再实现上层内容。她默认了这种做法，就像这位开发人员说的“这几个需求都差不多，只要底层做好了，基本上就都完成了”。虽然这部分工作早点和其他人一起集成测试会比较好，但是他这样做也只能推后集成测试的时间点了。还好她承诺给测试团队的交付时间点还在1个月之后，只要1个月之内能够完成这些需求就可以了。
项目执行过程中还有一些其他的问题，比如有的新人经常碰到问题，但是出了问题并不主动问其他人，而是在胡乱尝试中浪费了时间；还有个别开发人员非常激进，经常花时间去重构代码，追求完美的架构设计，进度很让人担忧。组内的开发人员还经常被其他项目的事情打扰，因为有几个人刚刚从之前一个项目中调过来，前一个项目的有些问题只有他们熟悉并有能力解决。她就不止一次发现有一个开发人员在修复其他项目的bug。
她会不定时地去询问每个开发人员的开发进度，当需求的计划交付时间点逼近的时候，这种检查会越来越频繁。开发人员感受到压力，有时候甚至需要加班来完成开发工作。尽管她花了很多精力去跟踪和检查每个需求的完成情况，还是有很多出乎意料的事情在不断发生。尽管她一直相信，只要开发人员能够完成任务，采用什么方式她都不干预，而具体的时间也是由他们自己分配的。但是她渐渐感觉到任务越来越不可控，计划通常无法按时完成，每天对大家的检查花费了大部分时间，然而却不能揭示出真正的问题。
运转良好的项目都差不多，而问题项目的问题各有各的不同。虽然每个团队的问题可能不完全相同，但是当我们审视这些项目的运作和管理方式的时候，不难发现一些诸如多任务并行等共性的问题，这些问题给软件项目带来了各种各样的浪费。当一个团队采用瀑布开发模式的时候，开发阶段全部结束之后测试人员才会介入，开展测试活动，在一个通常很漫长的开发阶段内，各种开发活动中的浪费、估计不准确以及成员自己的拖沓、被打扰、问题阻塞等，都被掩盖了。只要在最终时间点前能够全部开发完成，不管是前松后紧还是加班熬夜，都已经成了项目开发的常态。项目经理只能看到交付的最终时间点，问题不能及时地解决，而等到问题暴露的时候，可以使用的调整手段也非常有限。
这样的一种团队生存状态在外部环境要求短交付周期、需求允许经常变化的情况下显示出了极度的不适应。市场环境的变化驱动了软件需求的变化，这种变化催生了缩短交付周期的诉求，较短的交付周期使得人们不必去预期过于长远的需求，具备根据市场的变化快速地制定和调整软件需求的能力。而当交付模型由几个月的瀑布模型转变为数周甚至更短的迭代模型的时候，我们在前面谈到的团队中的各种浪费、低效、半成品堆积等问题，就会急剧地爆发出来。
熟悉敏捷方法的读者可能知道，敏捷方法包含一系列实践，来帮助团队实现短周期快速交付，更好地响应需求变化。比如说用户故事（User Story）方法将需求从用户价值的角度进行组织，避免将需求从功能模块角度划分。小粒度的用户故事可以在一两周的迭代内完成开发和测试（并行开发），从而可以缩短交付周期。问题是，在敏捷团队内，我们如何有效管理大量小粒度用户故事，同时避免上述项目管理中的问题呢？下面我们结合敏捷开发中的看板工具来看看敏捷团队是如何管理任务的。
看板源于精益生产实践，敏捷将其背后的可视化管理理念借鉴过来，经过一番改造，形成了有自己独特风格的可视化管理工具。曾有人总结过scrum和kanban的使用[1]，而很多时候，我们也将它叫作迭代状态墙。
我们先来看看怎样用这个状态墙来管理迭代任务。说起来其实是一个很简单的东西。
通常一个迭代的状态墙反映了某一个迭代的计划和任务进展情况。状态墙按照一个迭代内团队的典型开发活动分成几栏，例如“待开发”、“开发中”、“待测试”、“测试中”、“测试完成”等。在一个迭代之初，我们会将计划在本迭代完成的故事卡放到“待开发”这一栏中。可视化状态墙的一个好处就是所有团队成员都可以实时地了解本迭代的计划和进展情况。开发人员领取任务时，就将他领取的故事卡片从“待开发”移到“开发中”，同时贴上带有自己名字的小纸条。当他开发完成之后，就将故事卡片移到“待测试”一栏。测试人员看到“待测试”栏里有待测的故事卡，就取下一张，移动到“测试中”，然后开始这个用户故事的测试；测试完成后，就将故事卡移动到“测试完成”一栏。如果测试人员发现了一个bug，那么他可以用红颜色的卡片记下这个bug，然后放到“待开发”这一栏中。状态墙上除了用户故事、bug之外，还会有一些诸如重构、搭建测试环境这样的不直接产生业务价值的任务，这三类任务用不同颜色的卡片放到状态墙上统一管理。
这样一个简单的工具，是如何帮助我们消除浪费、解决项目管理中的问题的呢？让我们逐条分析一下看看。
返工是软件开发过程中的一大严重浪费。比如说开发人员完成的任务交给测试人员测试的时候，关键流程不能走通，阻碍了测试进程；交付给客户的东西被客户说“这不是我想要的东西”；分析人员将还没分析透彻的任务交给开发人员，在最后验收的时候发现开发人员加入了自己的一些“发挥”。这些都会造成返工。返工意味着没有一次性将事情做对，意味着流程中的上游没有交付高质量的产品，也可能意味着团队成员间的沟通出了问题。
在传统的瀑布流程中，我们往往是期望通过前期细致入微的工作来确保一个阶段的工作被高质量完成之后才移交到下一阶段。后来我们慢慢从失败的经验中学习到，这种方法在变化的需求环境下实在是太脆弱，不仅不能如愿保证质量，而且会造成更大的浪费，交付周期也不能满足要求。于是我们引入了迭代式开发方法[2]，一个需求的分析、开发、测试、验收成了一个小粒度的更连续的过程，在这个小的交付循环中，看板帮助我们以更细节的粒度来管理一个任务每个阶段的工作质量。
通常我们是这么做的。当我们把一张故事卡从“待开发”移动到“开发中”时，这张卡片必须是已经分析完成的。也就是说，当开发人员准备真正开始开发这张故事卡之前，我们的需求分析师们必须保证这张卡片所包含的所有内容和细节都已经分析完成，不再有模棱两可的细节，不会留给开发人员过多的自我发挥和想象空间，而且这些细节必须和客户确认过，而不只是团队自己“设计”的结果。
这一道关看似很寻常，实际上很多项目会在这里出问题。很多时候开发人员开始开发的时候，需求还没有分析完成，很多细节尚须澄清确认，实现上的技术风险还没有被完全排除。也有的分析师善于给开发人员留有大量自我发挥空间，需求过于言简意赅。开发人员开始开发这样的需求时，要么做不下去，要么按照自己的理解做下去。做完后分析师发现不对，和想的不一样，于是开发人员返工。最糟糕的情形莫过于最后客户说这不是他当初想要的东西。
由此可见，开发人员挪卡的时候，确保这张待开发的用户故事已经被真正分析完成，是我们准确实现用户需求的第一步。通过规定这一挪卡的前提，同时辅以用户故事的澄清（由分析师向开发人员澄清）或者反向澄清（由开发人员向分析师讲述自己的理解），可以很大程度上减少返工。
还有一种浪费发生在测试过程中。测试人员经常会发现，处于“待测试”状态中的一些故事卡，在测试的时候主要的流程走不通，根本无法进一步展开测试，于是乎不得不将故事卡打回到开发人员手中。而往往这个时候开发人员已经在另一个用户故事上工作了。要么他需要停下手中的任务解决测试的问题，要么让测试人员等到这些问题修复过后再测。无论哪种都是不好的选择。
出现这种问题的一个主要原因是因为开发人员声称他已经“开发完成”，将故事卡从“开发中”挪到“待测试”时，实际上自己并没有对这部分功能进行测试，或者是因为疏忽，或者是因为懒惰，或者是因为过于自信。通过在这个状态转换阶段引入用户故事初验，分析师在挪卡之前先到开发人员机器上看看该故事卡包含的功能是否被实现了，可以很大程度上提升效率，减少浪费。如果分析师在初验过程中发现了问题，那么开发人员马上能以最小的成本进行修复，而不用等到之后测试人员发现时再来修复。而且，分析师初验也提供了一个判断实现是否良好的反馈点，这是我们能够看到一个需求是否被实现并能够真正工作的最早的时间点。
多任务之间的频繁切换是一个常见的问题。表现在团队里的成员身上，特别是开发人员，多为会在不同的任务间切换。就像前面的故事中提到的，开发人员可能这一刻还在实现某一个需求，而下一刻可能就会被叫走去修复某一个遗留版本的缺陷；又或者该开发人员手头被分配了多个任务，每个任务都在进行中，而没有一个处于完成状态。任务切换是导致效率降低的一个重要原因[3]。不同任务间的上下文的切换会导致将任务当前状态频繁地在头脑中“压栈”和“出栈”，这些操作会耗费时间。如果完成一个任务一个人需要一天时间，那么两天内这个人可以完成两个任务；但是如果他在第一天开始在这两个任务上并行工作，那么完成这两个任务会需要大于两天的时间。
大家可能已经注意到了，在前面的看板图中，处于“开发中”的所有任务卡片上都有一个小纸条，上面标记着正在这张卡片上工作的人的名字。如果说有两个人结对在一个卡片上工作，那么这张卡片上应该有两个名字。这个小小的实践可以帮助我们随时发现团队内某一时刻，每个人是否只在一个任务上工作。
如果这一简单的规则能够严格被遵循，那么当我们看到一个人的名字出现在多张卡片上的时候，我们就知道这个人此刻可能忙着在多个任务之间切换，而每一个任务都可能不会在估计的时间点内完成。如果我们看到有人的名字没有出现在任何卡片上，那么他目前大概处于休息状态。团队内的每个人的名字都应该对应在一个小纸条上，如果你此刻在某个任务上工作，那么就将自己的名字贴到相应卡片上，如果此刻在该任务上没有工作，就将自己的名字移去。
我们在领取“待开发”状态栏中的卡片时，应该保证每次每人只领一张卡片，不要多领，完成了这张卡片之后，再回来领下一张。当一张卡片被认领之后，我们就会对这张卡片进行跟踪，在站会上谈论它的完成情况，谈论实现过程中碰到的问题。当它的进度和估计的可能进度偏差较大时，我们能够及时察觉而不是在最后一刻才发现，这样可以提供需要的帮助，确保它能够顺利完成。这样一种方式让我们能够将注意力集中到小粒度的需求（例如用户故事）上，来更多地关注这些用户故事的流动速度。而当每个小的用户故事能够顺畅地流动起来时，整个项目的交付也就得到了保障。
当然这一实践并不能自动保证团队内不再出现多任务并发、拖延或者做和任务无关的其它事情等问题。可能有些人在做一个用户故事的过程中，突然中断去做了一些其他事情，但是却没有及时在状态墙上更新自己的状态。重要的是团队要有实现交付目标的共同愿景，能够透明地暴露问题，而且善于利用状态墙来发现和改进自身的问题。对于不成熟的团队，这可能需要一个转变的周期。
如果一个团队的职责共享较好，所有人集体拥有代码，鼓励每个人在代码的不同部分熟悉和工作，那么在这样的团队内就不容易出现把一大块任务事先就明确给某一个人的情况。相反，所有人的工作事先不具体确定，大家会更容易形成某一时刻只领取一张卡片的习惯，避免同时在多个任务上工作。实际上，状态墙的使用也可以帮助团队走向职责共享之路，只需要在领取任务的时候有意地给人们分配一些之前没做过的内容，同时安排好有经验的人与其结对工作，一段时间之后，团队内的人便会逐渐体会到和之前只是专注在一个模块内不同的工作方式。
一个需求的交付周期（lead time[4]）是从它被识别到最终交付给用户手中所耗费的时间。交付周期越短，意味着客户从提出想法到能够在软件中实际使用的时间越短。从客户的角度来看，更短的交付周期意味着自己的软件能够对市场变化更快地响应，因而获得更强的竞争力，同时也意味着能够更快地验证自己的想法。
任务管理的粒度太大会直接导致交付周期变长。最极端的情况是将属于某一模块的任务在一开始就全部交给负责这个模块的人，所有这个模块相关的修改都由他来实现。在一个按模块划分职责、每个人只负责自己具体模块的团队里，通常这个模块的负责人会实现这个模块的所有修改；不然，就是将一个可能需要做两周到一个月的任务分给某个人；或者更好一点的情况是，单个任务本身不大，但是会将相关联的任务成批地分配给某个人。如果你的团队内也是采用大篇的“规格说明书”等Word文档来组织需求的，那么要小心，这种问题很可能在团队内已经存在。整个团队没有小粒度频繁交付的概念，习惯了大批量长时间地交付方式，因为批量大，所以估计常常不准，而且时间跨度长，中间也会有更多地干扰因素出现，这些都导致任务不能在开始承诺的时间点交付。开发周期长同样导致测试活动的滞后，极端地滞后就演变为所有开发工作完成之后才能进行测试，这就是我们熟悉的瀑布模式。最终的影响就是需求的交付周期会很长。
传统团队的一个常见组织方式是按照功能模块划分团队成员，明确分离职责，这也会变相增长交付周期。这样的团队通常倾向于按照功能模块来组织半成品任务，而不是按照可以交付价值的完成品来组织任务。习惯按照功能模块来组织开发的团队通常会阶段性地“联调”，不同模块的人带着自己的代码合在一起调试，由于缺乏频繁地集成，这种联调活动的时间经常不可控。团队在大部分时间内通常只拥有一大堆半成品，后续的测试和验收活动都没有办法进行，而只能等到团队在某一刻组装出一个完整的功能后才能测试，所以交付周期也会比较长。
因此，如果我们的需求都是按照软件的功能模块划分，而不是按照面向用户的价值来划分的，那么我们在交付用户价值这一目标上，一开始就走错了路。采用用户故事能够把需求以用户能够理解的价值组织起来，这一点是我们缩短交付周期的一个重要基础。
我们的状态墙能够揭示需求的交付周期。让我们来看看这样几个场景。
如果我们的需求是按照软件的功能模块划分的，那么通常单个模块的编码完成不可测。例如有的团队喜欢将Web应用的上层页面部分和下层数据库逻辑部分划分到不同的模块组，一个用户的需求也会拦腰切成两截，一部分交给上层团队完成，一部分交给下层团队。这样，即使单个团队的任务完成也不能开展这个需求的测试，于是这些任务就会堆积在“待测试”这一栏。
如果我们的需求很大，以至于开发人员要花费很长的时间（超过1周）才能完成开发，那么这个需求会在“开发中”这一栏停留很久。大家可以猜到，当一个人同时进行多个任务时，这些任务也会比它们被单个依次开发时在“开发中”这一栏停留更久的时间。
任何一栏中的任务其实都是半成品，只有完成测试、交付到用户手中的需求才是完成品。状态墙上的每一栏都好比一个存放着各种零件的仓库，每一栏中的卡片越多，停留得越久，就说明当前半成品的库存越多，是该得到团队认真关注的时候了。状态墙将每个阶段的半成品数量可视化呈现出来，让虚拟的数量通过卡片这种物理介质的数量得以呈现。
通过状态墙，我们可以计算出每一个需求的交付周期大概是多久。状态墙上一个用户故事从放到“待开发”这一栏，到它被移动到“完成”这一栏，这一个时间段是需求的整个交付周期的其中一段，也是很重要的一段。通过优化从“待开发”到“完成”的这一个过程，我们可以缩短需求的交付周期。通过比较需求的交付周期和客户对交付周期的要求，我们可以量化之间的差距，然后指导我们进行改进。
在理解了状态墙是如何呈现一个需求的交付周期后，我们就不难理解瀑布方法是如何让交付周期变长的。在瀑布模型中，全部开发工作完成之后才会进行测试工作，相当于所有的任务卡片都堆积到“待测试”状态之后，才开始逐一测试。所有开发完成的半成品，都会留存在“待测试”这一仓库中，一直等到所有开发活动结束的那一刻。
出现库存堆积的时候，就是我们需要改进的时候。如果“待测试”这一栏有太多的任务卡片，那么就说明我们的测试活动没有跟上，有可能是我们的测试环境出了问题，或者是我们的测试人员人力不足。如果太多的卡片位于“测试完成”状态，说明我们的发布和最终交付过程出了某些问题。如果“待开发”这一栏中任务过多，说明我们的计划有可能超出了当前团队的开发能力，或者说反映了开发人员的不足。还有一种情况是“待开发”这一栏空了很久，这可能说明了另外一个问题，那就是我们的分析师的分析速度匹配不上团队的开发能力。一个良好的团队，必然是各种角色协调配合，并行工作，同时他们之间的任务衔接也能够比较流畅。
团队在每个迭代所能完成的工作量，通常被称为迭代的速度（velocity），是衡量团队每个迭代产能的一个指标。这个指标能够帮助团队制定迭代计划。根据团队估计任务工作量的方法不同，迭代的velocity的单位也可能不同（例如故事点数）。通常，我们只需要在迭代结束的时候，数一数状态墙上完成的任务工作量就可以了。
当我们经历了若干个迭代以后，通常团队的迭代速度会趋于稳定，我们在做下一个迭代计划的时候，会参考以往迭代的数据。如果上一个迭代完成了15个点，那么下一个迭代我们通常也会计划15个点左右的工作量，将这些卡片放到“待开发”这一栏中。也就是说，每个迭代结束时，我们都会对状态墙进行更新，将即将到来的迭代的卡片放到墙上，而且将一些处于半成品状态的卡片进行适当的调整。
前面提到，状态墙上可能有三种卡片，除了需求，还可能有bug和技术任务。测试人员每次在迭代中测出一个bug，就会将bug写成卡片，放到“待开发”这一栏。当bug不多的时候，团队可以在不太影响原有计划的情况下消化掉这些bug，确保软件的质量持续地得到保证；如果bug太多，则需要做一些计划，将bug分散到几个迭代里去消化。然而到这个时候，团队可能更需要及时反省一下出现这么多bug的原因了。
另一类技术任务也需要和bug以及需求卡片一起被考虑到迭代计划中去。通常技术任务包括诸如搭建持续集成环境、准备测试环境、重构这样的任务。它们虽然不直接给用户带来价值，但是却是保证软件质量、确保团队效率的重要因素。比如重构类的任务，对于工作在遗留系统上的团队来说可能是需要一直考虑的事情，为了保障新需求的顺利实现，可能需要有计划地重构之前的一些遗留代码。
bug和技术任务耗费团队成员的时间资源，但是不直接产生用户价值。如果我们衡量团队每个迭代的总体生产能力，需要在计算迭代速度时考虑这三类任务；但是如果我们只考察团队每个迭代交付的用户价值的量的大小，那么就不应该包含技术任务和bug。当一个团队在迭代中花了过多的时间在技术任务或者修复bug上，那么这个团队就需要反省一下其中的原因，是不是团队的基础设施太差，或者是团队在开发时过于粗心导致太多的bug，抑或是其他的一些原因。
本文中我们从项目管理中常常出现的一些问题着手，分析了其中的一些原因，然后介绍了如何采用状态墙（看板）来可视化任务管理。在敏捷项目中，状态墙作为一种有效的迭代任务管理工具，已经被广泛地使用。团队利用状态墙这样一种简单的工具，将迭代开发中的日常工作透明实时地跟踪管理起来，能够帮助团队及时发现问题，消除浪费，快速地交付用户体现价值。希望这些文字，能够为渴望尝试敏捷、改善任务管理和日常运作的团队带来一些帮助。
[1] http://www.infoq.com/minibooks/kanban-scrum-minibook
[2] http://en.wikipedia.org/wiki/Iterative-and-incremental-development
[3] 参见《Lean Software Development: An Agile Toolkit by Mary Poppendieck》，Tom Poppendieck第一章。
[4] http://en.wikipedia.org/wiki/Lead time
在需要频繁交付、不断收集用户反馈、拥抱变化、追求业务敏捷的项目中，软件的开发和交付是迭代式进行的。在这样的项目团队中，业务分析师（BA）通常需要在一个开发迭代开始之前完成该迭代开发任务的分析。但在特殊情况下，从收集客户需求到将功能细节传达给开发团队的周期会缩短到一至两天。BA可以用于思考和分析的时间远远少于可以预先做出所有设计的瀑布式项目。
那么在这样的敏捷项目中，BA如何能够适应这种交付模式、完成高质量的业务分析、协同团队为客户交付高价值的软件呢？
ABC公司是一家知名的国际性会计师事务所，业务规模庞大，分支机构遍布全球170多个国家。
ThoughtWorks受邀对公司“全球派遣服务（International Assignment Service）”业务部门提供IT解决方案以及软件系统的开发服务。该系统包括收集公司客户的全球派遣雇员的报税数据，同时管理ABC公司税务咨询师对这些数据进行审核、汇算和出具报告的业务流程；逐步替换它目前远远不能满足业务和性能需求的遗留系统。
该系统主要有两类用户，一类是ABC公司客户方被派往不同国家工作的雇员（以下简称Mary），这些雇员使用该系统填入报税需要的数据；另一类用户是ABC公司的税务咨询师（以下简称Kim），负责审核、处理Mary提交的数据。
该项目为分布式开发，ABC公司的决策方在美国，而ThoughtWorks的开发团队在中国，沟通反馈周期有时较长。
由于ABC公司对用户体验的重视，开发团队需要频繁交付软件，以便收集用户反馈并及时调整解决方案和后续开发计划。这大大缩短了从收集需求、开始分析到进入开发的周期，增加了分析中出现缺陷的风险。
当开发过程中发现问题时，开发团队无法马上与客户取得沟通，开发进度可能会受到影响。
业务分析的重要性在于首先做正确的事情。理解客户的业务，关注需求背后的价值可以帮助项目团队在软件的设计方面做出正确的选择。
而我们面临的困难是，客户提出的需求往往都是直接的软件功能，而不是需要解决的业务问题。如果BA只专注于针对客户需要的功能进行系统分析，就丧失了帮助客户优化解决方案以及改进业务流程的机会。
以敏捷开发方法中的用户故事为例，找出客户要解决的业务问题的一个简单办法是，用以下方式概括每个用户故事的内容。
As…（角色），I want to…（完成什么样的功能），So that…（解决什么问题，带来什么价值）。
“So that…”说明了该故事的业务价值，即要解决的业务问题。准确地寻找业务价值将有利于我们设计出最适合的“I want to”，这很可能优于客户直接提出的功能要求。
需要注意的是，不要把解决方案或功能当成该用户故事的价值。以ABC公司业务系统中的一个用户故事为例，BA对该需求业务价值的了解程度将直接影响到解决方案的优劣。
| 作为 （As…） |
我想要 （I want to…） |
以便 （So that…） |
是否阐明了价值 |
| Mary | 即时浏览我的行程统计数据 | 了解我在各个国家或地区停留的时间以及从事的活动 | 否 |
| Mary | 即时浏览我的行程统计数据 | 我可以迅速地检查我所输入的在各国家或地区的停留时间及从事活动的数据是否正确（以保证我可以依照法律要求提交准确的报税数据） | 是 |
在该用户故事的两种不同表述中，由于第一种表述只说明了需要的功能，没有说明业务价值，在功能设计时，我们可能会将“行程统计数据”的内容设计得过于详细而造成浪费，使用户不明白此功能的意图；而第二种表述的业务目标就非常明确，可以帮助我们更加容易地设计出适合的解决方案。
此外，BA在了解客户的业务问题时，最好请客户提供一些真实案例/场景来证实其观点并加深自己的理解。
在实际工作中，我们发现BA容易忽略以下两个方面的分析工作，从而做出错误的 决定。
例如，客户需求的功能，是当前遗留系统中已经使用多年并且未收到过任何抱怨的功能。因此客户和BA往往认为这个功能是合理的，忽略了深入的分析和思考。但是这种思考不全面而做出的决定可能会与可以预见的新功能产生冲突。
在ABC公司的遗留系统中，用来收集报税数据的问卷内容是通过Excel表来维护的，而Mary在前台也是通过下载Excel问卷，填写完毕后再上传。
在新开发的系统中，问卷被改为在线方式，同时辅助以其他必要功能提升Mary的用户体验和满意度。因为客户方的员工都是财务背景出身，非常喜欢使用Excel表，而之前用Excel表维护问卷内容也被证明是非常有效的，所以客户坚持在新系统中延用这种方式。经过仔细地分析，我们发现在针对提高Mary用户体验的新功能上线后，使用Excel表维护问卷内容将大大增加维护的工作量并且提高错误率，而这与项目的相关目标背道而驰。ThoughtWorks在列举了问题的细节后，说服客户采用了新的解决方案。
客户发现目前的业务流程有不合理的地方，希望在新的IT系统里直接改变这些流程。如果不经过仔细的分析，这种做法可能会很危险，业务流程的盲目改变可能会给一部分用户造成麻烦，为客户实施该软件形成强大阻力。那么了解清楚目前这些流程存在的价值和原因事关重要，从而可以帮助我们为客户提供科学的、逐步优化其流程的IT解决方案。
在ABC公司的业务流程中，Kim和Mary之间的一些交流是通过邮件来完成的。这里存在两个业务风险：第一，Kim和Mary交流的重要信息被散落在各自的邮件里，系统无法记录，在遇到法律问题时，难以划分责任；第二，Kim和Mary可能会使用邮件发送一些保密性较强的内容，如果发错，后果不堪设想。
在开发新系统时，客户要求我们增加了一个消息功能，使Kim和Mary之间的交流可以方便地在系统内部完成。该功能上线后，很好地化解了这两个业务风险，同时收到了Mary这类用户的良好反馈。然而这却给该会计师事务所在某些国家分支机构里的Kim这类用户的工作带来了不小的影响。由于之前使用邮件系统，Kim可以将Mary的邮件转发给相关的同事并利用邮件丰富的功能进行结果的跟踪；而新上线的消息功能达不到邮件的所有要求，所以增加了他们的工作难度。此外，由于Mary对这个功能的青睐，发送消息的数量远远超过了在使用遗留系统时发送邮件的数量，超出了客户想提高Mary的满意度而在短期内所能承受的代价。
在遇到以上问题时，我们与客户一同分析，提出了折中的解决方案，付出了较少的代价将消息系统和客户的邮件进行集成，同时帮助客户制定了对此项业务流程改进和配套IT解决方案的蓝图。
在频繁上线的项目中，其中一个重要的实践是确定需求的优先级，使得重要的功能能够先得以开发出来投入使用，以便及时收集用户反馈。一般的做法是要求客户排好需求优先级，然后与项目相关成员一同制订迭代开发和上线计划。但是由于客户决策方所处角色以及思维角度的局限性，对优先级的评定可能存在盲目性。建议BA参照以下价值维度帮助客户对优先级进行评定。
需求价值维度分析图如下所示。
| 价值维度 | 说明 |
|---|---|
| 愿景目标 | 该功能点是否契合项目的愿景和业务目标 与项目目标的契合程度越高者优先级越高 |
| 时间限制 | 客户的业务是否有一定的时间表 如果该功能点必须在某时间点前投入使用，则该需求必须被排入相应时间的发布计划中 |
| 市场卖点 | 该功能点是否是吸引特定目标用户的卖点 如果客户的资金存在问题或者需要市场的快速认可，则可以考虑将该需求列为高优先级 |
| 有无替代方案 | 该功能点有无方便的替代方案 如果有简单易行的替代方案，则该需求的优先级较低 |
| 客户内部因素 | 该功能点是否存在客户内部的因素 例如某功能只对小部分用户提供价值，但会决定客户内部某个重要组织对这个项目的投资和评价，则可以考虑将该需求列为高优先级 |
| 投资收益 | 该功能点的开发成本和客户所能获得的收益是否匹配 例如客户某工作流程浪费了一小组人员大量时间，但对其他部门或工作环节无影响。如果开发相应的软件功能造成的投入大于客户在一定时期内可以节省的资金，则该需求的优先级较低 |
| 技术依赖性 | 其它需求是否依赖于该功能点 如果依赖于这个功能点的需求优先级高，那么该功能的优先级应更高 |
除了来自客户方面的决定因素，我们还应该考虑技术实现方面的影响。如果一些技术风险较高的功能可以先进入开发阶段，那么问题会尽早地暴露出来。开发人员在项目早期解决这些问题会有利于开发成本的节约。所以除以上客户价值维度外，我们应该再参考以下矩阵来权衡需求的优先级。
客户价值维度和需求优先级矩阵并不是优先级高低的计算器，而是与客户以及团队沟通交流的工具。不同项目的影响维度也会有所不同。由于各项因素的复杂性，客户价值维度和技术风险因素需要综合考虑，不可以用权重来计算。BA可以与客户对以上因素的内容达成一致，使得客户在评定需求优先级时可以快速、准确地做出判断。同时，通过对价值维度的分析，我们将有机会清晰地了解到功能优先级高或低的原因，以便我们能够准确地编制上线计划和项目开发，而且合理地划分用户故事范围。
有些客户的决策人可能会依据自己的喜好划分优先级，这对项目能够按目标成功交付造成一定的风险。此外，客户在功能的设计和验收阶段也容易对单个功能追求完美，产生额外工作量，增加项目范围。而这部分额外工作可能并不合理或者价值较低。长期如此，团队在开发过程中将逐渐偏离项目目标。如果能借助优先级维度对这些额外需求进行分析，则可以提供更有说服力的依据，帮助客户做出正确决定，达成BA和项目经理对客户期望值的有效管理，从而降低交付风险。
在频繁交付的项目中，如果BA独自承担业务分析工作，难免会出现疏漏。ThoughtWorks曾与ABC公司的IT部门合作完成其业务系统的一些集成工作。在合作过程中发现，ABC公司IT部门的开发人员在业务分析中参与度很低，由此造成了如下问题。
（1）BA需要写大量需求文档，所以从需求分析到软件交付的周期较长。
（2）设计缺陷的发现滞后。
（3）在需要频繁交付的情况下，解决方案质量较差，方案优化能力较弱。
而ThoughtWorks的开发人员在业务分析中的参与度较高，因此有效地避免了以上问题。
开发人员是软件功能的实现人员，对方案的实现工作量有较准确的估计。在明确项目目标或业务问题后，BA如果能够和开发人员一同分析解决方案，将会更有效地为客户找到兼顾成本和效果的方案。
在收集到客户需求后，BA可根据业务价值对需求进行分析，判断客户提出的功能或解决方案是否能很好地满足该业务价值或要解决的业务问题；或者按照自己的理解设计出满足该业务价值的功能实现或解决方案。
完成上述工作之后，BA应与开发人员就需求和业务价值进行充分沟通，验证功能实现的可行性，同时积极探寻更优方法。如果开发人员提出符合业务价值的不同方案，BA则可以要求开发人员提供一些关于开发工作量、方案优劣、技术风险方面的比较数据，从而帮助自己有效地与客户沟通并挑选最佳方案，甚至可以根据分析结果帮助客户调整该需求的优先级。对于技术难度和风险较高的功能点，建议邀请资深开发人员参与讨论。
由于上述方法需要与开发人员大量沟通，有些BA在应用以上实践时也遇到了以下挑战。
在ThoughtWorks，大多数开发人员都喜欢积极思考、主动为业务分析提供帮助，大大减少了需求分析上的漏洞。然而在ABC公司的IT部门中，开发人员很少主动为业务分析出谋划策，尤其是团队中资历较浅的成员，甚至不愿意参与解决方案的讨论。团队成员的优势没有得到充分发挥，开发人员只管按需求埋头苦干，结果功能和解决方案中的问题往往在测试或者验收阶段才暴露出来，不可避免地造成了浪费。
站在开发人员成长的角度，从ThoughtWorks实践来看，积极地理解业务、思考解决方案能够更快地提高技术能力。因此BA可以找出一些实际案例，协同项目经理与团队各成员进行沟通，鼓励大家积极参与业务分析，逐步形成开发人员与BA协作的良好氛围。
开发人员在积极参于分析的过程中，有时会对软件功能的价值吹毛求疵，在细节上与BA产生较多争论，使BA在应付开发人员的问题以及与客户求证答案之间疲于奔命。
解决此类问题，BA可采取以下方法。
BA在收集需求时，尽可能充分地了解客户要解决的业务问题，以便能够快速回答开发人员的问题。
面对开发人员对解决方案的质疑时，应保持良好的心态，清楚地了解开发人员顾虑的问题和原因。
如果自己掌握的信息确实不能证明现行方案的合理性时，协同开发人员，找到更优方案并与现行方案进行优缺点比较。
将新旧方案与客户沟通，则可快速帮助客户做出判断。
由于测试人员所处角度和对细节的关注，他们往往可以发现一些功能细节的设计漏洞。所以在用户故事进入开发前，BA与质量保证人员对相关业务价值进行充分沟通，可以在功能进入开发之前为BA创造更正某些设计缺陷的机会。
作为质量保证人员，如果充分了解功能背后的业务价值，对比于只了解功能需求，将可以写出更加完善的测试用例，提高测试覆盖率。这会为交付高质量的软件把好最后一道关。
业务分析是困难的，特别是当我们面对未知领域的时候。如果只是简单地按照客户的具体需求进行软件开发，那么我们交付给客户的产品价值将非常有限。然而识别业务价值、帮助客户分析需求优先级、保障团队协作，将有效提升团队的软件设计能力，解决客户真正的业务问题，实现更大价值。
作为一名业务分析人员，当您在尝试以上实践时，可能会发现自己对客户业务的理解变得更加深刻。在与客户的沟通中，也能够更加容易地提出有价值的问题以及建议，从而提升客户对项目团队的信任，为成功交付项目打下良好基础。
*注：“客户价值维度”的概念由ThoughtWorks咨询师李光磊提出，在此对李光磊表示感谢。
当软件行业进入互联网时代，市场对软件产品和服务的交付提出了更高的要求：不仅要快速实现需求，而且要快速发布上线，同时必须保证业务可靠、高效运行。为了满足这些要求，IT组织需要强有力的流程、技术和人员作为保障。
ThoughtWorks很早就认识到发布与运营对于成功交付的重要性。我们的创始人Roy Singham在《走完业务软件的“最后一公里”》[1]一文中提出以下观点。
所谓[软件开发的]“最后一公里”，是指软件满足了功能需求之后，尚未投入实际运行并创造业务价值的阶段。软件开发者──尤其是面对交付压力的软件开发者──常常对“最后一公里”视而不见。但它确实正在成为业务软件交付中最大的压力点。
本文将分析大型软件组织在软件发布与运营维护阶段常见的典型问题并介绍一种行之有效的解决对策。
众多大型软件组织在软件的发布、运营和维护过程中体会到以下两方面的压力。
传统观念中规模庞大、发布周期长达数月乃至数年的软件产品研发方式正在发生变化。在“快鱼吃慢鱼”的互联网时代，上市时间（Time To Market）成为衡量软件组织能力的重要因素：能快速接纳需求、快速完成开发、快速上线投入使用的软件产品，才能有效占领市场、吸引用户。
在以迭代式开发为特征的敏捷开发方法和以Ruby on Rails为代表的一批高效开发工具帮助下，很多软件组织在实现功能性需求方面的能力得到了显着提升。然而从业务负责人的角度来说，仅仅提升开发阶段的效率还不足以实现端到端的快速响应。很多软件组织虽然以迭代方式进行开发，但发布和部署仍然按照从前的节奏，每隔几个月才进行一次。这时从客户与最终用户的视角看来，这些软件组织的交付仍然是以瀑布方式进行：客户与最终用户并没有直接感知到开发能力提升所带来的利益（如图1所示）。
图1 迭代式开发+瀑布式发布[2]
不能有效缩短部署上线的周期，就无法真正实现快速响应业务需求、快速实现业务价值。如何缩短发布和运维工作的周期，已经成为困扰很多软件组织领导者的问题。
大型软件组织通常都很重视产品质量，而且在开发/测试阶段投入大量成本与精力进行质量保障活动。但软件产品的质量问题不仅是在开发阶段引入，靠传统意义上的测试工作也不能完全发现。有相当比例的质量问题是在开发/测试阶段之后引入或发现的。造成这一现象的原因有以下几点。
通过引入自动化测试、测试驱动开发、持续集成等敏捷实践，开发/测试阶段的质量保障活动能够得到有效改善。然而对于客户和最终用户来说，不论哪个环节引入的缺陷都同样会给业务造成损失。如何在部署上线的紧迫压力下保证质量，这也是众多软件组织领导者关注的一个问题。
一些软件组织意识到这些问题的存在，希望以敏捷开发方法为出发点，将下游的发布、部署、运维等工作环节拉通，从而提升整体响应能力。但是由于软件开发与运营之间存在一些固有的差异，这样的拉通活动往往困难重重。
由于存在这些固有的差异，单纯从开发团队的角度出发、将敏捷软件开发的实践推广到运营团队，很难有效帮助运营团队改善；需要从运营维护工作本身的特点出发，引入符合客观情况的流程、技术和工具，才能有效改善运营维护工作的质量和效率。
针对现代大型软件组织在软件发布、运营与维护过程中面临的种种挑战，ThoughtWorks建议在软件组织中建设DevOps[3]能力，从而提升整个组织的IT融合程度，改善软件交付“最后一公里”的质量和效率，为实现业务敏捷打好基础。
DevOps是一组流程、技术与工具的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。“DevOps”这个名称即是指开发（Dev）与运营（Op）的无缝融合。具备DevOps能力的组织能够开展快速、反应灵敏同时又稳定可靠的业务运维，使其能够与开发过程的创新保持同步，从而使得敏捷开发的优势在组织层面上得到体现。
传统的软件运营人员通常倾向于尽量避免修改功能，从而降低满足非功能性需求的风险。但如果拒绝了小的修改，而给定时间段内需要修改的总量不变，那么每次变更的规模就会变大，从而增加每次发布的风险（因为变更涉及的范围更大）。
DevOps的指导思想是“精益运维”。精益生产的很多原则，例如缩短交付周期、消除浪费、重视价值流动、拉动式生产、质量内建等，在DevOps中都得到了体现。与传统的软件发布方式相比，DevOps主要通过以下几方面的改变来提升效率和质量。
图2 应用程序-以平滑的速率逐渐生长[4]
（1）用VMWare或Xen等虚拟化技术标准化生产环境，实现生产环境的快速复制和快速恢复。
（2）用Puppet或Chef等工具自动化环境设置、软件安装/配置等操作，将配置信息转化为源代码，实现环境配置的版本控制。
（3）用Capistrano等工具自动化软件产品的部署，实现部署过程的版本控制。
（4）用dbdeploy等工具自动化数据库变更，实现数据迁移的版本控制。
（5）用Selenium、Cucumber等工具自动化生产环境的冒烟测试和回归测试。
从工作流程、协调机制、技术工具等几个方面同时着手，就能在软件组织中建立起DevOps能力，从而将精益运维变成现实。
DevOps与敏捷软件开发同样具有精益的指导思想，在实践层面也有很多共通之处。可以把敏捷软件开发看作精益思想在需求、研发阶段的实施，DevOps则是精益思想在发布、运营阶段的实施（如图3所示）。尽管建设DevOps能力并不必须要求软件组织具备敏捷软件开发能力，不过以下敏捷实践会对DevOps能力建设产生尤为明显的帮助。
图3 DevOps与敏捷既相关又不同[5]
通过建设DevOps能力，软件组织能够明显提高软件产品发布和运营过程中的质量与效率。具体而言，可感知的收益包括以下几点。
Flickr是全球最大的图片共享网站。根据2007年的统计数据[6]，Flickr拥有超过850万注册用户，存放了超过30亿张照片，每秒钟响应4万个照片访问请求（如图4所示）。
图4 全球最大的图片分享网站Flickr每天有超过10次部署上线[7]
通过自动化基础设施、共享版本控制、自动化构建和部署、共享度量体系、强化沟通机制等手段，Flickr在保证网站稳定性和性能的同时，达到了每天能部署10次以上的需求响应水平，同时在开发团队与运营团队之间建立起了互相尊重、彼此信任的协作关系。
该网站从2000年开始运营，目前拥有超过3000万注册用户。随着业务发展，该网站的运营团队感受到来自业务负责人和最终用户的压力。根据ThoughtWorks所做的价值流分析，该网站从接纳一个需求到最终将其上线投入使用需要15～40天，其中超过50%时间是被浪费的（如图5所示）。
图5 通过价值流分析发现浪费[8]
ThoughtWorks帮助该网站进行了DevOps能力建设，尤其加强了基础设施自动化、环境自动化、测试自动化和部署自动化能力，同时改进了开发和运营团队的工作流程，使得典型需求的交付时间缩短50%以上，有效工作时间比达到90%以上，从而使该网站能够实现全面的业务敏捷。
DevOps能力建设是一项系统工程，很多方面的因素可能对其造成影响。以下列举几项最常见的风险。
软件的发布过程是一个整体系统，需要对其进行端到端的流程优化。ThoughtWorks采用精益价值流改善（Lean Value Stream Improvement）作为DevOps建设的框架，同时在其中嵌入针对软件构建、发布、运营的知识和实践，以迭代方式管理改善活动，全程以可视化形式直观展现工作进展状态，从而最大程度地保障改善得以成功实施。
[1] 《软件开发沉思录》，人民邮电出版社2009年，第二章。
[2] 图片来源：Damon Edwards的博客“什么是DevOps”（http://dev2ops.org/blog/ 2010/2/22/what-is-devops.html，或http://article.yeeyan.org/view/139515/170072）。
[3] Wikipedia的“DevOps”词条：http://zh.wikipedia.org/wiki/DevOps
[4] 图片来源：Wikipedia的“DevOps”词条（http://zh.wikipedia.org/wiki/DevOps）。
[5] 图片来源：Damon Edwards的博客“什么是DevOps”（http://dev2ops.org/blog/ 2010/2/22/what-is-devops.html，或http://article.yeeyan.org/view/139515/170072）。
[6] 数据来源：April 2007 MySQL Conf and Expo和Flickr网站。
[7] 图片来源：10+ Deploys Per Day: Dev and Ops Cooperation at Flickr （http://www. slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr）。
[8] 图片来源：ThoughtWorks内部数据。
经过大家的努力，我们的体验设计团队从年初的两人扩充到11人，分布在三地，更多新人的加入扩充了我们的能力，却也出现了新人个人成长的问题。受到Lean Canvas的启发，我尝试使用面向问题的方式，帮助新人在团队中找到最为合理的成长方向。
从解决方案出发的成长方式
组织内传统的成长模式往往是：我要成为行业专家或者我要成为某某某。包括我自己，在最开始我也是通过跟随ThoughtWorks的资深专家成长起来的。可是，经历了很多创业圈里事情后，我越来越发现，这跟创业团队把自己定义成“下一个Facebook”或者“乔布斯第二”的错误如出一辙——关注更多的是解决方案而非问题本身。
以成为“行业专家”为例，我们一直在讨论我们应该积累行业经验，鼓励分析人员成为行业专家。如果我们深入讨论“领域知识”就能发现，它是一种解决方案，它尝试解决的也许是以下问题。
那么作为单个个体时，真正发生的到底是什么问题？组织真正需要解决的又是哪个问题？解决的办法是否只有一种？
如果我们尝试解决第一个问题，那么还可能存在以下解决方案。
从解决方案出发成长方式的最终结果其实跟大多数创业失败的结果类似。
从问题出发的成长方式
精益创业中总是把对问题的验证放在首位，解决方案永远放在最后。我尝试使用Lean Canvas的模式去梳理从问题出发的成长轨迹。
把自己当作一种服务
在组织内的雇员本身就是一种服务，他提供某种资源帮助组织达到成功，同时从组织获得经济回报，从某种角度来说雇员和组织的关系是服务和客户的关系。
如果把自己当作一种服务，保证组织（客户）持续雇佣（买单）的核心在于个人的价值转化为组织的价值。那么和任何服务或产品创新一样，最核心考虑的是“需求匹配”——雇员是不是能满足组织的需求。
所谓的成长，就是保证自己作为一种服务长期保值。任何服务都存在贬值，这和市场需求度与供给相关，个人作为服务也是一样。特别像ThoughtWorks这样的专业服务公司，服务的贬值速度更甚，这对每位雇员产生了更高的成长要求。
保证自己服务长期保值的方式与商业上下文中保持业务竞争力如出一辙，无外乎以下几个方面。
下面五步是定义自己服务内容的基本步骤。
图1 五步定义自己的价值定位
寻找问题
这是定义服务的基础，作为组织的一员，你能解决组织什么样的问题？所有服务的设计将集中围绕在这个问题周围。
一个用心的人，会积极地在组织内发现问题，个人越能够解决这些问题，你在组织内的重要性就越高；个人越能够展示未来解决这些问题的潜力，你就能在组织内成为重点培养的对象。
找到问题的所有者作为客户
一个组织的问题都必然应对一个组织中的所有者，他们也是问题解决后的受益者。这些人通常根据问题的重要程度占据不同的位置，因此把这些人当成你的客户帮助你在组织里更有效地生存。在ThoughtWorks，这些应该是你优先选择的sponsor对象。
图2 新人在纸上写下自己的核心客户
设计解决方案
当你确定了问题和目标客户之后，在进入解决方案前，尽可能地和客户进行沟通，对问题的真实存在性进行验证，尽可能保证你在解决一个真实存在且有解决价值的事情。
对于解决方案的设计，你要尽可能设计得小一些，而不是用“行业知识”这样大而空的方案，这与在你漏洞百出的创业方案上加上“O2O”或者“社会化”标签一样没有意义。
与其说总结“行业知识”，不如把解决方案设计成一个帮助售前总结一个针对特点行业且能体现业务知识的解决方案。因为组织不在乎你是不是能成为“行业专家”，组织在乎的是当外部客户深入理解组织时组织是不是能够体现出“行业优势”。
明确不可替代优势
做自己不该做的事情是创业失败的主要原因之一，在自己已经有和可能有的优势上做自己能做的事情往往能避免一些不切实际的失败。
总结出你的优势，例如较高的情商、好的仪表、逻辑能力强、有视觉表达能力、英文优秀等，基于此回过头去看看之前设计的解决方案是不是可行。
另一种方式是和你的内部客户沟通，一起设计出一个面向实质问题的解决方案。
定义成功标准
创业中最常犯的错误是将目标定得过远，对成功的标准定得过高，导致产品长时间不上线，要么偏离用户需求，要么错过最佳的市场时机。
在这里，你需要和你的客户商量一个好的成功标准定义，例如如果你的解决方案是帮助售前总结一个针对特点行业且能体现业务知识的解决方案，第一个迭代的成功标准可能只是一个脑图。
通过定期对成功标准的检查，保证你的价值环在更短的时间达到闭合，个人对组织的价值得到验证，个人和组织的关系必然长久和稳固，双方才能得到双赢。
个人价值定位的一个例子
我们用一位新人的价值定位作为例子，参照这个例子，你也可以在你的组织内写出你自己的价值定位。
就像真正好的产品不是设计出来的一样，一个远大目标并不是产品成功的决定性因素，而更多的是依靠短迭代快速上线，收集反馈不断演进，一个优秀的产品在不知不觉中自然成型；作为组织内的新人也是一样，我们不需要一个远大的目标，而更多的是从解决组织内真实存在的问题出发，不断推出自己的解决方案，让自己作为一种服务模式为组织稳定提供价值。
最后，成长愉快。
为什么敏捷实施或是任何一点的过程改进都步履维艰？即使是十几人的团队，也会出现“写自动化测试”→“不写自动化测试”→“写自动化测试”→“不写自动化测试”这种循环往复的过程？
除了人们常常总结的“敏捷实施模式”或是“敏捷失败经验分享”这样的具体话题之外，是不是还有一些存在于思维模式中的更加根本性的因素阻碍了我们对系统全景的认知，从而导致改革先行者的黯然退场？
本文将通过两个案例来讲述如何使用系统思考从全局掌握我们所处的复杂环境，做到既见树木，又见森林。
有一个测试团队的负责人找到我们说：“我觉得现在的自动化测试问题很大，执行时间长，也不稳定，有的时候是测试写错了，也要花很长时间修。我打算组织一批人，重新设计一下测试代码的架构，把常用的底层功能封装成设计良好的API。”
我的同事说：“好啊，你们打算怎么做呢？”
他说：“我也还没想好，所以想过来商量一下。我希望这个东西做成以后，能够让不会写程序的QA们都能用它来写自动化测试脚本。他们现在就是又要做测试，又要学着写程序，我觉得太辛苦了，能让他们不用学编程就能写测试脚本就好了。”
“呃……要不我们先看一下现在的代码，了解一下都有什么问题，然后再讨论？”我们内心有点小小的纠结。
“好吧，我来给你们开通访问权限，找人给你们讲代码。”他很爽快地答应了。
打开代码之后我们就忍不住风中凌乱了，满屏都是重复的代码片段，让人一阵阵眩晕。两天之内，我们仅仅用了“提取方法”这一个重构手法，就删掉了1200行代码。期间我们还发现，不知道谁在调试的时候把一处代码从等待3秒改成了等待10秒后忘了改回来，于是其他人再复制粘贴的时候，就全变成了等待10秒。
于是事情就明朗化了。
依赖于一小拨人重新设计代码结构、提炼API，确实会在短期内使问题得到缓解。但使用这些API的人依然是那些不懂得如何编程的QA，他们依然会使用复制粘贴来解决问题。再好的架构、再优秀的设计，最终还是会淹没在大量重复的代码中，犹如黄金深埋于浮沙之下。而且如果问题表象得到暂时解决，人们就会缺乏动力去从根本上提升QA的编码能力，随着设计一点一点腐化，就又需要精兵强将充当救火队员。如此反复，直到有一天又回到重新设计乃至重写的老路上来。
这是个典型的“舍本逐末”的模型。
在上面的场景中，对于“测试代码质量低劣”这个问题有两种解决方案，一种是精兵强将解决，另一种是测试人员自己解决。每一种方案都会减缓代码质量不断下滑的趋势，从而让系统处于一种平衡状态，如下图所示。
图中的“S”表示同向连接，即箭头起点所示变量的增长会导致另一方变量的增长；“O”表示反向连接，即箭头起点变量的增长会导致另一方的减少；天平表示调节环路，该回路会趋于平衡稳定。
由精兵强将出马可以让问题症状迅速得到缓解，但是提升测试人员的编码能力则需要长期的辅导训练，不可能一蹴而就，所以图中下方的调节环路实际上是有时间滞延存在的。
与此同时，由精兵强将解决问题会减少测试人员锻炼的机会，从而削弱测试人员的编码能力，进一步使人们不倾向于让测试人员自己解决问题，又反过来增强了对于精兵强将的依赖，所以还要在图中增加另外一条回路。
滚雪球表示增强环路，该回路会使得回路上的所有节点持续增强。
这幅图的全貌便构成了“舍本逐末”的模型。彼得·圣吉在《第五项修炼》中对此解释到：上面的环路代表快速见效的症状解，它迅速解决问题症状，但只是暂时的。下面的环路包含了时间延滞，它代表较根本的解决方案，但其效果要较长的时间才会显现出来。然而它可能是惟一持久见效的方式。有时候舍本逐末的结构中，会多出一个由症状解所带来的副作用所形成的增强环路。发生这样的情形时，副作用常使问题更难以解决。
人们或者是因为没有找到问题的根源，或者是因为时间延滞的存在，倾向于采取一种简单易行又可以立竿见影的方案，这便是症状解了。但是症状消除以后，问题就不再令人重视，从而丧失了从根本上解决问题的能力，而问题依然深藏；等到它有一天再度浮上水面时，症状就会更重，更难解决。
这是一条不断衰减的增强环路，在回路上每走一步，情况就会更恶劣一分。
面对“舍本逐末”，通常的解决方案有两条。
（1）必须要认识到症状解只是短期止痛的手段，切不能形成依赖。
（2）在症状得到缓解之后，要继续加强对根本解的重视。
但见招拆招总是相对容易一些的，更关键的是，如何才能识别出“舍本逐末”这样的模型？当我们采取某些理所当然的对策却得到了不合理的结果，有什么办法可以帮助我们分析问题根源、找到解决方案？
要认清问题的本质，就必须要认识到，我们所处的是各个因素之间紧密连接相互影响的复杂系统。当前采取的行动会从多方面对这个系统产生影响，而这些影响之间或推波助澜，或相互牵制，从而导致相同的行动在长期和短期来看具有不同的结果。
比如，当代码中发现bug的时候，很多人的常见反应都是“调试→定位→解决”这样的思路。从眼前来看，发现bug立即修复是可以最快见效的手段，但却丧失了将测试进行完善的机会，相当于是安全网上明明出现了漏洞却听之任之；等到以后因为需求变更等原因影响了这块代码的时候，就再也无法通过执行测试来得到快速而完整的反馈了。
丹尼斯·舍伍德在《系统思考》中说过以下的话。
如果你希望了解一个系统，并进而能够预测它的行为，那么，就非常有必要将系统作为一个整体来研究。将系统各部分割裂开来研究，很可能破坏系统内部的连接，从而破坏系统本身。
如果你希望影响或控制系统的行为，你必须将系统作为一个整体来采取行动。在某些地方采取行动并希望其它地方不受影响的想法注定要失败——这也就是连接的意义所在。
为了帮助人们更好地从整体上研究复杂系统的行为，丹尼斯在书中提供了一套完整的工具——系统循环图。
系统循环图中共有三个基本要素。
（1）增强环路。在增强环路中共有偶数个O型连接，增强环路上的各个节点会呈现指数增长或指数衰退。
（2）调节环路。在调节环路上共有奇数个O型连接，调节环路上的各个节点会趋于平衡状态。它会消化掉外界的影响力，使改变难以发生。
（3）时间滞延。时间滞延是一个不容忽视的影响力，由于滞延的存在，人们常常会发现某个行为在短期内没有产生预想的结果，从而加大投入力度，当行为的后果出现在眼前时，却已经矫枉过正。
下面我将通过另一个真实的案例来讲述“系统循环图”的应用。
一天中午，我忽然听到有人说：“我们又开始讨论要不要放弃自动化功能测试了。”
“咦？你为什么要说又呢？”我忍不住问道。
“因为我们半年前已经讨论过一次，当时得出的结论是不再写自动化测试了。后来不记得是什么原因了，又用Cucumber来写，最近发现每次上线还是要做大量的手工测试，这些自动化测试又要浪费很多时间来修，所以我们准备讨论一下到底还要不要继续写。”
当天下午，我参加了这个团队的讨论，终于弄清楚了事情的来龙去脉。
大概是一年前，为了减少手工测试的成本，团队决定一步步把上线时需要手工回归的测试用例转换成自动化，同时决定每个story做完以后都要加入自动化测试。研究了几天webdriver以后，就开始了自动化测试的尝试。
但麻烦很快就出现了。第一，开发人员用Java代码写的测试，QA不好理解，也不是很清楚哪些场景被测试覆盖到，哪些没有，所以无法信赖测试结果；第二，测试跟开发共享一套数据库，数据总是受到污染，因此造成测试失败，浪费大量定位和修复的时间。而数据库是由国外的客户控制的，催促了很长时间也没能给测试分离出一套专用的数据库来。
测试红啊红，修啊修，后来一算时间，在自动化测试上投入了120多人天，依然得不到一套稳定执行的测试用例，不但没办法保证交付质量，还让每个人心力交瘁，于是毅然决然的停掉了。
过了两三个月，客户终于准备好了一套专门用来跑功能测试的数据库，开发团队也对行为驱动开发有了一定的认识。于是他们又开始写自动化测试，这次用了Cucumber，QA写场景，Dev写实现。
写了大概100多个场景的测试后，又有人开始质疑这一切。第一，整套系统实在是太庞大复杂了，写到现在，连1/4都没覆盖到，所以应该上线还是手工回归？到底要花多大的精力才能把所有的场景都自动化起来？这些投入是不是值得？第二，测试环境还是不稳定，比如本地数据跟CI用的数据不一致，比如Tomcat里面部署的应用常常启动不起来，等等。每个问题都要消耗大量的人力。这些浪费能不能平衡自动化测试到最后能够带来的收益？
但团队中还有其他人对自动化测试持乐观态度，认为问题总是可以解决的，只要坚持不懈就能够看到长期的回报。于是就有了这次讨论。
绘制系统循环图的第二条法则是：“从有趣的地方开始”。在这个案例的场景下，开发团队最关心的是该不该写自动化测试、它对交付能力会带来什么影响，于是我们选择“自动化测试的数量”作为起始点。
接下来是第三条法则——“询问‘它将驱动什么’，以及‘它的驱动力是什么’”。
我们首先可以想到的是，自动化测试的数量增加会缩短发现Bug的周期，但是这个作用是需要测试数量积累到一定程度才会发挥出来的。它同时还会增加测试的开发和维护成本，增加测试执行时间，缩短手工测试周期，如下图所示。
手工测试周期的缩短会带来交付周期的缩短，提升产品收益，从而使人们更倾向于编写自动化测试。于是图中就出现了一个增强环路。
而测试的开发维护成本增加会导致开发进度放缓，从而削弱收益，于是图的下方出现了调节环路，这条调节环路的存在会阻碍人们在自动化测试上的投入。
与此类推，我们同样在图中可以发现其他的增强环路与调节环路。
而在这四条回路之外，还会有其他因素对这个结构造成影响，如图所示。
画出系统循环图以后，我们就可以结合团队的状况进行整体分析。
首先回到质疑的声音上来，有人说“整套系统实在是太庞大复杂了，写到现在为止，连1/4都没覆盖到，所以上线还是手工回归”，这里反映出的正是从“自动化测试数量”到“手工测试时间”这条线上的时间滞延的效果。在前面我们提到过，时间滞延在反馈环路中会造成矫枉过正，这里是它的第二个作用——给人带来挫败感。它会导致某个行为在短期内看不到任何效果，当滞延的时间过长时，会令人失望乃至放弃努力。消除时间滞延可以对系统起到卓有成效的改善。在这个案例中，我们可以通过推动手动测试用例向自动化测试的转化来缩短滞延。
然而，当时间滞延的作用被削弱以后，还有另外的问题等着去解决。下面我们再来看看这支团队从“写自动化测试”到“不写自动化测试”的变化过程中发生了什么。
在刚开始写自动化测试的时候，团队主要的感受是QA少了手工测试的时间，质量多了保障，所以增强环路发挥了作用，每个story完成以后，开发人员都会为所对应的场景写几个测试。但当测试数量增加到一定程度，调节环路的反馈力量开始占据主导地位——测试时间变长、维护成本增加，而且测试数量越多，带来的问题就越大，最后便有了第一次的选择：放弃自动化测试。
这正是《第五项修炼》中描述的“成长上限”模型——
增强环路导致成长。成长总会碰到各种限制与瓶颈，然而大多数的成长之所以停止，却不是因为达到了真正的极限。这是由于，增强环路固然产生快速的成长。却常在不知不觉中，触动一个抑制成长的调节环路开始运作，而使成长减缓、停顿，甚或下滑。
……
当改善的速度慢下来，你会更加努力地去改善。但渐渐的，你愈是用力推动你所熟悉的做法，调节环路的反作用愈是强烈，使你的努力愈是徒劳无功。到了最后，最常有的反应是放弃他们原来的目标。
所以，当我们观察到有增强环路与调节环路遭遇的情况出现时，更为有效的解决方案应该到调节环路上寻找。在上面的系统循环图中，“测试环境稳定性”、“开发人员技能”可以限制“测试的开发维护成本”，“硬件数量与质量”可以限制“测试运行时间”。我们可以通过控制这些在调节环路之外起作用的因素，削弱调节环路的影响，让增强环路的成长继续开始。
结构决定行为。增强环路总是产生指数级的上升或衰减；调节环路总是倾向于使整个环路趋于平衡状态；各种环路的相互影响，就会产生“舍本逐末”、“成长上限”或是“饮鸩止渴”等基本模型。
然而不幸的是，参与系统的各个部分常常见树不见林，只能针对眼中见到的局部信息做出局部的最佳决策。但每个人的局部最佳决策并不能构成整个系统的全局最佳决策。因为系统中有反馈、有延迟，因和果在时空上并不紧紧相连，显而易见的解往往无效。
在纷乱芜杂的因果关系中，使用系统思考可以帮助我们理清问题的脉络，认识系统全貌，从而进一步寻找有效的杠杆解——比如案例2中的限制调节环路；而不是固囿于局部优化，把环状的因果关系割裂成线段，看不到当前采取的行动会在未来反作用于自身，因此导致各种系统问题的出现。
系统循环图是一个很强大的工具，但一个人的视野总是有限的，用头脑风暴的方式往往可以得到更全面的认知。案例2的图形就是小组讨论的结果。只是这种方式需要引导者时时注意控制讨论的边界，不要偏离重心。
本文通过两个实际案例对系统思考的基本概念进行了描述，同时讲解了如何使用系统循环图对一个复杂系统进行分析，对这方面知识感兴趣的读者可以通过《系统思考》和《第五项修炼》这两本书进行深入研究，学会用这套工具来指导持续改进的步伐。
作为ThoughtWorks的一名咨询师，我曾不止一次地被问到ThoughtWorks的交付项目和一般意义上的外包到底有何区别。要区分差别，首先要对外包加以定义。外包从最传统的IT外包到业务流程的外包以及最近几年新兴的知识流程外包，其本身的定义也在不断地演化。每种外包有其不同的诉求，传统的IT外包和业务流程外包追求成本的降低，而知识流程的外包则更着眼于客户知识能力的提升以及团队的成长。
ThoughtWorks的交付项目更多的是一种知识流程外包的高端服务。交付项目的成功不仅是交付卓越的软件，还需要在交付卓越的软件的过程中，深刻理解客户的市场需要和业务模式，而且通过自己的努力去影响客户，最终和客户以一个团队的模式一同交付高质量的软件。而怎样去影响客户的行为、进而鼓励他们去尝试更多最佳实践呢？是否只能通过咨询项目达到这个目的呢？一般来说，咨询需要长期在客户现场进行持续影响才能产生效果。但交付项目如同很多外包项目一样，通常是离岸的。那么隔着十万八千里的距离，再加上几个小时的时差，如何才能真的像一个团队一样紧密合作并且持续地影响客户尝试更多最佳实践，一步步实现交付卓越软件这一目标呢？沟通，就是基于知识流程外包的分布式开发中最大的挑战。
正如前面所说的，我们有着地理上的距离，这就意味着我们可能会有巨大的文化差异。客户说“还可以”，可能意味着其实有些问题。如果说东西方的文化差异可以通过了解当地的风俗民情去理解的话，那么企业的文化差异就需要一些同理心了。作为一家“不创新就会死（Innovate or Die）”的先锋企业，我们的咨询师通常是勇于尝试、热衷创新的；而我们的客户却很有可能是拥有庞大的组织结构的传统企业，做任何一点改变都需要考虑所有部门利益，甚至很长时间都难以做出一个决定，这和我们的快速反馈原则往往都是不相容的。
所以沟通毫无疑问会成为分布式开发最大的挑战。通过多个分布式开发项目，我们总结出以下几个最佳实践。
快速启动中，所有的项目干系人通常会聚集到一起，在两周左右的时间中进行一系列的愿景分享、业务探索、产品设计、需求收集以及计划发布等活动。
快速启动的目的首先是让大家聚到一起。作为可能要合作上几个月甚至几年的队友，虽然之后很长一段时间大家天各一方地工作，但在启动阶段能够认识彼此，通过面对面的沟通对对方的工作有感性的认知，无疑会对于后面工作的展开起到重要作用。
快速启动通过两周密度较大的活动，让每个团队成员在尽可能短的时间内达成共识。这包括了解战略愿景，进而理解项目的机遇与挑战；通过和市场人员的沟通去理解客户需要；和产品部门一起设计出符合客户体验需要的产品原型，进而拆分出可开发的需求；根据优先级排列并发布计划。
在两周的时间里，团队将一个商业概念转换为形象的原型并制定可供开发使用的发布计划，快速启动的交付物无疑对于后面的开发阶段非常重要，而更重要的是快速启动的交付物是整个团队一起工作产出的。每个人都参与了产生的过程，分享了相同的上下文，这对于后面的开发阶段的有效沟通会非常有帮助。
在快速启动之后，团队一般就可以开始进入迭代0的开发了。在迭代0中，所有团队成员能继续一起工作，在这个较短的迭代搭建好环境，对架构都形成共识，试着在迭代0里去完成一个基本的需求。
快速启动和迭代0这段时间中，所有团队成员紧密合作，不光对于交付软件有所帮助，也能更好地让咨询师理解客户团队的工作习惯、技术水平和代码风格，进而评估哪些最佳实践是适合客户团队的。比如我曾经参与过的一个项目中，在快速启动阶段，我们发现客户团队的很多基本实践（如TDD）已经做得很好，代码水平也很娴熟，但部署的方式却很落后。同时，业务部门的需求明显需要持续交付来支撑，于是持续交付就成了重点尝试的实践。每个项目都具有自己的独特性，所以通过快速启动的方式，用最快的速度了解客户的知识流程上需要改进的地方，这样跟客户沟通的时候，才会让客户更加认同知识流程外包的高附加值。
相信了解敏捷的人对站会这一实践都不陌生。在分布式开发过程中，我们不仅开展了团队的站会，还进行了基于角色的站会。一般而言，团队的站会更多地关注故事卡的状态流动，检查路障，而不会关注每个不同角色的具体工作；而在基于角色的站会上，例如开发站会上，开发人员之间可以讨论技术上的某个难点。同样，业务分析人员也要通过每日的业务分析站会来了解产品经理的思路变化和业务部门的更新。我曾经遇到过一个项目有来自三地的测试人员，那么测试人员之间的站会就非常重要，测试人员利用角色站会这一机会讨论测试策略。随着项目的演进，测试的重点也不断转移，从一开始关注功能测试到逐渐关注集成测试，角色站会给他们提供了一个契机，可以及时讨论项目碰到的问题和机会。
迭代计划会议也是常见的实践。在分布式的场景下，迭代计划会议需要更多的准备，要求各方团队成员提前理解下一迭代需要完成的需求，这样大家可以在迭代计划会议的时候着重讨论有疑惑的需求，而不是浪费很多时间在解释需求本身是什么上。在答疑解惑之后，大家对要完成的迭代目标必须形成一致的意见。同时，在分布式的开发中，不同地域的团队成员会更加关注本地团队所能完成的需求，却忽略了其他地域团队的开发速度。在其他地域团队遇到困难时，更重要的是要帮助对方一起完成对方做的需求，而不是只关注自己做的需求。通过一起达成迭代目标，让大家分享共同的责任感。
在实际项目过程中，通常业务分析师会提前将计划的需求故事发给团队成员。运用合适的分布式项目管理工具会让这一过程更加容易，如Mingle或者Jira。我们可以在工具中整理出下一个迭代的故事墙，让团队成员提前看到虚拟墙。在迭代计划会议上，主持方将虚拟墙打开并屏幕共享给其他方，这样各方就可以关注在同一个需求故事卡的讨论上。
由于各种限制原因，分布式团队很容易产生沟通不足现象。而回顾会议创造了必要的沟通桥梁，因而非常重要，一定要保证所有方都能参与进来。远程回顾会议通常利用在线白板，让每个成员提前在在线白板上提交上一个迭代里做得好的和需要改进的地方。这样，当回顾会议开始后，每个人都是有所思考的，提出的意见更有深度，而且也可以更好地利用回顾会议的时间一起探讨所有人都关注的问题。通常，通过回顾会议我们可以发现，处于不同地理位置的多方成员往往关注的事情也不同，而会议上各方成员又可以了解对方在担忧什么、遇到了哪些困惑并将这些担忧困惑分享，形成大家都认同的改进行动。
结对编程这一实践对于知识的传递非常重要，即便在分布式团队中，结对编程依然是非常重要的实践。合理地利用时差，在各方重叠的工作时间里通过屏幕共享工具远程结对，是保证代码质量的重要手段。
每天合理地利用远程结对不光可以传递知识，同时也是一种有效地影响其他团队成员的方式。远程结对可以让咨询师清楚了解处于不同地域位置的客户团队的代码水平、代码风格和思维方式，从而可以通过每天频繁地结对编程言传身教最佳实践。这种影响行为改变的方式效果显着，而且对于增强团队成员互相了解信任并形成有统一责任感的“同一个团队”非常有帮助。
但不可否认，远程结对会影响开发效率。同时，由于各方工作时间安排以及公共假期等原因，很难保证远程结对的频率。所以，远程的代码评审（Code Review）就显得格外重要。每天各方开发人员在一个固定时段去评审所有提交的代码，能够让团队成员不光关注自己，也了解别人做了哪些代码改动。同时，代码评审对于形成统一的代码风格也很重要。当处于远端的咨询师想去影响客户的代码风格时，如果无法让所有的人都理解为什么要用某种风格，那么之后的一致性也就无从谈起。而远程代码评审就能在沟通不足的条件下，充分展示好的风格带来的改进（Lead By Example），从而达到提成远程提升客户技能的目的。
在分布式开发中，我们依然遵循基本的实践，同时为了克服远程开发沟通不足的缺陷并达到整个团队能力提升的目的，我们更关注建立沟通渠道和及时地分享。所有的实践在满足基本的目的之后，我们都要考虑是否能通过这一实践分享知识以及获取知识的正确方式，客户成员是否能得到能力的提升。
除了沟通这一挑战之外，分布式开发环境当然还有其他各种挑战，如如何远程地让团队保持足够的凝聚力，让大家不因为距离而产生陌生感？所以，经常在工作之余进行一些适合远程的团队游戏，定期邀请各方成员去对方工作的地方工作几周，体会对方的工作环境，能够更好地帮助团队保持一致的目标。此外，分布式团队模式下的项目也有需要关注的特有的风险，如各自国家的成员有不同的公共假期，最后的部署上线如何安排等细节都需要去关注。
由于基于知识流程外包的分布式开发追求交付的成功以及团队的成长，面对不同的客户团队就会有不同的挑战。作为咨询师，在关注软件交付本身的同时，更要关注如何提升团队的能力。通过以上这些实践我们不难发现，虽然依旧采用敏捷的基本实践，但在分布式开发的场景下，适当地改进基本实践，才能真正实现高附加值的卓越的软件交付。
本文结合热销图书《精益创业》中的核心观点，清楚地阐释了精益创业和敏捷之间的内在联系，而且在文章结尾得出结论：精益创业和敏捷开发双剑合璧，才是创新型企业成功进阶的利器。
2011年9月，一本题为《精益创业》（The Lean Startup）的书风靡硅谷，不仅仅是硅谷的创业者，很多产品和技术人员甚至管理层人员也都人手一本，开始琢磨精益创业理念。该书的作者Eric Ries，一位曾经的硅谷创业者，成为了热点人物，被邀请到各种场合，发表关于精益创业的演讲。各种有关精益创业的讲座、课程和工作室（Workshop）也应运而生。不久前一个名为“精益创业画布”（Lean Startup Canvas）的活动在上海举办，吸引了众多国内创业人员的参与。
新瓶旧酒还是新兴学说？
在回答这个问题之前，让我们先回顾一下目前常用的产品设计方法。
一个新产品的推出，可能是灵机一动的产物，也可能是大量市场调查的结果，不过能否被市场接受，只有用户说了才算。
鉴于此，很多软件企业和互联网企业采用了“产品原型”或者“概念验证”的方式。在早期搜集用户的反馈，从某种程度上降低了产品方向性错误的风险。然而，产品原型和概念设计体现的是当时对用户和市场的理解，有些关键需求可能没有在产品原型中体现；在快速变化的市场面前，当初被认可的设计有可能很快就不再适合。
以上这些方法的局限性，使得企业依然要承担很大的产品设计风险。有没有一种方式能以市场和用户为导向，快速灵活地根据用户需要，适时调整设计方向，从而做出为市场认可的产品呢？有人可能很快回答：敏捷方法。但这样的回答只是部分正确。
我们先来看看精益创业是如何应对这些挑战的。
Eric Ries在他的书中指出，精益创业的关键在于避免因路线错误而造成巨大浪费，通过建立一种开发、评估、学习（Build、Measure、Learn）的文化和机制，快速假设、快速验证、快速调整，有序地进行产品演进和开发。
这里的一个重要前提假设是:我们不知道用户真正需要什么，我们也不清楚适合用户的产品或方案什么。因此，我们来作出一些假设，通过验证这些假设，来找到正确的方向。很显然，我们要作出的第一个假设就是“用户假设”——假设用户有着某种需要。为什么用户会有某种特定的需要呢？这就引出了我们要作的第二个假设——“问题假设”，假定用户遇到了问题（“痛点”）。有了问题，自然会有第三个假设——“方案假设”，假设我们的方案能解决用户的问题。我们的精益创业课程中经常会用到一个例子说明这三种假设的关系（如表1所示）。这个例子是设计一种打扮宠物的工具。
表1 三种假设的关系
| 假设类型 Hypothesis Type |
假设举例 Hypothesis Example |
待验证前提举例 Assumption Example |
|---|---|---|
| 用户假设 | 我认为用户有为宠物打扮的需要 | 有的宠物主每个月都要为自己的宠物定制一个小饰品或服饰 |
| 问题假设 | 我认为我的用户在打扮自己宠物过程中不知道该怎么做 | 宠物主认为准备这些东西很麻烦，浪费时间 |
| 方案假设 | 我认为我的用户会愿意使用我们的工具打扮自己的宠物 | 宠物主会支付一定的费用来避免这些麻烦 |
从这个例子可以看出，产品是否有市场，关键在于三大假设是否成立，其中任何一个被推翻，都将颠覆原有的产品方向。《精益创业》把验证用户假设的过程，称为“客户开发（Customer Development）”和“验证学习（Validated Learning）”。还是以宠物打扮工具为例，我们说明一下验证假设的方法（如表2所示）。
表2 验证假设的方法
| 假设类型 Hypothesis Type |
实验类型 Experiment Type |
举例 Example |
|---|---|---|
| 用户假设 | 抽样调查；问卷调查；社交网络调查 | 问卷调查显示有85.2%的用户表示有宠物够来特制衣物的习惯 |
| 问题假设 | 搜素数据分析；网站用户行为分析报告；用户访谈 | “宠物衣服布料在哪里买”的关键字搜索结果达到七千万条 |
| 方案假设 | 最小产品集合（Minimal Viable Project，MVP） | 有10位客户为所展示的最小产品集合提前付费 |
可以看出，验证假设包含技术的和非技术的方法。最小产品集合（MVP）与产品原型的概念类似，其他市场调查、数据分析及用户访谈等方法，都是高效低成本的有效方式。精益创业主张尽量用非技术方式，经济快速地验证假设，及时作出变化和调整。一次验证一个假设。比如，一旦抽样调查的结果显示大部分宠物主没有给宠物购置衣物和打扮的习惯，我们就要立刻考虑是否还要继续这个产品。
当用户假设和问题假设得到相当程度的验证时，我们就可以开始定义并设计开发MVP了。《精益创业》特别强调，MVP不仅存在于产品早期，第一个MVP即使得到用户认可，也不意味着后续的设计和开发就要完全按照第一个MVP的思路走。相反，只有持续不断地通过迭代式演进，持续收集最终用户的反馈，不断调整产品设计、架构、定位和商业模式甚至是销售渠道，才可能最终做出成功的产品。换句话说，MVP是一个系列的产出，在产品的不同阶段，都会有相应的MVP。在整个过程中，不断地调整和变化（Pivot）是关键。
图1中的“数据”指的是各种市场和用户反馈的数据。学习的过程就是根据反馈调整创意和设计的过程。经过验证的学习，就是精益创业的核心理念之一——Validated Learning。
图1 开发、测量、学习的循环过程
精益创业vs.敏捷——流派之争还是双剑合璧
敏捷开发以人为核心，以价值为驱动，通过迭代、循序渐进的方式开发软件产品。在开发过程中，它强调每个迭代都产生可工作的软件供用户反馈并及时作出调整。为了做到这一点，敏捷方法通过测试驱动开发（TDD）、持续集成（CI）、结对编程（Pair Programming）、重构（Refactoring）等极限编程（XP）实践来确保高质量软件的及时交付。敏捷方法所倡导的可工作软件、迭代开发和持续反馈的理念与精益创业所追求的MVP、步步为营、不断试错的精神具有很高的契合度。但两者又不尽相同，以下是前面的问题答案“部分正确”的原因。
首先，两者的侧重点不同。精益创业的目标是快速、低成本地验证各种和产品设计相关的假设，避免造成产品上市后无人问津的后果。而敏捷方法的目标是通过迭代式开发，以一系列工程实践（XP）为基础，交付出高质量的软件。
其次，两者要解决的问题也不同。精益创业要回答应该做什么产品的问题，而敏捷方法要解决的是如何做好产品的问题。精益创业的各种实践，假设、验证、测量、调整等，都是围绕着“什么是用户真正需要的产品”展开的，其中大量的是非技术性的实践；而敏捷方法，除了迭代开发、敏捷发布计划、回顾等管理实践外，还有大量的工程实践，为的是做出高质量的产品。
从产品的生命周期看，精益创业更侧重前期的客户开发（Customer Development），通过发掘客户（Customer Discovery）和验证客户（Customer Validation），找到产品准确的市场定位和符合用户要求的设计。敏捷方法通常是在产品定位相对清晰之后，通过1～2周的快速启动（Quick Start），制定出迭代开发计划，然后在开发过程中逐渐完善需求。
既然精益创业和敏捷有这么多的差异，我们是否能认为精益创业是颠覆敏捷的新方法呢？在精益创业的理念推出后，的确有人提出了“敏捷已经过时，现在进入精益创业时代”的口号。我认为，敏捷方法非但没有过时，反而因为精益创业的提出，获得了新的动力。如果说敏捷方法是指导企业如何用正确的方法生产产品，那么精益创业是教大家如何找出正确的产品来生产。精益创业和敏捷结合，就是一个完整的方法论：“如何用正确的方法来生产正确的产品”。敏捷是精益创业的自然延伸，精益创业是敏捷的自然拓展。一个能成功实践精益创业的企业，前提是它已经足够敏捷，否则企业无法落地经过验证的创意，甚至不能有效地小步快跑，完成持续验证的过程。
价值回归——一个现实中精益创业和敏捷开发相结合的故事
REA（www.realestate.com.au）是澳大利亚最大的房地产垂直搜索和广告平台，几年前成功实现了敏捷转型。搜索和相关广告业务的成功，使REA产生了利用长尾客户拓展业务方向的想法。落实这一策略的方向之一就是建立一个子站，展示各种房屋的内部装修，以吸引原有客户甚至是新客户来浏览精美的房屋装修图片，然后通过页面上的装修和家居广告赢利。经过半年多的努力，新的子站成功上线，但访问量和广告的有效点击低于预期，经过一段时间的运营后仍然没有明显起色，以致管理层产生了砍掉项目的想法。
这时，我们与REA项目组的主要成员开始通过Workshop的形式一起探讨产品策略。我们都认为精益创业的思路能解决当下的问题。
我们从网站的定位开始，对原有的各种假设一一进行梳理。例如，项目组原先设想买了房子的客户应该有装修的需求，但网站的表现并不支持这一假设。当我们把当初的各种假设一一列在白板上，然后检验哪些经过了验证时，发现直到产品上线，很多还是停留在假设阶段，没有经过任何的验证，更不用说如何结合REA的现有资源发挥协同优势了。思路明确后，Workshop的一项重要产出物也形成了:假设清单（Hypothesis List）。该清单既有策略层次的假设，例如购买房子的客户在装修时是否来到这个子站寻求信息，是否有非购房用户直接来到这个子站；清单还包括了战术层次的假设，如用户社区的建立是否能帮助用户更好地作出采购决定；清单也有产品体验细节的假设，如图片分页浏览的体验是否好过图片搜索和过滤。
首批假设清单的建立，为下一步的行动定下了基调。这时，我们开始采用敏捷开发方式。当一个假设需要开发支持时，开发团队能很快完成高质量的代码，更通过一键式部署将功能很快上线，然后根据网站数据和用户反馈调整设计，再通过开发团队实现。整个设计、开发、部署、验证、调整的过程完美体现了图1所展现的循环，同时将每个循环的周期压缩到了最小，甚至以天而不是周来计算。随着越来越多经过精益创业方式验证的设计被采纳，网站表现开始改善，项目也得到了保留。
仅有好的工程实践不是做出好产品的充分条件，好的创意和验证体系也不能保证设计都能完美实现，只有创意、验证加上工程实践的紧密结合，才能做出用户认可的好产品。精益创业和敏捷开发的双剑合璧，才是创新型企业成功进阶的利器。
施韵涛
ThoughtWorks中国区客户和交付总监，负责软件交付项目的管理和业务拓展工作。他曾任职于德国SAP公司，还曾担任美国TRADOS公司中国区首席代表。
我——作为一名测试人员——有一个与众不同的习惯：每当要加入一个新项目的时候，我总会找到项目中的同伴，真诚而亲切地说：“为了更好地合作，我有5个约定，希望大家能尽量遵守”。
约定1．业务分析师们，我们其实是同一个角色的两种面孔，请叫上我们参加客户需求会议
我们的团队需要让客户频繁地得到可用的软件，客户的不断反馈会给软件的未来做出最正确的方向指引。
如果我们交付的软件有很多质量的问题，存在大量的缺陷，客户会被这些缺陷的奇怪行为干扰，没有办法把注意力放在软件本身的价值是否符合他们的真正需求上，不能给出最有价值的反馈。所以，我们只有频繁地做测试，在每次交付之前都把质量问题找出来告诉我们的团队，问题才能及时地得到改正。
而我坚信“prevention is better than cure”（预防胜于治疗），我会要把工作的重点放在预防缺陷上，这样可以节省Dev们很多修复缺陷的时间与精力。
为了达到这个目的，我需要跟你一起参加客户需求会议，尽早地了解客户需求与使用软件的惯常行为。这样在你完成需求的验收条件的定义时，我也基本完成了测试用例的准备。
我们可以赶在开发人员们写代码之前就告诉他们我要测什么，让他们避免因为过于乐观而漏掉的一些重要的有破坏性的情况，减少缺陷的发生。这是我测试的一项重要任务。
如果你们在大部分需求都整理好了之后再交给我们，我会浪费掉等待的时间。更重要的是，开发好的软件里面已经有很多本来可以不存在的缺陷了，开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷。
所以，请让我尽早了解需求，请不要让我到项目后期才能开始测试。
约定2．开发人员们，虽然你们是编写自动化测试的专家，但请听听我们的意见
我知道，对于你们，自动化测试不过是利用JUnit、RSpec、Selenium、Watir、UIAutomation等写出的“另一段程序”而已。而对于80%的QA来说，编写自动化测试并不是一件简单的事情。
不过我仍然相信，有测试人员介入的自动化测试更有价值。
你们用单元测试、集成测试来保证代码的质量。然而你们的这些日常测试离代码更近，离最终用户还有点远，很多测试都不是在测软件功能。
你们可以把功能测试写得又快又多，而我们可以指出什么功能测试最有必要加到自动化测试中。
你们平时大部分精力都在编码上，没有太多时间去查有什么缺陷。而我们可以指出什么地方缺陷可能会出现得比较频繁，建议在这些脆弱的地方加自动化测试。
所以请听听我们的意见，我们可以给你们提供这些信息。
约定3．项目经理们，请不要要求我们测试软件的所有路径
软件测试是一个永无止尽的任务。基本上没有什么软件简单到我们能够尝试完它的每一个可能的路径。就连一个看似简单的微软计算器都有无穷尽的路径、无止尽的输入，更何况比这个更复杂的商用软件。
如果你们担心没有尝试过全部的路径不可靠，疑惑我们怎么敢说这个软件质量是好还是坏，都有什么风险。请你们先注意，我们是跟业务分析师一样，都了解软件的价值。价值可以帮我们作出判断，什么时候可以停止测试并对客户说“我们的软件已经满足您的要求了，请放心使用。”
因为我们了解价值，我们可以肯定地说哪些软件的使用方式是至关重要的，哪些是不太可能出现的。我们会在全面测试了软件以后，把主要精力放在价值高的功能点上，合理地利用项目有限的时间。
因为我们了解价值，我们可以把发现的问题正确地分类。我们可以帮助Dev们把精力放在重要的缺陷上，避免把时间放在对于客户微不足道却不得不花费大量精力才能修正的问题上。
所以，请不要要求我们无止尽地测试一个软件。我们了解价值，请相信我们的判断。
约定4．迭代经理们，如果对于交付风险有任何疑问，请来询问我
BA和Dev们都是关注一个软件在什么情况可以良好地工作。而我们除了验证这些情况以外，大量的时间都用在寻找什么样的情况软件不能正常地运行。所以除了针对定义好的软件行为进行测试，我们还会做很多探索性测试。我们通常可以通过这样的测试发现一些没有定义的、不曾预期的行为。这些行为往往会构成软件交付的风险。
我们会告诉你们现在都发生了什么问题、分别分布在哪里。
我们会告诉你们在什么情况下软件可能会有异常行为，是不是会牵连到其他的部分，是否可以绕过去。
我们会告诉你们哪些部分功能比较不稳定，需要更多的留意。
约定5．测试人员们，那些敏捷实践对于我们也是有用的
结对不是Dev们的专利。我不希望总见到你们独自坐在自己的位置上冥思苦想。走出去，跟其他队友多多交流！
多跟测试队友交流，pair看看设计的测试用例是不是够全面，独自一个人想到的未必足够好。他们会给你诚恳的意见，对他们，也请一样认真对待。
如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们：“design for testability（提高你们设计的可测性）”。
如果你发现业务分析师写的需求无法验证，定义的客户行为不够具体，一个用户故事中包含太多了功能点，等等，那么也请大声地告诉他：“INVEST（独立，可协商，价值，可估算，短小，可测）”。
也请你们多跟开发人员结对写自动化测试，既可以帮助你们学习怎样更好地编写自动化测试，也能帮助开发人员们更多地了解用户行为。
这就是我的五个约定，它们是我在团队中顺利展开工作的基础。
作者：覃其慧，ThoughtWorks敏捷咨询师。她参与了大量的敏捷软件开发的实践和敏捷咨询，目前主要关注以价值为驱动的敏捷测试。
