Tag: #CA Technologies

正在『跑敏捷』的你是不是『真敏捷』?

正在『跑敏捷』的你是不是『真敏捷』? 時至今天,相信大家都已經聽說過「敏捷」這個詞語。閣下的公司甚至很可能已特設敏捷團隊。像大多數軟件驅動的公司一樣,你的公司希望透過從事敏捷(doing agile)的開發協助解決重大的業務和組織結構問題:諸如各種未兌現的承諾、不盡如人意的品質、缺乏可見性,成本太高、協作性差,以至創新進度緩慢等等。但很可惜,有許多公司發現他們並沒有從敏捷投資中得到預期的結果。事實上,『部署敏捷』或者『跑敏捷』,尤其是在團隊層面,與『變敏捷』即成為一個敏捷企業完全是兩回事。坦白來講,僅僅為了單純部署敏捷開發並沒有多少實際價值。   其實這並非敏捷團隊的錯。公司策略與執行不配合,導致團隊經常誤入歧途是見慣不怪的事情。這些公司的一般在組織架構中存在巨大的「脫節」。那些知道如何彌補這一缺脫節的公司可以正確進行投資,並以正確的方式組建。但更重要的是,他們可以定期以較低成本改變正在構建的產品,以緊跟市場需求,在開發過程中創造最大價值。這就是真正要成為敏捷企業,必須在規模上實現的精益/敏捷承諾。但要如何實現呢?   對Scrum的迷惘 在提供企業諮詢時,我通常會提出以下三個問題:1)你的團隊結構怎樣?2)團隊的工作流程怎樣?3)你會怎樣計劃? 典型答案都會關注團隊數量、角色、技術、流程、估算故事價值、sprints長度等等。我們總能改善團隊層面的行為準則,但那又如何?每家公司都可以有Scrum團隊,而絕對不可以迷信Scrum框架會解決公司所面臨的重大問題。事實上,如果你所做的一切只是依賴這些單獨的Scrum團隊,其結果可能比瀑布開發模式下更糟糕。   就讓我們潛心思考一下。如果你的敏捷團隊的成員認為用瀑布開發模式更好。其中可能原因就是:在瀑布模式中,在我們對工作所知甚少時,我們預先作出決策。經驗告訴我們項目將會推遲且超出預算,但我們會知道構建的內容,因為範圍是固定的。在此,我們將其稱之為「自然法則下的Scrum」(Feral Scrum) 的優化團隊進行比較,這些團隊能夠快速交付軟件。他們在Scrum模式下埋頭做著自己的工作。有時,他們與組織的唯一聯繫就是唯一一個跟其他模式共享的產品負責人。他們投入許多資源進行開發,但我們不知道他們要交付的產品是否就是我們目前真正所需要的。   首要問題 我們先不談出色的團隊執行未能解決我們的業務問題,讓我們來看一下如何計劃工作和安排人員。這時候,我們就要談到項目章程、業務案例、資金和資源批核。我們會討論他們計劃的頻度、參與人員以及需要花費的時間和精力。   一位客戶曾告訴我他們的年度計劃獲批准了商業智能團隊的71個項目,並且該71個項目目前全部仍處於活躍狀態,「因為管理者需要看到整個系統進展。」其中有一半的項目是從上一年度順延下來的。更致命的是,他們告訴我預期今年內不會有一個項目能夠完工!   透過實施看板方案,我們能夠解決這個仍在進行的工作問題。按照對業務的價值對項目劃分優先等級,列出項目必須完成的步驟,以及限制「正在進行中」的工作量。只有在當前的工作完成後,團隊才能接新的工作。一轉眼,項目交付變成可預測了,我們只構建最具有業務價值的部分。我們已經解決了我們的問題了,對嗎?答案當然是否定的。   成為敏捷企業 市場每天千變萬化。新的客戶需求層出不窮。一家公司想要生存有賴於能夠定期、以較低的成本改變項目組合,以跟得上新的業務變化。為縮短企業選擇最佳方案的時間,並不斷交付予客戶,要求我們解決策略與團隊工作之間的脫節問題。   答案就是如何細分舉措,讓團隊與不斷變化的優先重點保持一致、自動化進度報告和選擇能夠推動持續改善的指標。而這個的核心就在於季度小組計劃活動Big Room Planning,它讓團隊和領導共同構建每個人可以交付的共享、可實現的發布計劃。由現在開始,每個團隊的工作與策略變化將會保持一致,Scrum團隊可以「查看」以了解他們正在建模背後依據的基本原理,以及他們的工作如何推動公司策略的實施。但是,我們還需要具備另外一個條件。   培養企業的敏捷文化 一個敏捷企業必須深諳將策略、能力及文化結合起來,才能實現真正的機構轉變。文化產生於人們的互動方式,因此我們尋求能夠促進不斷學習和改進的互動方式,回顧和良好的績效指標能派上用場。   最後,我們不應只是『做敏捷』,更應真正『變敏捷』(being Agile)。我們已具備所有解決我們的重大問題所需要的一切條件:包括出色的團隊執行、按價值劃分的優先等級、從策略到執行的連接,以及滿足我們協調、溝通和改進文化需要的平台。我們應專注於為客戶創優增值,而非只是創建過程。我們已經彌補組織中的缺口,現在我們可以積極引導我們的公司響應市場變化,真正成為一個敏捷企業。 撰文:CA Technologies高級技術總監Doug Dockery