冰云@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 »

近期面试经验小结

在ThoughtWorks日常的面试中，大致会分为多个回合，每个回合由不同的人采用不同的方式来面试，例如电话，笔试，面对面交流等等。一般能够通过这样的流程的人，大多可以接受，一般的公司也都采用这样流程招聘开发人员。电话面试的主要意图是要考察应聘者的个人经历。因此，应聘者应多谈自己：自己在团队中做了什么，自己挽回了什么错误，自己的责任是什么，自己带来了什么影响，自己存在什么问题。面试者看中的是这个人的表达能力，他所发挥的作用，他个人经历，他的信心。问问题也多为开放问题，并经常要追着问他某个项目中的某件事情，并要求他举例来说。

笔试一般为写代码或其他题目，对于代码，我一般要先看这个人的简历，根据他的工作年限和经历，判断他的代码应该是什么水平。对于未毕业的学生，不妨有所宽松，对于工作很久的人，如果他好学上进，接受新鲜的事物和新鲜思路多的话，代码应该是什么样子。这样的标准大概在90%的情况下是准确的。

Joe Homs 写了一篇 如何被我面试 很清楚的写出了各种过程的注意事项。

对于技术人员的面试，相信每个做过开发人员招聘的人都会有所体会。技术问题很好度量，说一是一，很容易。然而，对于一些技术要求低一点的职位，如何面试就成了很微妙的问题。例如BA，PM等。

很多BA和PM很久没有写代码了，考察他们代码无疑是浪费时间。对于BA和PM，你可以不需要技术有多好，但你应该对技术有sense。至少别人正在用的新技术你知道是怎么回事。很多时候，BA和PM会在项目前期出现在客户处，决定一个项目的初始技术选择。

电话面试一个非技术人员也很麻烦，他们天天看别的PM和BA做事，你怎么知道他说的是他看到的还是他自己实践过的？所以很多时候，要追着一个问题问到底。这时候逻辑分析很重要，有的人前后说话会有矛盾，这就说明了他的说法有虚假之处，要小心。

我公司在面试的时候，有套逻辑题比较特别。对于Developer，当然要要求很好的逻辑才行。对BA和PM逻辑要求也不能低。例如BA，很多时候会面对逻辑比较差的客户，不能被侃晕是不是。

一个很tricky的事情是，许多人，可能觉得BA是要求比较低的工作，在申请公司职位的时候，觉得达不到Developer的要求才申请BA。我可以明确的告诉这样的人，BA不比Developer要求低，甚至在某些方面比对Developer要求更高，例如专注细节，例如交流，表达，组织，管理等等。一个差的BA，比一个差的Developer更能搞砸项目。

对于BA的面试，我经常采用角色扮演的方式来进行。我扮演客户，另一个同事扮演开发人员，我们一起面试一个BA candidate。我描述一些简单的需求，要求这个BA来分析和整理，并最终转述给开发人员。从这个过程中，很容易就能看出这个人是不是真正的做过需求管理的工作，是不是能够顺畅的表达，是不是能用一些巧妙地方法来获取真正的需求。

另一个难以面试的是PM。国内的PM很多时候扮演的更像是“政委”的角色。他负责管人和管理客户关系，主要靠做思想工作来控制团队，搞平衡。很少见有PM真正的做项目进度、成本、范围、质量控制，或者说，在这些方面做的比较欠缺。而这样的PM，面试时候也很头大。敏捷团队中，人和思想基本上不需要太多控制，更多的是需要项目经理真正的监控项目本身的属性，理解项目并领导项目。

对于一些想要转行的人，例如作了很久Developer想要做BA了，这样公司也支持。面试的时候就主要看潜质了，也就是学习和接受能力。但如果一个人是因为做某方面实在做不下去了才要转行，那还是好好做回原来那份有前途的工作好。公司鼓励每个人多方面发展。一个Developer也应该具备BA或PM技能，BA也应可以兼任PM，QA也可以转行当BA，这种每个人都了解其他知识，每个都负责的团队，才是最好的团队。

Posted in Consultant 咨询, ThoughtBlogs | 1 Comment »

客户协作 over 合同谈判

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

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

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

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

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

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

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

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

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

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

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

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

Tags: Agile 敏捷

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

令人烦恼的项目估算

Annoying Project Estimation

对一个项目的评估，往往被要求在项目需求还不明确的时候开始。不知道你是否有这样的体会，客户给你简单介绍了一点需求，或者发给你一份写的很粗略的文档，就要求你给个价格看这东西大概是要花多少钱多少时间才能建成。以前我做网站的时候，遇到过好多好多的这类问题。

在软件开发过程中，总要面临一个”估算(Estimation)”的问题。这个项目需要多长时间？这个模块你大概多久完成？一共要花多少钱才能搞出来？软件开发的成本主常常用人月来计算，当然，也有人/小时，人/天。从数学上说，计算一个时间的先决条件，是必须要知道速率和距离。那软件开发度速率是多少？开发要走完的距离又怎么估计？

假定”人天”可以作为我们需要找到的速率(Velocity)的单位，就是某个人每天8小时能干的活的工作量，或说他的开发能力。对于一大堆待要开发的需求，它的总工作量和整个团队的单位开发能力的计算需要考虑更多的因素。

先来考虑需求的总量。我们来看这一个例子，列举你认识的满足下面条件的人：人，男人，20岁的男人，20岁的 头发有些染黄的男人，20岁的头发有些染黄抽烟的男人。从这一组词中，我们可以看到，从左到右描述的越来越具体，你能列举出的也越来越少。而反过来顺序，词的外延更大，你的能想到的却越来越多的。

同样的，对于需求的描述，如果描述的越细致，你就越能够准确的估算它的工作量。 登录系统，这样的需求很难说要多久。而一个使用用户名密码登录，支持找回密码功能的登录系统就稍微好一些。如果能够画出界面原型图那就更加清晰了。对于这样的需求，我们可以用”理想的人天”来评估。我们说某一个需求的成本，是2 Ideal Days。 就是一个人在理想的2天内能够完成这个工作。

说到开发人员的”理想的人天”，就不能离开团队孤立的看。一个团队包括项目经理和需求分析师、测试员等角色。他们的工作不直接反应到代码量的多少。如果只考虑一个项目开发人员的代码开发量成本，毫无疑问要亏损的。另外，团队成员水准参差不齐，不同的任务不同程序员来完成所花费的时间也不同。因此，单独相加每个成员的”人天”毫无意义。必须要整体考虑一个团队的总”人天”。

那么如何衡量一个团队的总”人天”？如果一个团队已经经过长期的磨合，那么可以从以往的数据来获得他们的开发量。 如果是新建立的团队，没有经过磨合，那就需要开始实际进行一段时间的开发，在开发后3-4个星期再回头来计算这几个星期的团队速率。一般的，一个团队经过一段时间的磨合，在开发速率上会有缓慢的提升。例如一个需求的估算是5理想人天，而团队实际开发了10天。那么团队的速率就是5理想人天，团队的负载系数，即正常被其他事情干扰而降低的比率是2。

有了这个团队的速率，项目经理就可以放心大胆的说，我们团队有10人，开发能力是”n理想人天每周”，负载系数是2，由于有20n的需求总量，我们大概在40周左右完成。因此，我们的报价是xx,xxx,xxx元。

如果你有幸长期跟踪过一个团队的开发速率，就会发现很多有趣的现象。一开始，团队速率很低，但慢慢的成长。到达一定时期后，就会稳定在一个固定值附近。有时候有新的成员加入进团队，团队的开发速率会出人意外的降低一段时间再慢慢回增。

成本、时间、范围、质量，这是项目管理常见的四要素，四者很难同时满足。如果关心时间，又不想出钱，还要完成那么多功能，那牺牲的就真正是质量了。常说的一分钱一份货，在软件开发中反映的淋漓尽致。所以，为了能够保证按时按质完成任务，一个合理的开发价格是合格的项目经理必须能够估算出来的。而这需要长期经验和实践的积累，急不来的。

但有些时候，也有些不好处理的问题。有人问：我是老板，如果我的开发团队合起伙来编造一个估算，把我的需求估算的很多，而把他们的速率估算的很低，工起来工作量不饱和，老消极怠工怎么办？呃。。我只能说，这只好借助于开发方法以外的事情了，例如奖金激励、绩效考核、引入外部咨询团队(例如ThoughtWorks)等等，人的问题不是能够简单靠过程就解决了的，如果道歉有用的话，要警察干嘛？

Tags: Agile 敏捷

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

软件开发的速度与质量

软件开发的方法，在最开始是code and fix。这种黑客式的做法持续了很多年。直到现在，不少公司还是用code and fix的衍生版本：code …….. 3个月然后fix……3年。

软件不是一次性消费品，不能用过就丢掉。软件的生命周期应当随着业务和公司的发展而不断跟进，但多数公司，都把”维护“作为一个单独的部分并及其重视：有的公司为了保障系统的运营，但又不失提供新功能的能力，专门分出了运营组和创新组，分别负责两种不同的职责。而对于这样的公司和系统，平滑的更新和数据迁移又成了令人头疼的问题。

我们再次回到code and fix的过程中。考虑其中是否隐藏了其他步骤，会发现code和fix之间实际上还有测试和验证的过程，而这之前，是必经的需求过程：require - code - test - fix。是不是看起来很眼熟了，几乎完全符合Deming的PDCA环。

但我们为什么会fix？是因为verify时候发现了不符合require的部分，这体现到实际情况中，常常是质量不好。

质量的概念很宽泛，一般来说，我们将之分为内部质量和外部质量。内部质量是指代码的内在质量，多面向于开发人员。包括：可维护性，部署的便利性，性能，内部结构，可扩展性等等，外部质量是面向于最终用户，包括：可用性，易用性，响应速度，以及是否提供客户服务等等。质量常常表现为客户满意度：开发人员对系统的满意度和最终用户对系统的满意度。

如何提高质量？简而言之，不断的test和fix就是解决质量问题的法宝。Deming告诉我们，要不断的PDCAPDCA直到时间的尽头。。。为什么不断重复能够提高质量和满意度？因为可以快速获取用户反馈，快速适应变化，快速开发新要求。要多快的反馈才够好？半年不行就一月，一月不行就半月，半月还不够？那就一周。还不够的话就一天。当然，不同时间段的PDCA的粒度都不同。总不可能半年的活一周就完成吧。对于Plan，那就是半年的产品计划，一个月的发布计划，半个月的迭代计划，一周的短期任务，一天的开发任务。

为了提高速度，是否可以考虑简化过程？require是什么？一般是人口述或写出来的描述。能否require直接写成test的样子，然后code，满足了test/require就通过，这样应能简化了fix的步骤。如何将需求写成test？需求一般这样：系统应该允许用户登录。the system should allow user to login连在一起，和test合并。testTheSystemShouldAllowUserToLogin()方法出来了。如果能够将test自动的来回反复运行，是不是速度更加快一些？好，那我就持续的自动运行测试。

内部质量好点了，外部质量能不能也这么做呢？当然行。叫客户筒子经常来test呗。他觉得哪里好用就发扬一下，觉得哪里不好，就改进一下。当然人家很忙不能老来，那就一周一次，至少两周一次吧。

还维护不维护了？维护。那还开发新功能么？开发。还分不分部门了？不用了吧。。这样由一组人，既运营又维护又开发，才是一个产品/网站运营公司最好的做法。让公司的核心产品核心应用持续的保持竞争力，适应变化，并创新和引领市场变化，才能够立足于不败之地。

在每天的日常开发中，不停的test-code-test-code，连续的做下去，逐渐的你就会发现，这系统好像越来越受人欢迎了。用户也越来越愿意提出他们的新要求，因为你反应的快么。速度做的好了，质量也越来越高。质量高了，做的更顺手也更快了。

牙好，嘿，胃口就好。身体呗儿棒，吃嘛儿嘛儿香。

而这东东，就是人称的敏捷/精益开发方法。

Tags: Agile 敏捷

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