敏捷开发一千零一问系列之1-38

敏捷开发一千零一问系列之一：序言及解决问题的心法（无我）做敏捷开发时间长了，就感觉很多事情都理所当然，越发觉得“问题很可贵”，最近做培训的时候收集了一些问题，很多现场来不及解答，逐一发表在这里。如何解决一个问题知识多了自然可以解决问题，经历多了自然也可以积累经验，但是在一个只出现10年的领域，还有一堆只工作了10多年的年轻人中间，必然有一天会遇到从来没有人解决过的问题，这时候怎么办呢？掌握解决问题的心法是核心。对这个系列而言，就是要掌握用敏捷开发的方法解决问题的心法。掌握了心法就能解决所有问题，这比知道一千零一个问题的答案更加重要，因此会先用三篇来综述一下解决问题的心法，可以总结为无我、无住、共振三个词汇。为什么不写成更通俗易懂的现代汉语？因为找不到贴切的词汇，更没有简短、容易记忆的语句，罗哩罗嗦写了一大段，保证大家关闭IE就忘光了。估计在看完十个二十个问题和答案后，再回来看这篇序言，大家会和我一样认同这三个词汇是最佳答案。无我包括两个部分，无我无人和无现在无未来的我。无我无人这里的”人“是他人的意思。原来的敏捷宣言中包括了无我无人的成分，“个体与交互胜过过程与工具”及“客户协作胜过合同谈判”说的就是这个部分。为什么需要过程、工具、合同、谈判？因为有部门分割，有利益差异。在传统开发过程中无形中产生了很多对立团体，比如客户负责自己的价值而我们负责编写功能（注意功能不等于价值，否则用户故事语法就不需要前面的”作为一个……“和后面的”以便……“了），程序负责编码而测试负责质量，领导负责计划而员工负责执行，产品经理负责销售市场及竞争力而项目组负责……甚至乃至在一个团队中，都有我的任务、你的任务之分，一旦这些成为事实，那就太需要过程、工具、合同、谈判了。所以要用敏捷开发的方法解决问题，首先应该先融合不同团体的利益，比如拥抱客户价值，拥抱变化，团队工作，代码所有制，自动化测试与持续集成（开发人员参与编码的测试）、代码审查……无现在的我和未来的我就是千万不要以眼前利益为驱动，而要把现在和未来放在一起考虑。这个没有出现在敏捷宣言里，因而常常被伪敏捷的人拿来作为不写文档的接口，又被反敏捷的人拿来作为攻击敏捷的漏洞。”到底要不要写文档？“答案当然是”看着办“。但怎么看着办呢？如果一个人在”看“的时候心里想：”其实我自己开发者写代码不需把想法写出来的，现在劳心费神写文档的人是我，未来不知道便宜了哪个后来人呢“，这个时候看着办就是危险的。但如果他在想：”这个部分代码里边表达地很不清楚，而这个产品20年后还会有人用（比如汽车电子），所以应该写成文档；那个地方呢，一看代码就很明确了，不写了。“这个时候看着办就是安全的。差别在哪里？第一个人的想法里边有”我“有”他人“，干扰了看着办的出发点。人有天生的惰性，习惯了”Maxtheundo“，就是把事情拖到最后再做，如果一旦误解了敏捷开发中的“不做不行的时候才做”，就很容易找到借口把很多应该做的事情推掉。还有很多事情有现在和未来的差别，比如短期功能的生产率与长期架构的稳定性，短期“强分工的专家团队”的高效率与今后人员离职的困扰，现在马马虎虎提交代码与日后测试团队加班测试……这里边潜意识里都有一个概念：“现在先凑合过吧，到时候我还在不在还是个问题呢”。这都是因为区分现在的我和未来的我的原因。无我对于运用敏捷开发方法解决问题至关重要。如果解决问题的时候，总是想“我们应该干什么，他们应该干什么”“因为他们少干了什么，所以我们不能干什么”“这件事情没做好，是因为他……”，那么像开发人员要关心客户价值、两个人要结对编程、一个团队要每天立会这些实践，就永远用不好。敏捷开发一千零一问系列之二：序言及解决问题的心法（无住）无住在般若敏捷系列中已经提过，包括不住于法，不住于空。不住于法就是不停留在一种固定的方法上。如果把“敏捷”理解成一个名词，就会出现一个问题：什么是敏捷？又会扩展成Scrum是敏捷，还是XP是敏捷？RUP是不是敏捷？等等问题。如果把“敏捷”理解成一个形容词，也就是“敏捷的开发方法”，大致能找到敏捷新的定义：敏捷是一种轻量级的开发方法。如果把“敏捷”理解成一个副词，也就是“敏捷地开发”，就会找到一个更新的定义：敏捷就是不拘泥与形式不断优化地改进开发方法。用最后一个理解看待开发，敏捷方法的定义就有很大不同。比如CMMI，如果CMMI1.3修订之后更加适合美国国防部寻找适合的供应商开发军工项目（CMMI是美国国防部的供应商评价标准，而不是一个学术机构总结的通用最佳实践），那么CMMI就很敏捷；而一家企业已经实施Scrum很久了，但其质量、进度与日剧减，但大家坚持使用原汁原味的Scrum，那么反而很不敏捷。那为什么现在的敏捷方法看起来更像是“轻量级的开发方法”呢？这是因为重量级的敏捷开发方法早就有了（最早的软件工程始于军工、航空航天、银行业），其他行业比如敏捷宣言发表时乃至今日仍盛行的互联网行业却一直没有方法。当他们“敏捷地”寻找的时候，找到了“敏捷的”方法。但如果以为已经找到了就停了下来，就不敏捷了。不住于空“既然敏捷开发也不是最好的方法，那我们何苦要用敏捷方法呢？”“去年你们推CMMI，今年又推敏捷，明年天知道你们又会推什么方法（所以我打算不配合）”。因为世界上没有绝对最好的编码规范，所以你们别说我的编码烂；因为世界上没有最好的管理方法，所以你们也别说我的方法乱；因为世界上没有绝对的好人，所以且容我再当一次坏人……这是很多人处世的哲学，开发团队也不乏这样的“老油条”“刺头”。如果把“好”当作一个点，的确没有一种方法只好不坏。但如果把好当作一个方向，那么眼前，这里，这个项目，这个团队，的确有一些方法比另外一些方法好。虽然不是普适的最佳方法，但仍然值得追求。不住于空，就是尽管没有最好的方法，但是不能因此放弃寻找更好的方法。以往研发管理的教训这里不得不提一下以往软件研发管理的教训，尤其是推广CMMI时的教训。“为什么牛奶要检测氮含量？”“因为氮含量高，就意味着有更多的蛋白质，因而对人体更加有益。”如果把后两句给忘了，就产生了往牛奶里边添加三聚氰胺的做法。昨天一个学员就提到说他们企业坚持要他们编写一些文档，而他们明明知道这些文档被扔在那里从来没有人看过，不写又不行，问应该怎么办（这个将是1001问系列中的一个问题）。很多软件企业中的文档、评审、计划、会议并没有起到应有的作用，但却被盲目地坚持着。人们对这些方法的关注甚至超过了最终项目的成败和企业的盈利能力（神奇的是，美国国防部通过对这些方法的关注而大大提高了项目的成功率，但要认为我们只需要学习他们就能成功，则住在法上了）。重读敏捷宣言敏捷宣言中关于可运行软件胜过繁杂文档及响应变化胜过遵循计划的描述，说的就是这件事情。不过，为了通俗易懂，敏捷宣言把“敏捷地找到”的方法贴出来了，所以变成了“敏捷的方法”，如果住在上面，就会出问题。这就像“打土豪分田地”是一个通俗易懂的口号，但如果认为这就是共产主义，等土豪没了，田地分了，也就迷茫乃至要走上歧路了。敏捷开发一千零一问系列之三：序言及解决问题的心法（共振）共振共振是以无我、无住精神推广敏捷时的具体做法。很容易被简单理解为循序渐进，但这样理解不全面，这也是为什么会出现“共振”这个奇怪的词汇。之前的无我、无住，也都很难找到完整替代的又没有歧义的词汇或语句。循序渐进很多人都梦想有一家企业，高层领导支持，企业文化适合，队员个人能力超强，团队合作顺畅，就只差自己这个项目经理去推广敏捷。但睁开眼一看，自己的企业不是如此，因此“我们实际企业不适合推广敏捷”。很多时候组织架构、产品特征、人员能力都会影响推广敏捷（这些都会出现在一千零一问中），但这只会影响到“实现最好的方法”，并不会影响到“实现更好的方法”。因为实现不了共产主义就躺在奴隶社会睡大觉的人，其实是最没有敏捷精神的人。循序渐进，是以无住精神推广敏捷的具体做法。在掌握了共振的人眼中，这不是一个家“有些敏捷实践无法开展的公司”，而是一家“有些敏捷实践可以开展的公司”。劝、帮、替别人做事还有一种情况，比如“我们项目组学习了敏捷开发方法，但是产品经理却不写用户故事，怎么办？”乃至更加棘手的“你说产品优先级排序的第一要点是按商业计划排序，但我们公司没有产品总监，更是从来没有商业计划，我们该怎么办？”（这些都会出现在一千零一问中）在每一次沉默的围观事件中，单独拉出任何一个人采访，他都会说“其实我本来想出手相助的，但是看到那么多人选择沉默，我也只好违心地沉默了。”其实，我们不能想想自己高人一等，但却落入凡夫堆里，空有一腔热血不能施展。而是要想：“这些人多半和我有共同的想法，只是要么缺少具体的做法，或缺少一个人振臂一呼。”所以当我们发现产品经理不写用户故事，可以先尝试劝说他做好这件事情，兴许他正犯愁自己应该怎样写所以犹豫不决呢；如果他写不好，应该帮助他一起写好，他写好了用户故事，我们开发也会更加顺畅；如果他执迷不悟拒绝帮助，大不了我们替他做好。千万不要认为自己帮人做事、替人做事吃了亏。我们之前有个测试人员刚刚转到技术支持部门，大家觉得“写方案”是个累活就推给她写；后来销售说Word版本的方案能看不能讲所以请改成PPT的；后来又推说对方案不熟悉所以直接请你去讲吧……一年后公司政策调整销售竞争上岗，半年时间她就在一个全新领域（就是那个方案要覆盖的领域）打开局面，并成交了公司历史上最大的单子之一，并成为新的销售冠军，收入提高了200%。劝、帮、替别人做事是以无我精神推广敏捷的具体做法。在掌握了共振的人眼中，这不是一家“有些人不能配合我工作的公司”，而是一家“我能配合某些人工作的公司”。在共振中破除旧我，建立新我“别人”的范围不止与我们无法控制的外层和上层，也包括自己的队员、师傅的徒弟等等。无我的人心中没有“应该开除的刺头”，而只有“有才干不能发挥因而应该帮助的队员”；没有“学会后会饿死我的徒弟”，而只有“会接手我的工作以便让我管理更大事务的兄弟”；没有“拒绝做份内工作的其他部门”，而只有“可能被我帮助、替代、乃至纳为下属一起管理的其他部门”。破除掉旧我建立起来的“新我”不是一个具体的位置，而是一个更高、更好的方向，确切说就是“无我”。否则自己的职业生涯就会又止于某个位置。比尔盖茨这些当年的程序员之所以能在很短时间内跨越如此多的职位，一个必要条件就是他们从来没有固守“我是一个程序员，因此不应该管……”，而是相信什么都是我要做的事，我可以成为任何人。尽管这不是一个成功的充分条件，没有这个心量却永远不能成功。以上三篇是解决一切已知、未知问题的心法，掌握了它们遇到任何问题就不会迷茫、恐惧，也不会只把希望寄托于某大师正好说过这个问题的答案，而是能自己分析解决问题。此后的问题及分析，均建立在上述三者之上。或许今后还能总结出第四个词汇，但现在暂时只有无我、无住、共振这三者就够了。敏捷开发一千零一问系列之四：优先级排错怎么办？初始问题对于不断更新的需求，导致需求优先级的判断出现了错误，知道项目周期后期才发现，怎么办？答案1.（临时方案）确保所有排序均是由PO完成的常常出现所谓现场客户、由客户出PO、由一个销售当PO的情况，都是应该避免的。PO一方面要熟悉具体的需求和原始目的（广度与细度的要求），另一方面则应该对产品的商业目标、终极目的了然于胸（高度与深度），才能站在企业立场而非简单的客户价值立场。从这一方面看，“有无限时间陪着我们的现场客户”和“一个销售”，其细度有余，高度不足，很容易带入歧途；而由“客户出PO”则会被客户牵着鼻子走，客户的想法一变，项目就会变化，也不符合企业的利益。2.（最终方案）优先级排序应该基于较为稳定的商业计划，要确保有产品总监或项目总监来把控产品或项目方向一般的产品经理和项目经理排列优先级的依据一般有两个：一个是客户价值方面，一个是开发因素方面（比如对架构的影响、需求间的依赖）。但这些都相对浅薄的理解。真正决定什么优先的因素，是产品或项目的商业目标，并因此制定版本计划，在版本中体现优先级。作为产品，每个版本都是为了打败某个竞争对手，取代某个已有产品，获取某类客户的过程。从这个角度看，