項目管理有很多理論，并且相關內容非常豐富，例如經典的項目管理的教材《項目管理：計劃、進度和控制的系統方法》，字數達到了100萬字。

但是從源頭來說，經典項目管理理論都是源自于對生產項目的過程中需要的管理的總結。對于一個大型硬件設備的生產，需要組織龐大的供應鏈體系、工廠部門，所以需要合理的理論做指導。但是這種理論應用于互聯網環境時，由于本身出發點要解決的問題的場景的巨大不同，變得并不是很適配。

項目管理，是計劃、進度和控制的系統方法，也就是說，是一種方法論。所有的方法都是為了解決問題的，總體上來概括，可以認為項目管理的目的是在明確的目標下，讓資源的利用率最高，成本最低。

對于一般的互聯網團隊來說，沒有傳統意義上的資源的管理了（連機器的管理都是云服務化），那需要控制的，基本就是人。所以，很多內部團隊，不配置，也不需要配置項目經理，項目推進的工作就由產品經理順手干了。

但是問題在于，人力這個東西，尤其是智力型人力這個東西，伸縮空間極其之大。我曾經跟的一個項目，開發給排出了96人月的排期。然而最終差不多是6個人干了三個月完成的一期交付。

同樣的，還遇到過需求評審完了，在舊的功能上迭代，一個前端下拉框的修改，前端工程師給出0.5人日的排期。

不合理的排期有可能是開發本人的原因，大概率其實往往是團隊管理的原因。一個管理不善的組織，會讓開發來回的交叉做事情，經歷過一兩次吃虧后，再進行需求排期時，他就會留出非常非常大的余量。這樣，如果有交叉的工作了，還能應付，不至于加班到半夜，要是沒來交叉的工作，還能輕輕松松早點下班或者在公司磨磨洋工。這種情況，最終導致整體組織效率非常低下，而員工也不滿意。因為要么一堆活加班到半夜，要么閑著磨洋工。

以人的特新來說，對于任何事情，最怕的是不可控，對于不可控人心里是會恐懼的。

消除多人協作的混亂的一個很好的方法，就是節奏感。就好比交響樂、那么多人每個人都在獨立演奏，但是指揮帶來的節奏讓幾十號人能夠有條不紊的進行自己的演奏，每個人都清晰的知道自己什么時候該做什么，并且相信其他人也會按時完成自己的事情。從而達到整體的清晰明暢。

什么是節奏感呢？

音樂的節奏感的最直接的提現就是節拍器，固定時間打一個拍子。工作也可以有這種節奏感，就是固定時間周期，一個節點。

節奏感的不同，是瀑布式項目管理和敏捷式的一個重大區別。

瀑布式和敏捷式

瀑布式項目管理的典型表象特征：

1、產品經理產出需求文檔
2、設計、開發、測試評審
3、設計、開發、測試工作量評估，一般是基于功能產出工時表格。
4、設計師基于設計的工作量評估，預估交付設計稿的時間，然后在規定時間出設計稿，評審
5、開發啟動開發、基于工時評估，確定提測日期
6、提測后，測試基于工時評估定完成測試日期。
7、產品和項目驗收、確定上線日期、上線。

這種方式的項目管理，每個時間點是以及與每個角色的人對于自己工作量的評估來決定的。所以，每個節點的耗時可長可短，由相關角色或者角色的主管來確定。每個節點的時間是隨機的，是依賴前一個人的工作的。

敏捷式的項目管理的一些表現：

1.日會、周會
2.設定固定迭代周期
3.大迭代里套小迭代
舉個例子，以周為周期迭代，工作流程如下圖：

按周迭代的敏捷項目管理

第一周，產品設計和 UI設計，同時拆分工作。

第二周，產品設計下一模塊（如果需要），開發開始開發產品第一周設計的產品（基于優先級）并提測。

第三周，產品繼續下一模塊設計（如果需要），開發進行下一模塊設計，測試啟動第一模塊測試。

這里的周期設定為周，實際可以給予團隊規模、項目特征，設定為雙周或者月。例如，微信團隊是多個部門多個團隊要協作開發，他們設定的迭代周期為月。每個月的最后一周，項目經理組織多個部門的產品經理共同制定下個月的開發計劃。

對于敏捷式執行順利的團隊，每個角色，對于每周做的事情，交付的內容都有明確的目標。對于工作量的預估，不再是基于一個事要做多久，改為一周能做多少事情。為了配合整體節奏，整個團隊就要盡可能保持相同步驟、相同節奏。帶來的好處是顯而易見的：

1.不再完全依賴開發主管對于工作量的長周期評估——這種評估很大程度上并不是很靠譜。
2.不再產生由于開發資源緊缺導致的來回切換工作的并行開發——最起碼這一周，這個人就是這個事情。
3.團隊配合更加默契，這種項目推進方式，一般要求相對固定的產品、開發、測試人員。團隊之間在幾次迭代之后，變得更加默契，效率更高。
4.團隊成員焦慮感減少。每個人每周需要做什么、交付什么是很明確的、可預期的。不確定感減少。產品不需要每次需求再跑去申請資源，開發不用擔心來回插入工作、測試也不用來對插入工作。
5.綜上，帶來的是整體效率的提高，水分的減少。

習慣瀑布式項目推進方式的團隊或者個人，切換到上面迭代的方是時會有巨大的不適應。包括提出巨多關于實現上述項目推進方案的難點或者可行性的問題。典型的包括：

不可能工作都剛好拆到一周做完；
不可能給你固定的人；
要和其他團隊合作，經常有插入需求。

還有一些阻力來自于，修改項目推進方式，可能會讓某些成員覺得自己的話語權降低（比如之前主要工作是決定人力分配而很少寫代碼的開發主管），進而抵制。

對于習慣瀑布式的人來說，切換到敏捷式的另一個阻力在于，他會覺得工作被打散了，目標不夠清晰。

關于目標的問題，其實是另一個問題，不管是敏捷式還是瀑布式，都是在目標清晰的情況下組織人力工作的方式。也就是說，目標清晰，是進行項目開發前需要完成的工作。敏捷式不是產品經理偷懶的理由。

目標是會變動的，但是項目推進過程中目標應該是清晰的。敏捷式帶來的另一個好處是，應對目標的變動會更加及時。

即使推進團隊接受敏捷式的項目方式，由于人們巨大的行為慣性，依然會習慣的拿一個需求，問下排期，定下哪天到哪天開發。由于這種思維習慣，就讓敏捷的節奏特征被打破了。所以要推進團隊進行敏捷式的項目推進，要沒完沒了重復強化一種思維，就是評估工作不在是工作要做多長時間，而是固定時間內能做多少工作。當思維方式從明確工作估時間轉變成了固定時間塞工作，你就掌握了敏捷式的精髓了。

總結一下，如果團隊遇到下面這些問題，可以考慮改為使用敏捷式開發：

1.各種緊急需求來回插入，項目總是延期
2.產品經理抱怨開發評估時間亂估
3.定好的開發總被挪走去支援緊急需求
4.產品經理需求變來變去，經常開發到一半前面廢掉了
5.需求方經常冒出來緊急需求，應付困難。
按周迭代的敏捷式，執行的要點：
1.給與所有需求方一個預期，提任何需求，最少提前兩周，也就是需求本周提，最快下周開發，最快下下周上線。
2.產品經理能給出大致的總體目標，需求詳情可以分階段產出。
3.產出的需求詳情能夠基于邏輯和依賴關系進行分層和分塊，合理標注優先級
4.日會同步最新進展和問題
5.周會，總結本周開發進展，開發內容提測，安排下周開發的工作，切記是按照下周的時長塞入具體工作，不需要開發評估具體工期，就問這些工作，下周能完成多少。總結測試進展，將能夠上線的模塊整合上線，安排下周測試任務。
6.月度總結。

總結

以上是生活随笔為你收集整理的一般一个前端项目完成需要多久_一种按周迭代的敏捷式项目管理方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。