Migarated from here at ‘2012-06-04 17:16:25’.
在工作过程中，我发现有这样的情况：当前的sprint即将结束，scrum master（在我所在的单位该角色由PM担任）在考虑下一个sprint的story改怎么做。他指定了developer A来跟进story X的需求确认并考虑实现思路，并告诉A和team：下个sprint将由A来实现story X的开发工作。
我所知道的scrum实践里，“谁来做什么事情”是由developer自己选择的，而不是由scrum master来指定的。从我的角度理解，这样做的理由如下：
该行为对开发者的不利影响。如果developers在选择task之前，不知道自己将做什么task，则他们会试图了解所有stories的需求和大致的实现方法，客观上让每一个developer对所有的stories都比较了解。相反，如果一个developer知道他将做什么，他就不会花足够的时间去了解其他stories。这样做的结果是：某些developer只了解某些业务逻辑和代码，没有做到“不同developers之前是可以互相代替的”，这样会失去很多敏捷的好处：比如，只有某些人适合修改某些bugs，因为其他人对这部分需求和代码都不够了解；以后再有和改功能相关的stories，一定又是该developer来做；等等。
该行为对scrum planning的不利影响。如果某developer事先知道自己将做什么task而其他developers知道肯定不会做该task，那么在估计sprint planning的story point时，估计出来的story point一定是不准确的，因为所有developers没有就该story的了解达成一致。这样的planning就失去了大部分的意义。
该行为对代码质量的不利影响。当一个story的设计思路只来自于某个人的考虑，而不是团队的集体考量，则很难保证该实现是相对较好的，则该实现产生问题的概率会大大增加。
总之，我认为，“在Sprint开始之前显式或隐式地指定story(task)的owner”是一项坏的实践，不符合scrum的敏捷精神，是和敏捷方法学的原则背道而驰的。