主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷
- 复 可以举个例子说明
家园 我把敏捷分成两个层面来看 项目控制一个层面和实现一个层面。当然在高层次上的讨论，如Plan game等都会对成员的水平有提高。但真正提高的还是在实现的具体操作上，也就是在代码层次上的事情。菜鸟要提高就必须动手做，而且必须掌握方法。敏捷在这两方面的帮助是非常大的。
家园 这点是很实在的 特别是通过pp这种方式，成长都比较快，当然客观上就牺牲了牛人的一部分利益了，另外扯皮啥的，实在很不咋样了。
agile不强调效率，强调的是平衡，记得看过一个报告，说一个最高效的agile团队但结局比较不好。
其实老外想的也对，毕竟你和同事带的时间要比你跟家人还久，让工作气氛好一点，这也算是一种享受生活的方式。
家园 这点我持保留意见 当然这个所谓水平的定义本身就有二义性。
1. 我经历过不少项目，团队成员能力比较强的，整体生产率反而不高。因为想法比较多，大量的时间都花在讨论和控制上去了。
2. 团队成员个人能力比较弱的，有1，2个核心人员能力比较强的情况下，整体生产率反而比较高。每个人反而都可以发挥最大价值。
我个人觉得agile的目的还不是为了解决生产率的问题，而是为了适应软件开发环境已经发生大规模变化的情况下进行的适应性调整。agile更强调人性，说白了也就是要把软件开发回归到一种正常的普通人的工作状态，打破以往过于神话的地方或者非常个性化的方式。agile更强调团队的节奏感。强调团队工作，所以考核单个人的生产率，意义不大。
从这个角度看，agile不适合所有项目。
家园 我要解决的是需求变更情况下的生产率 agile面向的都是需求变更比较多的项目，需求变更多效率当然就低了。
有些项目不适合agile的，后面我还会说到。
家园 【原创】闲聊敏捷开发——SCRUM（四） 上一篇讲完优先级，应要求写了个实际的poker-plan流程
总结就是：高效的沟通取决于沟通前的功课是否做好了，poker-plan逼迫PO做功课。
如果有同学也开过poker-plan会，可以对照是不是也是这样的，如果不一样，拿来探讨一下。
我写到这里想先把SM的角色讲一下，因为这是比较特别的部分。Sprint以及sprint plan留到后面讲。
必须从瀑布式管理说起，因为瀑布式管理没有SM。
瀑布式管理的优点是计划性强，非常逻辑，先考虑清楚，再把需求写下来，然后估计工作量，然后运用甘特图之类的东西或者project这样的软件，就有了一个个时间节点。如果能够踩准这些时间节点完成既定任务，那么项目将完美结束。我干那么多年，每个点都准确踩准的只有好多年前的一次，那次没有遇到什么需求变更。
把计划都安排好了，让做什么就做什么，按计划干就行了，每件事情的工作量原则上必须有高你一层的技术骨干来决定（给你自己定啊？那肯定虚报怠工啊）。在过去这样干活没啥问题。可是需求变更遇到了困难，因为需求变更就意味着新的工作量，而这些新的工作量是当初没有被计划进去的。在过去这样也还行，因为变更小。少量的变化造成的新增工作量可以突击消化掉，只要是计划安排的还过得去。
新行业的出现带来了巨大的需求变更需要，于是当遇到很多变更的时候就只能不断的调整计划了。
很多人把善于做这种调整称为“管理的艺术”。好吧，暂且不论艺术不艺术。之所以还在艺术是因为变化还不够多，当需求变更多到一定程度，计划再也赶不上变化了。
对于被要求修改的开发人员，情绪必然是抵触的，他陷入了一种困境，即使他心中清楚改动具体有多麻烦，但是他难以告诉客户到底多麻烦，他只能说“很”麻烦。或者说需要1个礼拜来改（客户不会相信他）。
开发人员的抵触是可以理解的，对于他个人而言，这种变更是对他前面工作的否定，他前面基本就是白干了，而且在他看来再也没有人会记得他之前干过的那些，他潜意识里必须想个办法让人知道他的苦难，让上司知道是一个办法，至少不算太白干，他有种本能要把事情搞大，让他的上司出马去顶（顶不过至少也算知道了）。 而对他的上司，困境是类似的，有时甚至不如实际开发人员了解到底这个麻烦的程度。
当然，在代码里尽可能的留下修改的余地这只是妥协的手段罢了，治不了本，而且为了留下修改余地搞出了额外工作量。
对于开发组而言，怨恨目标自然是白痴客户，因为在他看来，由于客户的鼠目寸光，导致了他的困境。开发组吃饭时一起骂客户是常见的消遣方式。
但从客户角度讲，也有个困境，他没有办法真正让开发人员理解这个修改多么重要，而且他也不知道这个开发人员只是因为怕麻烦不想改，还是真的很麻烦，他见惯了开发人员向他抱怨麻烦，于是他到处找人，找那些能帮他把需求修改“压”下去的管理人员，比如lead之类，如果还是被顶回来，就一级一级往上找，究竟要找到多高，取决于这个修改在他们心中到底有多重要。
就像我在（一）里面说的，需求修改其实是常态，在双方不断的处于这种困境的情况下，双方变得很难互相信任，所以高唱要建立信任是很重要的，也是很难的，需求变更越多，就越难。怎么可能信任呢？今天你要这样改，明天你要那样改，我能信你？我改的越快你变的更快，我改出来你看看不喜欢，又要那样改了。客户也不信你，你说很麻烦不能改，我找你头头一压，你不是很快改好啦？你不肯改，我找别人改，别人很快改好了诺。
看看SCRUM怎么解决。
PO把自己的需求变更写下来，然后拿去poker-plan一把，最终都会得到一个公正可信的价格，他了解了这个需求到底有多麻烦。尽管有时候他还会假装惊呼“好贵啊”之类的话，但这个和你买东西问完价格喊贵的道理一样，你不一定是真觉得贵，只是希望再杀杀价，人之常情。
有了价格以后，PO好好思考了一下到底值不值得做的问题，比如要把夹板门换成实木门，20个点，值不值呢？花在这里20个点，是不是宁愿花20个点给夹板门装个高级门锁呢？
就和我们拿着皮夹逛商店的想法差不多。只要皮夹里的钱是有限的，我们就会自觉排列优先级。
然后TEAM里无论谁拿到这个story，修改么，也只是一个story而已。前面虽然夹板门白做了，但是夹板门的5个点是着实被记录下来了。不做这个story也要拿别的story做的，否则积不到点数。（这里和考评有关，后面详细说）
我对SCRUM的处理方法概括就是：“给所有的变更估价，以价格为导向形成内部的市场经济体系”。于是简单了，所有的改动都可以接受，只有标价不同而已——没有买不到的，只有买不起的。PO只是在这个体系中买东西，TEAM是在卖东西，不强买强卖。听上去一买一卖倒挺合理，为啥还要一个SCRUM MASTER呢？
这个SM到底起什么作用？大家想一想，既然我说了这是市场经济体系，那么市场经济必须是在一个法制社会中进行，否则有人抢东西怎么办？SM就是法官＋警察，维护秩序的。谁会抢东西呢？一定是PO，PO有种我是客户我说了算的习惯思维。简单说就是当惯了皇帝不太习惯于去市场付钱买东西，常常越界。PO们总是迷恋权力的（指手画脚惯了），当PO发现自己的需求需要更改的时候，通常他们第一个想到的不是另写一个story，而是直接走到某TEAM成员那里去：“小王，上次那个夹板门不好看，还是改实木门吧！”，
小王回答“改实木门很麻烦的，我做不了主，需要请示”。
于是找到小王的LEAD，接着开始斗嘴，最后无论改不改，双方已经浪费了大量的时间在这种本不应该出现‘沟通’上了。从此以后，无论是TEAM还是PO都再也不把poker-plan会议当回事了，一切回到熟悉的从前。我见过好多这样沉沦下去的项目。
谁的错呢？PO和小王都有错，他们都忘记身处一个市场经济中，应该用钱说话。
小王正确的回答应该是：“请问有story了么？如果没有请写个story”，对于TEAM中的小王而言他真的不需要记住太多规则，他只需要记住自己只认story，因为只有story才能给他带来点数。就像店小二只需要认识钱就可以了。
如果PO强行让他做，那就是抢东西了，小王需要做的是打110——找SM来。
SM就是个法官＋警察，也就是说，他干的就是法制建设的工作。
听上去是不是很滑稽啊，反正这完全是我自己的理解，这个说法也没见过别人说过。
SCRUM搞那么多规则其实就是法律啊。只有搞市场经济才需要法律，老是有人抢东西的情况下是不需要什么法律的。
本帖一共被 1 帖 引用 (帖内工具实现)家园 搞技术的 怎么和搞文史的一样，转弯抹角的东西太多了，再看1000字，还没到正题，想给你100个砖头
- 复 搞技术的
家园 LZ其实说的很不错，先把问题展开 没有问题，何来的道理，谁也不是吃多了撑的才琢磨这些劳什子。
lz一上来把重点就放在需求上，这不是无的放矢，而是道明了问题的根源。敏捷开发流行许多年了，其中的操作规章等也被人背的滚瓜烂熟，但多数人眼中仍然是那个开发二字，想得仍然是如何开发的问题。方法没有十全十美，不能从哲学意义理解一个方法的前世今生，那么一个方法不过是又一套规章制度而已。
让我们看lz的后文...
- 复 搞技术的
家园 不要以搞技术的眼光来看管理问题，我也不做技术很多年了 管理学，政治学，经济学，相通的内容很多。
在SCRUM里有很多融合。很多同学可能根本没接触过Agile或者SCRUM，得从本源推导。在我看来这是个很革命性的管理方式。写出一本书来也很正常。