敏捷管理初期出現的常見問題

一個成功的敏捷開發項目有可能將瀑布式開發組織由緩慢的、龐大的發布轉變為快速的迭代式循環發布。一旦組織已經牢牢掌握敏捷基礎知識,那麼該組織就可以從原來的年發布周期改為周發布周期,這種轉變非比尋常。

以50個快速發布取代一個大型發布有幾個優點。通過早期發布獲得重要的數據特性,開發團隊能夠更交付價值數據。當判斷出需求是錯誤或者誤解時,他們也能夠迅速改變方向,而不是沿著錯誤的方向繼續工作。這些優點是很重要的,要實現這些功能並不容易。

當他們離開一個既定的開發項目,如由瀑布式方法轉向更多的使用敏捷方法時,許多項目經理被敏捷方法的基礎知識所困惑。並不是你自己有這樣的困惑。這裡我們已經整理出來一些敏捷開發基礎階段會出現的常見問題。

誰促進敏捷計劃、設計及需求收集?

根據行業分析師兼顧問Mary Gorman所說,涉及引領敏捷組織的人可以是任何一個人。如果組織處在一個Scrum環境中,那麼這個領導者可以是敏捷教練。也可以是產品冠軍,他來自業務部門並且運用嫻熟的業務知識將不同團隊和不同微焦點聚集在一起,一同為綜合業務、顧客及技術需求服務。

三個實例中沒有一個對於領導角色的選擇是顯而易見的。Gorman說,為了一個特定的產品而開發新平台,可能不僅需要技術上的引領,而且也需要推出一款新產品或者添加一種可以連接到業務領域產品冠軍的新性能。儘管如此,這個領導者可能是聲稱沒有足夠信息的QA人員,而測試人員卻需要獲得更多細節。

敏捷管理方面的努力需要團隊整體的付出,可能不需要任何一個領導者。Gorman說:「我們需要一個框架,團隊中的每個人能夠都能很好的參與其中、引導成員進行對話、提出更有針對性的問題或提供獨特的見解。」

引入敏捷管理意味著要扔掉以前的文檔嗎?

敏捷宣言的四大原則之一是要評估全面文檔層面的工作軟體。然而,記住如下四條原則相當重要。「這就是,如果項目的價值在右邊,那麼我們評估項目左邊的價值更多一些。」許多剛接觸敏捷管理的人(可能是有豐富經驗的專業人士)誤認為敏捷方法中要避免使用全面的文檔。根據EBG諮詢公司的創始人兼原理分析師Ellen Gottesdiener所說,這根本不是事實。

Gottesdiener認為,不要詢問敏捷團隊是否應該生產軟體文檔(因為答案是肯定的),相反,項目經理要詢問的是「對於項目的運行哪類文檔是最有價值的,及什麼時候生產是最恰當的。」團隊應該區分產品文檔——「對於銷售、維修和使用產品有很高價值的文檔;與流程文檔——「探索和交付期間所使用的進度或者交易信息」。

如何控制敏捷項目中的描述點?

故事點(story point)的使用是衡量長期、可能會出現很多變化的敏捷項目長度的最基礎方法。當開發人員進入一個新項目——尤其是如果他們之前從未接觸過這個項目——對於團隊來說,估計項目每個階段多久能完成是非常困難的事。另一方面,相對於其他要求來說,衡量滿足一個需求有多複雜就很容易了。一般而言,一旦團隊在新項目中具備了一些經驗,那麼其複雜性就會很好的反映出實際交付時間。項目初期,故事點方法可以使那些不確定的問題固化並可測量,因此,未來不確定的問題可以更精確,也可以衡量團隊的進程。

儘管他們也使用過其他敏捷方法,但是,描述點方法對於Scrum過程特別有用。敏捷及敏捷教練認證專家Yvette Francino解釋說,規劃項目時使用故事點方法是複雜的,因此也很難估計。每次迭代的尾聲,團隊都將會完成一定數量的故事點。這個數量就是團隊的速度,因為這可以衡量團隊運行速度如何。

起初,這個速度可能會有點波動,但是,當團隊成員及項目經理更加理解故事點對於特定項目的意義時,這個速度就會達到平衡,並且變得更加穩定。Francino說,故事點系統最初可能要做一次WAG評估,但是當需求細節發生變化,從一種迭代狀態轉向另一種迭代狀態時,那樣做總比陷入決定具體時間表的困境要好得多。

當敏捷項目遇到瓶頸時,項目經理應該做些什麼?

儘管我們付出了最大的努力,但是即使是敏捷項目的專業人士(+本站微信networkworldweixin),在項目的運行中也會遇到瓶頸。不知怎麼的項目就會被負面因素所影響。但是,不必擔心。不會出現一直佔用工時或者延緩開發周期的現象。如果項目經理能以敏銳的目光及清晰的思路去發現項目所存在的問題,那麼解決項目問題,並使項目繼續運行就不會那麼困難。

產品管理諮詢專家Scott Sehlhorst解釋了根源分析如何幫助延遲的敏捷項目解除停滯現象。他解釋說,如果項目停滯,就意味著項目團隊不生產任何東西或者生產出來的產品也是錯誤的。如果團隊能夠穩定的生產產品,但是卻沒有什麼進步,Sehlhorst說是時候檢查一下關鍵性指標了(KPI)。如果團隊朝著錯誤的目標發展,那麼他們最終沒法生產出正確的產品。Sehlhorst告訴我們「許多團隊都在衡量什麼指標容易估量,而不是那些重要的指標要估量」 ,這是一個常見的缺陷。

一個人如何成功地管理多個敏捷項目團隊?

當項目經理帶領敏捷試點團隊成功地加入項目組織時,他們經常帶領多個團隊,因此組織可以看到更多成功的敏捷。但是帶領敏捷團隊是非常費時的工作,橫向擴展多個團隊可能非常困難。不過,這可以做到。經驗豐富的測試人員及團隊領導者Amy Reichert解釋說,當在多個團隊之間進行細分時,成功管理時間的秘訣就是消除一切外界干擾。

如果一個敏捷教練要同時帶領兩個或者兩個以上的團隊,Reichert建議,她必須集中精力關注來自敏捷團內部的需求。另外,即使是能改善敏捷教練小組的項目,也需要對她領導的團隊投入時間和注意力。也許有人會說,分些精力干其他的事情應該是可以的,但是Reichert說任何分心都會造成更多的干擾。自身的每一個干擾並不會影響敏捷教練的能力,但是像這樣的20個干擾堆積起來就會破壞其有效地支持多個團隊的能力。

文章來源:敏捷視界

推薦閱讀:

如何能讓開發效率快10x倍?
如何看待重型敏捷管理框架?
敏捷實際是迭代的瀑布模型的變種,這種觀點對嗎?
如何看待 PMI 推出的敏捷認證 PMI-ACP?

TAG:敏捷开发 | 敏捷项目管理 | 敏捷 |