连续几天没写日志了，需要惩罚一下懒虫了，监督的人上哪去了啊
曾经有过一个想法，给TeamLeader发邮件，请他们参观我们的Scrum方式，不过效果不理想，除了揪住一个TL和他对话外，再没有其它感兴趣者主动来问，一来他们太忙，二来他们太没有好奇心了，第三就是我们太没吸引力了。
某日，老大问起，我就给了以上三个答案，老大的判断，主要是没有好奇心，这是个问题，好奇心是成长的基础，没有好奇心，当然也就没有尝试的动力，当然，还有一个可能是他们都不看好这样的模式:(
没关系，这个方法失灵，还有更多的方法，我想在整个事业部内部面向所有工程师做开放的培训，也就是说随愿意参加谁报名，不强制，哪怕只有一个人报名也行，这样起码可以评估在整个研发队伍中，有多少人希望了解更多信息。
老大问我打算讲哪些内容，我的想法是把Scrum基础做些介绍，再讲下我们在N项目中的实践，老大不以为然，说如果工程师有基础的好奇心，很容易找到这方面的基础知识，我们是要激发他们的好奇心，所以建议直接讲我们在N产品上的实践，把我们遇到的问题、解决的问题、思考，以及各个角色的体验写出来，不要做成培训，而是沙龙的形式。
这和我之前实践先行，培训后做的理念还是相符的。于是先请SQA MM拟稿。
今天看看已经过了几天了，问SQA MM要份初稿看看，有些观点又不一致，讨论……
关于现实角色的小分歧
在SQA MM的PPT中，PM的角色是Product Owner & Scrum Master，而我认为Scrum Master理所当然应该是SQA MM本身。
我的观点错综复杂
1、我一直认为SQA理所当然转型为Scrum Master，这是一种可行的职业发展趋势。
2、在N产品项目中，虽然在Scrum过程中，PM有很多自发的实践，但她这些行动还是以往管理的惯性、已经PM责任的延续，这当然是好事，但不能说PM执行了Scrum Master的实践
3、在Scrum Guide电子书中，有一个提示相当明确
“ScrumMaster 可以是团队的成员，例如，他可以是承担 Sprint 任务的开发人员。但是，当他需要在排除障碍和执行任务之间选择权衡的时候，这种身兼二职的情况常常会对做决定带来矛盾。ScrumMaster 绝对不能是产品负责人。”
SQA MM的观点也很明确
1、她是以观察者角度来编写这份教材，因此，她要把她观察以及理解的东西写上去，而不是记录我的理解
2、Product Owner兼Scrum Master的确不是最好的实践，这种实践使得同一个人的行为我们无法知道他是基于哪个角色做出的判断。所以他会在后面的案例分析中，指出这种实践的不足之处。
呵呵，她的理由也很充分啊，这个复杂了，于是我展开游说工作，（此处省略10分钟文字）
SQA MM被我体谅我良苦用心，外加我实在比较烦，终于同意在PPT上牺牲她的角色定义。（俺可是以德服人，呵呵）
框架怎么搭
现实角色认定的分歧算有个临时解决方案，然后再看PPT后面的内容，把我们的实践和Scrum的框架融合着，读起来的确不错。
不过和老大的建议－直接讲我们的故事－还是有些不同，于是再讨论
SQA MM认为光讲我们的故事而不讲基础框架，有些词汇不做解释的话，人家就会很茫然，比如Sprint，如果不解释，叫迭代，但这个迭代和工程师平常理解的迭代又不一样，这样他们听起来就很费劲。
想想也是啊。Scrum Master是什么，不解释的话，听的时候就会糊涂。
“还有，当初你们怎么讨论下来就决定尝试Scrum了的？”，SQA MM问，呵呵，这可是个很不错的回忆，写日志的好处就出来了，找第一篇呗，然后按照日期找聊天记录，IM不删记录的好习惯再次派上用处。
SQA MM大刀阔斧编辑……，“就这个作‘缘起’篇好了”
PM: 你们有没有时间研究敏捷开发
泥泥: 有
PM: 好，你们看看，我想在N产品项目里面做一些尝试
泥泥: 很好。我们最近都在研究，希望能够找到试点的
PM : 好，那就是一拍既合，你们研究的什么时候能给我讲一下
泥泥: 下周可以在项目组内做些培训
泥泥: 你想用敏捷模型，最希望改变的是什么？
PM: 主要是在递交速度，完整功能的递交速度
泥泥: 完整功能的递交速度？ 难道现在不是完整递交？
PM: 就是把功能拆细，然后减少错误，快速递交
PM: 最主要的还是要让每一个产出都是可实际投入使用的东西
泥泥: 那么，我推荐你们使用Scrum……
以上文字经过SQA MM整理过的信息记录，其中删除泥泥套近乎的词汇若干千
多好的文字啊，取精华去糟粕，直指人心，见性成佛:)，
这样的开篇不错，后面就是讲故事，列出我们面临的问题，以及我们做的尝试，效果，未解决的……
呵呵，大纲定下，后面应该就快了，国庆节后应该可以展开沙龙了