【IT168 分析评论】

    Scrum角色的职责思考：

    总体上，三个角色是一个团队，通过沟通、演示等共同完成目标。但在具体实施中，各有偏重：

    Product Owner：负责项目的ROI，具体的措施是和Stakeholder沟通，建立Vision以获得Invest，确认Product Backlog，Product release，并确定每一个sprint的优先级。偏向于商务；

    Team Member：负责项目的实现，具体的措施是制定Sprint Planning，通过Self-managing完成commitment。偏向于技术；

    Scrum__ master：负责项目的成功提交，具体的措施是帮助PO选择更有价值的Product Backlog，帮助团队将Backlog转变为Functionality，保证Scrum的过程实践（例如保证团队在Sprint过程中不受外部干扰，解决团队遇到的问题等）。偏向于协调。

    在国内项目的实践中，发现一些不同之处，例如：

    公司会有PO这样的角色，但真正的PO是老板。很多时候老板会越过“PO”直接给团队发出需求。中国的“Damand-and-control”的观念比较强，可以和老板沟通，但在sprint内完全不受外部干扰的这种理想待遇很难保证。 -:)

    Scrum在中国的实施要适应中国的特色（文化不同，资源不同（10年以上的程序员还有几个在一线？）等等）。理解Agile/Scrum背后的哲学，理解中国的特色，在实践中找到之间的结合点，是我目前一直在做的事情。

    还有一点体会：

    Team、Scrum__ master如果要和PO讨论Product Backlog的优先级，Scrum__ master首先要先了解Project的Vision，Backlog是为vision服务的。同时Scrum__ master必须和Team共享这个Vision. Project Vision是用户买单的动机，product vision是公司为团队投资的动机。Backlog，sprint，team等存在的价值都是因为有了Vision。所以，所有讨论的出发点是如何更快、更好实现Vision。这是PO、Team、SM讨论公共的平台，只是大家的侧重点不一样而已。

    总结一些Scrum理论中经常遇到的问题和自己的心得：

    1. 每日的daily meeting，SM询问成员昨天的工作完成情况，然后告诉各位今天的任务，最后问大家是否有issues。如果从理论上讲，这样的问题是：SM没有理解SM的职责和PM的区别，SM更加是一个Lerader/coach，而不是一个Manager。同时Team也没有Self-organizing的感觉，committment是对SM布置任务的回应，并不是成员对项目的承诺。但在国内项目的实际操作中，在Scrum的应用初期可能就是这么做，一方面是SM更多的有传统PM的背景，惯性使然；另一方面并不是所有的成员都是“Pig”，有相当比例的成员只是“chicken”，完全按照self－organizing来管理团队，收效并不好。按照self－organizing管理团队的前提是：保证Team成员95%以上都是“pig”。如何做？下次再专门整理一下思路。

    2. 作为Scrum___ master，如何帮助team完成backlog？有一个例子：如果团队遇到了技术问题无法解决，如何？作为SM，可以做：a)参与进行技术讨论（如果你有技术背景）；b)寻找外部资源帮助，提供解决方案，无论是公司的其他部门，还是外部的咨询公司；c)将此模块外包；d)考虑市场上的成熟产品，不要自己开发。SM可能不需要进入到细节，但需要提供尽可能多的思路来帮助team找到最好的解决方案。

    3.如果遇到对公司更有价值的机会，完全可以临时中断正在进行的Sprint，重新开始新的Sprint，根据新的优先级选择Backlog，可以适应新的机会。这是现实的。为了让临时中断的Sprint对项目的影响最小，我现在的做法是将Sprint中的backlog中的故事（功能）one by one或者group by group的完成，而不是所有的features同时并发完成。