咸与敏捷，并且穿上了马甲

你以为我就不认识你了吗。

本来Scrum的Demo是相当重要的事件，Team向Product Owner和利益相关者演示可运行的程序，并允许他人使用操作。而现在的Demo就是充满PPT的Report和training，没有多少人真正关心内容，因为很不相关，但又必须参加，所以只能用手机来打发时间。

clipped from www.infoq.com Jim Shore的那篇广受欢迎的文章《The Decline and Fall of Agile》，该文指出在日益增长的敏捷社区中有这样一种倾向，组织只是在名义上采用“敏捷”，而没有采用如何真正成为敏捷的实践。 在Flaccid Scrum一 文中，Martin Fowler重复了Shore大部分的观点：许多敏捷实施缺少了极限编程中强调的技术实践，比如结对编程、持续集成、测试驱动开发。和Shore一 样，Fowler也承认组织实施敏捷时普遍会优先选择Scrum，但即使这样，这也不是Scrum本身的错。作为补救措施和对大家的提醒，他强调说那些领 导实施Scrum的人需要特别留心，要找机会推动合适的技术实践： 以我之愚见，“他们会逐渐采用技术实践”这种想法极其幼稚。大多数情况下，他们根本就不会采用技术实践，即使采用也是少之又少，就好像根本没采用一样。 所以我们需要承认好的流程依赖一些关键因素，而技术实践就是软件开发中最关键的因素。把它推迟到敏捷后期实施绝对是一个坏主意。 极限编程/敏捷/Scrum越来越流行，许多团队和个人都想这么做，或者想“成为”其一。这直接导致了称之为“环境相关”的一些敏捷方法。其意思是任何类型的敏捷都“太死板了”，“不适合我们的环境”。所以我们不得不修改敏捷实践，因为上帝也知道我们没法修改环境。 亲 爱的朋友们，真为你们感到难过。恰恰是你宝贵的环境拖累了你：是中央级别的执行官和高管们不能把职责和权利交给大家；是产品的人总是太忙，以致不能解释真 正要做什么；是管理设施的人不能创建适合工作的环境；是程序员不愿意学习必须的技术；是经理和产品负责人不断施压，直到对项目的质量没有任何关注。 太极敏捷有一个理论叫 CMT，文化决定管理，管理决定技术，因此太极敏捷认为只有具有先进文化的团队和企业，才能实现真正的敏捷变革，并从中获益

测试人员其实也需要知道业务逻辑

昨天和Brand在谈这个Sprint测试中的一些感受，我们都承认，我们的测试，尤其是自动化测试，往往是根据当前程序的行为结果来作为测试的预期。举个例子，我们的程序应该是输出A，但当前程序输出是B，我们的测试人员就把B作为测试的预期。当然，如果在未来，程序员发现实现的逻辑存在问题，做了修改后做回归测试的时候就会发现问题，也许要通过更多的代价来确定是测试问题还是程序问题。为了完成当前的测试任务，而摒弃了测试的基本原则，将解决问题的时机推迟到了以后，为未来埋下了祸根。

究其原因，是我们Team的测试人员，对业务需求和逻辑不是很清楚，他们也不是很清楚正确的程序行为应该是什么样子。这些在开发人员尤其是代码实现的成员那里应该是清楚的，业务逻辑作为知识没有实现在Team中的传播，大家各有各的目标各做各。

确保测试的原则被贯彻和软件产品的质量，这是SM的责任。而我们的SM整天在忙着救火，解决Bug和技术问题。

测试人员和开发人员的比例多少才合理？

clipped from www.infoq.com 测试人员和开发人员的比例多少才合理？ 许多年来，人们对研究测试人员和开发人员的“合理”比例充满了兴趣。《微软秘笈》书中指出，微软员工中测试人员和开发人员的比例是1比1。根据在某会议上非正式的调查，Randall Rice发现通常的比例是1个测试人员对3个开发人员。而Cem Kaner和Elisabeth Hendrickson发表的一篇论文认为，这样的比例毫无意义。不同的项目里这些角色被赋予的职责和任务相差甚远。举例来说，自动构建负责人应该算作开发人员还是测试人员？ 除了计算问题，小组还发现，项目环境的差别使得不同项目的比较更缺乏意义。这些因素包括： 项目要求的可靠性 必须测试的可配置的范围 软件的易测试程度 工具的可用性 测试人员和开发人员的经验 必须坚持的质量标准

以前的很多经验和理论是和敏捷原则是相悖的，比如，专门的QA和测试Team。QA的工作如果是从软件开发流程和宏观的角度来给质量把关，最终秀一些Report的话，我想他们不薄的薪水可以用来购买（或者采用免费的开源系统）和使用类似的软件系统，有些不能被机器代替的工作交给Management来做就可以了，显然这是一种浪费。单纯的测试Team,如果是为了提高质量和客户满意度的话，有其存在的理由，但测试的应该是High level的。

将测试分散到软件开发的各个阶段，交由Team去完成，尽量自动化，尽可能高频率地重复测试。

复杂度如何更好分解

几个月前的一篇Blog——软件复杂度的构成中，已经对软件开发复杂度的构成有了分析。

The Boeing 747-400 “Jumbo Jet” has six million parts, of which half are fasteners. It contains 171 miles (274 km) of wiring and 5 miles (8 km) of tubing. Seventy-?ve thousand engineering drawings were used to produce the original 747 design. It is a very, very complex machine, and because of this complexity, no single person can have a complete understand of how a Boeing 747 works. Yet, this is a machine ?rst designed in the 1960s — modern aircraft have multiplied the level of complexity many times over. The only approach that will allow human beings to design such incredible machines is to break them down into smaller, more understandable modules.

——From 《OSGi In Practice》

除了问题域带来的复杂性之外，还有其他两个维度：
1）软件开发是多个个体通过分工协作进行智能产出的Process，人员的组织和Process的风格，当团队Scale后引入了人为因素的复杂性
2）技术作为工具，在不断发展更新，技术和工具的使用的同时也会引入额外的复杂性（配置和约定，不同语言的集成，操作系统/数据库/应用服务器/框架，更多的成为黑盒子，将程序员划分为不同的家族）

通过分而治之是解决复杂性的王道：通过抽象和松耦合集成，下放复杂性到内聚的子模块，上层很简单下层充分自治。

在软件开发团队管理方面，ScrumMaster只是Coaching的角色，让团队自己决定技术方向实现并承担失败的责任；在工具方面，Eclipse将各种IDE功能下放到松耦合的不同插件中去，而自己的OSGi+Plugin内核相对简单。

秀一下我的Scrum Master证书

这可不是什么假证，上面还有Ken Schwaber的电子签名哦

Scrum和我系列之———群众基础

理越辩越明，思想在碰撞中激发，问题在探讨中找到出路。

Wiki,群众的智慧，三个臭皮匠顶个诸葛亮（三个皮匠是第一线）

Bob的想法很务实。

Team中队Scrum和敏捷的认识，也许只是表现出来的一些实践(每日例会，Cross-function team，自动化测试和持续集成），并不知道为什么不知道如何改进。他们需要知道这些吗？知道和不知道有什么区别

Scrum需要team的了解和理解和支持，需要有广泛的群众基础

如何扩展群众基础的几个思路：
1）通过新媒体建立自由讨论的社区
2）让Scrum Retrospect Meeting起到作用
3）让Team行使自己的权利，做出自己的判断和行动，看到改变的效果（我始终相信，在外企中的不少人还是希望在工作中做些让自己有成就感的事情，但是这种希望和冲劲被抑制了），有了Feedback,尝到了甜头就是最好的开始。

Scrum和我系列之———开场白

许久没有静下来写关于自己的Blog了，很有可能是太忙的缘故，这时候我总是试着拿自己调侃：忙忙忙，到底是真忙还是假忙？忙的是有意义的事情还是瞎忙？

回想最近一个多月所作的事情，其实还是不少。在Cometa上个也是第一个Sprint中，Maven和Production Pipe环境搭建，让我真实实践了一把XP Practice——Maven and CI，这种切实的实践让我对如何带领一支Java团队在技术上一步步敏捷化有了足够的信心（在IJO的时候只是在使用也知道原理，但这次是真实的动手操作）。在技术兴趣方面，对TCard的技术选型有了比较清楚的路线图——OSGi成为架构的核心，先以Riena作为基础架构；然后重构RCP端的UI部分，实现自动更新；最后考虑增加Web版本，直接挂在OSGi 后端业务server上。

昨天刚刚参加完CSM培训，两天的培训相当充实，老师讲得不错，不少东西还亟待以后思考消化。在培训之前做了不少的准备：再次读了一些书，和同事在中午散步时讨论对Scrum的理解和感受，介绍一些Scrum的资料给新的员工。在Scrum Master狼叫声中(一种形象的问候和勉励方式），大家写下并交换了自己打算在培训后采取的行动，我拿到的是Bob的：Brief the basic idea and some practical issues to our team,很切实很有意义；而我的似乎有点很难实现：在Team中采纳真正的Scrum实践，并Ask for support from management level。今天中午散步时本想把自己的真知灼见布道给同事，却没想到被泼了一身冷水：Scrum还是其他什么Process，无论是team leader还是Line Manager还是Scrum Master，换汤不换药，只管做事拿薪水，I don't care那些虚的东西。

从前两天的对实践Scrum的渴望激情，到现实的无奈的思考，真有点冰火两重天的感觉。很想找个人进行交流，只好以Blog作伴，将自己的所有想法和理解用理性的文字陈述出来。

希望在此系列谈论的话题包括(此时能想到的)：0)一个人的单打独斗 1)Waterfall的经历 2)初始Scrum 3）从技术/People/需求的视角化解复杂性 4）Defined VS Empirical 5）Lean,改变世界的机器 6）Scrum Master是角色不是职位 7) 合格的Scrum Master是个会教育孩子的父母 8）XP实践是推进Agile的利器 9）公司文化和组织架构如何影响Scrum演进 10）Component VS Feature Team 11）透明/Owner/Reputation/开源文化 12）自下向上的草根革命 13) 因为Simple所以Difficult/容易背骂名

工作中的两个想法（一）

在NSN工作了一个半月了，随着对NetAct产品的了解和敏捷团队的融入，有一些感受和想法。

以前没有接触过像NetAct如此庞大的应用系统，部署和运行在网络运营商的内部网络中的网络管理软件，一言以蔽之就是收集网络中的各种元素（网元）的运行状态信息，展示给业务操作人员，并进行远程的配置和管理。但由于要符合网管标准和考虑到和其他网管系统还有上层Business Level的系统集成，运行的高可靠性，及方便快捷地更新和升级的要求，系统就变得复杂起来。

整个系统架构的特点就是：非常多的松耦合的进程，通过协作完成所有功能。这种设计的结果就是非常细粒度的模块，被不同的团队所负责，不同的模块形成不同的小的Layer，系统整体上很复杂，但或多或少受人为和历史包袱所致。

以前开发的应用基本都是在Java虚拟机进程的范畴内，通过将业务员逻辑细分为不同的模块，数据流是和线程绑定的，线程是对外部消息和请求反应的执行载体，一般不会把数据流的操作划分为自治的多个线程，通过线程间通信来实现。

对于动态性的部署需求，Java社区中的OSGi热也许是未来的一个发展方向。

当前项目团队中需要能够扮演Architecture的角色，讲解每个模块的由来和未来如何发展，扮演Product Owner的Scrum 角色。

Scrum from Ken Schwaber at Google Tech Talks

Ken Schwaber is the owner of the scrummaster trademark, a course in Scrum software development process. He is one of the leaders of the agile software development movement, and a founder of the Agile Alliance.

Ken worked with Jeff Sutherland to present Scrum as a formal process at OOPSLA'95. They have extended and enhanced Scrum at many software companies and IT organizations.

如何学习/引入/改进敏捷

1） 敏捷实践和技术是和团队和团队所在的环境紧耦合的，不是跨平台的
2） 敏捷背后的哲学（价值观和原则）是抽象的，需要通过具体的敏捷实践来表达
3） 先看到别人是怎么实践的是第一步，活学活用是最困难的

clipped from www.infoq.com 很多人都只是片面的关注具体实践，而不是它背后的哲学。如果你只是一味的采用实践，对这套体系的哲学理念置之不理，还想有多好的成效，那可能吗？ …… 我觉得要学会怎么实践敏捷，最起码要花上几个月的时间。你得进入团队，用敏捷的方式工作，你需要查看所有的因素是怎么配合到一起的。这要经过几个月的练习才行。 学过唯物主义认识论的人，或者说，能够有清晰缜密的思维逻辑的人应该都清楚，我们是先要认识世界，然后才能谈得上改造世界。换句话说，是先认识到问题所在，然后对症下药量体裁衣去 解决问题。假如，我们能够有一个统一的认识：为客户交付高质量的软件，能够适应客户不断变化的需求，在成本和收益之间达到最佳的平衡，消除潜在的或是明显 的浪费，能够让客户收获最大的ROI（Return of Investment）；那么问题就很明显了——为了达到这样的目的，我们需要采取什么样的手段？ Jeff Xiong在敏捷中国内说过的一段话 我不要敏捷 我要致力于消除软件开发中的一切浪费

在Scrum的讨论中审视QA

A:你对软件流程方法论有多少了解？
B:你指的是哪些？
A:Agile/RUP/Scrum/XP/CMMI？
B:有那么一点点研究,我在项目中正在实施scrum
A:你是什么角色？
B:pm啊
A:靠，应该是ScrumMaster或者Product Owner
B:哦 你是说在scrum中的角色啊
------------------------------------------------------------------------------------------------------------------------------
这位老兄可能对Scrum没多少了解（他也承认）就在实施，他似乎更关心行政上的PM title.

------------------------------------------------------------------------------------------
B:我们没有完全的按照scrum checklist中的方法去组织项目,毕竟，这些方法论在实践中要灵活的使用，不能一味的完全照搬。xp，scrum的一个很大问题，就在于它们和传统的QA制度简直是格格不入。
A:传统QA都具体做些什么？
B:传统qa主要是通过在开发和集成阶段的一系列测试来保证qa质量
A:那么QA的工作应该转移到ScrumMaster这里，test成员应该是开发Team的一部分，对吧
B:不能这么简单的来转移,qa并不属于开发team，在任何一个公司都不属于
A:我的意思是，没必要专门成立QA部门,质量的保证是一个Scrum团队的责任和义务
B:你不可能在全局范围上 让公司的建制跟着你的项目变动，那样的话，你根本推不动scrum
A:思维的转变，管理层的支持是推进敏捷的必不可少的东西
B:如果这是必不可少的，那就不要实施敏捷好了 ：）,你不可能让老板们放弃传统的qa制度，仅仅因为你说敏捷可以解决一切问题
A:敏捷和传统的方式都能解决问题，只是敏捷可以更好的交付真正有价值的产品。如果老板不能放弃，那么真的很难
B:站在老板的视角，你凭什么说敏捷能交付更好的产品呢
A:实践是检验真理的唯一标准
B:公司不是实验室，产品也不是实验室里的小白兔。况且敏捷的方法并不是万能药，特别在大型项目上，要掌控好敏捷项目，对pm是一个很大的挑战
A:就是为了掌控好项目，所以才采用敏捷的方法论。当然不是万能药，敏捷是一个框架，你可以根据自己的需要扩展。有那么多的成功软件企业都在实践敏捷（最多的是Scrum），他们不是在闹着玩吧
B:有实践的结果吗？微软的哪一个大型产品是敏捷开发的？adobe呢？sap，oracle，IBM呢
A:Nokia是Scrum实践最好的，还有google http://www.infoq.com/presentations/Agile-Management-Google-Jeff-Sutherland
B:什么产品？
A:我认识的诺西的一个Manager，他们的网管产品NetArt,他们自己部门在实践Scrum
B:google只是在试验scrum罢了 成果还没看到呢。说实话 像NetArt这种大型产品，根本没有做scrum的必要，我不看好这种胡乱上马的架势。
A:Scrum是一种软件开发的方法论。任何东西，千万不要上来就排斥，兼容并包......
B:我怎么排斥了 我正在自己的项目中实践scrum
---------------------------------------------------------------------------------------------------------------------
一个正在实践Scrum得管理者对Scrum抱着种种猜疑，我很怀疑其实践Scrum的动机。

对于Agile和QA/Test的讨论，发现有很好的一篇讨论文章,援引几段文字表达我的看法。

The problem with QA is that programmers lose the responsibility for quality, because they start to think "it's QA's job." No, quality is not QA's job. It is the programmer's job, and the designer's job, and the architect's job.

You want quality in software? Make your programmers do peer reviews of all code before it gets checked in.

You want quality in software? Don't let your programmers start writing code until they can explain it clearly in English (or whatever spoken language your team has standardized on) to someone else on the team. Make sure the design makes sense before they get half-way done building the new pile of spaghetti code.

Our industry -- the software industry and those who write application -- as a whole produces mostly crap.

忘了粘贴讨论中的一句话：scrum的整体架构大话都知道，它起源自制造业的精益生产的变革，它是为了解决传统瀑布的问题，没有限定使用在什么软件开发环境。当然工程性的软件开发用起来最有效果。说到解决什么问题：根据市场变化就是快速生产，减少浪费（制造业的视角）。

当然对于偏产品研发的项目，适当保留QA的角色是合理的，但要求在项目中更多的参与并成为团队的一员。

还是很感谢B先生，思路和想法真的在讨论/辩论中才会越来越清晰。

Open Your Eyes，Nothing is new

历史总是不断地重复，只是你视而不见而已

《改变世界的机器》，这本只粗读了一半的陪我度过“至今最苦闷”的那段职业生涯的日子的一本书，不仅让我了解了汽车史和福特、通用和后来的丰田的发展史，更让我豁然开朗，作为制造业代表的汽车行业上演的关于如何更好地进行生产管理的理论的与时俱进的不断演进，也让我更好地理解了当前的商业竞争的趋势。对于一个当时身处于“软件制造业”笼罩的软件工人的我，发现来自软件开发的领域的敏捷开发的方法论就是从“制造业”前辈的变革和哲思中，引入和借鉴而来的。

日本人提出了精益生产模式，主要是通过降低成本的方法来提高利润。在长期的生产管理实践
中，日本人发现决定产品成本和利润的主要因素是制造过程中的各种消耗，特别是人的工资消耗。于是日本汽车业就提出了精益生产，旨在优化生产组织结构，去掉一切不增值的生产过程和环节，通过降低成本的方法来提高利润。

在Scrum为代表的敏捷软件开发方法论中，无论是通过快速开发的Iteration，还是每天的Daily Scrum对过程的Visiblity不断Inspector，和Retrospect meeting试图对过程的改进的最终目的都是减少那些和“增加客户价值”无关的活动。以前那段苦闷的经常开会的日子里，没有人关心这些meeting有没有增加产品的价值。

作为技术人员，我也曾经痴迷于技术实现，也的确认为技术有意思。

但当我们将软件行业作为社会各行业的一分子去看待的时候，站在更高的视角来看待其中的很多的背景的时候，你会发现IT是服务性的行业，还很年轻，其变革是随着整个商业变革演进而演进。

关于Scrum Roles

There are only three Scrum roles: the Product Owner, the Team, and the ScrumMaster. All management responsibilities in a project are divided among these three roles. The Product Owner is responsible for representing the interests of everyone with a stake in the project and its resulting system. The Product Owner achieves initial and ongoing funding for the project by creating the project’s initial overall requirements, return on investment (ROI) objectives, and release plans. The list of requirements is called the Product Backlog. The Product Owner is responsible for using the Product Backlog to ensure that the most valuable functionality is produced first and built upon; this is achieved by frequently prioritizing the Product Backlog to queue up the most valuable requirements for the next iteration. The Team is responsible for developing functionality. Teams are self-managing, self-organizing, and cross-functional, and they are responsible for figuring out how to turn Product Backlog into an increment of functionality within an iteration and managing their own work to do so. Team members are collectively responsible for the success of each iteration and of the project as a whole. The ScrumMaster is responsible for the Scrum process, for teaching Scrum to everyone involved in the project, for implementing Scrum so that it fits within an organization’s culture and still delivers the expected benefits, and for ensuring that everyone follows Scrum rules and practices. ——摘自Ken Schwaber，Agile Project Management with Scrum，Chapter1

从上一篇Blog（软件开发复杂度）的分析，三个维度构成了复杂性: 软件实现技术，开发团队的组织，客户需求。在Scrum中，正好有对应的角色：自组织的Team通过交流合作解决软件实现中的各种技术问题；ScrumMaster负责组织团队，激励服务团队；Product Owner负责对客户需求从宏观和Business的角度来管理。

Product Owner是由什么样的人来担当？
理想情况下,应该由客户担当，但考虑到交流的成本还是由公司内部的人作为客户代表，负责和客户沟通交流。他可以完全不懂技术。

ScrumMaster是否应该是个技术专家？
从其职责来看，ScrumMaster应该是Scrum和项目管理的专家，也就是可以不是技术专家，但对于小团队来讲，需要担任一定的技术工作。ScrumMaster不一定嘛也不可能知道掌握所有技术细节，但对技术的背景应该有深入的理解，这样才能给予团队技术的培训和支持。

软件开发复杂度的构成

第一次从宏观地看待软件开发，还是在研究生毕业论文中对“软件危机/OO/CBD”的研究。当时主要是从代码重用，代码可维护性等软件实现技术的角度来探讨，在现在看来是“盲人摸象”。

软件开发是“脑力制造业”,属于服务业，服务的对象是其他不同行业，帮助他们降低成本改善运营和扩展business。

既然是服务性质的辅助行业，那么来自不同行业和领域的软件需求，固然会随着整个经济形态的不断变化，客户需要的是软件系统能支持和适应市场的瞬息万变，所以需求复杂度的提高、需求可变化成为必然。

软件开发是一个群体合作的过程，人怎么组织和规范他们的行为从而使得软件开发更有效率，关于软件开发流程和管理的方法论也不断演进。人的参与带来了软件开发的不确定性，这其中还包括组织架构，多团队合作对软件开发的影响。

能够让软件开发在技术实现、团队组织、客户需求等方面有好的表现，才能减低复杂度。

我突然想到，在Scrum中的ScrumMaster就要从这三方面均衡掌控。

从零开始是不容易的

"Some people are so embedded in their familiar ways that they have trouble seeing what they have to change, no matter how many articles and books they read and agree with."
—— Ken Schwaber 《Agile Project Management with Scrum》

这句话很好地解释了“It ain't what you don't know that gets you in trouble.It's what you know that ain't so. --Will Rogers”的意思。

Scrum involves a paradigm shift from control to empowerment, from contracts to collaboration, and from documentation to code。

丢下“曾经成功”的包袱，始终实事求是，勇于创新，对一个人和一个公司都是很难做到的。