當我讀到《Scrum敏捷軟件開發》關於項目經理的討論時，讓我產生了極大的共鳴，使我不得不放下書來閑扯兩句，一方面抒發自己的感受，另一方面也算是一種反思吧。
我平時一般要同時帶3~5個項目。作為項目經理，我都要花上大部分時間去分析需求，然后將其拆分成小任務。拆分任務時，我會將任務錄入到我自己設計的項目管理程序Teamview。在錄入過程中，我會根據自己的經驗，為每個任務設置優先級和完成該任務所需的時間。接下來，項目成員就可以根據在Teamview中任務分配，按部就班地展開開發工作。
這個過程中，看起來和敏捷沾邊的就“優先級”了。我會同銷售人員或者客戶溝通來確定優先級，以幫助團隊達成銷售或者客戶的目標。但溝通的時間點是無序的。有時候，會憑自己的經驗，感覺應該同客戶溝通；有時候是自己空閑下來，突然想起有很長時間沒有同客戶溝通了；有時候是不能回答團隊成員提出的需求理解問題，需要向客戶尋求幫助，順便同客戶溝通一下優先級問題。但如果我的時間安排得很緊，我可能會在較長的時間內都不同客戶溝通優先級問題。這種無序，沒有辦法最大限度的保證客戶對優先級的關切能夠順利地反映到當前的開發序列中，從而不能最大限度的保證團隊在朝着客戶期望的方向前進。
另外，任務的拆分同敏捷的“故事點”有些類似，但也是要不得的。
首先，任務分配這件事情是我一手包辦了，我和團隊成員之間仍然是分配與被分配的關系，這和敏捷的自組織相抵觸。其次，我分配出來的任務迫於時間的壓力，欠描述，和敏捷提倡的故事點有距離，通常就一句話或一張圖片。團隊成員要處理這些任務，有時還要和我進行進一步的溝通。當然，這個過程還算有效，畢竟我已經用這種方式成功地完成了數不清，各種規模的項目了。
但我也不得不承認這種方式的弊端。這種方式是填鴨式的，受限於我本人的經驗與見識。我曾經不懂JQuery Mobile，導致在處理一個客戶的需求時，要求成員通過自己寫代碼來實現手機應用上的列表效果。要知道，這在JQuery Mobile中只是一個data-role而已。雖然這個項目成功了，但是花費了超出預算的時間。
這種方式最致命的弊端是它剝奪了項目成員展開想象和思考的最佳時機，因為我在分配任務的時候，多少已經限制或暗示了應該怎么做。其結果是項目成員得不到有效的成長。總之，這是一個低效的過程。
這是我目前對着敏捷的鏡子照出來的兩個問題。你是否也遇到過類似問題呢？歡迎討論。