日志
过程改进日记之学习Scrum2010-10-14：内部沙龙
热度 1 ||
原计划沙龙15：00开始，我到了14：50还在十万火急地修改，希望把最新Sprint5计划的情况写上去。（我还以为是15：30开始的呢）
赶紧保存了赶过去，有点迟到了，不过迟到的参与者更多，于是等了一阵子。
之所以以沙龙的形式，希望参与人员能够以放松的心情来观察别人实践，探寻项目管理中的疑问。
沙龙方面，准备也不够细。很多工程师之前对Scrum了解不够，带着问题来的人不多，不过不乏一些有代表性的问题，我把一些典型观点和问题以及我的理解分别描述下。
所幸做为典型客户代表的N产品PM参加了（简称N-PM），并回答了很多问题，也阐述了自己的心得，避免我陷入王婆卖瓜的尴尬局面。
一、维护看板应该比较费时吧
有人问我：你们俩（指SQA MM和我）在N产品过程中投入多少工作量？
我看着SQA MM，不确定的自问自答，“我们主要是边学习边观察，我还会写着日志来记录心得，但这些不能算到Team工作中，SQA MM这边每天应该最多两小时来看系统中的数据吧”。
SQA MM补充：“哪有这么多啊，除了参加每日立会，每天观察用的时间都是零星的，最多1小时撑死了”
我看有些人对这方面好像很在意，于是说：“我们愿意帮助大家抄写的，如果你们愿意尝试执行，我们会尽可能帮助大家做些琐碎的事情的。”
有人道出了他的顾虑：“我们我们大家都用Scrum，你们俩可能就没时间来帮我们做了，这样，我们会很麻烦”
“嗯，我估计我们俩每人应付3个Team还是没问题的，等以后大家都做，我就再多招聘一个SQA不就得了，这个你们不用操心。我可以搞定没人抄纸条的问题”，我觉得这个问题只是一个表象，提问者应该有更深的顾虑。
我的看法：
这看似最不值得操心的问题，每个Sprint中单纯的抄写不可能超过1小时，也许这些人在顾虑是否他们可以把任务细分成较小的颗粒度吧（比如0.5～2天）。
二、我们目前主要配合其它Team的工作，本身的目标不好定。
一个开发Team Leader发表他的评价：“我觉得N产品之所以用Scrum可以取得这样的效果，是因为N产品人员很固定，目标又简单，专心做好自己的产品就可以了，不像我们现在底层库开发，同时还要响应其它Team的产品需求，工程师经常被其它项目拉去做事情，导致我们自己的任务延误。所以我们的工作很难计划”
我问：“那你们很难计划，但也得计划啊，总不可能毫无计划的，你们是怎么安排工作的呢？，应该还会在Task Tracking中分配任务吧”（Task Tracking是我们的内部任务管理系统，可以从项目中获取功能点）
Team Leader回答：“对啊，但是我们通常每个任务的周期是3～5天，大致估计下，这样如果没有额外工作，他也许3天完成，有额外的工作，他也许要5天完成。”
我展开回答：“如果这样，你们还是有自己基本的计划，并且你们Team的目标就是两个：一是开发新版本的底层库，二是维护老版本的底层库。如果这样，你可以考虑把这二者目标合并在一个Sprint中”
我还想再问下：“当其它Team提出新的bug、新的需求，要求插入到你当前的工作中，他们一定会认为自己的事情很重要，你是怎么来区分他们的重要程度，以便把他们恰当的安排到你的任务中？
Team Leader回答：“我会和工程师讨论下是否有空，并和提出需求的人安排下优先级”
我：“这就是答案，Scrum也一样要做这些事情，但Scrum中每个任务有明确的周期，有明确的优先级，而你们现在的做法使得项目目标更含糊、优先级更不明确，需要依赖反复的讨论交流。而Scrum是怎么做的呢，有人提出需求，你们的产品经理应该把他领到看板前，对他说，看，我们有这些事情要做，现在我们估计你的事情要3天，来看看我们把他插在哪天来做，然后，我们再Unplanned区域贴上这个任务，这样的沟通是清晰的”
我：“但现在你们的任务不够精确，并且别人也不知道你们的任务序列，在这种情况下，他们会互相竞争，不断到你这边来缠着你，以便你能够把更多考虑他们的需求，最终让你放弃既定的目标。”
Team Leader：“但不是每件额外任务都能够被很好计划，当额外任务更重要，为了全局利益，我们就要放弃我们的既定目标”
我：“放弃就放弃啊，这没有问题，任务至少可以让你明白你放弃的时候哪些是已经做好的哪些，以后接着做也不会错乱。”
三、我们有些工作依赖其它Team的，别人搞不定，我们也没办法搞
一个DPM说：“N产品相对来说比较简单，没有太多跨部门协调，我们这边有些事情需要依赖其它部门的成果，他们交付不了，我们计划就没办法执行了。”
N-PM接过话题：“我们这边也有跨Team协调，有一次我们觉得和另外一个事业部的沟通很不顺畅，经常就一个问题来回讨论，而且他们的接口人还在做其它工作，响应速度很低。我们也觉得头痛，当发现这个瓶颈后，我们的行动是索性让我们的工程师搬到对方那边去，坐在一起，一天就解决了那件事情。瓶颈越多，就越需要看板来帮助大家记得重要的协调事宜。我们曾经有过遗漏重要事项，现在我们不会靠记性来做事情，依赖别人成果的，就经常催他啊。有些事情拖延是因为驱动力不够的原因”
我补充：“这个问题和前面的刚好相反，第一，正如N-PM建议的，可以把他贴到看板上，做为一个瓶颈事件，每天都看得到，这样，保持你找人的冲动。第二，你要影响他们，使得他们认可你合理的deadline。并且及时告诉他你这边对他成果的依赖状况。
“你如果每次都心急火燎的找人家，但每次都找了之后他完不成也没看到有什么严重后果，或者你后来对他无望，就不接着催了，次数多了，别人难免会尝试降低你的可信度。也许，有一个精确的看板的话，你让他看到你看板中的关键依赖任务，他也许会认同你给他的信息，从而更多关注呢。”
四、我最关心测试怎么搞，但你们也没有做好
某DPM：“我看你们进行了4个Sprint，好像测试阶段没有管理起来，我觉得开发我们现在的方式也没有多大问题，关键是测试周期很长，有时候都超过了开发的，我很想这方面得到解决，但你们现在都没有测试方面好的经验，那我觉得对我来说，Scrum没有意义。”
我：“的确，N产品的Scrum实践中，我们除了把bug做为任务跟踪外，也的确没有太多测试方面的方法可供参考，但是，测试时间很长并不全是测试环节的问题，而极有可能是开发环节质量不足，使得不得不投入更多的测试时间来补救。也就是说测试时间变长的根源关系到开发质量。因此，好的Team是把质量上的投入一部分放在工程师自测中，而不是指望最后才递交测试。
“至于具体的测试阶段如何用Scrum，我们还没有找到更好的实践，这方面请持续关注我们的未来的实践，如果有新的尝试，我们后面的实践会继续安排些沙龙的，只要大家有兴趣听，有兴趣讨论。但我认为有很多实践值得借鉴的，测试问题并非是唯一需要关注的问题。并且，如果开发任务管理还达不到目前的精度，N产品即使有好的测试实践我觉得也很难照搬。”
五、我关心的是任务分解方法，但你没说
有Team Leader说：“我觉得N产品从最初的平均3～5天的任务，到现在0.5～2天的任务，的确做得很好，我觉得我们最大的难处就是任务不好分，一大块的，如果是没有UI，就更难了，连验证都不能验证”
一资深工程师补充：“有些任务是需要前期学习的，了解不够的情况下完全不能分。强迫分解等于浪费时间”
我回答：“任务分解是我们不断尝试的，当工程师实在分不出来时，我们也不是非逼他胡乱分，而是希望工程师先不急着分，研究半天一天，基于研究成果来分，然后他又做了一天半天，我们在下一个立会中希望他基于新的认知再来尝试分一些。最重要的是持续分解，而不是计划完成了就不分解了”
我继续：“刚才讲到不能验证的任务，其实验证方法很多，可以用测试桩，也可以把设计工作分离出来，做文档review，或者做codereview，总是有办法的。”
Team Leader继续：“我了解到N Team任务颗粒度很细，所以我想请教下他们总结了哪些方法来分解任务，我觉得这个是我现在最关心的，但是我没有在你的PPT中看到，你能不能讲讲。”
我惭愧：“这个不好意思，实在没有，我们的实践还不够，我们还没用到什么高级的任务估计方法，本质上还是拍脑袋的，但这是一个不断反复的实践，我想用熟能生巧解释吧。”
六、每天都要参加例会，工程师们一定很痛苦
有工程师问：“每天都要开会？这太烦了，哪有这么多事情要说啊”
他的DPM安慰他：“我们如果要做，我觉得可以每两天一次”
SQA MM：“那一定有项目组三天一次，搞不好就有Team一周一次了，每天一次是Scrun框架的基础实践，如果你们觉得内容少，可以一次花10分钟，甚至5分钟，而不是几天一次。否则无法养成快速沟通的习惯，两天一次可能会使问题被发现的周期增加了一倍。”
另一工程师：“可怜的人啊，他们每天要参加会议，太痛苦了，我每周都嫌多”
我无语：“好像没有这么痛苦吧，我看N Team工程师没啥特别不适的感觉啊”，SQA MM和N－PM都点头同感。
再一人语：“新员工老实，不敢表态”
我汗“我之前发邮件给Team Leader们，有兴趣来观摩，不过没有来啊，要不这样，等下周Sprint5，我们每天邀请一个人来观摩，实在想了解工程师感受，也可以在15分钟后问问工程师本人，我想你们应该有答案的，至少你们会相信自己的观察”
（散会后，我找到DPM问，“实话说说，你每天开会，到底烦不烦，因为刚才沙龙有人觉得你们一定很痛苦”
“嗯，一开始有点，后来习惯了，我不太迟到，无所谓，倒是你迟到比较多，应该比较辛苦”
我勒个去……，这家伙什么意思
）
（anone评价这个case：那说明他们每周开会比较痛苦，所以他们推导出每天开会更痛苦）
）（anone评价这个case：那说明他们每周开会比较痛苦，所以他们推导出每天开会更痛苦）
批评与自我批评：怀疑变更、谨慎有余、担心执行力
沙龙中出现的观点，尽管我不太认同，但其实每个人都会有，我就能够我曾经多次有过类似的保守言论，我觉得有必要经常提醒下自己，面对新事务要保持良好的心态。就当写我自己吧。这样我可以写的更透彻点。
1、Nini考虑到，他的项目不适合Scrum，或者Scrum不能解决他们最重要的问题，总之，Scrum有很多局限，而且局限性刚好在他们的项目中被暴露出来（N年前，对于CMM也常有这样的判决）
2、Nini觉得，把任务抄即时帖上形式是好的，但是太烦了，除了我们外，Team工程师没有愿意做这个，一定没人愿意，这个太琐碎了（的确有些工程师非常关注效率，所有非编程的事情都会影响效率，比如在纸上把思维画出来，以便于设计是个很琐碎的事情，最好直接驱动工具画ＵＭＬ）
3、Nini又认为，没什么特别之处，其实万变不离其宗，换汤不换药，无非是把任务贴墙上而已，这个算不上什么大变化，形式而已（B不就是A＋么，这没啥的，我睿智的抓住了事务的本质，多年工作历练，我信任自己的洞察力。）
4、Nini还认为，要不要用Scrum，是领导们的安排，工程师只要做好开发就可以了，他不介意用什么流程（我是一个纯粹的、本份的工程师，我更愿意一心扑在代码上，两耳只闻需求声，直接告诉我你想做成啥样子就可以了，然后你要做的就是等待。）
5、Nini最后说，一个不完善的，没有解决所有问题的Scrum可以去了解，但贸然尝试是不成熟的，有可能是不理智的（对现状不满，希望得以改变？但同时畏首畏尾，不愿意承担风险？这是人性的缺陷，谁都是这样的，区别只是改变的范围而已。）
看来游说新的Team还是任重而道远的，我希望能够说服工程师和他们的TeamLeader尝试。慢慢来吧，不同的项目有不同的实践路线。
接下来，一方面尝试逐渐减少我和SQA MM的投入，观察他们Team自己的行动，另一方面，游说其他人观摩
