Dreamhead觉得等待发布是件很爽的事。当然确实是很爽的事。不过，《 最后期限 》里面贝琳达这样描述电影里的巴顿将军：

    “片子开始的那一幕，巴顿‘指挥’战役的那一幕，我们那位年轻的朋友所说的那一幕：呵呵，巴顿在那一幕里根本连一条命令都没下过。他只是从望远镜里看着整个战役。德军坦克分队像他预料的那样穿过山谷，而他就看着那些坦克。在那儿，在第一辆坦克上，站着一位军官，手里拿着马鞭。巴顿盯着他，说道：‘隆美尔，我读过你的书。’他读过隆美尔的书，所以他很清楚隆美尔会怎么做。然后，战斗打响了。进攻，侧翼机动，佯装撤退，再次进攻，空中支援，后备队到达。巴顿只是看着，根本没有下达哪怕一条命令。”

如果一件事会成功，在最后一天之前它已注定会成功；如果它会失败，最后一天之前它已注定失败。所以我对这个“最后一天”没什么感觉。做一些和往常一样简单的事，让一些注定发生的事情发生而已。平常的一天而已。

重温在贝琳达的评论之前，一个颇有些代表性的项目经理是如何在记忆中构造巴顿将军的：

    “我想，我就像巴顿。我是说，项目经理就像是巴顿。必须这样。就像在电影的第一个战争场景，直接打击隆美尔那样。他就是策划整个战役的那个人，他指挥每一次炮击。”

    这个年轻人站了起来，在虚拟的战场上挥舞着手臂：“空中支援！他这样说，然后空中支援就来了。收到—收到—收到！轰隆！转向侧翼！这儿！那儿！左侧编队，进攻！进攻！现在撤下来，赶紧撤下来！快！现在等着，等着，等我的命令……就是现在！进攻，进攻，把所有的炮弹都扔给他们！右翼，切断他们的后续部队！是的，就是那儿，就是那儿。现在我要更多的轰炸机，把炸弹丢在中间。好了，现在该决个胜负了，后备队，上。后备队从左侧进攻，快。是的，就是那儿，就是那儿，敌人绝对不会想到。嘣！轰隆！把他们全干掉！耶！！”

5年前也许我也这样想。人们需要像贝琳达那样把自己累垮，然后学会用简单的方式获胜。

---

作者介绍
熊节是ThoughtWorks公司的咨询师，曾参与《重构：改善既有代码的设计（中文版）》、《J2EE核心模式（原书第2版）》、《Contributing to Eclipse中文版》等图书的翻译。目前正在从事Ruby on Rails的项目，并致力于敏捷方法与思想的推广。

团队的成员们都已经有相当丰富的sprint retrospective经验，如何保持大家的激情，以及保证回顾会议的效率和效果都是我感觉很重要也并不容易的任务。大家开始有些厌倦于差不多的流程，即使我们想方设法地换用各种不同的retrospective方式，情况依然如此，而不断更换方式所带来的副作用还包括大家需要花费时间熟悉，也有可能导致大家干脆置之不理。其实换在不同的地点进行回顾会议是个不错的点子，但可以这一定程度上涉及到经费问题，所以。。
 
这次比较凑巧的是，sprint中，我曾经将sprint backlog和burndown chart打印出来，贴在工作区域的白板上，督促大家每天更新。而我们的一些会议记录也都被我打印出来，粘贴在一起，所以，可以说将这些文档资料收集起来后就成为了我们非常宝贵的一些回忆。回顾会议开始前，我将这些文档粘贴在会议室的墙上，大致按照时间顺序排列。由于有几个新同事加入，所以花了点时间重复那些essential statements，然后我希望大家能够快速地回顾过去的这个sprint，然后用一个词语或者短语来描述自己的感受，此时此刻的感受。对于这些感受的稍加发掘，有助于放松情绪，拉近彼此的距离，使氛围能够引导大家畅所欲言。而这些感受也可以用于之后与那些action进行一定的对比，如果大家更多的是不满意，却没有太多用于改善现状的action，那么说明其中一定有什么问题，导致前后大家给出的信息不一致。
 
感受阶段结束后，我准备进行timeline，在此时，我向大家展示粘贴在墙上的这些文档，分配出2~5分钟来浏览这些文档，增强他们对于 sprint大致过程的记忆。这其中，还会有助于大家发现一些可能不容易想到的问题，比如在某一周的weekly review上有提到的下周工作计划，但在随后一周的weekly review记录中却发现此工作计划没有按预期的完成，那么这就是一个潜在的问题，或者可以提高的方面。之后就是给出一些时间让成员们回首，并将自己的看法记录下来，写在便签纸上。此时我已经准备好三张大的flip chart纸张，张贴在墙上，用于大家粘贴便签纸。
 
之后的mining阶段，我开始阅读这些便签纸，然后将它们就地记录在这些flip chart上面，用记号笔，并给这些条目编号。当然，这三张flip chart分别为start doing、stop doing、continue doing，条目会被写到对应的纸上。接着就是要探讨可行的解决办法了，但在此时有一点点的小状况。整个会议的气氛都是比较轻松的，有点点随意，但是从大家半开玩笑的话语中，我发现一种趋势，大家有些许的死气沉沉，觉得有些境况难以改变，有些困难是必然，我觉得这样的心态对于我们找寻SMART的 action有负面效果。快速地思考后想出一个办法。我们开会在26楼，公司的健身房也在这一层，我认同劳逸结合的观点，于是决定放大家15分钟的假，和他们一块去健身房运动片刻。于是大家嘻嘻哈哈地过去，打乒乓球，打台球，跑跑步，抬抬杠铃，挺活泼的。差不多15分钟后，回到会议室时，大家显得比之前更具有活力，就开始接着下面的brainstorming过程，来产生action。
 
以前的做法通常是先一个人想，再两个人交流，再两两配合交流，然后一起总结。有些scrum master喜欢主导整个过程，而我则非常喜欢将控制权交由团队的成员。曾经的一次是，最后形成分别是4人和3人的小组时，结束讨论，让他们展示自己的成果，一个同事负责讲解他们的action和理由，另一个同事则协助将这个action记录在flip chart上，这既满足了大家理解的需求，也有一定的visible的特点，又强调了团队成员间的充分沟通（如果不充分，那么记录的同事可能根本就不知道他的同伴在讲什么）。这次也差不多，我讲控制权交给成员，希望他们有自愿者可以出来记录action，并启发大家思考，而此时我又使用了两张额外的 flip chart，标题都是ACTIONS，放置在之前的三张flip chart的中间，彼此非常靠近，是希望可以在对应的问题和最后的action之间形成一个关联。效果还不错，在大家略带调侃的方式中，action被讨论出来，当然还有其负责人。而在这样更轻松些的氛围中，虽然有开玩笑式的推诿，但其实大家都默认的接受了必须有人来负责action，相比以前我们有很多 action都因为似乎只能有外部人员可以负责而付诸流水，我们给每一个action都找到了主人，而且大家都承诺会完成！
 
至此，整个sprint retrospective结束，历时接近4个小时。

此文最初发表于博客。

---

作者介绍
徐毅目前在一家大型欧美电信企业工作，具有丰富的软件开发、软件测试及测试自动化经验，同时，具有丰富的Scrum开发模式经验，目前担任公司的Scrum Master。专注于如何使Scrum顺利地融入企业中，如何创建一个Scrum的生态系统，以及敏捷开发中的测试。

 

    在敏捷开发过程中，我们还需要对系统架构进行设计吗？事实上，Martin Fowler在《Is Design Dead?》一文中已经给出了答案，那就是我们同样不能忽略对系统架构的设计。与计划性的设计（Planned Design）不同，我们需要演进式的设计（Evolutionary Design）。在敏捷开发的生命周期中，我们通过每一次迭代来丰富与更新我们的设计方案，以使其最大限度地符合客户对系统的需求。这里所指的需求，包括功能性需求和非功能性需求。

    在Agile Journal四月刊中，IBM's Methods Group的敏捷专家Scott W. Ambler详细地阐述了在敏捷语境中的架构设计方法，他提出了所谓“架构预测（Architectural Envisioning）”的方法，以应对敏捷开发中逐步演进的架构设计过程。

    Scott指出，敏捷模型驱动开发（Agile Model Driven Development，AMDD）明确地包括了初始需求分析与架构建模，这个过程发生在敏捷项目开发的第0次迭代中。所谓第0次迭代，就相当于项目的热身活动，是项目得以启动的基础。在此迭代期间，团队需要充分地理解项目的范围，甄别可行地技术策略。这个阶段所能够收集到的信息将有助于你对整个项目最初的粗略估计，以制定合适的项目计划，从而获得启动项目的资金与足够的支持。

    敏捷模型驱动开发的生命周期如下图所示：

    根据图中所示，在每次迭代的初期，制定的迭代计划都应该包括建模的工作。在此期间，可以召开建模的头脑风暴会议，讨论系统的功能特征，并思考实现这些特征的高层设计策略。大多数敏捷团队都会通过测试驱动开发（TDD）确定需求与设计的细节。

    通过对架构的预测，可以在项目早期进行一些高层次的架构建模，以助于团队与关键利益相关人商讨系统采取的技术策略。这一行为的关键目标是识别出架构策略，而不是撰写如山一般堆积的文档，从而使得你能够快速完成架构建模。其中的窍门就是尽量保持简单。开发者不需要对大量的细节进行建模，而只需要足够即可。如果你正在编写用例，意味着你只需要以标注形式列出用例的要点就足够好了。如果你正在对领域建模，可以直接在白板上绘图，或者使用CRC卡片。你的目的在于对信息的共享与交流，而不是编写细致的文档。

    如果采用架构预测的方式，你需要对哪些内容进行建模呢？Scott在文中指出有如下四部分内容需要建模：
   1. 技术图表。例如UML部署图。这些图表有助于开发者预测主要的软件和硬件组件，包括你需要访问的旧系统和数据库，系统有可能会与它们进行交互。
   2. 用户交互流程图。通过分析用户交互的主要页面/外观和报告，对系统的UI进行架构设计。如果在进行架构设计的时候不考虑用户交互界面，就可能存在潜在危机，那就是你构建的系统不是利益相关人所希望看到的。请记住，UI才是最终用户使用的系统。
   3. 领域图。在最初的架构建模中，一个重要的组成部分是对领域的高层建模。模型可以非常微小，只需要捕获主要的业务实体，以及它们之间的关系。有的人可能认为领域模型应该属于需求建模的一部分，而不是架构建模。但正如上图所示，这两者在第0次迭代中是并发进行的。
   4. 变更情形。就是在架构级需求中描述可能的技术或业务变更，而这些变更需要在未来能够提供支持。变更情形要求你考虑架构的扩展能力，但并不是过度构建你的系统。因为你只是要考虑由于变更所造成的影响，以确保你构建的系统还能够正常工作。

    架构建模是贯穿于整个项目周期的，因此这些图表就是在项目结束时形成的整体文档的基础。由于你事先明确架构是演进的，因此就不必承担架构设计在项目早期必须“正确无误”的压力，而只需要在当前形势下保证足够好就可以了。Scott建议使用白板和草稿纸等简便工具，勾勒出这些模型的初始版本。当然，如果团队成员具有熟练的建模技巧，也可以使用专门的建模工具。这一建议足以体现架构设计的敏捷性，与长篇累牍的传统架构设计方式迥然不同。

    对于这样一种架构设计方式，熟悉传统架构设计方式的架构师普遍不以为然。Scott对这一看法给与了强有力的反驳。他将架构设计场景分为三种类型。第一种是架构师熟悉系统架构设计所必需的技能与经验。既然你已经熟悉了这些内容，当然就没有必要作出完整的设计了。你只需要在白板上体现你的架构设计，保证团队的每个人都能够按照相同的体系架构进行实现就可以了。

    第二种场景是架构师对相关技巧与经验完全不知。此时，仍然只需要作少量的初始建模即可。因为你缺乏足够的知识来完成细致而又全面的架构设计，反而会因为了解不够而导致错误，从而增加项目的风险，并且阻碍了项目的进度。

    第三种场景则是架构师熟悉部分知识。这种情形也是团队开发中最常见的场景。在这种情况下，可以耗费几天时间作出一个初始的架构建模，以验证系统可能存在的风险，并制定可能策略以减轻风险可能造成的后果。你可以实现一些可工作的代码来验证架构。建模在这种情况下是非常有意义的，因为它使得你可以定义一个一致的技术愿景，为团队成员所分享，并对系统的主要问题进行思考。

    当你的团队成员是分散在各地时，或者当团队非常庞大，下面分为多个小组时，这种初始的架构建模就能够带来无与伦比的价值。它有助于在团队成员之间建立一个公共的愿景，更重要的是它能够识别出分离的组件/子系统，以及这些组件的初始接口。一旦识别出这些耦合度较低的组件或子系统，就能够合理地对团队进行分组，并保证小组之间设计与实现的一致性。

    Scott指出，所谓的“架构预测”能够提供如下价值：
    1. 提高生产力
    2. 降低技术风险
    3. 减少开发时间
    4. 增强沟通
    5. 可伸缩的敏捷软件开发。

    需要明确的是，这样的一种架构预测方式，正好符合敏捷开发迭代的需要。在项目开发早期，对系统整体进行一次高层次的概览，并对关键业务需求进行甄别与分析，划分合理的系统模块，有助于在迭代开发中为团队成员建立一个统一的标准与目标。而在每次迭代过程中，团队就可以对本次迭代期间的功能进行深入的架构建模，然后通过TDD充分理解需求，对模块的细节进行设计与实现。这是敏捷架构设计的核心操作原理，它与敏捷开发原则是一脉相承的。

本文最初发表于IT168。

---

作者介绍
张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（MVP），著作/译作包括《软件设计精要与模式》、《WCF服务编程》。张逸熟悉C#，ASP.NET，WCF等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 SOA企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。

作者：袁绍    来源：IT168

     不久前在广州，笔者参加了一家软件公司主办的关于软件项目开发的高层研讨会，其间有两个问题讨论非常热烈，值得与大家分享。第一个问题是：“有多少人的工作跟项目开发管理相关？”大部份的人举起了手。但第二个问题是：“有多少人了解软件项目开发精益管理的方法？”举手的人就寥寥无几了。

    精益管理的思想起源于丰田公司，归纳起来精益思想是在创造价值的目标下，通过改良流程不断地消除浪费。现已被广泛用于生产制造管理，但用于IT软件项目产品开发的实践尚属凤毛麟角。我们看到这个讨论的话题时，许多人发出了一种会心的微笑，在笑容的背后感到这又可能是一个外行人指导和领导内行人的炒作话题吧。但经过大家的研讨，发现在做IT软件项目开发的时候，也应该跳出本行业局限的眼光，看看外面其它行业的思想和方法，从中吸收有益的精华。

    精益，是一种思想，一种哲学，一个方法论，其精髓是拒绝浪费。我们IT项目开发学习的不是“精益生产”的形式，而是其精髓思想。这种思想，不仅可以用于生产，也可以渗透到IT软件项目开发中。在研究会上，我们讨论到一个借鉴了精益思想的IT项目开发是一个系统的观念。一般来说，IT软件项目精益开发系统包括三个要素，即人、流程和技术。以借鉴到IT软件项目精益开发来说，就是需要为IT项目的开发提出一系列的流程，培养技术队伍，运用最有效的技术和工具。同时，必须注意要把这三个方面整合在一起，成为一个协调发展的系统。

    例如在人的方面，精益思想强调如何将每个员工的能力发挥到极限，认为不应该只是简单的管理人，而应该去培训人。如果不能将管理的重点放在员工的培养上，就不能理解精益生产的真理。同时，精益生产的另一个精髓是管理过程，精益思想不是着眼于结果，而是强调过程。“只对结果管理”的管理思路的结果是员工对找借口、为结果辩护很在行，对数据、报告很在行，但软件项目成果的质量只有在全过程都有效控制下才能得到根本的保证。

    一. 建立顺畅的开发流程

    确定高效的IT软件开发流程，是精益思想开发的第一个精髓。

    如何创建一种高效、顺畅的软件项目开发流程？首先，精益思想提出强调“建立健全研发流程“。所谓精益软件开发思想包含了一整套的方法论和实施方法。精益软件开发将精益生产中持续改进的概念引入到软件开发过程之中，实现对软件开发过程进行精益管理。实现精益软件开发的核心在于：建立一套完整的开发流程，然后建立一套测量流程的手段，不断持之以恒地改善流程，不断优化，坚持不懈。

    不同的企业因定位不同，对于研发的价值理解也是不一样的，他们的流程和实现流程的工具肯定是完全不一样的。但我认为软件开发人员应当向丰田公司的产品开发流程学习和借鉴。目前，丰田内部的精益开发步骤是这样的：首先，在客户需求的基础上，对工作进行分辨，区分出哪些部分是能够满足客户需求的有效部分。如果工作中的某些流程生产出的结果并不能满足客户的需求，便是一种浪费，就不是增值的流程和操作。因此，精益开发首先需要了解客户需求。此后，需要对工作流程进行细化分割，把流程分成更细微的步骤，并保证每个步骤都能满足客户的需求，增加价值。

    其次是流程的标准化和可操作化，这是精益思想流程的基础之一。在软件开发过程中，每个企业的现状不同，因此产品开发的方式也不同。但精益思想提到如何关注研发流程，让管理流程“落地”，并要让流程规范起来，不再是像过去把好流程放在纸上，靠人去管理。固化和标准化开发流程就是一个方式。

    二．引入首席项目主管负责制

    精益软件开发的第二个精髓，是将合适的人员安排在合适的岗位上，建立一个有效的软件项目开发组织。首席项目主管负责制度是精益软件在人员安排上的核心方式之一。每个项目的开发团队的都心须确立核心领头人，并要突出了首席项目主管的角色和地位。

    首席项目主管必须非常清楚，他们接手任务之后，他就要开始考虑自己的设计思路，并把这个思路和团队交流。他的思路有两部分：一是勇于面对困难和挑战，当遇到挑战时可以这么做，也可以那么做，最终希望能在这些方案中达成平衡，而不是做退缩；二是要找到问题的根源。

    首席项目主管应该具备三个能力，这也是丰田的标准：首先是很高的技术水平，是一个能力非常出色的总工程师,而且要对产品有整体意识和远见卓识。第二，要有项目管理能力，要代表客户，理解客户的需求。第三，要有出色的领导能力。

    对于一个企业来讲，如果需要做软件精益开发，公司的结构也要做一些改组。精益思想建议采用的是一种矩阵式的组织架构。在这种架构中，团队按照具体项目和功能来划分，最大程度地使两者的优势结合在一起。比如说，首席项目主管整体负责一个项目，不同项目有不同的首席主管，他们可以组成首席主管团队。而对于各种不同的项目功能需求，又按软件不同的功能部分分组，负责每个功能小组的是职能部门经理，如某些不同项目可能用到共用的功能模块，各职能部门的工程师向该部门的经理报告，以实现按功能优化和同类经验共享。

    其次，精益思想除了强调首席主管负责制度外，还提到一个重要的关于人的因素是：团队是推进精益管理的关键。通过推行精益管理，建立一个基业常青的团队，调动起每一个员工的积极性，只有这样才能推动开发项目各项工作持续发展。建立一个良好的团队则是企业能否有效实施精益管理的关键。

    最后，精益管理的推进要以人为本，精益管理虽然有各种流程作为基础，但是运行这些体系和流程的是人。熟悉丰田精益方式的人都知道，丰田方式中一个很重要的内容就是人员管理，即“育成”。育是培育，成是成功，强调人才培养，把人才看作是人“财”。一项针对包括丰田在内的50家具有百年历史的全球500强企业的调查显示，这些企业的共同之处，就是拥有共同的理想、共同的价值观、共同的行为准则的一支强大团队。

    三．有效技术和工具的支持

    精益思想软件项目开发的第三个精髓，是用工具和技术来支持流程和人的工作。在引进新技术方面，丰田奉行的原则不是积极倡导新技术，而是使用可靠的、已经过充分测试的技术。工具和技术的意义在于支持流程，而不是驱动它；是加强人的工作，而不是替代人。

     无效的软件项目开发技术和工具会糟糕的在计划进度，成本和质量等方面带来失败，这将最终导致整个项目的失败。同时，没有有效的工具来支持会使项目开发处于非持续性和不完备状态。很多失败的项目中的教训揭示了能够充分地支持项目开发的工具简直太少了。很多时候，软件项目在没有监督和跟踪时都会变得失控。因此，要很好地完成项目，必须要有好的项目管理工具，进行有序的项目管理才能够实现。

    精益软件开发在这里提到两个观念，一是软件开发应用到的技术平台，二是开发过程所使用的工具。软件开发应用到的具体技术平台，由于每个项目的需求和资金预算不一样，所使用软件开发技术平台也是各式各样，不能一言而简之。但精益思想重点提到的开发过程中工具的选择和使用。工具不一定要追求最新的，最高科技，最昂贵的工具。反而应该不断发挥团队的智慧，结合开发的具体情况，不断探讨实用的工具，减少浪费。

    这里与大家分享一个有趣的例子，工具并不一定是最新的高科技的东西，有时它可以是很直观的方法。“大屋”是丰田普锐斯首席工程师想出来的一个工程合作方式。他把各个职能部门的工程师聚集在一个大房间里。在这里，他们把产品开发状态的信息打印出来，包括种种数据、成本、质量、进度等关键问题，贴在墙上，每个人都可以方便地查看、讨论。当他们在一个房间开会和沟通的时候，他们就更加融洽，交流得更好，更容易做出决定，从而缩短产品开发时间。“大屋”听起来很简单，甚至有点可笑，但是它支持了流程和人的工作，就是正确的工具和技术。

    所以精益思想强调，首先正确设计你的流程，然后再去找合适的工具让这个流程开动起来。不管是软件开发用到工作工具，还是别的工具，只要能够支持这个流程，就是合适的工具。