頭大？

頭大瞬間

個人同時參與多個項目開發(fā)（以下簡稱一人多項目）在實際生產(chǎn)中是比較常見的，由于員工參與多個項目，管理工作很難進行。在拜訪企業(yè)過程中，有家企業(yè)針對這種情況提出這樣一個問題：“我們企業(yè)規(guī)模比較小，每個開發(fā)人員都是同時做兩三個項目，在敏捷中應該如何管理，有沒有辦法看到每個人當前的工作量”，一個人同時做多個項目應該如何管理呢？

問題分析

在企業(yè)中一個人做多個項目有很多原因，比如：

企業(yè)沒有意識到一人多項目的弊端

傳統(tǒng)研發(fā)模式?jīng)]有迭代的概念，項目交付周期通常很長，研發(fā)人員在保證項目按時交付的前提下，可以在多個項目之間進行切換。企業(yè)做敏捷轉型，把重心放在敏捷的日常實踐上，比如Scrum的“計劃會議”，“每日站會”等，忽略了“敏捷不提倡一人多項目”這種隱含的約束，在團隊配置上依然采用之前傳統(tǒng)研發(fā)模式的配置方式。

企業(yè)簽的項目規(guī)模小，數(shù)量多

有的企業(yè)意識到一人多項目的弊端，但是企業(yè)簽的項目規(guī)模很?。赡芎贤瑤兹f塊錢，兩三周就開發(fā)完成），項目數(shù)量多，如果每個項目都組建一個專門的開發(fā)團隊，那必然需要很高的成本，所以出于成本和項目性質(zhì)考慮，公司不得不讓一個人同時開發(fā)多個項目，這種情況是可以理解的。

稀有資源不夠分配

還有一種原因會導致一個人跨越多個項目。這種情況通常發(fā)生在一些稀缺資源身上，比如軟件架構師，產(chǎn)生問題的原因一方面是架構師薪水比較高，每個項目配備一個架構師浪費成本；另一方面，架構師的能力特征適合為多個項目服務。

解決措施

針對沒有意識到一人多項目弊端的企業(yè)

敏捷并不提倡一人多項目，而且大量數(shù)據(jù)表明：敏捷中一人多項目會降低生產(chǎn)力。一人多項目有很多弊端：

1.故事優(yōu)先級被打亂

敏捷開發(fā)靠價值驅動，團隊應優(yōu)先完成優(yōu)先級高的故事。如果一人多項目，將會打亂各項目中故事的優(yōu)先級。

2.難以估算速率

由于各項目投入精力不同，很難估算個人速率。領導層也無法很好的監(jiān)控團隊進度，無法合理安排工作。

3.難以保證全員參與重要會議

一人多項目的情況下，員工缺席會議在所難免。不能全員參與的會議會變成一種形式，起不到會議該有的作用。

一人多項目的弊端還有很多，在此不一一列舉。所以，沒有意識到那些弊端的企業(yè)較解決如何管理的問題，優(yōu)先應改善這種情況，并在以后項目開發(fā)中避免一人多項目再次發(fā)生。

改善的過程比較像大規(guī)模的敏捷轉型。項目經(jīng)理或其他領導重新規(guī)劃項目配置，進行服務拆分。規(guī)劃時應保證每個服務的資源是足夠的，避免后續(xù)由于人力不足引發(fā)其他團隊來“救火”的情況，重新造成一人多項目。研發(fā)人員按新的配置交接工作，交接工作完成后就專注于一個項目。

針對小項目很多的企業(yè)

如果公司的項目規(guī)模小、數(shù)量多，必須有人跨項目開發(fā)，這種情況應優(yōu)先考慮讓一個團隊開發(fā)多個項目。

一個團隊開發(fā)多個項目的意思是A團隊的每個員工都同時負責X，Y項目。最好在組織內(nèi)部將X，Y項目當成同一個項目進行管理，這樣做X，Y兩個項目可以共享一個產(chǎn)品待辦列表（Product?Backlog ），沖刺待辦列表（Sprint?Backlog ），燃盡圖等；相關領導可以在這個大項目中，看到每個人當前的工作量以及詳細的工作信息。

這樣做還有其他的好處：團隊速率相比之前更好估算，同時各種會議的時間也變得容易安排；

接下來我們用DevCloud?演示下如何應對這種情況，首先在DevCloud?中創(chuàng)建一個Scrum項目，

在項目的“需求規(guī)劃”功能中，創(chuàng)建兩個Epic，分別代表X項目和Y項目，然后在每個Epic下面規(guī)劃各自的工作項。

在“Backlog”中，可以通過合并后的產(chǎn)品待辦列表，估算團隊速率，便于后面迭代故事投放。

如果項目因某些原因，無法變更項目配置應該怎么辦呢？

這種情況使用敏捷進行管理是有困難的，原因之前提到過，我們只能退而求其次，找一個相對好的管理方法。項目經(jīng)理統(tǒng)計完員工在自己項目的工作量后，和其他項目的統(tǒng)計結果做一次匯總，推算出員工當前的總工作量，匯報給管理層。

DevCloud提供“管理看板”功能，在“管理看板”中可以看到員工在其參與的所有項目中的投入，便于管理層在一個人同時參與多個項目開發(fā)的情況下，了解每個員工當前的工作量。

針對不夠分配的稀有資源

從組織層面看，類似于架構師這種稀有資源，同時為多個項目服務通常不會影響項目發(fā)展。

由于稀缺資源數(shù)量少，工作內(nèi)容特殊，所以想對稀缺資源進行管理的話，可以采取匯報的形式，比如發(fā)日報，周報；也可以通過上面提到的“管理看板”功能，查看稀缺資源在每個項目的詳細工作。

總結

一人多項目不符合Scrum框架的“專注”價值觀，敏捷也不提倡跨項目開發(fā)，原因上文已經(jīng)分析；如果必須一人多項目，建議讓一個團隊同時開發(fā)多個項目，減少資源浪費。

參考附錄

Mike Cohn:敏捷軟件開發(fā)實踐——估算與計劃. 北京：清華大學出版社

Kenneth S.Rubin:Scrum精髓. 北京：清華大學出版社

敏捷開發(fā)

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。