虽然零零星星接触过scrum的一些知识，之前并没有深入了解过。这次机缘巧合，将 Jeff Sutherland 的《用一半的时间做两倍的事》拜读完毕，感觉 scrum 的做法其实很多和我自己摸索总结出来的是一样的，很多地方都有知音之感。并且，在理论穿透性方面，我的方式还略胜一筹 ^_^。倒是今后某些话题能够有所援引。
比如说经典之问：这个项目要多久，要多少人工？
我一直的回答和 Jeff 一样：得做一段时间我才能看出速度，才能给出大概的时间。
和 Jeff 不同的是我在实际操作时有时会忽悠一下客户：估计要一周左右。：D
现在我可以更为理直气壮的说“这是scrum理论说的”。
闲话少说，它山之石可以攻玉，学习scrum的过程对自己的理论也是一个梳理。
下面说说scrum和我的方式的同与异。
| scrum | 我 | 分析 |
| 小团队： 3-9 人； 卓越的目标； 全技能； 自我管理； |
倾向于小团队： 充分的沟通与分享； 个人能完成独立功能或功能MOCK，团队全技能； 为了充分沟通，个人应部分习得其他人的技能； |
scrum认为人太多沟通渠道就多，大脑应付不过来，所以不需要那么多人。最终证实3-9人效率更高。 很多书都是这样介绍的。人可以共同活动的不超过15人，公司最多150人云云。这我一直认可。 我的立论基础是大脑的组织结构与生态。人多近似于形成神经网络全连接，可以缩小规模为部分连接——类似于卷积神经网络的原理。基于该立论，我主张团队应具备兴奋传导机制，包括知识传导，情绪传导等等。同样，基于该理论，我认为个人应该扩充技能，习得其他人的部分技能。 团队全技能我一直无意识的在进行。后来有的公司将美工等置于其它部门，沟通协调成本确实大增。这点scrum提出的好。 自我管理云云看似合理，但当技能发展不充分时，有可能形成团队短板。这时正如知乎所说，师徒式团队更能培养人。 scrum团队对人的要求太高。且没有提供造就人的机制。可能因为scrum是在火线压力下提炼出来的，在deadline人除了精诚团结没有其他选择。 |
| 设置产品负责人 | 产品负责人这个角色近似于产品经理，需要完成需求分析、产品定义等工作。但因其为团队设置目标，必须具有激励与鼓舞的能力。这种角色其实很难扮演。实质上是核心角色。 scrum也要求产品负责人与团队商议。 我的依据是团队成员应从源头即获得兴奋，造就参与感，这样当成功或挫折时，才能感受到一样的情绪。 正如《不行》一文所担心的，这个角色政治化的危险很严重。压制团队意见、难以取得团队尊重，都是棘手的问题。 |
|
| 设置 scrum 教练 | 这个角色主要功能是维持秩序，可能有其价值吧。但同样有威信来源的问题。 | |
| 建立代办事项清单，安排优先顺序 | 完成核心功能，渐次开发外围功能 | scrum在开发流程上的主要特点是迭代交付、快速响应变化。其认为这是对瀑布流、甘特图的重要颠覆。 迭代交付与我的认知相同。 但软件次序与作者认为的商业次序有所不同。软件是一个生长的过程，建立扩展性强的架构（平台）、原型、先从核心到外围，更符合软件自身规律。所以优先事项云云，似乎只适合于没有技术突破的外包项目。 或曰，老板喜欢商业顺序。老板可能喜欢，但是后面的代价更大，老板最终还是吃亏。 |
| 修正与评估产品待办事项清单 | 这个活动主要是评估任务难度。 | |
| 冲刺规划会议 会议确定的事项不能改变，也不能加入新的东西 |
开工会议，需求梳理清楚后，和成员介绍需求故事。故事有主角，有顺序，有对应的设计，设计可以共同商讨。 | 这是scrum过程控制的一个精髓。大变化中的短而稳定的不变化。 但是，即使在一个冲刺周期内，成员也可以自由改变达到目标的方式。为何不能让团队改变或放弃一个目标呢？毕竟PO也可能产生新的想法啊。有些时候你不做根本不会产生想法，进行过程中产生新的认识是常事。 如果不搞瀑布流，不分阶段，需求阶段过早让成员介入无疑会造成空耗。 |
| 工作透明公开： 三栏白板 燃尽图 |
本人设计过类似的日历白板。 总的来说，这个方式有其价值，有督促作用。但对于任务的因果关系不如甘特图清晰。 |
|
| 每日立会 昨天做了什么 今天计划做什么 遇到什么障碍 |
站立这个仪式据说是向球队学的。我认为这个很扯，需要团队有娱乐精神。在国内搞会很别扭。就和教会让在座的会众问候旁边的人一样，如果不是社区教会会很尴尬。这个设计和Jeff是军人出身有关。 有的人觉得这个过程需要，形式可以散漫点，比如早上来到公司每个人拿杯咖啡气氛融洽（safe）的陈述。 每天都开个小会我认为不如密集而非正式的沟通，我不喜欢事情等开会时再商议。实际上交流频繁的队伍不可能不知道其他人的进度。但也不排除有内向的个体需要提供一个发言的外部设施。 |
|
| 冲刺检视或冲刺展示 展示成果，不惟团队成员，利益关系人、管理阶层、客户都可参加 |
成果展示，技术介绍与分享 | 我非常重视成果展示，成果展示与技术交流是我最喜欢的一个会，其他人看法也一样。成果展示是兴奋的最高点。所以也特别能传导兴奋，分享知识、情绪。 但是很难认为每周都正好有成果可以展示。以7天为周期未免干扰正常开发进度。有的活干能干完故意延长，有的干不完只好加班赶进度，有的可以做的更好点的，就取一个平庸的松懈的效果。毕竟在scrum的体系中有领导、客户参与，人都爱面子，希望自己显得进度超前。 另外，scrum有领导、客户参与，还会造成客户不断提出新需求。scrum认为这是拥抱变化，实际上客户的变化是无穷无尽的，根本不存在20%功能解决后客户心满意足的提前结束开发，除非吝于加钱。 有些成果是不可见的，例如服务器连续稳定运行。我也要求将其可见。譬如，展示top命令进程的时长，或提供更美观的报告。这与scrum一致。 但我会要求开发继续解释是如何实现的。这样开发有成就感，有兴奋点。大家也可以学习或提供更好的思路。——往往开发后面发现自己有新的解决办法，看着他一起成长，你相应的认知也会提升。 |
| 冲刺回顾 | 这个会议可能就是我一直做的成果与技术分享吧。 把会议分拆为面向客户、领导和面向团队内部是一个好主意。 让团队参与交付，符合“吃你自己的狗粮”的思路，能给团队传导直接的兴奋。 这和我的思路是一致的。直接的刺激显然更容易引发兴奋。由销售面对客户再传导给团队，团队难以体验到那种压力，也得不到客户的认可。销售认为团队自闭内向，团队认为销售爱折腾。躲在黑暗的船舱里比站在船上看着风浪更容易晕船。面对活生生的客户，胜过面对二道贩子。 如果要出差见客户，最好也能带上一个开发。 scrum团队貌似是项目制，所以如何与其他同工种人员分享交流，如何沉淀公司的技术成果，是一个问题。 |
从上面的分析可以看到，scrum 可以理解为两个重点：
团队：scrum团队
工作方法：迭代交付、五个会议
支持scrum团队的理论主要是小团队、交流分享、透明、跨技能、自组织。
支持迭代交付的理论主要是20%的成果能满足80%的需求、快速响应变化、速错、化零为整，形成多个交付周期。
至于每日立会等等，可能不是重点。
我的团队理论主要是个体化、兴奋传导。实际上是一种更为根本的自组织理论。
这套理论对人的依赖不如scrum高，团队只要能达到充分的兴奋传导即可。有的时候适合师徒式合作，有的时候适合对接式合作，应当视不同的个体实际状况和工作内容而定。总的原则是人尽其才。个体技能越多，知识领域越广、心态越积极活跃，在团体中的价值越大。对应的成果会议、技术交流会议、WIKI，都受该理论支撑。我主张团队中个体应能完成独立功能，希望招进来的人丢到水里就能自己学会游泳，这与scrum团队的要求相似。和scrum一样，成员能看到项目头尾，其更清楚自己所处的位置，成长更快。
另外一个维度是工作维度。工作有计划与计划分解、分配与认领、进行、成果、转交。scrum使用戴明的理论，将工作分解为PDCA，即计划、执行、检核、行动。scrum使用该理论的根源似乎是拒绝瀑布流后又必须完成含测试在内的所有工序。有的人发现scrum队伍最好实现测试自动化部署自动化，那最终岂不是只剩开发一个工种了。而我对瀑布流并不排斥。瀑布周期太长可以拆大瀑布为小瀑布，加强兴奋传导以弥补分工造成的隔离，取消分工并不可取。没有工序、流程像样点的合作将无从谈起。scrum 不需要项目经理，原因是成员可以自治。我也不需要项目经理，原因近似，但是 scrum 主张大家一起分工主动认领任务。而我抱持的是建立流程，自动流转，自己手里的工作自己安排不劳项目经理插手，每个人都共享业务故事，每个人都明白优先级。所以可以说我的自治是基于流程基于工作的自治，而scrum的自治是基于人的自治。
我认为 scrum 在面临大团队作战时会发生很多问题：
1. 跨团队的知识共享：如成果共享、技术推广、技术沉淀。
2. 项目完成后团队继续保留？答案是解散。这对打造团队文化似乎有一定害处。
3. 大团队如何实施？现在有各种 SOS 的说法。要点是 PO 组成一个大的 PO 圈。那么问题就很明显了，所谓 scrum 就是 PO 掌管一群群小组。只有 PO 是能自由活动的，其他成员都是某个PO的跟班。有说 scrum master 管人，PO管事，工作中显然事重于人，且 scrum master 没有组织，PO 却有公司范围内的组织，最终演化结果必然是 PO 成为核心。当然，以 scrum 对PO资质的要求，PO成为核心也无不妥，但是PO是否合格很难考察。
人员成长是公司一个重要课题，一个高手带来的价值胜过10个菜鸟，公司不仅要招高手，也要让公司内部的菜鸟成长为高手。成长的重要基础就是兴奋传导。一个人会了闭包，另外一个人就会跟着去学，身边的人可以带来更大的刺激，产生更大的兴奋。按 scrum 的搞法 Java 与 Java 分隔于 2 个小组，其产生技术交流的概率接近于 0，除了上面说的短板问题，显然人员如何成长也是一个严重问题。
我没有管理过中大型的队伍，但按兴奋传导的理论，这个问题是可以轻松解决的。比如之前弄的技术 wiki，或个人博客，或企业内的技术交流BBS等。但按 scrum 理论这些似乎是不存在的。在技术方面精进，若干人员一起搞一个更好的框架，这些没有客户的活动在这样的企业似乎难以进行。——可能也可以，但是谁来启动它呢？
一些参考：
如果用scrum做sprint plan，怎么确定user story和task？ - SegmentFault
https://segmentfault.com/q/1010000002758305
如何实施 SCRUM ？ - 知乎
https://www.zhihu.com/question/19638322
Scrum—官僚者们的游戏 - 简书
http://www.jianshu.com/p/bfb00db24640
简述淘宝团队的技术沉淀和对外分享 - OPEN 开发经验库
http://www.open-open.com/lib/view/open1452260815073.html