天机不可泄漏

最近关于敏捷的的讨论很是热闹(1,2)，要是各位专家不常常出来讨论一下，我都快忘记敏捷这个词了。 看了各位大牛和专家的讨论，特别赞同Martin Fowler说的：……it isn’t methodologies that succeed or fail, it’s teams that succeed or fail. 所谓事在人为（见《伟大的软件要靠伟大的团队》，《敏捷团队建设》），就是看你做不做，当然要挑符合实际情况的最佳实践来做。 所以，接下去我要把敏捷“山寨”一下，找到适合自己的敏捷方法，然后不断改进（这点上很符合迭代的要求嘛），用敏捷的理念来指导敏捷实践。 比如：一个团队刚刚接触敏捷开发，结对编程的门槛可能有些高，但每天的立会、程序员参与对需求的估计相对来讲要求低一些，也能达到敏捷的目的，就可以先实施。甚至我觉得结对编程不是很适合“中国国情”，因为中国的程序员相对比较内敛，不善于表达，习惯得到任务后直接完成，不会像国外的员工喜欢问为什么，要把整个流程问清楚。这也是我欣赏敏捷的原因之一，程序员（人）在敏捷实践的过程中需要更多的交流，更加符合人性。（人之所以有丰富的表情，就是表达用的，我认为表达欲是人性） 好，哪些实践是敏捷的呢？我们先来看《检验团队是否敏捷的四个标准》 是否执行了单元测试？如果你不是以回归的方式执行单元测试，你就不是敏捷的。 是否将项目客户引入开发团队？你是否建立一种交流机制，要求每天或者一周几次的与你的客户进行交流？ 你正在开发的软件是否是可工作的（working software）？我希望看到可工作的软件演示，它的配置版本。是否有团队之外的人员在每周都看到你所开发的软件？ 开发团队是否是自组织（self-organization）的？也就是说，团队对于项目是否具有控制权。自组织并不意味着毫无限制，但对于项目的一些重要事情应该具有决定的权利。 太好了！我先自我检查一下：单元测试我倒是用，但没有迭代的用，以后望改进。其余的3项，不折不扣可以帮助到项目顺利进行，在项目遇到困难（block）的时候，更是很让客户理解项目遇到的问题，说到底还是“沟通”。 我们再看一下去年VersionOne发布的一份报告。报告中显示，在调查的团队中，实践敏捷方法的，迭代计划86%，单元测试77%，每日立会75%，持续集成72%，……结对编程31%。 好极了，我们的“山寨”敏捷就从迭代计划、单元测试、每日立会、持续集成开始吧！当然我们需要一些特别的工具来帮助我们做迭代计划（我觉得Story Card太浪费纸张了）；用*Unit来做单元测试；大白板做每日立会；*Ant做持续集成，等等……内容很多，每个人的选择不一样。 最后，我没搞明白Scrum、XP啥关系，只知道两者的共同点就是迭代，Scrum大方向上要迭代计划、迭代开发；XP在技术层面上要小规模签入、单元测试、每日集成。我只知道它们都叫“敏捷”，以区别传统的瀑布。如果理解有不对的地方，还请您赐教。

计划编制风险 计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致。 计划是优化的，是“最佳状态”（但不现实，只能算是“期望状态”）。 计划忽略了必要的任务。 计划基于使用特定的小组成员，而那个小组成员其实指望不上。 在限定的时间内无法建成已定规模大小的产品。 产品规模比估计的要大（代码行数、功能点、与前一产品规模的百分比）。 工作量大与估算数（按代码行数、功能点、模块等）。 进度已经拖延的项目在重新估计时过于优化或忽视项目历史。 过度的进度压力造成生产率下降。 目标日期提前，但没有相应地调整产品范围或可用资源。 一个任务的延迟导致相关任务的连锁反应。 涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。 组织和管理 项目缺乏一个有凝聚力的最高领导人。 由于前期乏力，项目长时间被搁置。 解雇和削减开支导致项目小组能力下降。 仅有管理层或市场人员进行技术决策，导致计划进度延长。 低效的项目组织结构降低生产率。 管理层审查、决策的周期比预期时间长。 预算削减打乱项目计划。 管理层做出了打击项目组织积极性的决定。 非技术的第三方的工作比预期延长（预算批准，设备采购批准、法律方面的审查、安全保证等）。 计划性太差，无法适应期望的开发速度。 项目计划由于压力而放弃，导致开发混乱，低效。 管理层强调英雄主义，而忽视客观确切的状态报告，这会降低发现和改正问题的能力。 开发环境 设施没有及时到位。 设施到位，但不配套（如没有电话、网线、家具、办公用品等）。 设施拥挤、杂乱或者破损。 开发工具未能及时到位。 开发工具不能期望地那样有效，开发人员需要时间创建工作环境或者切换新的工具。 开发工具的选择不是基于技术需求，不能提供计划要求的性能。 新开发工具的学习期比预期的长，内容繁多。 最终用户 最终用户坚持新的需求。 最终用户对于最后交付的产品不满意，要求重新设计和重做。 最终用户不买进项目产品，无法提供后续支持。 最终用户的意见未被采纳，造成产品最终无法满足用户期望，而必须重做。 客户 客户坚持新的需求。 客户对规划、原型和规格的审核/决策周期要比预期的要厂。 客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和耗时的变更。 客户答复的时间比预期长（如回答或澄清需求相关问题的时间）。 客户坚持技术决策而导致进度计划延长。 客户对开发进度管理过细，导致实际进展变慢。 客户提供的组件无法与开发的产品匹配，导致额外的设计和集成工作。 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。 客户要求的支持工具和环境不兼容、性能差或者功能不完善，导致生产率降低。 承包商 承包商没有按承诺交付组件。 承包商递交的组件质量低下无法接收，必须花时间改进质量。 承包商没有买进项目开发需要的工具，进而无法提供需要的性能水平。 需求 需求已经成为项目基准，但变化还在继续。 [...]

工欲善其事，必先利其器。孔子告诉子贡，一个做手艺或工艺的人，要想把工作完成，做得完善，应该先把工具准备好。 自认为，敏捷开发对参与的人员要求都太高，如果对敏捷没有一点概念，其实实施会遇到很大的难度。我们大都不是布道者，也许也不善于布道。我们需要的只是一些工具，能够帮助我们对软件开发的生命周期进行管理，让团队的参与者有据可循。 Mingle 2.0 排在第一个介绍的是Mingle，因为个人对ThoughtWorks的关注，或者说是她的首席科学家是Martin Fowler，让我感到那是能够胜任“布道”的公司，自然对她提供的工具投入更加多的关注。 Mingle是一个项目协作和管理的工具，为整个团队提供了一个共享的工作台。它能帮助你收集Story, Bug等，并且将他们组织起来，同时还提供你需要的Wiki，图表等等功能。 我曾经使用过Mingle的上一个版本，不知道是不是运行在jRuby上的原因，它在效率上的表现影响到我继续使用它，当时机器的配置情况是：Celeron D 3G，2GB RAM，Windows XP SP2。 你可以免费使用30天，30天以后，5人以下团队免费。 更多信息请关注Mingle2.0官网｜注册下载Mingle2.0 XPlanner 同样的，XPlanner也是一个基于web的极限编程的团队计划和跟踪工具。XPlanner的特点非常的明显：简单的模型、开源、免费、图表输出，简单甚至说粗糙的界面下是强大的功能，它能提供图表的输出、SOAP接口、多语言支持。 XPlanner虽然是JSP的程序，但配置在windows的平台上一点都不麻烦，我曾经就发出这样的感叹：“这样就可以运行了吗？”。它所有的数据都是存储在脚本中。每一次系统重新运行，都会需要一点时间，将历史数据Insert到MySQL中。 更多信息请关注XPlanner官网｜下载XPlanner页面。 VersionOne 曾经３次获得Jolt大奖。VersionOne提供了4种敏捷模型的支持：XP, Scrum, DSDM, Agile UP. 相比前面介绍的2款工具，VersionOne提供了更加强大的功能，它能够导出N多种的报表和图表，在用户体验方面做的也很出色，它提供了很多快捷键，方便使用者能够快速的进行项目内容的调整，它还使用了AJAX技术，让使用者感到好像在使用桌面应用程序一般。 另外VersionOne在不同敏捷模型间切换也非常的方便，只要重新运行一下安装程序，选择你需要切换到的模型即可，不会造成任何数据的丢失。不过在我看来，不同模型的切换在VersionOne中只是名词的改变罢了，比如在Story和Issue就是一样东西；Iteration和Sprint是一个玩意儿。 VersionOne基于ASP.NET，可以使用SQL SERVER 2005 Expression作为数据库。VersionOne在5人以下的团队是免费的。 更多信息请关注VersionOne官网｜下载VersionOne页面 Trichord Trichord是我在InfoQ上，看到的一篇关于“看板图”介绍的文章中提到的一个工具，是一个日本人开发的敏捷工具，基于Eclipse的界面，很多人应该不会陌生。它的特点是很有趣，在使用的过程当中就像真正在使用看板一样。它的名字很有趣TRI指的是三种视角（时间、任务和团队），CHORD则是和谐的意思。 我在使用Trichord的过程中发现，看板固然有趣，但是如果你屏幕不是很大的话，还是比较痛苦的，至少一个列表能显示更加多的内容。 另外，它还提供了一个很有趣的功能：表情日历。 Trichord提供2种授权模式：一个是evaluation，你可以免费使用evaluation license 30天。另外一个是免费版本，但是免费版本只提供一个用户帐号并且只能有50张故事卡片，是不是很不爽？ 更多Trichord信息请关注Trichord官网 | 下载Trichord

最近的一个Flash项目，很累很痛苦。 Flash Application和Web Application的人员差别 差别最大的地方在于，Flash Application中，美工人员的参与度要比Web Application中的美工人员参与度要大很多。原因在于，美工人员能比较容易的在Flash中制作出一个特效，比如淡进淡出的效果，而在Web中利用Javascript制作一个淡进淡出的效果并没有想象当中那么容易。 就是这个小差别，就会给项目管理上带来不同的体验。好比，你的部队中拥有不同特性的兵种，有的是血牛，有的是远程部队，有的是魔法部队，这么一个团队，在指挥上一定比全是血牛的部队相比费劲很多。 做好版本管理 fla不是文本文件，所以最好不要多人签出编辑，因为这样不能合并(Merge)。 充分利用Action Script 3种面对对象的特性，组织好你的Action Script文件。 使用Action Script 3 下面有几个理由去使用Action Script 3 Action Script 3提供了完好的面对对象方案，有了命名空间。 支持了ECMAScript for XML (E4X)，使用XML更加方便。 更加统一的事件处理模型。 更加纯正的时间类。 善用工具 Flash  CS3，Flash美工方面没的挑。 就算不开发Flex，也推荐使用Flex Builder。 欢迎有同样经验的同志补充。

作者：汤姆·迪马可 (Tom DeMarco)，同作者作品有《人件》、《与熊共舞》。 译者: UML / China翻译组 页数: 306 出版社: 清华大学出版社 出版年: 2003-1-1 《最后期限》用一个虚构的故事阐述了项目管理中的一些原则。汤普金斯先生是书中一位资深的项目经理，书中以第三人称的角度描述汤普金斯先生这一段特殊的经历，让你在阅读项目管理书籍的同时，如同阅读轻松的小说一样。每一章的最后以汤普金斯先生的日记作为结尾。以下是我在阅读过程当中的一些摘录，并不包含书中的所有章节。 汤普金斯先生的日记——前传 汤普金斯先生的日记——优质管理的四大要素 汤普金斯先生的日记——安全和变化 汤普金斯先生的日记——负面效应 汤普金斯先生的日记——面试和招聘 汤普金斯先生的日记——生产力的提高和风险控制 汤普金斯先生的日记——防止失败 汤普金斯先生的日记——度量 汤普金斯先生的日记——催化剂的角色 汤普金斯先生的日记——人类的错误 汤普金斯先生的日记——人员安排 汤普金斯先生的日记——项目社会学 汤普金斯先生的日记——精兵简政

对于汤普金斯先生来说，今天是个好日子，不仅项目组成功交付了产品，而且他所在的国家上市了（他的国家就是一个专门制造软件的国家，第一个上市交易的国家-。-），汤普金斯先生拥有5万股，股票的发行价会是14美元，而且一天之后会涨到20甚至是25美元，而且汤普金斯先生决定离开这个国家，去享受这笔飞来横财。 但是这个时候汤普金斯先生收到一同国际长途，电话的另外一头是这个国家的国际事务部的部长，一个专横的人物，他告诉汤普金斯先生，他要实行裁员减薪，而汤普金斯先生的想法正好相反。总之，汤普金斯先生没有功夫与这位令人讨厌的国际事务部部长周旋了。他挂掉了电话，拿起日记本。 精兵简政： 精兵简政是失败的公司使用的办法。它让员工负担失败的责任。 公司的目标应该正好相反：兴旺而人性化。 当你听到“精兵简政”这个词的时候，请记住它的弦外之音：失败 和恐吓。

还记得上次的那份成绩单吗？汤普金斯先生打算亲自去看看A团队。正巧，A团队正在举行一个会议，出席会议的人数总共有31人，当汤普金斯先生旁观会议的时候，整个会议已经举行6天了。 汤普金斯先生最后做出一个决定：让会议尽量短，精简参与的人数，缩短会议的时间，并且所有人都知道会议的议程。 最后，汤普金斯先生决定休会，并且为下一次的会议精心准备议程。 项目社会学： 让不必与会的人可以放心离开，从而保证会议的精简。有一份公开 的议程，并严格执行，这是最简单的办法。 项目需要仪式。 用小小的仪式来使人们注意项目的目标和理想状态：小规模会议、 零缺陷工作等等。 采取行动，防止人们随便发怒 记住：愤怒=恐惧。随便对下级发怒的经理一定是因为恐惧才会这样 做的。 意见：如果所有人都懂得“愤怒=恐惧”这个道理，就能明显地看出 发怒的人是在害怕。由于无法再隐瞒自己的恐惧，他也就不会再生 气了。（这不能解决这些生气的人的问题，但是肯定可以让其他人 好受一些。）

今天汤普金斯先生收到了一张成绩单，如下 产品 A团队 B团队 C团队 Notate F A A PMill F A A Paint.It F A B PShov F A A Quirk F B A QuiekerStill C A A 如同常规的，A表示最佳，说明已有设计方案。F表示最次，说明只有行政文档。 如果你还记得在“汤普金斯先生的日记——前传”中记载的，对3个团队的描述的： A团队——人员过量 B团队——人员不足 C团队——人数最合适 汤普金斯先生面对着一份成绩表陷入了思考，沉思过后，他在他的日记中写下如下文字。 人员安排 在早期，人员超编会迫使项目跨过关键的设计阶段（这是为了让 所有的人有事可做）。 如果在设计完成之前，工作先被分给了很多人，那么人与人之间、 工作组之间的接口就会很乱套。 这会使团队内部耦合度提高，会议时间、重复劳动和无效工作都 会增加。 理想的人员安排是这样：在项目的的大部分时间里由小型核心团 队来做设计工作，在开发的最后阶段（时间安排的最后1/6）加入 大量的人手。 可怕的猜想：时间安排紧迫的项目，与时间安排比较合理的项目 比起来，完成的时间发而会更长。

今天，汤普金斯先生不再周旋于他的项目中，决定在周末轻松地享受这难得的休息。汤普金斯先生驾车在公路上行驶，决定走“5号公路”去郊游。不久看到一块黑红各半的标记牌，上面写着“4号公路”。汤普金斯想，接下去的一块黑红各半的标记就可以转向了，但是一直没有找到。 当汤普金斯先生发现自己走错路的时候，回头再找那错过的路口时，发现原来那个标识“5号公路”的路牌不像标识“4号公路”的路牌一样，是黑红各半的标记，而是白底黑字的路牌，上面写着“5号公路”。 汤普金斯先生飞快地记下自己的想法： 人类的错误 将你置于死地的，不是你不知道的的东西…而正是你“知道”绝不会置你于死地的东西。

汤普金斯先生今天碰到一个问题，他没有成功调解他手下两个程序员的冲突，幸好有麦斯特罗·迪耶尼亚尔先生，他告诉了汤普金斯先生很多有趣的故事，并且帮助汤普金斯先生了解到如何化解冲突。 催化剂的角色 有这样一种催化剂式的人物，这样的人能帮助团队成型并凝聚，保 持团队的健康和生产力，从而对项目做出贡献。就算“催化剂”别 的什么事情都不干（其实，通常他们还会干很多别的事），这种催 化剂的角色也是重要而有价值的。 调解是“催化剂”的一项特殊工作。调解是可以学的，而且只需要 很小的投资就能学会。 调解应该从一个小小的仪式开始。“我能帮你们调解一下吗？”在解决冲突的 时候，这是必要的第一个步骤。

这几天对于汤普金斯先生来说，真是惊喜不断，上次是碰到了世界上最最著名的项目经理，而这次遇上了这个国家的一位将军——马克夫，他主要负责军方使用的软件。汤普金斯先生参观了马克夫将军的团队，发现他们都很忙碌，而马克夫将军告诉汤普金斯先生说：“其实他们的项目已经被取消了。而他们现在还在工作的原因是，这能保持好的团队在一起，这是项目成功或失败以外的收获之一。” 在和一位将军的交流后，汤普金斯先生感到了紧迫感，于是他拿出了日记本： 防止失败 壮士断腕。 控制住失败比优化成功更能提高你全面的成绩。 要有闯劲，尽早取消失败的工作。 除非必要，否则就不要自己去凝聚一个团队：出去找一个已经成型的团队来用。 保持好的团队在一起(只要他们自己愿意)，以帮助你的继任者避免团队凝聚得慢或者不能凝聚的问题。 把凝聚在一起的团队—— 准备好、并且也愿意接受新的工作—— 作为项目的收获之一。 项目开始时浪费的一天和最后阶段浪费的一天对项目造成的伤害是同等的。

汤普金斯先生这几天很困扰，原因是软件工程院的人一直试图在说服他，要求汤普金斯先生立即执行一次过程改进计划。他和世界上最最优秀的项目经理尼佐利博士进行了一次谈话，尼佐利博士告诉他说：过程改进总是好的，但往往例如CMM这样的过程改进计划把计划本身当成了目标。在他的到生产力的时候，那是之前的管理者所作的长期投资的直接反映。 汤普金斯先生非常的激动，不仅是因为他见到了世界上最最优秀的项目经理，而且还得到了尼佐利博士的建议： 生产力的提高 没有“短期生产力提高”这样的东西。 生产力的提高是来自长期投资的。 任何承诺立刻见效的东西都很可能是江湖游医所卖的万灵油。 风险控制 通过控制风险来管理项目。 为每个项目创建并维护风险统计表。 跟踪根源性的风险，而不只是最后那讨厌的结果。 评估每种风险具体化的概率和可能造成的开销。 对于每种风险，预测标志其具体化的早期征兆。 任命一个风险控制官，这个人不应该维护组织内部“我能行”的态度。 建立简单的(可能是匿名的)通道，让坏消息能传递到高层。

项目开始之前汤普金斯先生需要对招聘几位项目经理，但他并不是单枪匹马闯入人海之中，寻找合适的人选，而是带着得力的助手，让其他人给予他建议，在面试的过程当中，汤普金斯先生碰到了形形色色的人物。在一天的招聘结束后，外面已经漆黑一片，但汤普金斯先生还是在桌前写下今天的心得。 面试和招聘 招聘涉及到所有与管理相关的身体部位：心、灵魂、鼻子和肠胃 (但是主要是肠胃)。 不要试图单独去招聘—— 两副肠胃远比一副肠胃的两倍要好。 对于新的雇员，让他们承担与以前曾经成功过的同样难度的项 目，把有挑战性的目标推迟到下一次。 征求提示：你最希望雇的那个人可能还知道其他很好的人选。 多听，少说。

有一天，汤普金斯先生被一名女子“绑架”到一个国家，这个国家唯一的作用就是制造软件，而汤普金斯先生被“绑架”的原因是，他是一位资深的项目经理，并且被寄予希望能够带领这个国家的项目团队来完成一个世界级的软件。 此时，汤普金斯先生已经平静地接受了“绑架”这个事实，他手下一共有200名顶尖的项目开发经理组成的核心团队、数十名关键领域的专家…… 汤普金斯先生认为，这些人已经远远超标了，所以汤普金斯先生将200人分成3个不同的团队，打算做一个受控的实验，何为受控的实验呢？ 一个项目组承受巨大的压力，另一个少一些，第三个几乎没有压力； 一个人数超标，一个人数过少，一个人数适合； 一个全部由资深人员组成，一个以一些资深人员和一些新手组成，一个全部由新手组成； 一个团队由一直在一起工作的人组成，另一个由陌生人组成 如果完成这个实验，我们就可以真正理解项目成功的原因。这就在汤普金斯先生的脚下，世界上第一个项目实验室！

负面效应 威胁不是提高业绩最好的办法。 如果分配的时间一开始就不够，不管威胁有多么吓人，工作也无法按时完成。 更糟糕的是，如果目标没有实现，你就必须兑现你的威胁。 　　是的，威胁有时候是没有用的，因为威胁不是目的。 　　妈妈对孩子说：“你要是不乖，妈妈就不喜欢你了。”说完以后，孩子就很乖了。但如果孩子还是不乖呢？妈妈好尴尬啊。不过现在的孩子一般都不会吃这一套吧，

安全和变化 除非感到安全，否则人们就不能去迎接变化。 在所有成功的工程中（以及在绝大多数其他有价值的工作中），变化都是基本的要素之一。 安全感的缺乏会让人们反对变化。 逃避风险是致命的，因为这会让你也得不到与风险同在的利益。 人们可能会因为来自客观世界的直接的恐吓而觉得没有安全感，但是如果察觉到管理者可能滥用权力来惩罚自己，他们也会觉得没有安全感。 总之大家都有一个圈，在这个圈里面，都感觉是安全的，但是如果想把这个圈扩大，就得冒点风险，先跳出这个圈来。

汤普金斯开始了他第一天的工作，首先他收到了第一份礼物——日记本，翻开日记本，第一页已经写了第一条记录： 优质管理的四大要素： 选择正确的人。 为他们分配正确的工作。 保持他们的积极性。 帮助团队凝聚起来并保持团队的凝聚力。（其他一切都只是“文案”。）

度量每个产品的规模 估计产品规模，直接影响了可行性的分析以及随后的计划。但是并不是说这个规模的估计要达到如何的精确，除非这个产品的生命周期是如此的短暂。 不要执着于单位——在等待客观度量的时候，先用你自己的主观单位 我的主观单位就是功能点、故事点，而非工时。 从已经完成的项目中收集原始数据，以推导出生产力趋向 要想达到准确估计，首先就要采用计数的方法，其次是计算，最后才是判断。 借助数据库画一条趋势线，把预期工作量作为人造度量值的函数显示出来 在敏捷开发中，这个图通常是Burndown Chart。

一开始就未很好地研究需求； 在需求确认阶段缺乏最终用户的参与； 导致代码中出现无数错误的不良设计； 引发大量排错工作的不良编码实践； 缺乏有经验的人员； 不完整或不熟练的项目计划活动； 在压力下放弃计划工作； 缺乏自动化的源代码控制； “首席女歌手”团队成员(总是把自己想象成关键影响者或支配人物)； 开发人员“镀金”(为了自身的利益增加不必要的功能或采取不必要的方法)； 以上的几条只是项目混乱源的一部分，这些混乱源会产生可变性，对项目的估算会产生很不好的影响。

　　敏捷估计能很好的控制项目风险，因为敏捷估计告诉大家，计划也是需要迭代的，通过对计划的迭代，可以预知项目的风险，了解项目的实际规模。 　　这本书提供了一系列的方法和工具，包括规模估计、故事点、理想工作日、优先级的制定、速度、kanban、burndown chart等等。 　　这本书解决了我之前对敏捷方法的一些疑问，比如：项目规模的估计、迭代周期中的任务安排、何时开始分割用户故事、如何对采用敏捷方法的项目进行监督和跟踪。 　　这本书成为我2008年第一本推荐的书籍，是因为我觉得：如果您想在您的团队中采取敏捷方法或者您对敏捷方法还有很多疑问的话，这本书将帮助您解除心头的疑云，让您对敏捷方法有更加全面的了解。