敏捷之旅:Braze 如何重新構想其軟件項目管理流程

已發表: 2019-02-19

我們在最初五年左右的時間裡構建 Braze,並沒有太多正式的項目管理方式。 我們使用設計文檔、Trello、電子表格、啟發式、最佳實踐和大量會議來完成大量工作。 沒有兩個項目是相同的——有些項目是由一個將當前狀態牢記在心的團隊管理的,而另一些項目則被精心記錄,幾乎包括單個提交。 這一切都運作良好......直到它沒有。

到 2018 年初,我們開始看到存在一些基本問題的明顯跡象:

  • 一次有太多的項目在進行中。
  • 在構建週期後期更改了太多需求。
  • 其他人的工作透明度太低。
  • 太多時間花在指導人們如何管理項目和正確地分塊工作上。

這些都是相互關聯的重大問題網絡的一部分。 目前尚不清楚項目的優先級如何、何時進行以及預計將建造什麼。 問題是它可以得到的核心:我們如何工作? 是時候從根本上改變我們管理軟件項目的方式了。

制定計劃

經過一番思考,我們決定為工程團隊採用一種久經考驗的方法——我們決定要變得更加敏捷。

為了應對這一新挑戰,我們希望組建一個小組,代表並利用我們整個產品和工程組織的知識——因此我們創建了一個委員會,由八名成員組成,代表產品管理、設計和工程。 我們包括經理和個人貢獻者,以及具有不同敏捷背景、資歷和經驗的人。

這個敏捷委員會,正如我們所稱的那樣,在處理這種情況時牢牢記住了一些關鍵原則:

  • 我們希望盡可能跨方法和軟件使用經過驗證的解決方案。 成為獨一無二需要付出很多努力,而我們只希望在必要和戰略性的領域獨一無二。 我們還希望人們能夠在 Google 上搜索有關管理工作的最佳實踐——或者更好的是,讓加入 Braze 的人已經知道如何去做。
  • 我們希望 Braze 的產品工程團隊在他們的運作方式上基本保持一致,因為能夠說同一種語言是很有價值的。
  • 我們不想教條地做任何事情,或者不經過深思熟慮。 僅僅選擇一種方法然後照本宣科是不夠的; 對我們來說,重要的是常識和深思熟慮的迭代統治了這一天。

有了這些指導方針,我們決定使用 Scrum,這是一個敏捷框架,已被證明對許多組織有效。 它廣為人知,具有可擴展性,當您希望實施敏捷流程時,它是安全的默認選擇。

接下來,我們面臨兩個主要決定:(1)我們應該使用哪些工具來支持我們的新流程,以及(2)我們應該如何對我們的流程進行更改。 我們討論、評估和演示了幾個軟件,最終證明 Atlassian 的 Jira 是我們的正確選擇。 這是一個經過充分驗證的解決方案,我們團隊中的幾個人已經有使用它的經驗,Braze 中的其他團隊已經在使用它,這為更好的跨團隊協作提供了機會,因為我們都在一個系統中工作。

在選擇敏捷推出計劃時,我們需要做出一些關鍵決定。 首先,我們如何訓練/賦能團隊? 我們可以聘請敏捷教練,讓團隊中有經驗的人來培訓其他人,或者讓顧問幫忙。 其次,我們是否應該讓在敏捷方面有一定經驗的工程團隊在實施之前等待培訓?

最後,我們決定讓熟悉 Jira 和 Scrum 的團隊在他們認為有能力的範圍內開始工作,並聘請了一名顧問來幫助完成整個組織的過渡。 我們對讓團隊中的人或獨立玩家主要負責在過渡期間指導團隊成員不感興趣,因為:

  • 我們不希望任何單獨的團隊擁有我們如何做敏捷,我們認為培訓會更好地接受,如果他們來自第三方的建議會更具包容性
  • 我們認為諮詢業務會比單獨的敏捷教練更穩定、更可靠
  • 我們希望對整個工程組織進行基礎培訓,並在開始時不對組織成員對敏捷的知識做任何假設
  • 最後,我們想讓教練在某個時間點離開,以明確我們組織中的每個人都有責任維持前進的過程

我們決定使用 Scrum,它是一種敏捷框架,已被證明對許多組織有效。 它廣為人知,具有可擴展性,當您希望實施敏捷流程時,它是安全的默認選擇。


布賴恩·惠勒
Braze 產品工程副總裁

執行計劃

經過幾個月的計劃,我們有了一份詳細的文件,詳細說明了我們打算做的所有事情——我們與整個組織分享了它以獲取反饋。 然後,在評估了幾家供應商之後,我們選擇了 Eliassen 與我們一起踏上敏捷之旅。 這段旅程始於 Eliassen 進行的為期兩天的敏捷培訓,隨後是 Eliassen 與我們聯繫的專家為期三個月的敏捷指導。

從一開始,我們就對遷移到 Jira 和 Scrum 相當謹慎。 互聯網和我們團隊的個人經歷都充滿了關於過度教條方法的危險、Jira 如何成為“反模式”以及 Scrum 在組織中可能出錯的所有方式的警示故事。 我們諮詢過的人都非常警告我們,這些變化可能需要時間,而且在我們看到敏捷帶來的真正好處之前,很可能會經歷成長的痛苦。

值得慶幸的是,我們立即發現了新流程的價值。 這種過渡的好處之一是,我們從未感到盲目地遵循 Scrum 的任何特定方面的壓力。 為了讓事情變得更好,我們會每兩週回顧一下事情的進展情況,然後修改需要修改的內容。 在三個月的輔導中,我們在整個工程組織中實施了徹底的變革:

  • 每個人都學會瞭如何編寫、修飾、指出、分解和挑選用戶故事
  • 在完成手頭的工作時,站立會重新獲得關注
  • 產品、設計和工程都學會說相同的語言,界面設計得越來越好

結果

現在我們已經完成了這大約六個月的努力,這些變化是顯而易見的——而且是戲劇性的。 我們已經看到導致這項工作的問題顯著減少。 借助敏捷,我們現在擁有清晰且易於理解的簽核、協作、積壓工作創建和梳理機制,並且我們會定期對需要改進的地方進行回顧。

我們還為設計工件提供了更加一致的位置,以及對給定項目真正“完成”的期望更加一致。 查看其他團隊正在做什麼變得很容易,而且人們比以往任何時候都更容易理解如何很好地合作。

在這個過渡的尾聲,我注意到,在任何特定時間,組織中打開的拉取請求的總數都在下降,即使我們正在做更多的事情並擴大我們的團隊規模。 通過以較小的增量工作並專注於完成工作,飛行中的項目數量顯著減少。

我們在組織中取得的成功也啟發了其他人。 我們開始看到 Braze 其他部門的團隊開始他們自己的敏捷轉型,因此很快會有更多人使用相同的語言並擁有定義和改進協作所需的工具。

外賣

我們努力的兩個主要因素確保了它的成功。

首先,它由一個代表委員會推動這一事實對於從工程組織周圍和從各種不同的角度獲得輸入至關重要。 在公司範圍內,人們在可能影響他們日常工作的問題上感到被傾聽和代表。 隨後創建了一份詳盡的文檔,其中列出了可以與團隊共享的敏捷過渡的動機和計劃,這也非常有用。 我們相信展示決策是如何制定的並引入清晰的反饋路徑——因為它提供了上下文並建立了一個提供反饋的工件。

其次,讓第三方幫助指導我們團隊的決定至關重要。 擁有一個客觀、經驗豐富的合作夥伴使我們能夠快速對我們的流程進行大量改進。 我們的教練知道什麼是好的,並且能夠毫無偏見地提出建議,我們可以多次問:“團隊通常會如何做 X?” 並立即獲得可行的解決方案。 另一方面,如果我們使用內部資源,我們就會冒這樣的風險,即我們收到的反饋來自有偏見的一方,並增加了與現有職責的資源爭用。

還要別的嗎?

如果您想了解更多關於我們如何看待我們的產品以及製作它的工作,請查看 Building Braze。 有興趣加入我們的團隊嗎? 查看我們當前的職位發布。