读《scrum精髓》一书，对照之前和现在的不同项目的实践，对scrum有了新的认识和一些反思，Mark一下：
最近的S和H项目中，需要我们与客户组建成为一个新的团队，并且出于对我司的尊重以及对敏捷的好奇，客户决定使用scrum来进行项目管理。作为一个不成熟的融合团队，目前我看到的问题有以下几点：
1. 违背scrum的八大价值观：简单，以人为中心，诚实、开放、勇气、尊重、专注、信任、授权和合作。S项目中，SM（一个新的TWer, 老的PM）在每天下午之前都询问开发人员的进度，经常笑着对桌子对面的开发小哥说“嘿，兄弟，你的卡今天能不能完成？加把油哦，今天必须搞完哈，你一定可以的。” 这种看似友好的关心，信任，实则是一种柔软的push，让developers很有压力，特别是客户方的developer，他们对敏捷文化也很陌生，所以只能遵照了scrum master的意思，加班到晚上十一点也要把卡做完。在估点的时候我也观察到他们这种“敬畏”，以为承诺了点数就必须要在规定时间内做完，害怕自己不能按时完成任务。scrum master应该给团队营造一种“自信、大胆”的环境，而不是让氛围变得紧张。
2. 过分追求“仪式感”
我们团队并没有一个agile coach，所以自然而然每个人都会分担一点这个角色。其实不同TWer 对敏捷也会有不同的认识，因为每个人经历的项目不同，受到的熏陶也不同。当我们面对一群敏捷新同学的时候，如果带好这个队伍呢？当然可以通过公开讨论，一致决定。
在S项目中，一开始我们并不想做单独的敏捷培训，先让子弹飞一会儿，结果问题真的很快就暴露出来了，客户的同事等待他们的BA分配story，而不是pick；客户的同事也不开卡，拿起story就开始干，等等。在迭代开始的第一周，我们意识到必须快速给大家普及一下敏捷的基本概念，所以我用一个小时快速给大家讲了敏捷的核心以及不同成员的分工配合，不同仪式的价值和产出。当然，会议的目的是探讨出属于S团队的敏捷way of working, 也就是做敏捷的定制化。基于第一个月交付压力特别大，所以我们简化了很多会议，省掉了很多仪式，比如story elaboration 和IPM可以合并，retro按需进行，等等。
有些同事会陡然丢出一堆的敏捷实践，敏捷仪式，很多新敏捷团队在形成了敏捷仪式后就以为自己敏捷了，并不关心把别人家的敏捷照搬到自己身上是否合适。其实客户也都是很高素质的群体，不会任由你把宝贵的时间花在这些看不到产出的仪式上，我们时刻都要准备好回答“这件事情对我们的交付有什么价值”。
scrum的易错点是“本地化”，它同敏捷一样，其核心是“适应性”， “响应力”。 scrum的各种实践都应该做好本地化，量体裁衣，基于自身的情况改造各种实践，不然就会流于瀑布的失败-过度关注形式，流程，成为敏捷的奴役，而忽略了对个体，对团队的关注。选用最小、够用的仪式， 让敏捷这颗种子在不同的土壤中开出不同的花朵。
3. SM没有权利控制团队，这个角色担任的是领导者，而不是管理者
在H项目中，同样也是一个多年瀑布经验的新敏捷PM，她几乎在一周之内就把整个团队弄得鸡飞狗跳。她要求BA只关注她分配的工作，不该参与未来需求的讨论；她认为所有角色都应该服从她的安排；她要求所有 team member每天都给她写日报，汇报工作；当团队需要一些物料找到她时，她认为这是项目助理应该做的事情......诸如此类。就事件本身而言，有很多原因，首先她不是一个合格的TWer, 更不是一个合格的scrum master。 这是个很极端的例子，但是我们可以观察一下身边的scrum master， 即使没有犯那么低级的错误，会不会还是想要管理团队，而不是领导，服务团队呢？
4. 不是所有人都要接受敏捷，迁就敏捷。作为一个强管控的公司, H 公司的流程并不是我们一个项目就能够撼动的。在短时间内，我们依然要寻求“局部”的敏捷。
未完待续。。。
网友评论