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

资源描述

敏捷开发一千零一问系列之一：序言及解决问题的心法（无我）做敏捷开发时间长了，就感觉很多事情都理所当然，越发觉得“问题很可贵”，最近做培训的时候收集了一些问题，很多现场来不及解答，逐一发表在这里。如何解决一个问题知识多了自然可以解决问题，经历多了自然也可以积累经验，但是在一个只出现10年的领域，还有一堆只工作了10多年的年轻人中间，必然有一天会遇到从来没有人解决过的问题，这时候怎么办呢？掌握解决问题的心法是核心。对这个系列而言，就是要掌握用敏捷开发的方法解决问题的心法。掌握了心法就能解决所有问题，这比知道一千零一个问题的答案更加重要，因此会先用三篇来综述一下解决问题的心法，可以总结为无我、无住、共振三个词汇。为什么不写成更通俗易懂的现代汉语？因为找不到贴切的词汇，更没有简短、容易记忆的语句，罗哩罗嗦写了一大段，保证大家关闭IE就忘光了。估计在看完十个二十个问题和答案后，再回来看这篇序言，大家会和我一样认同这三个词汇是最佳答案。无我包括两个部分，无我无人和无现在无未来的我。无我无人这里的”人“是他人的意思。原来的敏捷宣言中包括了无我无人的成分，“个体与交互胜过过程与工具”及“客户协作胜过合同谈判”说的就是这个部分。为什么需要过程、工具、合同、谈判？因为有部门分割，有利益差异。在传统开发过程中无形中产生了很多对立团体，比如客户负责自己的价值而我们负责编写功能（注意功能不等于价值，否则用户故事语法就不需要前面的”作为一个……“和后面的”以便……“了），程序负责编码而测试负责质量，领导负责计划而员工负责执行，产品经理负责销售市场及竞争力而项目组负责……甚至乃至在一个团队中，都有我的任务、你的任务之分，一旦这些成为事实，那就太需要过程、工具、合同、谈判了。所以要用敏捷开发的方法解决问题，首先应该先融合不同团体的利益，比如拥抱客户价值，拥抱变化，团队工作，代码所有制，自动化测试与持续集成（开发人员参与编码的测试）、代码审查…… 无现在的我和未来的我就是千万不要以眼前利益为驱动，而要把现在和未来放在一起考虑。这个没有出现在敏捷宣言里，因而常常被伪敏捷的人拿来作为不写文档的接口，又被反敏捷的人拿来作为攻击敏捷的漏洞。 ”到底要不要写文档？“答案当然是”看着办“。但怎么看着办呢？如果一个人在”看“的时候心里想：”其实我自己开发者写代码不需把想法写出来的，现在劳心费神写文档的人是我，未来不知道便宜了哪个后来人呢“，这个时候看着办就是危险的。但如果他在想：”这个部分代码里边表达地很不清楚，而这个产品20年后还会有人用（比如汽车电子），所以应该写成文档；那个地方呢，一看代码就很明确了，不写了。“这个时候看着办就是安全的。差别在哪里？第一个人的想法里边有”我“有”他人“，干扰了看着办的出发点。人有天生的惰性，习惯了”Max the undo“，就是把事情拖到最后再做，如果一旦误解了敏捷开发中的“不做不行的时候才做”，就很容易找到借口把很多应该做的事情推掉。还有很多事情有现在和未来的差别，比如短期功能的生产率与长期架构的稳定性，短期“强分工的专家团队”的高效率与今后人员离职的困扰，现在马马虎虎提交代码与日后测试团队加班测试……这里边潜意识里都有一个概念：“现在先凑合过吧，到时候我还在不在还是个问题呢”。这都是因为区分现在的我和未来的我的原因。无我对于运用敏捷开发方法解决问题至关重要。如果解决问题的时候，总是想“我们应该干什么，他们应该干什么”“因为他们少干了什么，所以我们不能干什么”“这件事情没做好，是因为他……”，那么像开发人员要关心客户价值、两个人要结对编程、一个团队要每天立会这些实践，就永远用不好。敏捷开发一千零一问系列之二：序言及解决问题的心法（无住）无住在般若敏捷系列中已经提过，包括不住于法，不住于空。不住于法就是不停留在一种固定的方法上。如果把“敏捷”理解成一个名词，就会出现一个问题：什么是敏捷？又会扩展成Scrum是敏捷，还是XP是敏捷？RUP是不是敏捷？等等问题。如果把“敏捷”理解成一个形容词，也就是“敏捷的开发方法”，大致能找到敏捷新的定义：敏捷是一种轻量级的开发方法。如果把“敏捷”理解成一个副词，也就是“敏捷地开发”，就会找到一个更新的定义：敏捷就是不拘泥与形式不断优化地改进开发方法。用最后一个理解看待开发，敏捷方法的定义就有很大不同。比如CMMI，如果CMMI1.3修订之后更加适合美国国防部寻找适合的供应商开发军工项目（CMMI是美国国防部的供应商评价标准，而不是一个学术机构总结的通用最佳实践），那么CMMI就很敏捷；而一家企业已经实施Scrum很久了，但其质量、进度与日剧减，但大家坚持使用原汁原味的Scrum，那么反而很不敏捷。那为什么现在的敏捷方法看起来更像是“轻量级的开发方法”呢？这是因为重量级的敏捷开发方法早就有了（最早的软件工程始于军工、航空航天、银行业），其他行业比如敏捷宣言发表时乃至今日仍盛行的互联网行业却一直没有方法。当他们“敏捷地”寻找的时候，找到了“敏捷的”方法。但如果以为已经找到了就停了下来，就不敏捷了。不住于空 “既然敏捷开发也不是最好的方法，那我们何苦要用敏捷方法呢？”“去年你们推CMMI，今年又推敏捷，明年天知道你们又会推什么方法（所以我打算不配合）”。因为世界上没有绝对最好的编码规范，所以你们别说我的编码烂；因为世界上没有最好的管理方法，所以你们也别说我的方法乱；因为世界上没有绝对的好人，所以且容我再当一次坏人……这是很多人处世的哲学，开发团队也不乏这样的“老油条”“刺头”。如果把“好”当作一个点，的确没有一种方法只好不坏。但如果把好当作一个方向，那么眼前，这里，这个项目，这个团队，的确有一些方法比另外一些方法好。虽然不是普适的最佳方法，但仍然值得追求。不住于空，就是尽管没有最好的方法，但是不能因此放弃寻找更好的方法。以往研发管理的教训这里不得不提一下以往软件研发管理的教训，尤其是推广CMMI时的教训。 “为什么牛奶要检测氮含量？”“因为氮含量高，就意味着有更多的蛋白质，因而对人体更加有益。”如果把后两句给忘了，就产生了往牛奶里边添加三聚氰胺的做法。昨天一个学员就提到说他们企业坚持要他们编写一些文档，而他们明明知道这些文档被扔在那里从来没有人看过，不写又不行，问应该怎么办（这个将是1001问系列中的一个问题）。很多软件企业中的文档、评审、计划、会议并没有起到应有的作用，但却被盲目地坚持着。人们对这些方法的关注甚至超过了最终项目的成败和企业的盈利能力（神奇的是，美国国防部通过对这些方法的关注而大大提高了项目的成功率，但要认为我们只需要学习他们就能成功，则住在法上了）。重读敏捷宣言敏捷宣言中关于可运行软件胜过繁杂文档及响应变化胜过遵循计划的描述，说的就是这件事情。不过，为了通俗易懂，敏捷宣言把“敏捷地找到”的方法贴出来了，所以变成了“敏捷的方法”，如果住在上面，就会出问题。这就像“打土豪分田地”是一个通俗易懂的口号，但如果认为这就是共产主义，等土豪没了，田地分了，也就迷茫乃至要走上歧路了。敏捷开发一千零一问系列之三：序言及解决问题的心法（共振）共振共振是以无我、无住精神推广敏捷时的具体做法。很容易被简单理解为循序渐进，但这样理解不全面，这也是为什么会出现“共振”这个奇怪的词汇。之前的无我、无住，也都很难找到完整替代的又没有歧义的词汇或语句。循序渐进很多人都梦想有一家企业，高层领导支持，企业文化适合，队员个人能力超强，团队合作顺畅，就只差自己这个项目经理去推广敏捷。但睁开眼一看，自己的企业不是如此，因此“我们实际企业不适合推广敏捷”。很多时候组织架构、产品特征、人员能力都会影响推广敏捷（这些都会出现在一千零一问中），但这只会影响到“实现最好的方法”，并不会影响到“实现更好的方法”。因为实现不了共产主义就躺在奴隶社会睡大觉的人，其实是最没有敏捷精神的人。循序渐进，是以无住精神推广敏捷的具体做法。在掌握了共振的人眼中，这不是一个家“有些敏捷实践无法开展的公司”，而是一家“有些敏捷实践可以开展的公司”。劝、帮、替别人做事还有一种情况，比如“我们项目组学习了敏捷开发方法，但是产品经理却不写用户故事，怎么办？”乃至更加棘手的“你说产品优先级排序的第一要点是按商业计划排序，但我们公司没有产品总监，更是从来没有商业计划，我们该怎么办？”（这些都会出现在一千零一问中）在每一次沉默的围观事件中，单独拉出任何一个人采访，他都会说“其实我本来想出手相助的，但是看到那么多人选择沉默，我也只好违心地沉默了。” 其实，我们不能想想自己高人一等，但却落入凡夫堆里，空有一腔热血不能施展。而是要想：“这些人多半和我有共同的想法，只是要么缺少具体的做法，或缺少一个人振臂一呼。” 所以当我们发现产品经理不写用户故事，可以先尝试劝说他做好这件事情，兴许他正犯愁自己应该怎样写所以犹豫不决呢；如果他写不好，应该帮助他一起写好，他写好了用户故事，我们开发也会更加顺畅；如果他执迷不悟拒绝帮助，大不了我们替他做好。千万不要认为自己帮人做事、替人做事吃了亏。我们之前有个测试人员刚刚转到技术支持部门，大家觉得“写方案”是个累活就推给她写；后来销售说Word版本的方案能看不能讲所以请改成PPT的；后来又推说对方案不熟悉所以直接请你去讲吧……一年后公司政策调整销售竞争上岗，半年时间她就在一个全新领域（就是那个方案要覆盖的领域）打开局面，并成交了公司历史上最大的单子之一，并成为新的销售冠军，收入提高了200%。劝、帮、替别人做事是以无我精神推广敏捷的具体做法。在掌握了共振的人眼中，这不是一家“有些人不能配合我工作的公司”，而是一家“我能配合某些人工作的公司”。在共振中破除旧我，建立新我 “别人”的范围不止与我们无法控制的外层和上层，也包括自己的队员、师傅的徒弟等等。无我的人心中没有“应该开除的刺头”，而只有“有才干不能发挥因而应该帮助的队员”；没有“学会后会饿死我的徒弟”，而只有“会接手我的工作以便让我管理更大事务的兄弟”；没有“拒绝做份内工作的其他部门”，而只有“可能被我帮助、替代、乃至纳为下属一起管理的其他部门”。破除掉旧我建立起来的“新我”不是一个具体的位置，而是一个更高、更好的方向，确切说就是“无我”。否则自己的职业生涯就会又止于某个位置。比尔盖茨这些当年的程序员之所以能在很短时间内跨越如此多的职位，一个必要条件就是他们从来没有固守“我是一个程序员，因此不应该管……”，而是相信什么都是我要做的事，我可以成为任何人。尽管这不是一个成功的充分条件，没有这个心量却永远不能成功。以上三篇是解决一切已知、未知问题的心法，掌握了它们遇到任何问题就不会迷茫、恐惧，也不会只把希望寄托于某大师正好说过这个问题的答案，而是能自己分析解决问题。此后的问题及分析，均建立在上述三者之上。或许今后还能总结出第四个词汇，但现在暂时只有无我、无住、共振这三者就够了。敏捷开发一千零一问系列之四：优先级排错怎么办？初始问题对于不断更新的需求，导致需求优先级的判断出现了错误，知道项目周期后期才发现，怎么办？答案 1. （临时方案）确保所有排序均是由PO完成的常常出现所谓现场客户、由客户出PO、由一个销售当PO的情况，都是应该避免的。 PO一方面要熟悉具体的需求和原始目的（广度与细度的要求），另一方面则应该对产品的商业目标、终极目的了然于胸（高度与深度），才能站在企业立场而非简单的客户价值立场。从这一方面看，“有无限时间陪着我们的现场客户”和“一个销售”，其细度有余，高度不足，很容易带入歧途；而由“客户出PO”则会被客户牵着鼻子走，客户的想法一变，项目就会变化，也不符合企业的利益。 2. （最终方案）优先级排序应该基于较为稳定的商业计划，要确保有产品总监或项目总监来把控产品或项目方向一般的产品经理和项目经理排列优先级的依据一般有两个：一个是客户价值方面，一个是开发因素方面（比如对架构的影响、需求间的依赖）。但这些都相对浅薄的理解。真正决定什么优先的因素，是产品或项目的商业目标，并因此制定版本计划，在版本中体现优先级。作为产品，每个版本都是为了打败某个竞争对手，取代某个已有产品，获取某类客户的过程。从这个角度看，若商业目标明确了，那么要做什么功能才能达到商业目标，应该也是相对明确的（或者说，只有商业目标变化时，才需要发生重大的变化，不会突然有人一拍脑袋又变了）。这一点要求产品研发需要产品总监来做好产品的商业计划，并与具体负责的产品经理不断制定和沟通产品版本计划，并进而明确版本中应该实现的功能。作为项目，看似是为了完成需求规格上面的描述，其实是为了支撑客户的某个业务。这个客户业务，乙方要有人明确是什么，并最好能预见未来的业务。这样除非这个业务的优先级发生变化，项目任务不会发生重大变化。另外一个要做好的事情则是项目切忌不能客户说什么做什么，或者什么项目都做，而是要想好自己企业的主营业务是什么，有什么可以平台化以进行积累的东西，才能在做大的同时做强，成为某个领域不可替代的供应商。这一点要求应该按业务领域设立项目总监，对外不断审视领域的投资价值、分析客户群，对内推动核心业务的开发而抑制周边业务的开发。有了这个主心骨，就只有符合实现想好的业务方向的项目才接，自然也就不会发生重大的变化。项目要想被乙方控制，初期很难做到，甚至说如果这样是找死；但是如果做了很久还处于什么项目都做，客户说什么做什么的状态，则是在等死。案例 1. 一个军工项目这个项目发生在某年的10.1阅兵仪式上，但可别就此认为所有需求都与此有关，里边还是掺杂了甲方很多人的想象，面对强势的甲方，这些需求很难拒绝。不过项目负责人还是很清楚那天这个软件到底会被用来做什么的，所以核心功能被提前4个月完成并经常使用（因此也很少有缺陷）；而其他功能被扔在最后零星且“凑合”地实现。在最后期限逼近的时候，所有纯粹的想象都烟消云散，最重要的功能顺利运行。 2. 一个产品这个数字电视产品研发时，国外已经有两家企业运营一段时间了，因此主要工作就是“抄袭”他们的功能。在抄袭了一段时间后，终于成为国内的佼佼者，但是现在反观走过来的几年，反而冒出一身冷汗，为什么呢？原来直到10年后的今天，有很多功能仍然没有“被使用”，原因就是国内电视台有自己的业务规矩，比如年龄分级、赛事区域禁播这些功能，在国外是很热门的，但在国内至今也没有运营。这些功能的优先级在国内和国外排，会截然不同，这不是一个开发问题，而是一个客户的业务问题。如果不是因为当年这个领域的竞争不像现在的互联网行业这么强，加之团队的工作能力极强，结局很可能不是现在的样子。补充很多问题的发生，并不局限于要在开发组的范围内找答案，而一定要追究最终的原因（无我）。很多时候人们只现在在自己范围内找答案的原因，是因为自己可以控制，可以解决。但实际上如鞥这些答案解决问题不彻底，问题就会永远存在。但如果遇到了别人的答案，则应该遵循劝人、帮人、替人解决问题的方法。有时候在这家企业、这个部门、这个项目上有可能失败，但就像共振一篇中所提到的，如果因此而放弃，则必定失败；不但如此，还会失去在那家企业、那个部门、那个项目的成功准备。敏捷开发一千零一问系列之五：怎样让队员主动要活？本问题被评为某次课程最佳问题之一（每场2～4个）。问题怎样让团队成员完成从派活到主动要活？方案步骤0：在一个传统团队中，多半是由一个人（一般是项目经理）估算、分配、监督任务完成。由于这个人处于鸡的角色（请参考百度“猪与鸡”），所以真正承担任务的人要冒任务被错误估算和分配导致绩效低下的风险，引起大家的不满。按时完成了经理领导有方，延期了则总能找到一个临时工来顶缸，事情永远做不好。步骤1： “领导”和“管理”的区别在于后者利用权力行事，而前者亲自带领队员。比如如果项目经理仍然估算和分配任务，但是会主动帮助认为估算不对、任务过难的人。传统上让项目经理估算和分配起于其能力超过一般人，而他只有帮助别人完成任务，才能让他的能力发挥出来，也能让别人有所收益。完成步骤1后，人们就不会过于担心任务的难度。步骤2：把团队分解为1-3-9团队（参考松结对编程系列），安排师傅和徒弟，让师傅做第二级别的分配。在1-3-9团队中，师傅对整个团队的成败负责，因此最难最重的活，一般他都会主动承担。从长远看，为了防止自己总是累得半死，他又会把自己的一部分技能教给徒弟们，让徒弟也能为自己分担一些工作。此外由于末级团队规模较小（只有2～5人），人们极少冷漠地对待对方，相反地以兄弟相称，主动帮助乃至要活的概率更大。在心理学上，从众心理在人数众多的时候更容易发生，多数社会上“冷漠”事件的发生，不是路过的人太少，而是太多。步骤3：这个算是师傅的回报期了：师傅可以因为小组工作量变大而要求加人，所招聘的新人，其招聘、试用、培养环节，均由师傅负责。他会在这个过程中将文化根植于自己看中的弟子心中，而不是被迫接受领导送来的菜鸟或刺头。这样建立起来的团队更加稳固，人们更加乐于互相帮助。如果团队早就存在了，可以从步骤1开始，逐渐过渡到步骤3。很多人会说：“如果是新建的团队，一切都还好说，我直接用步骤3，但现在我们已经太晚了，已经有20个人了……”如果这样想，会在团队有200人的时候后悔：“倒霉，早知道20人的时候就动手了”。所以，没有太晚，只有更晚。案例暂无分析 1. 个体分离（有我）是人们不愿意主动要活的原因，因为人们觉得一旦自己要了活，付出的是自己，而受益的是别人（包括自己在内的团队有时候也被认为是“别人”）。应该首先破除这一点，形成团队工作的概念。 2. 责与权的分离是一个障碍，因为谁先破除“有我”的障碍，谁先需要付出。因此团队应该有一个机制保证多劳者多得。所谓的“得”，未必是钱，因为很难计算；但可以是任何其他东西。比如经常帮助新人的，我们可以将其提拔为师傅，进而成为未来项目经理的候选人；经常帮助别人的，还可以给他几个下属，让他帮助一下（而这些下属自然也可以帮助他做更多事情）……等等，都可以称之为“多得”。 3. 有时候会感觉自己企业的老板或直属领导很失察，自己做了帮助别人的事情，未必会有回报。其实不然，首先在没有帮助别人前，怎么知道领导是这样的想法呢？或许领导正愁没人愿意带个头呢，以至于他想提拔个副组长，都没有个合适的人选。其次，不要总想着在这里就得到回报，因为没有回报，所以我也就不帮助别人了。或许在这里，或许在下一家公司，或许被你帮助过的新手在下家公司推荐了你，或许……俄狄浦斯命中注定会杀死父亲，因此父亲把他扔到野外，没想到被人所救，长大后参加一个运动会，不小心把自己的父亲一标枪（或者铁饼？忘了）给杀了……世界运行的规律，不要用小学数学分析。因做到了，自然会结果。 4. 不要想有一家企业，大家互相帮助，在那里自己也会主动要活，但这里吗……算了。这样的企业是找不到的，因为即使有，他也不让我们这些从来不自己要活的人去。怎么办？从头就做一个主动的人，作为强者，帮助别人作为弱者，寻求帮助（至少不拒绝帮助），最后会证明自己的企业就可以被改造成哪家人人互相帮助的企业。这就叫共振。敏捷开发一千零一问系列之六：业务人员怎样参与开发？有一次课程上居然来了一个非开发人员，他是个网站的业务人员，提出了这个问题，并被评为课堂最佳问题之一。问题一线业务部门应该怎样具体参与到敏捷开发中来？答案方案1：敏捷开发中有很多活动是需要业务部门参与的，如果没有时间，第一个要参与的事情是“评审会”，就是阶段性验收产品的会议。在会上应该思考产品在实际应用中是否可用，并提出改进意见。但是要注意改进意见不要急于实现，而是应该询问下一步原来的计划，或许原来的计划更加重要。如果能在评审会上对产品未来的应用做出一点预测，对之后的迭代会有帮助。方案2：如果能选出一个代表，参与到计划会中，对于产品经理难以解答的问题给出补充解答，是一个更好的活动。各种解答应该具有预见性，因为所谓软件需求，无非是业务需求在软件中的体现。业务需求很少是没有计划就盲目开展的，因此若能提供预见性的解答，对整个产品未来的方向都会有很大的帮助。方案3：将业务架构、商业计划转达给开发人员。技术架构实际上是业务架构的体现，比如360，其业务从最开始就没打算局限于杀毒，所以业务部门就可以提前告诉开发组，当有一天要开发聊天、安全桌面、安全浏览器的时候，开发组并不需要把一个杀毒软件“重构”成一个聊天软件，这是不可能的。对于产品研发，业务部门若能将市场定位、商业计划、竞争对手等信息充分与开发人员沟通，可以有效地避免闭门造车、缺乏预见性、变更频繁等情况。方案4：变敏捷开发为敏捷交付。敏捷交付是最近的一个热词，其核心是真正地次第地交付产品。在以往的开发中，比如微软、Nokia，都是做敏捷开发、持续集成的高手，但是他们的产品都不是“敏捷交付”的，都有巨大的版本和断代存在，而销售模式也是工业时代的模式：一次付款，不退不换。在新兴的企业中，比如腾讯、苹果、Google、Facebook及众多网络游戏，都会感觉到他们的产品不是“一次买来的”，每次使用都可能有所更新（苹果是更新应用），这就叫做敏捷交付。敏捷交付创造了新型的互动关系，使得“拥抱整个市场的变化”落到实处，而不再是“把可用产品拿给部分用户评价一番”，这将是未来业务架构的趋势。案例 1. 某银行在访谈某银行的开发过程时，开发部门抱怨说业务部门的人只能说出零星的功能，而且还经常在变化，导致变更很多。后来访谈业务部门的时候，业务部门却抱怨说开发部门每次开发的产品都不太符合自己的预想，而且每次增加功能都要“重构”，反应时间较长。后来又访谈一个“战略规划部”，发现原来业务部门的业务发展，远在一年前就会有详尽的规划，业务部门所提出的零星需求，其实都是基于这些计划产生的。若能与研发部门事先沟通这些计划，开发部门就能充分理解需求的来源、根本目的、未来走向等等客户价值相关的信息，开发出更加好的需求。战略规划部接受了一个建议：将定期与研发部沟通未来的计划，从而让研发部能看到整个业务的全貌。实际上在银行这类业务预见性较强的领域，“拥抱变化”不是不断改进核心价值（在互联网则是），而是在确定业务目标的情况下，不断改进具体的实现方法而已。分析 1. 在很多场景中，业务部门都以“客户”自居（尤其是甲乙方真正的合同关系时），认为摸索、返工这些事情都是开发组的负担，与自己无关（有我）。但实际上，如果开发混乱，真正受害的无疑是业务人员这些终端用户。因此应该以无我的精神，去帮助那些为自己“交付价值”的开发人员，最终自己也将受益。 2. 从案例中可见，“拥抱变化”和低头走路是两码事在能看到未来的时候，有时候可以延长Sprint0中做架构的时间，将变化局限于具体业务细化、评审会上改进产品等活动，开发出来的产品反而更好。人们在“敏捷地”寻找最佳方法的时候，找到的未必是“敏捷的”方法，而是一种相对重型的方法，因为其业务本身是重型的。这是“无住”的一种典型体现。用副词“敏捷地”来描述敏捷开发的时候，一个问题就成了伪命题：“什么项目（不）适合敏捷？”任何项目，都应该敏捷地寻找最佳方法。敏捷开发一千零一问系列之七：怎样对待有看法的徒弟？问题松结对编程中，师傅对徒弟安排任务时，对于有想法的徒弟提出的意见怎样解决？方案步骤0：正心，诚意。人们到底是在管理一个人（控制，监督，指令）还是领导一个人（帮助，引导，培养），被管理者和被领导者其实心里是一清二楚的。因此在师徒关系中，不能为了师徒而师徒，而是要找到师+徒这个体系的目的，把心态放在把事情做好而非维护师徒结构上，从这个角度看问题才能做好下面的事情。步骤1：师傅日常要多在收尾的时候检查徒弟的代码，指出其中的问题，以让徒弟正确认识自己的水平。软件开发有一个好处是比较理性：好的就是好的，没有什么可争辩的；但也有一个坏处：好坏多半在做出来后才能看得出来，十个手指头胜过两张嘴皮子。所以师傅应该多在最终结果上指导徒弟，徒弟就会意识到如果从头就听取师傅的意见，中间会节省很多无用功。步骤2：有个笑话挺逗的，有人问某人你家谁说了算？回答“一半一半。如果我们两个意见相同，我说了算；如果不同，我媳妇说了算。” 随着一起工作的时间变长，师傅也不用强调每次都有更优答案，反而可以鼓励在大方向一致的情况下，让徒弟自己进行一些“微创新”，这样徒弟不会有一种巨大的阴影感。步骤3：在有些时候，师徒都拿不准，这时候应该引入更强的技术力量，就是“师祖”级别的程序员加入讨论。师傅不要因为自己都要接受指导而感到没面子，其实如果徒弟发现师傅这么厉害都还能尊重师祖的看法，自己自然更加会尊重师傅。步骤4：对于接近出师的徒弟，应该将其当作自己思维的延续，而非始终仅仅当作左膀右臂。其实很多人都将经历一个放下编程，拿起业务/管理/产品/市场乃至决策的过程，如果始终放不下，就永远拿不起来。从这一点上说，师傅不永远是师傅，徒弟不永远是徒弟。从这个终极目的出发，反而应该在早期就培养有看法的徒弟，而不是简单地把自己的看法交给他。培养的要点，在于心和法的培养，即养成正确的思维方式、价值观、看问题的角度，日后遇到师傅自己也没有遇到过的问题，自然就能轻易解决。案例无。分析作为一个师傅，要理解实际上并不存在“我的想法”，而是应该存在一个“正确的想法”，因此不应该每次都突出于徒弟的不同，而是在团队内部形成正确的价值观，鼓励人们“正确地思考”（正确是副词），从而得出“正确的想法”（正确是形容词）。这一点和敏捷开发差不多。所以师徒团队的目标不是找到一堆能执行师傅想法的徒弟，而是一堆与师傅想法相同的徒弟，进而找到与师傅思维方式相同的徒弟，甚至超过师傅思维方式的徒弟。当徒弟超过师傅的时候，师傅不能想“有人坐了我的位置”，而是应该想“有人替我办所有事了，我终于可以去办更大的事情了”。这是一种“人无我”的想法，就是不能固执地认为自己就是师傅，而不是更高职位的人。另一个很无奈的事实是人会变老，思维也会僵化（比如多数科学家都是在很年轻的时候做出贡献的，老了以后基本上就是做科普工作了；多数新公司也是年轻人创造的，老了以后公司也会逐渐衰落）。因此每个人无论职位高低，都应该培养接班人，按照正确的思维方式，探索新答案。（这个称为“法无我”，就是“法”也没有我，也在变化中，就是之前提到的“无住”）。敏捷开发一千零一问系列之八：团队习惯了分工怎么办？这是敏捷开发一千零一问系列的第八篇。（在这里提问，之一，之二，之三，问题总目录）问题在Team中，TeamLeader给人指定任务时，基本没有选择怎么办？（因为大家对别人的工作都不熟悉）方案步骤1：如果团队已经习惯了沉闷地自己开发自己的工作，办公室里边总是静悄悄的，那么一个可行的起点，是Leader可以先与大家进行松结对，就是不断地指导有难题的人。实际上当大家听到有人在交流的时候，就会侧耳听听，如果听到自己感兴趣的话题，也会积极参加。步骤2：下一步，可以主动喊某些人一起交流，比如“老张，过来帮忙看看小李这个问题”，这样交流的范围就逐渐扩大到3个人，而且老张-小李之间也建立了联系。一个宽敞点的办公环境还是很有必要的，如果隔断林立，别说三个人，就是两个人挤进一个工位都有困难。可惜这个问题很难在Team的层面解决，但是如果公司搬家、老板推广敏捷之类的机会来临，一定记得提一下。步骤3：从新招来的人入手，一点点形成师徒制度。原来的团队大家分工习惯了，可能挺难评判谁比谁厉害的（即使完全跨职能，这个也很难，何况加上了工作分工），但是新招来的人很容易适应跟老员工一起工作。首选那些工作能力超强的老员工，因为分工严重，公司内部没有人能帮他（有时候也没有人愿意），所以给他找个助手还是说的过去的，但是也要提前沟通好，这个徒弟可不是来打杂的，有要求其支持的权利，自然也要有培养的义务。步骤4：逐渐形成师徒微团队，在微团队内部做到没有分工（应该说是“没有分割”，强弱的分工还是有的，但不要硬生生地在模块、功能上面再分工了）。本人觉得让所有人做所有事有难度，所以比较可行的是有那么几个人都可以做那么几个事，至于最终会怎样，走着瞧吧。案例无分析实际上很难说团队会习惯什么，不能接受什么。我们当年因为人少，曾经在一个很开放的环境中工作，也算是习惯了其乐融融。后来公司发展了，老板来问打隔断的事情，大家觉得有一个私人空间一定很爽，就统一定制了隔断。可惜人数变化太快，安装隔断的时候又来了人，少了一个隔断，于是我和对面的MM（已婚）“高风亮节”决定我们中间先不安装了，等以后再说。结果过了一段时间，大家非常羡慕我们扭头就能面对面说话交流（那时候屏幕只有15寸），纷纷决定把隔断拆掉。所以习惯这东西，不能惯着它。等大家习惯了没有分工的时候，再分工也会感到很别扭的。敏捷开发一千零一问系列之九：总体架构什么时机进行？（上）问题总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？这是少数几个被提到的技术问题。在两天的培训课程之后，最后剩下的纯的技术问题一般只占1/5都不到，多数都是管理问题，而管理问题中，又基本上是人的管理问题，这也说明了在“心法人事物”中，心总是第一位的。方案最早想写成方案1、方案2，但感觉有点像说是有不同的很多并行方法，之后又改成步骤1、步骤2，又有点把事线性化了。现在干脆写回成方案123吧，总之越往后的越终极一些，也越难以一步到位。方案1：Sprint0 对于长期的项目，常常引入“Sprint0”的概念。 Sprint0就是在开始不断开发功能的众多Sprint迭代前，先做一个准备工作，大约持续一个迭代的周期。准备工作的内容五花八门，从团队组成，项目范围，到这里说的架构设计。有些团队每过一段，尤其在发布了重要的版本后，都会重新开一个Sprint0，来分析下一个版本的架构设计。这样就可能出现几种不同的迭代变形，最左边的是最轻量级的（周期短的、架构不重要的），最右边的则相反。 Sprint1 Sprint2 ... SprintN Sprint0 Sprint1 Sprint2 ... SprintN ... Sprint0 Sprint1 Sprint2 ... SprintN Sprint0 Sprint1 .... SprintN ... 实际上为了解决总体集成和发布问题，还经常采用SprintN+1的方法。方案2：制定迭代计划。 “架构想不全”这个问题，在于不知道未来要做什么，如果有一个相对清晰的迭代计划，就会驱动架构的设计走向正确的方向。正确的方向的重要性远远超过“详尽的设计”，只要架构能支撑未来的迭代计划，即使不太详尽，也还可以每个阶段细化。但如果方向是错误的，只会“精确地走向错误的地方”。有了迭代计划后还有一个好处是架构设计可以分阶段开发了。由于能预见未来发生的事情，因此也就能在关键接口处做好准备，而放心地把某些架构留待几个月后再做。方案3：补文档。本人正在用的一个方法。当设计一个交互性很强的产品时（比如游戏、手机软件），有很多判断来自于面对最终产品时的感受，而不是数据库结构这类东西。所以有时候不得不先把架构放在心里（不是没有），把产品做出个雏形，获得感受后决定是否如此，还是更改设计。这种方法常常伴随巨大的返工（原因倒不是因为不做架构造成的，做了架构，返工会更多，因为连架构也得返工；不做架构反而减少了返工量），但是对于创新性产品而言，返工不返工不是评价成败的主要因素。等最终结果得到认可后，会在管理系统中补充被确认的功能的架构。由于产品都做出来了，所以文字中可以引用很多确定性的数据库表乃至代码等，补文档的过程异常轻松。案例无。分析 1. 敏捷的架构设计之前智慧敏捷中曾经提到过一个问题“敏捷开发为什么不提倡做架构设计”。在变化决定一切的领域（比如互联网），提前做一个详尽的架构的确不是一个好事情，一方面时间不运行，另一方面等架构实现了，业务也发生了变化。因此在这些领域工作，要尝试把架构设计也迭代化，比如方案1表中最右边的不断迭代的Sprint0；另外一个概念则是简单性（Simplicity，maxmize the work not done），简单说就是能不做的事情就推迟做，比如“三个月内不会发布的功能的架构设计”就应该三个月后做。要做好这些事情，一个前提是不能逃避工作，也就是对现在的我与未来维护产品的人有分别心，“反正我暂时用不到，管他日后谁头疼没有架构设计呢”，否则就极度危险。 2. 敏捷地架构设计每种产品的架构设计方法各不相同，如果把上面“敏捷的架构设计”理解成为敏捷开发，那么军工、航空、银行这些项目，多半就不适合敏捷开发了。但如果说一切产品的架构设计，都应该“敏捷地”进行——就是不拘泥于形式，既不追求大而全，也不追求小而巧，而是要放下这些包袱，轻松地分析这个产品到底应该怎样做架构设计——则基本上放之四海皆准则。敏捷开发一千零一问系列之十：总体架构什么时机进行？（下）问题总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？方案之前提到了在时间的角度上，从技术和商业层面上的架构设计，下面看看横向的架构设计。方案1：开发人员全体参与架构设计敏捷开发整体上是一个崇尚“跨职能”的管理方法，开发和测试融合（所以才有很多类似自动化测试、单元测试、持续集成这些需要开发人员强参与的测试活动），开发与产品融合（开发人员要参与客户价值分析）等等，所以在架构设计与编码这两块，也不会分得很开，不能有人专门做架构，另外一些人专门编写代码。一方面，“架构设计”一旦变成一个文档，就要被写，被读，效率不说，中间难保不发生歧义，因此做架构的人和写代码的人在一定程度上融合一下，能大量减少不必要的架构设计，尤其是某些细节。二方面，文档或设计本身不是工作产品，在上面投入太多的工作量，极有可能是浪费而非保障。当然问题是：哪些人有能力做架构？这个问题如果换成：哪些人可以开一家新的世界500强企业？答案是“大学在校生”（IT界最近的世界500强多数都是在大学里边成立的）。所以同样是这些人，一样能做架构，只是看怎么做了。方案2：用师徒团队搭建全民架构团队如果没有专门的架构人员和编码人员，那么最好的结构就是师傅们做架构，同组的徒弟们将其实现为编码。 “这不也是分工吗？”是的，但是由于师傅们与大家密切合作，所以他很快就会把架构能力传递到徒弟手中，也会逐渐找到一些帮助自己做架构的徒弟，从而让自己能腾出手来做更大范围或更高层次的架构。由于师傅要为全组的成败负责，所以这种传授过程是由衷的，中间没有什么可以扯皮的。（关于这种机制如何运作如果有疑问，请参考“松结对编程系列”）方案3：商务人员参与架构一个产品中有三样东西是核心：商业模式，业务架构，技术架构。其中业务架构是核心，商业模式是从外界观察到的业务架构，而技术架构是从技术角度看到的业务架构。怎么讲呢？请看案例。案例比如360这个软件，它的技术架构到底是什么？刚开始，看上去是个单机版的杀毒软件；后来呢，变成了一个云查杀；再往后，出

展开阅读全文