当我读到《Scrum敏捷软件开发》关于项目经理的讨论时，让我产生了极大的共鸣，使我不得不放下书来闲扯两句，一方面抒发自己的感受，另一方面也算是一种反思吧。
我平时一般要同时带3~5个项目。作为项目经理，我都要花上大部分时间去分析需求，然后将其拆分成小任务。拆分任务时，我会将任务录入到我自己设计的项目管理程序Teamview。在录入过程中，我会根据自己的经验，为每个任务设置优先级和完成该任务所需的时间。接下来，项目成员就可以根据在Teamview中任务分配，按部就班地展开开发工作。
这个过程中，看起来和敏捷沾边的就“优先级”了。我会同销售人员或者客户沟通来确定优先级，以帮助团队达成销售或者客户的目标。但沟通的时间点是无序的。有时候，会凭自己的经验，感觉应该同客户沟通；有时候是自己空闲下来，突然想起有很长时间没有同客户沟通了；有时候是不能回答团队成员提出的需求理解问题，需要向客户寻求帮助，顺便同客户沟通一下优先级问题。但如果我的时间安排得很紧，我可能会在较长的时间内都不同客户沟通优先级问题。这种无序，没有办法最大限度的保证客户对优先级的关切能够顺利地反映到当前的开发序列中，从而不能最大限度的保证团队在朝着客户期望的方向前进。
另外，任务的拆分同敏捷的“故事点”有些类似，但也是要不得的。
首先，任务分配这件事情是我一手包办了，我和团队成员之间仍然是分配与被分配的关系，这和敏捷的自组织相抵触。其次，我分配出来的任务迫于时间的压力，欠描述，和敏捷提倡的故事点有距离，通常就一句话或一张图片。团队成员要处理这些任务，有时还要和我进行进一步的沟通。当然，这个过程还算有效，毕竟我已经用这种方式成功地完成了数不清，各种规模的项目了。
但我也不得不承认这种方式的弊端。这种方式是填鸭式的，受限于我本人的经验与见识。我曾经不懂JQuery Mobile，导致在处理一个客户的需求时，要求成员通过自己写代码来实现手机应用上的列表效果。要知道，这在JQuery Mobile中只是一个data-role而已。虽然这个项目成功了，但是花费了超出预算的时间。
这种方式最致命的弊端是它剥夺了项目成员展开想象和思考的最佳时机，因为我在分配任务的时候，多少已经限制或暗示了应该怎么做。其结果是项目成员得不到有效的成长。总之，这是一个低效的过程。