“怎样保证每个团队成员高效地工作，使组织产生大的效益”是每一个经理大的挑战。通常经理们会采取以下两种手段:

    告诉团队成员该做什么（Command and Control）
    团队成员根据设定好的原则，自己决定下一步该做什么（Self-organizing）

在很多软件项目开发团队中，项目经理和部门经理负责项目管理和控制。为了控制软件开发的进度，效率和风险，经理们往往要求团队成员提交和更新各种各样的表格，例如日报、周报、代码量报告、缺陷报告等等，通过各种计划、报告、表格来管理团队。但是这种方法有很多固有的弊病。

    首先，数据不准确。例如在日报中，一般要求提交任务完成百分比。这个数字很多时候是团队成员拍脑袋想出来的。任务完成90%后，剩下的10%需要更多的时间完成的情况在很多团队中也屡见不鲜。
    其次，数据不及时。除了项目文件，经理们没有办法了解项目的具体运行状况，进度，只有通过日报或者周报。任务分配也不及时，团队内部工作量也不均衡。
    再次，衡量标准不恰当。
        用代码量作为衡量Dev生产率的标准本来是不恰当的。这使团队成员单纯追求代码量而不停的复制拷贝，不关心系统架构所要求的代码简洁，架构清晰。
        用缺陷作为衡量Dev工作效率的标准也是不恰当的。软件开发并不仅仅是编写代码，更重要的是沟通问题。绝大多数缺陷其实是由需求不明确或者是沟通的不充分和不准确导致的。用缺陷率作为标准会导致团员成员之间的矛盾，互相指责，推卸责任。
    再次，信息不透明，不直观。报告往往不是团队成员直接可见的，需要登录到网站，或者访问Source Control或者共享文件夹的某个文件（往往是有权限控制的）。这些信息不会直接展示给大家，他们总是需要一路点击过去。
    后，过多的无效工作。团队成员要花费很多时间和精力在更新及维护报告上面，但这些工作并没有业务价值。

在处理复杂像软件开发这类复杂问题的时候，使用Command&Control方式效率十分低下。很多情况下即使是有经验的经理，由于他不在现场，不掌握全部具体情况，也很难做出准确的判断，有效地指挥团队成员工作。而第二种管理方式（Self-organizing）在解决复杂问题时要有效得多。在复杂的环境中，可以通过训练及培训使团队成员掌握工作的基本原则，把责任下放给第一线的工作人员，由他们根据不断变化的实际情况，不断地调 整，完成团队任务。军队也是类似，在战斗过程中，作为战斗指挥的上级极少直接指挥每个士兵战斗。人员和班组是自我管理，根据现实情况和战略目标动态调整 战术。这也是绝大多数的敏捷方法论都在强调团队的自我管理的原因。

怎样在软件开发中实现团队的自我管理？怎样让团队找到自身的问题？怎样实时地反映项目的进度？团队成员怎样知道每天应该做什么？为了解决这些问题，我们的经验是日常开发中建立一个基于拉动式生产方式的信息化工作空间。

    首先，我们的日常开发以Scrum为基本框架，并特别强调团队的自我管理。具体做法是：
        短迭代。每两个星期一个Sprint。每个Sprint给几个客户做演示。产品负责人会根据演示的反馈以及原先的发布计划重新整理Product Backlog，并由此产生下一个Sprint的计划。因此团队的每个Sprint的任务是由业务驱动的。
        用户故事。产品负责人会在计划会议开始之前整理成用户故事。产品负责人在整理用户故事过程中会注意收集真正客户想要的东西，理解客 户的意愿，而不是业务以及技术上怎样实现。在计划会议会议中，给团队成员解释需求，团队成员会根据对需求的理解提出可能的方案（当然也有可能是多个方 案），分出任务，对任务做出估计。但是这些估计也是比较粗略的，很多时候需求还是不能很明确，但是一般达到大家能够对用户故事有一个基本的理解，能够开始 着手，能够做出大体的估计的程度可以。在Sprint过程中，还会不断发现新的需求，或者采用或者否决一些方案。这些都是每个Scrum团队在 Sprint中动态调整的。
        迭代开始时，避免任务分配到个人。在计划会议会议中，用计划游戏，每个人都参与估计，每个人都要求理解用户故事。在Sprint 中，每个成员根据一些简单的原则来认领任务（比如从上到下优先级，不超过大并发任务数）。通过结对编程、Wiki等一些知识共享的手段，多数人很快能胜任各种任务。
        周期性的例会（每日例会、Scrum of Scrum）。在例会中团队成员汇报进度（做了什么），承诺（根据当前情况，下一步要做什么），需求（有哪些困难，需要其他成员或者组织的帮助）。团队会 重新估计剩下的任务，如果需要，项目成员和产品负责人一起调整Sprint Backlog。
    其次，合理使用信息辐射器（Information Radiator，另见The Ideal Agile Workspace），我们目前使用的信息辐射器包括：
        Sprint Backlog，这是整个项目团队自我管理的核心。实时反映项目的状况。通过Sprint Backlog可以了解到任务分配，项目进展（燃尽图），缺陷，困难等等。Sprint Backlog上的不同类任务用不同颜色区分，一目了然。很容易可以了解任务分配，Sprint的瓶颈以及困难（用红色表示）在哪里。
        故事墙，较为长期的开发计划。
        Build Monitor，一般包括一个红绿灯，一个大屏幕显示器。红绿灯监控主分支的持续集成系统的状况，如果构建失败（可能 原因包括编译错误，单元测试问题，冒烟测试以及回归测试问题等），立刻显示红灯，同时也会发出声音（XXXX project is "still" btoken）。大屏幕显示器主要是反映一些大家主要关注的持续集成项目的状态。其实如果采取按组件做分支的方式，每个Scrum Team还可以有一个熔岩灯，用来监控团队分支的状态。
        各种白板，团队成员可以用白板对具体需求，具体模块架构以及其实现进行讨论。然后将白板的内容作公示，指导团队成员的日常开发。如果发现问题，随时修改白板的内容。
        团队日历，主要是表明一些重要的日期以及成员请假情况。
        系统框架图，招贴画。团队成员可以了解整个系统的高层次的系统架构。
    除了这些，还可以考虑加下面的一些内容
        各种手绘表格。用于过程改进或者其他作用的手绘表格，常见的例子有在回顾会议里面发现的问题；测试用例数目；测试覆盖率；结对编程轮换表；要重构的函数；Burnup Chart等。
        产品愿景，团队成员对具体开发中遇到的问题，需要做决定的时候，能够基于愿景做出取舍。
        系统词汇表，统一语言和隐喻。只有开发团队和客户用同样的语言，才会减少沟通中的误解。
        团队可根据自身的需求设计更多的信息辐射器。

笔者的体会是，信息化工作空间的关键是信息，终目的是使任何人只要进入一个团队的工作区域，可以立刻了解项目的进度，项目的运行情况，现有的问 题，每个人现在的任务，一些团队需要改进的地方等等。大家每天来上班，只要看一下板，立刻知道自己该做什么。不光是团队成员，一些 Stakeholder也可以到工作区域去看一看信息辐射器，了解新的状况。即使Stakeholder不能到现场，只要经常发送一些照片，或者经常参 加一些演示，效果也会不错。实现信息化工作空间的前提是团队成员要坐在一起，如果不能坐在一起，那只能通过一些电子手段进行同步。当然信息辐射器也不能太 多，太多也会导致混乱。

很多的敏捷方法论（Scrum、XP、Lean）都提倡团队的自我管理。而信息化工作空间则是保证我们团队自我管理的核心实践。