冰云@Blogging

什么是敏捷？– Q&A

本文是回复CSDN编辑的问题：

> 1. 每个地方、每个人对敏捷的认识和理解都不一样，在我国技术应用和开发的背景下，能否结合您的体会说一下什么是敏捷？

从理论定义上讲，“敏捷是指在动荡的业务环境中，适应变化并创造变化，从而获得价值的一种能力“。Jim Highsmith在他的敏捷项目管理一书中如是说。“同时敏捷是平衡灵活性和稳定性的一种能力”。

(Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Agility is the ability to balance flexibility and stability )

不同的情况下，敏捷的适应能力可能会体现出不同的解决方案和做事方法。这也许是有人对敏捷认识不同的原因：他们被缤纷的实践手段而遮蔽，而忽视了对敏捷原则或理论的目的理解，那就是适应性。

有人说要做有中国特色的敏捷方法，而敏捷本身就是一种适应性方法，所谓适合中国的敏捷方法这本身就是一个错误的阐述。这句话应该说：敏捷思想天生的适合于各种情况，也包括中国的情况，因为他本身就一个适应性方法。在具体的实践上需要针对各组织和团队的情况进行创新。

> 2. 在我国，总体上说敏捷的实施和推广并不理想，“雷声大雨点小”。既然敏捷这么好，您认为为什么不是所有人和公司都用它？

上面说了，敏捷是一种指导思想。在这种指导思想下做事能获得很大的成功。敏捷需要团队协作，这种成功不可能是靠一个人的英雄主义来完成。必须是整个团队和组织在共同一致的目标和价值观作用下，共同努力的结果。很多人实施敏捷不理想的原因，是由于他们无法改变其他人的做事方法，无法获得团队的认同。在没有人支持和响应的情况下，成功真的很难。

另一方面，由于很多敏捷方法的实践者的尝试都局限在开发团队或IT部门中，他们无法改变外在环境，只能靠团队的努力来进行敏捷实践。这对他们的实践带来了很多限制。有时候外部的力量迫使他们不得不放下已经初有成效的实践。这也是在国外敏捷实践过程中人们逐渐发现的一个问题。ThoughtWorks提出敏捷企业的口号，就是要将敏捷思想和方法带给开发团队以外的公司其他部门。从而提升IT部门的创造力，为企业带来增值。

> 3. 摩卡软件的总工程师说，“敏捷并不适合中国？”您是否认同？能否说说您认同或者不认同的原因？

他说敏捷不适合中国的主要观点是说，中国开发者水平不足以实施敏捷。虽然没听上下文有断章取义之嫌，不过这点我不敢苟同。中国的开发者大多数都很聪明，能力用于实施敏捷开发足以。

目前的问题是，许多团队对敏捷了解不多，或者缺乏敏捷教练的指导。敏捷还没有成为他们做事的一种准绳，开发者的对敏捷的思路还不熟悉，很多人还是只了解学校里学到的瀑布模型。所以，在敏捷的普及上还有待各位敏捷支持者一起努力，来建立这样的大环境。

> 4. ThoughtWorks 在敏捷方面一直做得很优秀，在业内引领着敏捷前进的旗帜，您认为为什么ThoughtWorks 会做得这么好？

信念。因为每一个ThoughtWorker都对敏捷抱有坚定的信念。我们发自内心的认为敏捷是好的，是正确的。因此我们都会告诉我们的朋友，来吧，试试看敏捷。

> 5. 如果有开发者从未真正接触过敏捷，您要说服他使用敏捷的开发方法，您会怎么说？

我建议从具体的实践一点点的，手把手的去让他理解为什么要这么做。不用提敏捷，等到他自己逐步的了解之后，自然会水到渠成的明白敏捷是什么。

> 6. 对于使用敏捷开发方法的程序员，您有什么经验或者教训告诉他们呢？

如果你坚信一件事情是正确的，那就去做，不用管别人怎么说。你在做的同时，也告诉你的朋友，我在做这件事，我认为正确的一件事。这可以潜移默化的影响你周边的人。总有一天，你的努力会有成效的。

题外话：不仅仅是对敏捷，对任何你觉得正确的事情，都应该坚持。例如保护环境，例如节约，例如帮助困难的群体，例如微笑。

Tags: Agile 敏捷

Posted in Agile 敏捷, Consultant 咨询, ThoughtBlogs | No Comments »

敏捷需求管理 - Agile China 2006演讲

2007年7月14日下午，俺在AgileChina大会上做演讲：敏捷需求管理。

根据2006年的调查报告，软件项目失败原因的71%是由于缺乏或糟糕的需求管理造成的。敏捷需求管理过程注重于用户交互和客户参与，能够最大程度的发现和发掘用户的真实需求，从而引导正确的软件开发。敏捷需求管理是敏捷过程的重要一环。良好的需求管理可以使开发团队交付更令用户满意的软件。敬请关注

[updated: 2009.05.07 - added the slide]

Tags: Agile 敏捷, Analyst, Business

Posted in Agile 敏捷, ThoughtBlogs, 需求分析 | 1 Comment »

Distributed Agile Software Development

异地分布式敏捷软件开发 (Distributed Agile Software Development)

异地分布式软件开发（Distributed Software Development）是指由多个位于不同地理位置的团队进行同一个软件项目的开发过程。这个词越来越频繁的出现在各种技术媒体中。

异地分布式软件开发不同于外包，它建立在平等关系的两个团队之间。通常是一个公司的不同分公司或办公室间的协作，他们之间大多不存在博弈的合同关系。而外包是指一个公司将其软件系统的开发委托给另一个公司或组织完成。二者之间是合同的甲乙方关系。

但无论是异地分布式软件开发或是外包，可以接触到实际客户的一端一般称为on-site，另一端可相应的称为off-site，他们可以根据地理位置分为三类：on-shore（在岸，指在同一个国家或同一个时区内），near-Shore（近岸，在接近的国家和地区中）和off-Shore（离岸，通常在时差8小时以上）。如下表。

异地分布式开发的组织方式

异地分布开发的组织方式有很多种。最常见的一种是公司将完整的团队组织结构分布在两地，每个团队都有本地项目经理，需求分析师，开发者以及测试。同时公司设定项目总负责人角色，负责两地的沟通与协调。

有的公司将需求分析人员放在on-site一端，开发者、测试人员和项目经理在off-site一方，同时在本地也保持常规的需求分析师。也有公司将测试人员和开发人员分放在不同地方，一方面开发，另一方面利用时差，在夜间测试并在第二天及时反馈测试结果。

各种组织方式都有其不同的适用场合。然而他们的共同点在于，都是注重micro-management，即加强在本地团队中项目管理和协调，而不是由一个人同时直接管理两地的活动。同时，也尽量保证团队两边都具有项目协调人、本地项目经理、需求分析师等辅助角色。

基本原则：极尽交流之能事

异地分布软件开发面临的最大问题是交流问题。随着人员距离的增加，交流效率将大大降低（参见Alistair Cockburn的文章），同时交流成本将极大提高。很多时候on-site一端团队不能把正确的需求传递到off-site一端，这直接造成产品质量的下降。

为了使避免这种情况，应尽量采用一切手段来提高交流的效果。例如，项目经理和团队成员都需要了解其他人的工作状态，一个技巧是可以将你的MSN或Y!名称后缀写上你在做哪一块的需求。并可以随时和同事通过IM进行交流。

交流频度和价值图，Vincent Massol，2004

每天的定时会议将成为很重要的一个很重要的交流方式。如果团队的人数较少，大家可以按照站立会议的方式在电话会议系统中说明自己的情况和遇到的问题。如果人数较多，一种可替代的方式是每个团队自己进行每日例会，并由个项目的项目经理和需求分析人员进行另外的会议以便协调工作。

如果两个团队时差较大，例如中国北京时间和美国东部时间时差12-3小时，想要进行直接的电话会议交流很困难。如果遇到3个处于不同时区的团队，更是经常不可能找到一个合适的时间来进行任何的会议。在国际化的公司中，起早贪黑的进行几地的电话会议很常见，但这却不适用于整个开发团队。对这种情况，每日的开发状态邮件是很有用的。每日开发结束后由项目经理或成员来根据团队的情况来撰写一天的总结，并发送给远端的团队。

交流的障碍经常发生在陌生人之中，如果两地的开发人员互不熟悉，可以考虑将双方人员的照片贴在墙上，以增加熟悉感。可行的话，进行可视会议和当面的会谈。尽量减少陌生感，使交流效果提升。

任何交流方式都比不上面对面的交流。异地开发时，off-site一端很容易丢失on-site一端与客户交流的语义上下文和环境。如果情况允许，公司应该设立常规的出差和轮换制度。让一部分的团队成员到另一端，见一见一起工作的同事，了解一下客户的需求和感受一下不同的环境。

敏捷开发过程的改进

般的敏捷过程中，都会有一个初始阶段，在这个阶段了解开发需求和制定发布计划。要进行这样的活动，最理想的办法是让所有人都出差到on-site一端，一起了解需求和建立共识。这将会对后面的开发有很大帮助。如果由于人数或成本不可行，至少要派遣所有的需求分析师和项目经理、协调人以及部分测试人员到场参与。对于迭代一级的计划，应该由两地的项目经理和需求分析师提前进行计划会议并做出决定。

日常的项目管理工作中，采用卡片墙的方式只适用in-house的开发。在异地开发中，为了使得每个团队都可以了解到团队任务，至少需要在两边开发室都设立卡片墙，并保持同步。可以采用在线工具帮助进行项目跟踪，例如Mingle或Trac，都是适用的在线工具，同时也是在线Wiki或共享知识库。

项目协调人，应当制定完善的交流计划和交流机制。例如前文提到的每日的例会和每日开发状态邮件，每周的需求交流计划，问题的提出和反应机制等等。这些应当制定成为团队守则来遵循，并随着实际情况的变化修订。交流不怕多，只怕不充分。

一个共享的代码版本控制系统是必须的。例如在公司内网建立一个SVN并通过VPN来使用。On-site和off-site团队可建立自己单独的持续集成环境，但需要保持系统环境的一致。两方的开发人员都应该保证每日离开办公室前的提交通过集成。这样可以避免异地团队开始开发不至于被失败的集成所耽搁。

基本的敏捷时间必不可缺，例如测试，尤其是功能测试。On-site的QA应当在需求确定的时候制定好验收条件。一个描写良好的验收条件会对开发人员有所帮助。尤其是在On-site一端不能及时解答问题的时候，会起到很大的作用。

每个迭代结束时，应尽量安排一个两地同步的演示会议。让所有人都在电话会议上看到这个迭代的成果。迭代后的总结与回顾也应当两地一起进行，如果人数和条件不允许，可以分别进行，并互相通报回顾结果和改进方法。

离岸团队的参与度

多团队中，处于on-site的成员由于可以接触到客户，他们的话语权可能会被放大，使得on-site一边的人倾向于命令式的消息传递，直接指派需求和开发进度，而忽视了对需求背景情况和上下文进行介绍。这种情况可能造成off-site一端团队产生抵触心里，从而导致项目的失败。

解决方法是提高off-site团队的参与度。如制度性的进行人员轮换，让两端的团队成员有所接触，并互相熟识。定期组织两个团队的共同活动。如果都处于一个时区，可以考虑进行每周的Learning Lunch，大家在互相能看到视频的情况下一起吃饭和听讲座。讲座内容可以是任何话题，例如一些项目相关的技术决策等等。

不要忽视offsite团队的任何意见和建议，他们在很多时候能从另一个侧面对项目提出见解。鼓励offsite团队决策和发起讨论，这样可以提高他们的参与度。

实施异地开发的最初目的是为了降低人力成本和运营成本，一些跨时区的异地开发还可以提高时间利用效率，实现全球24小时开发。然而，异地开发带来了高昂的交流和管理成本，如果处理不当将直接导致项目或产品的失败。

近年来随着国内软件公司业务的发展，异地开发项目将会越来越多。全球化的进程也会使得外国公司开展更多类似的开发。异地开发项目将会逐渐发展和普遍。可以想像，多年以后，如果一个公司没有异地开发的团队，将会是多么的令人诧异。

Tags: Agile 敏捷, distributed

Posted in Agile 敏捷, ThoughtBlogs, 思考 | 2 Comments »

敏捷团队建设

敏捷团队建设 本文发表于4月《软件世界》

最近很多人都问我，有没有适合的人可以推荐给他们公司，他们正在招人，面试了很多个，但有经验的开发人员太难找了。有一个朋友在问我要人的同时，他手下的一个开发人员反而问我有没有好的机会，他想跳槽。

不久前一份报告称，中国本地软件企业面临的最大问题之一，就是高级技术人才的缺乏。造成这种问题的原因，主要是由于本地软件企业的人才培养机制和管理机制的欠缺。人才大量涌入外资企业和频繁的流动，导致了各类有经验人才的欠缺。

每个人都会梦想自己的理想工作。做技术的开发人员要求的更是简单：一个能够不断学到新知识和新技能的职位，一个融洽的团队，一个舒适宽松的开发环境，一份成长的空间。而这些简单的需要，恰恰是许多公司所忽视的地方。这些东西，很多时候就是一个人决定离职的因素。

有的公司认为开发团队是成本中心，所以给他们买最便宜的桌椅——而恰恰是开发人员们一天都依赖于这样的桌椅为公司创造价值；有的公司觉得自己的一套软件不停的实施就能不停盈利——而开发人员最厌烦的就是做重复性工作；有的公司要求开发人员必须上班打卡——好的，那开发人员绝对不会晚下班一分钟。有的公司从来不举行内部的技术交流和培训活动——而开发人员希望的技术提高绝不仅仅是只靠读书能够完成的。

公司要依靠软件来盈利。而要开发一个成功的软件项目，人的作用是第一位的。而个人的力量相对于整个团队来说，又是微不足道的。稍微有点规模项目的成功都是集体努力的结果，而不是靠一两个英雄程序员能够完成的。为了能够保持一个稳定和高效的团队，建设一个吸引开发人员的环境和氛围是所有公司的管理人员们应该考虑的一件事。一个核心的产品开发人员离职，很可能使得当前的项目或订单陷入瘫痪，这目前已经成为了影响许多中小公司存亡的大事。

我所在的公司不仅仅以敏捷过程著称，同时，它以其特有的文化和团队氛围吸引了一大批高水平的开发人员。他们不仅仅是认同敏捷而聚在一起，更多的是，他们向往着这种平等、自由、轻松、快乐的空气。

人与团队

在公司一个典型的敏捷团队中，大致有四种不同角色：项目经理、业务分析师、开发工程师、测试工程师。同时，根据项目不同可能还需要：美术设计师、数据库工程师、系统工程师、交互设计师等不同人员。虽然在项目中不同的人需要确定一个角色，并担负相应的责任，但在公司内部，人与人之间是完全平等没有级别区分的。这种平等的文化，就使得人与人之间的交流不会因为等级差距而丧失。同时公司鼓励每个人向其感兴趣的其他领域发展，成为综合性人才。例如某个人现在是开发人员，但他也可以通过帮助项目经理做一些辅助工作，来学习项目管理方法，从而最终成为独当一面的项目经理。

项目成功的一个重要因素就是交流。保障团队内外顺利交流是项目经理的责任之一。公司鼓励员工之间交流看法和讨论问题。在公司内部，如果有闲暇时间，随时可安排一场讲座。这些讲座都是由员工自发组织和自愿开展，话题多种多样，不仅仅限于技术。经济、法律、业务知识等等，都是大家平时感兴趣的领域。在项目中，定期的Learning Lunch也是公司项目的一大特色。和客户一起围坐在餐桌前，边享受公司提供的午餐边讨论项目中的技术，团队的学习交流气氛自然会无限高涨。

除了自发的、自由的交流，还有一些约定的交流时间和形式，例如，每天的站立会议。你要说出昨天做了些什么，今天会做些什么，遇到了什么困难是否需要别人的帮助。站立会议鼓励每个人说出事情的真相。有了困难就大胆的向你最值得信任的同伴来寻求帮助，没有人会嘲笑你，也没有人会冷漠的不去理睬你的困境。一个自组织的团队，应当是一个温馨而又和谐的集体。每个人都会努力的帮助其他的人，帮他解决他的问题并从中积累更多的经验。

图略：站立会议

无论是在项目中还是在个人的发展过程中，回顾与总结都是一个必不可缺的步骤。公司内部任何事情告一段落的时候都会有一个总结活动。迭代总结，项目总结，发布总结，陪训总结等。在这段时间内什么做的好，什么做的不好，如何进行改进。任何的过程和成绩都不能是静止不变的。只有不断的反省和总结，才能够在未来的发展中进一步提高。项目团队一起召开总结会议活动，在这个活动中，任何人不能够对其他人进行指责和攻击，一切都应该以互相信任为基础，我们的目的是提高下次的工作效率和增强同伴的信心，而不是批斗和推卸责任。公司对员工的绩效考核，也是类似的由一起工作过的同伴来进行评价，360度全方位考核。这种定期的总结和回顾，提供给了员工与团队自我成长的机会。

除了内部的交流，公司还鼓励员工进行技术创新和参与其他社会活动，例如参与开源软件开发、撰写书籍、向杂志投稿、参加和举办技术社群活动等。这些对技术社区的贡献，不仅仅能够提高员工个人的能力，同时还展现了公司员工的整体能力和提升了公司的知名度。对公司和个人来说是双赢。

环境与工具

如果你有机会到我们的办公室，你就会发现，每一张墙都被占得满满的。墙上可能会贴满了各种颜色的小卡片，这些都是正在进行的项目的需求。每张卡片都是一条用户故事，开发人员根据用户故事实现系统功能。这种被贴在墙上的一目了然的管理方法叫做可视化管理。在公司内部，开发、招聘、销售等各种流程的状态都被一一列在墙上。一来可以作为工作的进展图公示于众，二来可以使每个感兴趣的人都可以随时提出他的想法或主意，集思广益，将工作做到最好。

图略：墙面

公司采用大长桌作为开发用桌。座位之间没有隔板。一方面适合与敏捷开发中的结对编程实践，另一方面可以减少隔板带来的交流障碍。如果你到一个采用隔板的公司去走一圈，再来比较公司的工作环境，就会明显的感受到交流频度和广度的明显不同。公司提供给开发人员舒适的座椅，带有扶手并可以调节高度和后仰角度，以适合每个人不同的需要。如果中午工作累了，还可以躺在椅子上小憩一会养足精神以便下午更好的投入到工作中。

图略 开发桌椅

在项目中，必不可缺的交流工具是白板和纸。再没有比这更廉价和更好用的工具了。两个开发人员遇到了分歧，两人走到白板前写写画画，很快，一副清晰的系统脉络就出现在两人面前。分歧达成了一致，开发继续进行，而图像留在白板上，任何过路的程序员都可以驻足观看，如果感兴趣还可以问一问作者，更深入的探讨。在开发的过程中，随时遇到问题或需要记录的，都可以立即写在手头的白纸上，一些简单的算法草稿，也都是用白纸完成。这些白纸多是打印用过一面的纸张，环保而又经济。

我公司和其他大多数外企公司一样，为员工提供免费的饮料和零食。每天早上，公司的面包机都会工作个不停，烤面包的香气会和着咖啡的味道飘扬在空气中。午饭后，从冰箱中拿出一罐健怡可乐，冰凉爽口，喝下后休息一下就可以精神十足的开展下午的工作。下午四五点钟，正是开始感到饿的时候，到零食区找一块巧克力吃补充一下体力，顺便休息几分钟，活动一下筋骨。

图略 饮料零食区

公司还在办公室内放了一台电视机和一台PS2，午饭后和下班后，你可以和同事相约PK一场实况足球，既休息了神经，又和同事加深了感情。公司还经常组织各种体育活动。每周租一次羽毛球场，让长期在电脑前工作的员工运动运动，有助于身体健康。

以上这些是我公司在团队文化建设的一些做法，提出这些供大家参考，希望更多的公司管理人员，能够从中或多或少的汲取一些经验，将之用于提高公司开发人员的物理和人文环境。

改造公司的开发环境，可以先从很简单的做起，例如，在办公室的一角开辟一处饮食区，提供免费的饮料和食品；在走廊上挂一个白板，随时有人记录一些东西；为员工提供更舒适的座椅。这些东西花不了多少成本，但其收效是明显的。不论是技术部门还是其他部门，都会为公司这一点点人性化的举动感到高兴。有了高昂的士气，做事情自然也会更加积极高效。不需要公司一下子全部改变，但往往一点点的细节变化就能够获得全体人员的支持。虽然有些投资，但员工给公司的回报会更多。

无论是敏捷开发理论还是精益管理理论中，都提到团队的作用是最重要的。如果能够发挥人的能动作用，并良好的保持下去。我想，没有什么目标是我们完不成的。如果所有的公司都能够提供良好的环境给开发人员，那不仅仅是开发人员的的幸事，更是我们整个中国IT界的一大幸事了。

Tags: Agile 敏捷, organization, team

Posted in Agile 敏捷, ThoughtBlogs, 项目管理 | No Comments »

敏捷界面重构 - Agile UI Refactoring

敏捷界面重构 — initial idea

很多人都觉得界面的事情是细枝末节，等功能做好了，找个时间一起清理一下就好，不会占用太多工夫。很多人也都是这样做的。

这里说的界面开发是指系统的交互设计和界面可用性及易用性设计，也包括CSS的界面布局、颜色、字体等基本的视觉元素。这些问题的重要性不用多谈。

我在项目中期加入过几个项目，这时候最令人头疼也最令人兴奋的莫过于在开发中期对于界面和UI进行变更了。一个项目在初期如果没有做良好的界面设计，想要在中间来进行大的变更简直是噩梦一般。在一个敏捷团队中，做这样的事情尤其困难。

敏捷开发中的一个实践，是需要客户的协作和参与，及时由客户认可做完的需求以及由客户决定下一步的开发。这种客户享有决定权能够使开发变得更顺畅，客户关系变得更融洽，是一个很好的实践。

但是，这种实践给界面的改进带来很大的麻烦：如果在项目中期打算进行界面的变更，自然要写出很多跟界面相关的需求，而客户按照需求的价值决定优先 级，他们有时候不理解这样的界面改进如何带来价值，为什么改善一些文字描述和交互方法还要占用开发时间，他们更希望在有限的时间内增加更多的功能和修复更 多的BUG。这时候，这些界面调整的优先级就被排的很低，在几个开发周期内都没有得到采纳。

我们先后尝试了几种方法来改进这个过程，例如给客户培训交互设计和可用性知识；将开发人员分为两组，其中一组专职负责界面改进；或者将界面改进需求单独分成一组，要求客户每个迭代从其中选择一部分等等。但这些办法都不是很理想，没有达到预期效果。

事后总结原因，觉得最大的原因还是在于：客户不是用户。他们虽然负责对项目功能验收，但他们并不最终使用系统。系统使用上的问题不是他们最关心的。他们需要得到投资回报，因此选择了回报更快的功能开发。从这方面看，客户的选择是无可厚非的。

理想的解决方案应当是在一开始就对界面及UI进行控制和把握，并进行持续的度量和改进，或者称为：界面重构。将界面重构和代码重构等同到同样地位，在开发过程中持续随时的进行改进。

我们都知道，代码重构是在不改变代码行为的基础上，改变其内部的结构。通过一系列小的步骤进行重新构造，系统不会因为这些小步骤的改变而停止运转， 仍然会保持顺利正常的运行。重构的结果是一套良好可读的代码，它不仅能够对我们扩展功能有帮助，也是我们适应变化的基本手段之一。

我们将其类比到界面的开发过程中：我们需要在不改变界面功能的情况下，通过一系列细小的步骤，来改变界面的交互行为和可用性。最终结果，不仅仅是一套良好的界面，也是保证我们扩展新的功能和适应变化的基础。

重构的一个要点是测试。测试可以保证重构的正确。而界面开发的过程中，测试工具的缺乏导致我们不得不采用其他的方式来保证功能的正确。一种可行的办 法是维护一个界面原型，纸质或电子形式均可。在不停地开发过程中，不断的维护这个原型，使之先于实际实现被用户感知和体验，提前获得用户的反馈和客户的认 可，并将原型用于指导团队的开发。这种不断的用户体验和用户测试过程，可以在一定程度上保证界面重构的正确性。BA阐述需求或QA进行验收测试的时候，也 不妨考虑使用界面原型作为一个验收条件来展现给开发者。

重构的另一个要点是要经常不断的进行，每当写新代码之前，先进行一点重构，使旧的代码更好阅读。界面重构也应该是这样。对每一个开发完成的需求，提 高界面验收的标准。不仅仅是完成功能就可以，还需要达到一定程度的可用性和可维护性要求。例如必须遵循提前制定的UI Guideline等等。避免因为界面开发的涣散导致的破窗户，这种疏于整理的小细节可能最终成为最头疼的问题。

比如，我们在开发的过程中，以前只以60分作为界面的验收标准，等积累一段时间后再批量修改界面一次，但可能这次修改只能达到80分。现在我们需要 改为以80作为验收标准后，在开发的过程中多花点时间来重构一点点，一直保持80的水平。这样如果我们需要进行更大的改进，可能很容易就能改到90或 100分，从而达到我们最终的目标。

由于开发团队的人员多数不太擅长界面的知识，并且界面的测试和度量工具缺乏所致，界面的持续改进在项目中较难做的很好。这些实践又要求BA或QA能 够有相应的交互设计能力和可用性工程的经验，也限制了其在项目中的实践。但这些确是在一个项目中长期被忽视地方，应当进行一些加强和发展。

总而言之，敏捷过程和界面设计并不是矛盾的，将敏捷的思想应用于界面开发和交互设计的过程中，我们可以获得更多更广泛的想法。

补：4月24日，和Erik谈了谈这个想法，他也认同这类做法，但觉得由于目前没有一个显然的Vision，或者说，不像Code Refactoring那样有良好的OO设计准则和可读性在前方可以到达，这样的UI重构的准则不是很明显。原因可能还是由于Developer大多缺乏这方面的Sense。路还很长。

Tags: Agile 敏捷, UI

Posted in Agile 敏捷, ThoughtBlogs, Web设计 | 1 Comment »

客户协作 over 合同谈判

客户协作 Customer collaboration OVER 合同谈判 contract negotiation

最近有人和我谈起他们的项目管理。他是一个项目经理，负责项目的进度跟踪和与客户的沟通。他能够很好的保持客户关系。他的团队中有一个年轻的程序员，工作充满热情，喜欢思考，喜欢用新技术，也很勇于指出问题。

有一天，这个年轻的程序员在客户处外勤，跟客户交流的时候，讨论到了系统某一块儿的功能。年轻的程序员基于他的工作热情，向客户提出，如果这么这么做，那可能会给你带来更好的功能。客户听了挺高兴，觉得可行，这小伙说的不错。于是就反映到了项目经理处，说这小伙干的不赖，表扬表扬。这项目经理听到客户的表扬，也附和的说，他确实很上进，回头我再给他当众表扬一下。

项目经理回到了公司，就把这程序员单独叫来聊了一下，他说，你给客户提建议，这样多思考挺好的，不过，咱们给客户开发，要一单一单的做。你说的那个功能我早就想到了，但我没提，主要是考虑这个功能实现起来很容易，我们可以放在下一期，我们引导客户一下，让他们提出，我们再把它说的复杂艰巨点，这样咱们很容易就能完成任务，下一期时间更充裕，而且还能收更多的钱。所以以后有想法咱们内部讨论，先别跟客户说。程序员点头称是。

这样的事情在很多公司都很常见。他们把客户视作敌方阵营，利用自己对IT知识优势了解，努力在一些地方上欺瞒和糊弄客户。

与客户成为敌对的关系，就难免要进行谈判。客户希望用低廉的价格买到他希望的功能，或者说，在一定价格内实现更多的功能。而公司希望提高价格，降低成本。两方表面上达成共识，实际上都在暗地博弈，要在边边角角上沾点小便宜。而这种博弈结果，就是双方都不能达到最好的情况。就像著名的囚徒困境，结局就是纳什均衡(Nash equilibrium)，或非合作均衡。

软件开发的最终目的是要给用户交付价值，要达到客户的商业目标，从而完成公司目标。而为了实现客户和公司的双赢，咨询公司采用了加深客户协作的方式来达成目标。咨询师会和客户一起工作，了解和认识客户，提出针对性的建议，帮助客户发现和识别业务价值，改进目前的系统。咨询师会站在和客户同一方的阵营，和客户一起思考、学习和成长。虽然说起来很粗泛，但我所认识的每个咨询师确实都在认认真真的为客户考虑。

另一个会产生非合作均衡现象的是按时收费的单价合同和固定价格固定范围合同的问题。一般PM书籍上都会讲FFP合同对买方的风险比较低，而单价合同对于买方风险可高可低，取决于内容和项目性质。

如果签订固定价格合同，通常的，由于价格固定，客户会倾向于在这个价格内挤入更多的需求，有些人甚至不顾质量而要求更多的特性，反正完成不了都是开发方的责任。而相对的，开发公司会希望在这里面减少成本，或者是人，或者是需求范围，甚至是不惜牺牲质量。最终两方博弈的结果就是项目出了问题。

这种情况下，更好的办法是单价合同，或者具体说，就是确定阶段时间内的开发力量，但不确定开发范围的收费方式。按照客户需求的优先级来开发，双方合作，尽最大的努力，频繁交付。这种做法的好处是，客户可以控制项目的长短。可以不停的做下去，也可以立即随时终止。由于双方的协作，开发公司也会按照自己的能力，尽最大可能来保证质量和进度。另一种改进过的单价合同，是基于开发方对项目的理解和估算，报出一个固定价格。在合作共赢的前提下，双方信任并接受这个契约。这种情况好像更加适合国内的甲方。

前些天，一个原来的同事电话我，她以前是负责销售的，现在自己开了家公司。她雇佣了一个公司给她开发软件，开发了两个多月了还没见到是什么样子。眼看就要到交付期限了，她想去看看，就问我应该怎么样去中期查验这软件。我告诉她，要怎么怎么样才能看出这系统到底能不能做完，怎么看出到底做的质量如何等等。

瞧瞧，怎么样，客户也不是很好糊弄的嘛。你糊弄客户，焉知客户不会另请人来对付你？所以，在商业的博弈中，合作才能双赢。这就是为什么客户协作 over 合同谈判的原因了。

Tags: Agile 敏捷

Posted in Agile 敏捷, Consultant 咨询, ThoughtBlogs, 项目管理 | 1 Comment »

Software by Numbers

Software by Numbers

China-Pub Amazon

我大概在05年初买的这本书，第一次读这本书的时候，由于对许多概念不清楚，看了几章就完全不懂了。最近参加了一次会计培训课程，学到了一些PV(Present Value), DCF(Discounted Cash Flow)的知识，忽然想起来这本书上好像提到过，于是翻了出来，仔细阅读了一遍，果然，大有收获。

本书主要讲的是，从财务的角度来分析软件项目和软件过程的ROI(Return Of Investment)，从而判断一个项目是否值得投资开发，如何选择特性的优先级，以及怎样发布才最大化ROI。

书中的主要内容包括：软件项目发布周期不同而造成ROI不同。确定需求特性的成本及其可带来的回报。给出了需求按照价值优先级高低排序的理论及一些方法。用IFM(Incremental Funding Methodology)解释RUP, XP等方法的可行性。

对于一个项目，假设初期投入是50，回报将会是100，项目开发期为1年，年利率是5%（可计算出半年利率2.47%，季利率1.23%），那么我们可以做如下的计算：


A 如果项目分1期开发，在1年期末交付，则其NPV为
100/(1+5%) - 50= 95.238 – 50 = 45.238
B 如果项目分2期开发，每半年交付一次，则其NPV为
50/(1+2.47%) + 50/(1+5%) – 50 = 48.795 + 47.619 – 50 = 46.414
C 如果项目分4期，每3个月交付一次，则其NPV为
25/(1+1.23%) + 25/(1+2.47%) + 25/(1+3.7%) + 25/(1+5%) - 50
= 24.696 + 24.397 + 24.108 + 23.810 = 97.011 – 50 = 47.011

上述对理想情况的简单的计算，得出一个结论：交付的越频繁，项目可获得的实际价值就越高。并且如果项目规模更大，利率更高，这结果越明显。

此书的中文翻译水准不敢恭维。好在我一贯对书上理论持”知其然”的态度，因为毕竟这些东西都要实践了才能成为自己的，因此看到翻译差了的书也勉强能接受。

书中从数字和财务分析的角度来探讨软件开发的方式给了我很大启示。打算在这方面再深入的阅读一些文字。已经购买了Barry Boehm的软件经济学准备要看，居然老早有中文版，而且还没缺货，不过好贵。

说到缺货问题，好像China-pub很多敏捷开发方面的书都被买的缺货了。不知道是印制的量太少，还是读者太多。这一般5000册的印量，按说至少得有近万的IT人员手中有书了，那怎么敏捷开发在国内仍然的如此不流行呢？莫非是因为翻译的不好懂？

Tags: Agile 敏捷

Posted in Agile 敏捷, ThoughtBlogs | No Comments »