作为一个开发团队的管理者，例如当你是一个团队的项目经理的时候，任务的完成情况通常是你关心的内容之一，比如说分配的任务是否能够按时间完成，整个项目的进度是否尚在计划之中，团队内的人是不是都在高效地工作，大家有没有什么困难，这些是你经常会关注的问题。在软件开发团队中，任务的分配、跟踪和管理通常是这个团队管理者的一个重要的工作内容。

　　1、从问题谈起

　　我曾经碰到过一个项目经理，她管理着一个团队开发一个web应用，团队里开发人员大概10个左右，测试人员3个，业务分析师1个人。对于任务的管理她是这么做的。通常，她会将需求分析人员分析得到的需求给每个人分一些。然后每个人在领到任务之后会给她承诺一个大致的时间点。整个项目大致的交付计划用一个excel表管理着，根据客户要求的交付时间点，并且考虑到一些需求之间的集成测试关系，定出了每个需求的大致交付时间点。只要每个开发人员承诺的时间点和期望的相差不大，她都可以接受，每个开发人员这样知道自己应该在什么时间点交付什么东西。

　　一切本该很完美，但是不和谐的问题不断出现。经常发生的事情是大家在承诺的时间点快要到的时候不能按时交付，每次她询问进度的时候，会被告知还差一点完成了。通常的说法是“底层部分已经做完了，或还差页面部分可以搞定了”，然而实际情况是又过了相当的时间才真正完成。当然也不是没有按时交付的需求，但是她发现也许是大家经常加班，已经开始疲倦了，有时候明明很简单的可以提前完成的需求，大家还是到后一刻才交付给测试。

　　也有的开发人员拿到自己的那一批需求之后，会批量工作，把若干个类似的需求的底层逻辑全部实现，然后再实现上层内容。她默认了这种做法，像这位开发人员说的“这几个需求都差不多，只要底层做好了，基本上都差不多完成了”。虽然这部分工作早点和其他人一起集成测试会比较好，但是他这样做也只能推后集成测试的时间点了。还好承诺给测试团队的交付时间点还在1个月之后，只要1个月之内能够完成这些需求可以了。

　　还有一些其他的问题，比如有的新人经常碰到问题，然而出了问题并不会主动问其他人，而是在胡乱尝试中浪费了时间。组里还有个开发人员非常激进，经常花时间去重构代码，追求完美的架构设计，进度很让人担忧。组内的开发人员有时候还经常被其他项目的事情打扰，因为有几个人刚刚从上一个项目中调过来，上个项目的有些问题只有他们熟悉和有能力解决。她不止一次发现，有一个开发人员经常在修复其他项目的bug。

　　她会不定时地去询问每个开发人员的开发进度，当需求的计划交付时间点逼近的时候，这种检查会越来越频繁，开发人员感受到压力，有时候甚至需要加班来完成开发工作。然而尽管她花了很多精力去跟踪和检查每个需求的完成情况，还是有很多出乎期望的事情在不断发生。尽管她一直相信说，只要开发人员们能够完成任务，采用什么方式她是不干预的，而具体的时间也是由他们自己分配的。但是她渐渐感觉到，任务越来越不可控，计划通常无法按时完成，每天对大家的检查花了大部分时间，然而却不能揭示出真正的问题。

　　运转良好的项目都差不多，而问题项目的问题各有各的不同。尽管每个团队的问题可能不完全相同，但是当我们审视这些项目的运作和管理方式的时候，不难发现一些诸如多任务并行等共性的问题，这些问题给软件项目带来了各种各样的浪费。当一个团队采用瀑布开发模式的时候，开发阶段全部结束之后测试人员才会介入，开展测试活动，在一个通常很漫长的开发阶段内，各种开发活动中的浪费、估计的不准确，以及成员自己的拖沓、被打扰、问题阻塞等，都被掩盖住了。只要在终时间点前能够全部开发完成，不管是前松后紧，还是加班熬夜，都已经成了项目开发的常态。项目经理只能看到交付的终时间点，问题不能及时的暴露，而等到问题被暴露的时候，可以使用的调整手段也非常有限。

　　这样的一种团队生存状态在外部环境要求短交付周期，需求允许经常变化的情况下显示出了极度地不适应。市场环境的变化驱动了软件需求的变化，这种变化催生了缩短交付周期的诉求，较短的交付周期使得人们可以不必去预期过于长远的需求，具备根据市场的变化快速地制定和调整软件需求的能力。而当交付模型由几个月的瀑布模型转变为数周甚至更短的迭代模型的时候，我们在前面谈到的团队中的各种浪费、低效、半成品堆积等问题，会急剧地爆发出来。

　　熟悉敏捷方法的读者可能都知道，敏捷方法包含一系列实践来帮助团队实现短周期快速交付，更好地响应需求变化。比如说userstory方法，将需求从用户价值的角度进行组织，避免将需求从功能模块角度划分。小粒度的用户故事可以在一两周的迭代内完成开发和测试（并行开发），从而可以缩短交付周期。问题是，在敏捷团队内，我们是如何有效管理大量小粒度userstory，同时避免上述项目管理中的问题呢？下面我们结合敏捷开发中的看板工具来看看敏捷团队是如何管理任务的。

　　2、可视化看板任务管理

 

　　看板源于精益生产实践，敏捷将其背后的可视化管理理念借鉴过来，经过一番改造，形成了有自己独特风格的可视化管理工具。曾有人总结过scrum和kanban的使用，而很多时候，我们也将它叫做迭代状态墙。

　　先看看我们怎么样能用这个状态墙来管理迭代任务。说起来其实是一个很简单的东西。

 

　　通常一个迭代的状态墙上反映了某一个迭代的计划和任务进展情况。状态墙上按照一个迭代内团队的典型开发活动分成几栏，例如“待开发”、“开发中”、“待测试”、“测试中”、“测试完成”等。在一个迭代之初，我们会将计划在本迭代完成的故事卡放到“待开发”这一栏中。可视化状态墙的一个好处是所有团队成员都可以实时地了解到本迭代的计划和进展情况。开发人员领取任务时，将他领取的故事卡片从“待开发”移到“开发中”，同时贴上带有自己名字的小纸条。当他开发完成之后，将故事卡片移到“待测试”一栏。我们的测试人员看到这一栏里有待测的故事卡时，取下一张，移动到“测试中”，开始这个用户故事的测试，测试完成后，将故事卡移动到“测试完成”一栏。如果测试人员发现了一个bug，那么他可以用红颜色的卡片记下这个bug，然后放到待开发这一栏中。在状态墙上，除了用户故事、bug之外，还会有一些诸如重构、搭建测试环境这样的不直接产生业务价值的任务，这三类任务用不同颜色的卡片，放到状态墙上统一管理。

　　这样一个简单的工具，是如何帮助我们消除浪费、解决项目管理中的问题的？让我们逐条分析一下看看。

　　2.1 如何减少返工带来的浪费

　　返工是软件开发过程中的一大严重浪费。比如说开发人员开发完成的任务交给测试人员测试的时候，关键流程不能走通，阻碍了测试进程；交付给客户的东西被客户说“这不是我想要的东西”；分析人员将还没分析透彻的任务交给开发人员，在后验收的时候发现开发人员加入了自己的一些“发挥”。这些都会造成返工。返工意味着没有一次性将事情做对，意味着流程中的上游没有交付高质量的工作，也可能意味着团队成员间的沟通出了问题。