奇葩說之Scrum Master 話“敏捷”


​話說很多很多年以前,軟件開發都是以“年”來計算的,需求3個月,設計三個月,開發一年,測試半年,改bug半年,上線之後發現需求沒做對,剛開發的需求就已經歐藍德了。


奇葩說之Scrum Master 話“敏捷”


這個時候,敏捷開發(Agile)就應運而生了,它是由一位聰明”絕頂”的美國大叔Martin Fowler提出來的。區別於瀑布型開發方式,敏捷開發並不是追求前期的盡善盡美,而是力求在較短的週期內開發出產品的核心功能,儘早發佈可用版本,在後續的生產週期中根據需求不斷地迭代,升級和完善產品。

那麼瀑布和敏捷,具體有啥不一樣呢

瀑布模型的開發過程是有固定順序的,並且每一階段的的輸入是由上一階段的輸出得來,也就意味著之前的工作沒有完成,是不能夠繼續進行下一階段開發的。因此,應用瀑布模型思想進行開發,雖然比較穩定,而且需求明確,但是其耗時長、任務順序固定、越往後越難糾錯、不能應對需求變化。另外,由於在開發過程中缺少週期性的產品校驗,驗收交付的成果往往與前期的需求相差甚遠。


奇葩說之Scrum Master 話“敏捷”

在敏捷軟件開發中,測試是與編程在相同的迭代完成的,強調短期交付和驗證。每完成一個迭代即產生一個可交付的產品,即便這個產品相對於上一個迭代只多了一小部分的功能增量,用戶仍然可以使用這些新的軟件進行價值驗證,並依據驗證判斷軟件的未來。敏捷不是方法論,不是開發框架或者過程,而是一套價值觀,它要求團隊關注最新情況,不斷調整自己的計劃滿足當前的業務目標,做價值驅動的交付。


瀑布開發的方法只在最後時間交付,此方法使得風險逐漸積累和攀升,在交付時期達到頂峰。若相關方滿意,則功成名就;若相關方不滿意,則前功盡棄。而敏捷開發方法更注重需求的理解和改變,他在開發的過程中不斷地修正對需求的理解,檢查需求的正確性,使得風險逐層降低。


奇葩說之Scrum Master 話“敏捷”

如何實踐敏捷開發方法?!?

敏捷的實踐方法有很多,SCRUM, XP(極限編程),kanban, 等等。今天我們將結合微策略的管理體系著重介紹SCRUM開發框架。

SCRUM中定義了很多角色,這些角色被分成了兩組:豬組和雞組。這個分組方法來源於一則笑話:一天,一頭豬和一隻雞在路上散步,雞看了一下豬說, “嗨,我們合夥開一家餐館怎麼樣?”,豬回頭看了一下雞說,“好主意,那你準備給餐館起什麼名字呢?”,雞想了想說“餐館名字叫火腿和雞蛋怎麼樣?”,“我不這麼認為”,豬說, “我全身投入,而你只是參與而已。


奇葩說之Scrum Master 話“敏捷”

微策略的“豬”組成員:

  • Product Owner(PO):確定產品功能,確定功能優先級,接受或拒絕開發團隊的工作成果。
  • Scrum Master: 作為團隊的敏捷教練, 必須保證團隊資源充分被利用和協同合作,解決團隊障礙,做好外部藉口,保證開發過程的正常進行。
  • Scrum Team: 負責產品的研發工作,人數控制在5~10人,每個成員負責不同的技術方面並且有很強的自我管理和表達能力。成員之間必須進行充分的交流,形成可信任的關係。

在微策略,每一個scrum team都有一個PO,負責項目的優先級和每次迭代增量的確認。幾個功能相似有緊密聯繫的scrum team會有形成Area或者division,由CPO,GPO或者APO來領導,一般擁有40~70團隊成員不等。每一個division一般配備一到兩個Scrum master,負責團隊內部以及跨域的協同工作,團隊障礙的清理,把握項目進度,及時發現並清除風險等工作。


微策略的“雞”組成員:

雞角色並不是scrum過程的一部分,但確實必須要考慮的。作為B2B的企業,微策略員工在日常工作中很少直接面對客戶,PM(Product Manager) 在這其中起了非常重要的作用,也就成為了微策略最典型的雞組成員。在項目的前期,PM負責市場需求和開發團隊的對接;項目中期,通過週期性的開發彙報會議,確保開發工作符合市場或客戶預期;項目尾期,PM確認產品交付。

角色確定了,那麼我們如何實施SCRUM呢?

奇葩說之Scrum Master 話“敏捷”

1、我們首先需要確定一個Product Backlog(產品需求列表),如下圖(最左邊一欄就是產品backlog)。PM和PO會根據市場需求,團隊能力確認產品優先級和開發順序,並計劃在不同的release週期。

奇葩說之Scrum Master 話“敏捷”

2、有了Product Backlog列表,我們需要通過 Sprint Planning Meeting(Sprint計劃會議)來確認每次迭代需要完成的目標,並在會議上對目標進行分解,行成spring backlog, 由scrum team去完成。

而實際上,在PO具體規劃每個迭代的目標之前,會先組織團隊進行tech spike和feature grooming,把feature分解,並根據公司release strategy制定大概的開發計劃。這個計劃往往是有一定的餘度的,來應對開發中的不確定性。在微策略一般定義兩週為一次迭代,每六次迭代(也就是3個月)進行一次產品發佈。

奇葩說之Scrum Master 話“敏捷”

3、每個成員根據Sprint Backlog再細化成更小的任務(Task)。微策略推薦每個任務不超過4個小時,最大粒度為8 hours,也就是一天。這樣安排的好處在於對於大多數工程師而言,他可以每天對自己的任務進行總結和梳理,保存開發現場或者上傳代碼,有利於快速切換任務。

奇葩說之Scrum Master 話“敏捷”

4、在Scrum Team完成計劃會議上選出的Sprint Backlog過程中,需要進行Daily Scrum Meeting(每日站立會議),時間控制在15分鐘左右,每個人都必須發言,並且要向所有成員當面彙報你昨天完成了什麼,承諾你今天要完成什麼,遇到了什麼不能解決的問題。微策略使用的敏捷工具Rally可以幫助繪出每次迭代的燃盡圖(burning down chart), 如果to do下降的速度太慢則有可能是加入了新的需求,或者開發遇到了瓶頸。Accepted的部分增長過緩,則本次迭代會有burnout的風險。

奇葩說之Scrum Master 話“敏捷”

5、每一次迭代的完成,我們都要進行review meeting(演示會議), 也稱為評審會議。PM、scrum team、PO、SM都要參加,每一個Scrum Team的成員要向所有人演示自己完成的軟件產品。成果的評審經常會影響下一次迭代的任務和目標。

6、最後一項內容就是Retrospective Meeting(回顧會議),總結並討論改進的地方,產品的改進方案常常會被放入下一輪Sprint的產品需求中;在微策略,很多scrum team會把Retrospective meeting放在review meeting之後,除了討論和總結產品的改進方案之外,成員也可以對團隊的運行發表建議和意見,大家行程統一意見之後,會在接下來的時間內實施,這對新組建的隊伍或者結對開發是有很重要的意義的,極大地縮短了團隊的磨合期。

7、為了更好的敏捷實踐,我們需要做到每日集成,也就是每天都要有一個可以成功編譯、並且可以演示的版本。除了要構建一整套自動化流程來保證構建、集成、測試、交付、部署的高可靠性之外,還需要各個團隊開發強有力的自動化測試代碼來保證每次迭代的可用性。微策略擁有自己的DevOps團隊,來支撐敏捷實踐下的持續集成和持續交付。根據CI/CD的設計,微策略的自動化流程包括了以下幾個步驟:

  • 提交:工程師根據當前工作內容向相應代碼庫提交代碼。
  • 測試:代碼倉庫對commit操作跑相應的自動化測試(pre-merge), 測試成功後可以合併(merge)進主幹, 然後進行第二輪測試(post-merge)。
  • 構建: 將源碼轉換可以運行的代碼,配置資源和依賴。
  • 部署/交付: 將可以執行代碼進行打包存檔。在微策略,構建完成的代碼會自動部署到某一個環境下執行各個功能點的自動化測試,嚴格的說,這並不屬於持續集成的部分。但是由於微策略產品的複雜性,系統級別和端到端的自動化測試腳本能更好地檢查產品的交付質量,所以往往在每次迭代後自動運行來保證後續開發和測試的穩定性。

它的好處是可以快速暴露錯誤,提高代碼質量,降低整體集成風險,以及促進產品的快速迭代。

奇葩說之Scrum Master 話“敏捷”

活學活用Scrum

微策略具有非常開放的企業文化,既會“拿來主義”,又會把方法本地化。大到一個division, 小到一個scrum team,每個團隊都有自己對scrum獨到的解讀和實踐。

比如,一個7~10人的團隊,利用站會時間分享近期棘手問題的解決辦法,新成員可以從這一短暫的分享中迅速積攢自己解決問題的能力。又比如,微策略的一些團隊會在Retrospective meeting的時候給團隊成員點一些下午茶,大家邊吃邊聊,開誠佈公,每個人在輕鬆的氛圍中更積極的參與問題的提出和解決辦法的討論。

由於團隊的分工不同,每個時期的任務強度也有所不同。每天8個小時的plan對於很多團隊來說很容易burnout,微策略的PO會根據不同時期的任務強度,市場的反應情況,為團隊計劃不同的工作量,以便更靈活地應對變更和緊急任務。

奇葩說之Scrum Master 話“敏捷”

對於敏捷,大家詬病最多的就是文檔記錄的缺失。在我看來,這並非敏捷與生俱來的槽點,只是敏捷實踐中並未對此做深入詳盡的定義。文檔記錄也應該是因人而異,因地制宜的,每一個敏捷團隊可以自己構建一套可執行的流程。在微策略,每當準備開發新feature時,Scrum master 團隊會監督每一個scrum team完成四大文檔(feature spec document, PD document, QA test plan document 以及UX document)並嚴格遵循review流程,保證文檔的準確性和可讀性。

還有不少實踐敏捷的團隊只是把瀑布中的開發過程截斷成一個一個短的週期,其結果是每個迭代出來的都是未經驗收的半成品,並未實現持續交付。更可怕的是,在沒有確定當前開發的正確性之前,命令團隊死磕到底把故事做出來,這種錯誤的打開方式會使團隊產生誤解,敏捷就是更多的COB和更頻繁的加班。實則不然,正確的姿勢是每個sprint都應該有一個小目標,團隊需要估算能完成那些故事,約定好DoR和DoD,每一個迭代都應該產出業務價值,並得到確認。

SCRUM敏捷開發

給微策略帶來的改變

1. 更快的市場響應速度:在瀑布開發模式下,微策略每3~4年發佈一個版本,為了紀念千日等一回的激動時刻,我們用星星來命名發佈的大版本,像Orion(MicroStrategy 9),Polaris(MicroStrategy 10)。實施敏捷開發模式後,release的週期縮短到每三個月一次, 較短的迭代週期使團隊快速進入開發狀態。高質量的產品投放有效地刺激了市場,更及時的客戶反饋減少patch的維護成本,促進新產品的開發和調整。(下圖為11.2GA產品發佈後給各個組分發的慶功零食)

奇葩說之Scrum Master 話“敏捷”

2. 更強的質量保障:質量包含了兩個方面,一是做正確的事,二是把事情做正確。微策略通過每日例會,review meeting對產品質量和進度進行檢驗,以便優化下一次工作目標的價值。持續集成結果快速反饋到開發小組以確認新產品代碼的正確性,以便及時發現及時處理,減少錯誤增量交付的成本。

3. 更高效的自我管理團隊:Agile 在組織形式上講究自我組織,自我激勵。在微策略,每個開發小組就像球隊一樣,當比賽開始的時候,前鋒,後衛,中場,每個人在自己的位置上發揮自己的作用,而無需監管。每日例會和週期性的產品交付會幫助團隊時時檢查產品的正確性和價值增量,達到自治的狀態。

奇葩說之Scrum Master 話“敏捷”

開發方法千萬條,適合自己第一條。敏捷和瀑布都是軟件開發方法,沒有孰優孰略。小編從業若干年,見過一些公司盲目跟風從瀑布硬轉敏捷的,也見過把敏捷搞成小瀑布的,這都偏離了敏捷的初衷。想要真正趟出一條適合自己的敏捷之路,需要非凡的市場決斷——天時,穩固的商業地位——地利,和堅定的團隊實踐——人和。說到這裡,不得不為自己的公司賺一聲吆喝:微策略看準了天時,佔據了地利,贏得了人和,更歡迎優秀的你一起玩轉“敏捷”!


我們會每週推送商業智能、數據分析資訊、技術乾貨和程序員日常生活,歡迎關注我們的頭條&知乎公眾號“微策略中國”或微信公眾號“微策略 商業智能"。


分享到:


相關文章: