读《移山之道》五问题

1、 VS里的TASK为什么没有deadline这个属性？VS里的TASK只是开发任务吗？

a.      使用TFS之前，一直误以为TASK是有deadline这个属性的，因为这样才能方便安排各项具有依赖关系的任务关系，也能更合理的安排各个开发人员的时间和工作，所以在最初撰写backlog时都是这样安排的，可是使用TFS后，发现task压根没有这个属性，为什么呢？经过专业PM老大CHERRY的批评指教并翻阅《移山》，才发现原来在敏捷开发和TFS里，backlog并不是一个所有人的calender，安排到没人每天做什么，而只是告诉大家需要做什么，以及所有任务之间的相互依赖关系，至于每天做什么，什么时候做完，由开发人员自己最优化。

b.      看到《移山》介绍TASK分配的范例时发现不仅仅只有对应开发feature的task，也有一些分配文档撰写工作等的task，和我之前的概念不一样，查找后发现，事实上task可以细分为deployment, development, documentation等各个细节，对应一个团队项目的各种所需工作类型，也就是说，task是设计给团队所有成员用的，而不是仅仅设计给开发人员用的。

 

2、 《移山》里并没有提到issue这个work item，那么，它是什么呢？

《移山》之中确实没有issue，而VS2010里是有的，原因也许是移山默认的VS版本是2005？但是我在里面找到了有些类似的条目risk。但前者不仅包括预测的风险，也包括也已遇到的问题。在我们OMG队已经开展了的Iteration1工作中，我忽然发现issue其实是很有用的东西，所谓敏捷开发，最难处理的应该就是应对各种突然出现的问题，而如果做好风险估计，做好问题备案，则会方便很多。

3、 所谓敏捷开发，行进中遇到问题和修改的需求，究竟怎么安排呢？

读罢《移山》，仍旧对“敏捷”的概念心存疑惑，再加上近日团队项目碰到的一些问题，对怎么让团队更“敏捷”很关心，一下是一些自己的想法。1、虽然敏捷是项目推进过程中的表现，但事实上项目准备对最终效果影响很大，包括最初的场景、用户设想，产品草案的交互设计，还有backlog分配时的仔细把握和对风险、问题的预估，都非常重要；2、项目推进过程中，遇到问题要及时互相通气，团队成员最好能时刻保持对产品远景和设想的一致，而PM应当承担起沟通和更新文档的责任；3、关于修改backlog，最好不要擅自作十分巨大的改动，即使有，也应该先完成已有的设计，完成之后再说。

4、 各种工作项细节，是由PM来设计和录入好，还是只由PM分配，各成员各自填写细节好呢？

《移山》里貌似并没有细节到这个地步，结合经验教训以及老大教导，我觉得这里面其实有个鱼和熊掌的问题，一方面，PM对团队成员的了解终究是有限的，不可能也不应该规划好每个人的工作，另一方面，各个成员对产品的整体影响和各个任务的相互关系的了解又是有限的，各自为战会很乱。所以，比较理想的方式，我以为是由PM来规划各个大的场景、用户、特征以及Task，做好详细介绍，并清晰地录入这些item间的相互关系，至于task的估计时间等细节，则由负责的开发人员自己决定。

5、 《移山》之类的教学书籍，怎么阅读方式更有效？

实践表明，直接光看书效果是不大的，必须learning by doing，寓学于干，看了书的知识，只有马上通过工程实践尝试过，才有直观深刻的印象，才能发现问题和优点。所以，我觉得我们边上课边做项目的课程安排是很合理的。

转载于:https://www.cnblogs.com/OMG-Team/archive/2011/10/10/2205233.html