Sprint3计划会
反思是痛苦的,但实践是飞快的
我们没有再找PM讨论需求是否太多的问题了,但我在会议上惊奇的发现几个现象
1、一个外围模块没有被安排在Sprint3中(PM会后告知,原本这些模块拿到Sprint2做就是为了让新员工尽快熟悉软件的,现在看情况来不及了,这些并没有答应客户,所以就先不做了)
2、一个模块用最简单的功能代替了之前较复杂的逻辑(同样事后得知,这是最初的产品设计,后来丰富出来的延到后期)
3、个别工程师的任务很少,看起来很容易完成(PM说,等他们的模块简化后,做起来会很简单,多出来的时间他们需要从别人来不及完成的任务中去取)
哈哈,我还没去实践关于“问问题的能力”,PM怎么已经有了众望所归的抉择了。看来正确的思维方法总能带来正确的结论,我在思考,PM何尝不在思考呢。只不过,借Scrum的角色表达,我是鸡,他是猪,我只是部分参与而已,况且我没有做出过承诺,所以我是纯思考,而PM是思考,并且行动,他需要对后果负责。
Sprint3的计划会比Sprint2有很大的提高,但计划的过程中仍旧有些不完善的地方,最主要的是自上而下的分解任务,当然这个PM和DPM可能都没有意识到,他们的行动方法还是先确定需求,再和工程师一起分解,但经过这段时间的学习和被教育,我知道这样的分解任务仅仅是看起来自主的,实际上工程师未必真的了解要做哪些了。另外,我在PM边上,总是打断PM的话提出我觉得不好的地方,PM忍无可忍,低声喝道:“知道啦!
![](https://i-blog.csdnimg.cn/blog_migrate/33a126241d0d7285c75888787f3b4978.gif)
我汗,我的确太着急了,越俎代庖了。
![](https://i-blog.csdnimg.cn/blog_migrate/5369dacf6aefa511c6d0d2803d8c3168.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/b7d0375117f01ec885268899a334ce54.gif)
(其实,我检讨自己的说话方式已经很多次了,爱插嘴胜过倾听
![](https://i-blog.csdnimg.cn/blog_migrate/da7bf2d27a4211ff64e9a5aa00d6979f.gif)
-----------------------------------
Sprint2反思会
在Sprint3计划会之后,我们直接开始了Sprint2的反思会
虽然PM说了好几次应该叫总结会比较好,“ 反思”这个词感情色彩太浓,感觉失败的项目一样,还是叫“总结会”比较和谐。
不过我还是坚持这个说法,通常总结会都差不多是准备表彰了,我们开这个会的目标就是要找到后续可以执行的改进项,不反思则无法深刻理解改进的必要,不利于改进的执行。
我特意把以前SQA MM从TechExcel索取来的大海报取下来(之前粘贴在作战室的墙上),一段段的念着,以确保我们的反思会形式上的正确性。( 欲下载可以点击此处)
首先,每个人都需要至少一句话来评价好的实践和不好的实践。我把他们写到玻璃板上,如图。
![](https://i-blog.csdnimg.cn/blog_migrate/819bd9eaf057d98f1a8b2e8183d93401.png)
问题出来了
当大家枚举“不好的实践”时,基本还算是陈述实践动作
但是当大家枚举“好的实践”时,就可怜了,清一色的形容词,果然大家更有对付“总结会”的经验。
不过也有一些闪光点,比如有位经常不更新的工程师很含蓄的说“对系统不熟,使用不充分”,那是做自我批评呢,太棒了
![](https://i-blog.csdnimg.cn/blog_migrate/7c1ec50d693db1f728a2068b1cda5276.gif)
工程师的自我管理的训练一点一滴地融入到日常工作中做。日积月累会使得个人和Team都有很大的进步的。老大对这方面也多有期望。那就去慢慢做吧,让工程师自己觉得自己的努力换来更多的自由分工才对。
具体剖析就不需要展开写了,我的后期图片是完全仿真的。都在上面了。
为帮助工程师加深印象,SQA MM把我们的改进项贴到墙上去了。
![](https://i-blog.csdnimg.cn/blog_migrate/2c68da33205290628cefe75fbad691f6.png)