當我讀到《scrum敏捷軟體開發》關於專案經理的討論時，讓我產生了極大的共鳴，使我不得不放下書來閒扯兩句，一方面抒發自己的感受，另一方面也算是一種反思吧。
我平時一般要同時帶3~5個專案。作為專案經理，我都要花上大部分時間去分析需求，然後將其拆分成小任務。拆分任務時，我會將任務錄入到我自己設計的專案管理程式teamview。在錄入過程中，我會根據自己的經驗，為每個任務設定優先順序和完成該任務所需的時間。接下來，專案成員就可以根據在teamview中任務分配，按部就班地展開開發工作。
這個過程中，看起來和敏捷沾邊的就「優先順序」了。我會同銷售人員或者客戶溝通來確定優先順序，以幫助團隊達成銷售或者客戶的目標。但溝通的時間點是無序的。有時候，會憑自己的經驗，感覺應該同客戶溝通；有時候是自己空閒下來，突然想起有很長時間沒有同客戶溝通了；有時候是不能回答團隊成員提出的需求理解問題，需要向客戶尋求幫助，順便同客戶溝通一下優先順序問題。但如果我的時間安排得很緊，我可能會在較長的時間內都不同客戶溝通優先順序問題。這種無序，沒有辦法最大限度的保證客戶對優先順序的關切能夠順利地反映到當前的開發序列中，從而不能最大限度的保證團隊在朝著客戶期望的方向前進。
另外，任務的拆分同敏捷的「故事點」有些類似，但也是要不得的。
首先，任務分配這件事情是我一手包辦了，我和團隊成員之間仍然是分配與被分配的關係，這和敏捷的自組織相牴觸。其次，我分配出來的任務迫於時間的壓力，欠描述，和敏捷提倡的故事點有距離，通常就一句話或一張。團隊成員要處理這些任務，有時還要和我進行進一步的溝通。當然，這個過程還算有效，畢竟我已經用這種方式成功地完成了數不清，各種規模的專案了。
但我也不得不承認這種方式的弊端。這種方式是填鴨式的，受限於我本人的經驗與見識。我曾經不懂jquery mobile，導致在處理乙個客戶的需求時，要求成員通過自己寫**來實現手機應用上的列表效果。要知道，這在jquery mobile中只是乙個data-role而已。雖然這個專案成功了，但是花費了超出預算的時間。
這種方式最致命的弊端是它剝奪了專案成員展開想象和思考的最佳時機，因為我在分配任務的時候，多少已經限制或暗示了應該怎麼做。其結果是專案成員得不到有效的成長。總之，這是乙個低效的過程。
這是我目前對著敏捷的鏡子照出來的兩個問題。你是否也遇到過類似問題呢？歡迎討論。
敏捷故事點與時間
在scrum培訓中，經常有人問 故事點和時間怎麼對應？忘記了那本書上曾經有個大牛舉了個例子，把系統中最簡單的乙個功能時間作為故事基準點，比如乙個 登入功能，從開始到發布大概需要8小時也就是1個人天作為故事點。於是，在很多公司中預設以此為基準點。在之後的敏捷計畫會議上直接用時間進行估算，甚至乾脆把敏捷...
敏捷開發中故事點和估算的秘密
高質量的估算能夠幫產品負責人優化效率和衝突。因此，精準估算的重要性毋庸置疑。估算並非易事。對軟體開發人員來說，估算堪稱是最難的工作之一。估算必須考慮所有能幫助產品負責人做出影響整個團隊和業務決策的因素。因此，從開發到高管都為它焦頭爛額也不足為奇，但這種做法是錯誤的。敏捷估算並不是什麼性命攸關的大事，...
敏捷讀書之使用者故事 《使用者故事與敏捷方法》解讀
本期分享mike cohn 使用者故事與敏捷方法 精益思想五步 價值，價值流，流動，拉動，盡善盡美。使用者故事是精益思想五步的核心載體。首先，使用者故事是價值載體，是承載使用者價值的基本單元。使用者故事要承載價值，而價值也要承載在使用者故事這種歸一化的載體中。其次，使用者故事是節拍器。故事有節奏的流...