2017年5月，SoundCloud公司的CTO Artem Fishman在內部的工程師年度聚會上，分享了SoundClou在的產品開發流程上面臨的挑戰和應對辦法，原文可以在這里找到。
Artem表示，“我們面臨很多產品壓力，我們已經非常努力了，但是實際上卻還是存在交付延期的情況，我想大家都已經意識到了這些問題，整個流程耗時太長”。
這是Artem通過與技術部門的一百多名員工溝通后得出的結論。綜合來看，員工會從本質上和直覺上理解這些挑戰，而這些都是由于產品開發隊列過渡負荷的典型癥狀。
Artem隨后分為四個部分講述了軟件開發流程的最新進展情況。
第一部分分享了SoundCloud近期在評估和改進軟件產品開發流程上所做的工作。第二部分分享了所改進流程發現階段的定義和度量辦法，并衍生出了用于改進SoundCloud產品開發流程的相關策略，包括以下5點：①公司應該承諾減少一次交付的產品數量；
②團隊應該一次開發較少的產品特性；
③工程師應該一次完成更少的任務；
④工程應該減少代碼清單數量；
⑤工程應該隨著時間的推移，減少bug的數量。第三部分分享了持續學習過程和改進流程的指導方針。第四部分和最后一部分分享了努力的初步結果。
Artem介紹，為了改進業務成果，企業定義了所需結果的評估指標，然后通過觀察所采取的行動是否改善或惡化指標，反復達到該結果。SoundCloud的流程優化小組成員使用生產時間和周期時間，作為產品開發中獲得成功的兩個重要指標。
這里提到的所謂生產時間是指產品開發和完成之間的時間。在SoundCloud，這是產品所有者收到工作請求到工作完成之間的時間。周期時間是指產品開始生產到完成之間的時間。在SoundCloud中，這是從工程團隊收到功能請求到軟件部署給用戶的時間。
保持生產時間和周期時間較短有四個優點。首先，可以比競爭對手更快地將產品交付給用戶，增加了占領市場份額的機會。其次，減少積壓的比率。由于新產品的需求變化迅速，最小的積壓意味著更快地使用產品想法。再者，涉及到運輸產品的規模。專注于縮短交付時間，激勵團隊提供最有價值的新產品，并對現有產品進行較小的改變，可降低大規模失敗的可能性，并降低了失敗項目過度投資的可能性。最后，SoundCloud可以更快地獲得產品開發信息。通過快速交付的辦法，比競爭對手更快獲得市場反饋信息，便于在開發周期的早期獲得產品的反饋意見，即可通過對策略進行小幅調整，以此達到其預期的結果。
那么如何提高SoundCloud的生產時間和周期時間呢？有以下幾個重要的變量。
①WIP與貢獻者的比率
工作進度（WIP）與貢獻者的比率是衡量一個團隊中平均貢獻者多任務處理的標準。可以通過兩種方式縮短循環時間，使得WIP與貢獻者比率保持在1.0以下。首先，如果工程師一次開發一種產品，那么產品將比多任務并行執行時更快完成。假設一位工程師被分配了兩個任務，每一個都需要兩天的時間。他們既可以并行工作也可以一個接一個地工作。這兩個選項的時間表如下所示。
在上面的這張表格中工程師并行工作，任務1在第3天完成，任務2在第4天完成。工程師交錯工作越多，完成這兩項任務所需的時間就越長。在極端情況下，每天的多任務處理，這兩個項目可能直到第4天結束才能完成。
如果現在讓工程師進行第一個和第二個工作，第一個工作在第二天完成，第二個工作在第四天完成。通過一次處理一件事，工程師就可以在不增加工作量的情況下完成一項任務！
將WIP與貢獻者比率小于1.0比率的第二個原因是，這關系到個別成員的快速改變開發角色的能力。具體詳情，請參閱下面介紹的團隊工作流程的理想模型。
如上面這張圖所述，軟件工程是一種看不見的“U形”流通池。
工程師需要快速地在計劃、開發、審查和修復bug之間輪轉工作角色。他們在軟件開發過程中扮演了多種角色，這種協作模式類似于精細化制造過程中的U型流單元。
在U形單元格中處理任務是非常有效的，但如果任務隊列過度負荷，那么情況就不會是如此了。如果需要進行的任務超過工程師任務進行的進度，任務將形成隊列等待情況。例如，工程師開發代碼時收到了新的特性請求，將形成一個功能請求隊列。此外，他們很可能無法審查隊友完成的代碼，這會促進評審階段的第二排隊隊列形成，因此無論是周期時間還是質量都會受到影響。工程師需要將角色切換到隊列形成的位置，從而將任務推到隊列中。同理，具有高WIP和貢獻者比率的重載團隊將不能處理傳入的bug修復和特別請求。
②WIP中的產品數量
“WIP產品”是指正在進行的產品。PDKP通過計算Jira項目中代表產品的問題數量，估算出WIP中的產品數量。對于大多數團隊來說，這是“史詩”還是“故事”的選擇問題。產品可以是內部或外部用戶，減少WIP中的產品數量可以縮短生產時間和周期時間。假設我們有兩個任務，每個任務需要四天，并且可以由兩位工程師共享，而不需要額外開銷。如下所示，這項工作有兩個時間表：每位工程師需要完成一項任務，或者第先配對第一位，然后第二位。
在上面這張圖里，第一項任務在兩天內完成，第二項在四天內完成。我們已經提前兩天發貨了第一款產品，但沒有添加任何工作。配對增加了一些開銷，但是通過盡快獲得產品信息往往是值得的。這些相同的原則適用于產品開發的規劃階段。
③庫存
在企業內部，庫存是產品的組成部分，它們是沒有被組裝成準備出售的產品，包括未部署的代碼、RFCs和未完成的Jira問題。代碼量的增加是產品銷售不佳的一個癥狀，對周期有負面影響。也就是說，存貨越多，我們的用戶所看不到的工作積累的時間就越多。一般來說，庫存隨著產品堆積時間的增長而貶值。
理想情況下，我們希望實現所謂的“單件流”，即所有代碼清單都在積極進行的過程。這意味著每個團隊最多應該只有一個產品，并且每位工程師正在進行的任務只有一個。
在軟件開發中完成一個流程的挑戰是，代碼庫存是不可見的。在一個生產實體商品的工廠里，庫存是顯而易見的，倉庫里隨處可見。在軟件公司里，情況就不那么明顯了。
軟件庫存與制造庫存的方式是不一樣的。出于這個原因，我們需要采取措施監控代碼庫存，并確保其及時交付。
④特征與工程師的比率
特征與工程師的比率衡量指的是團隊每位成員平均持有多少特征。較高的比率與更高的錯誤報告率和維護開銷有關，如果一個團隊的比率異常高，公司應該考慮為他們提供更多的人員，或重新分配他們的職責，以獲得更均勻的分配。
⑤錯誤
我們接觸到的錯誤是通過Jira項目中“Bug”的問題類型數量來估計的，持續的bug會對生產時間和周期時間造成負面影響。如果工程師基于存在bug的代碼基礎上構建工程，那么最終的實現可能是有缺陷的，最糟糕的是可能會導致代碼浪費，無法繼續生產。
⑥按時完成已積壓的工作
將一個團隊的周期時間乘以待辦事項列表中剩余的產品數量，就會降低團隊完成待辦事項的時間。
大量積壓有三個負面影響。首先，它增加了我們的生產時間，過多提前計劃會導致團隊無法快速完成工作，并且需要從經理和工程師那里獲得開發時間。其次，它降低了我們在未來改變計劃的靈活性。一旦事情發生在待辦事項列表上，團隊就會覺得有責任交付于他們。最后,它降低了積極性。
那么我們需要對此做些什么呢?
項目經理使用了一些方法論，鼓勵團隊在一段時間內減少產品的工作量，而工程師則在一段時間內完成較少的任務。值得一提的是，指導方針并沒有建議團隊更加努力。他們的目的是增加注意力，而不是總工作時間。
從2017年3月開始，PDKP收集了來自SoundCloud Jira和GitHub組織的生產時間、周期時間、WIP、bug、貢獻者和代碼庫存指標。到目前為止，已有18個工程團隊配置了系統來收集生產時間和周期時間的指標，并在SoundCloud的GitHub組織中收集了開發所需的庫存指標。所有的指標都聚集在PDKP儀表板和匯總表中，其指導思想包括如下幾點：
①公司應該一次承諾減少產品數量
SoundCloud可以通過減少其提交的產品數量來減少周期時間，并增加其在規劃新產品時的靈活性。團隊在完成待辦事項的時候下限較高，這表示過度承諾是一個問題。
②團隊應該一次開發較少的產品特性
如果工作可以并行化，團隊應該一次完成一項工作，以完成最大化流程。在產品開發過程中，不可能有足夠的調整時間，在任何給定的時間內，每個團隊都需要不斷前進。
③項目工程師應該一次完成更少的任務
理論上，工程師應該一次完成一項任務，直到完成為止。
在抽取的18個團隊中，PDKP報告顯示WIP與工程師的平均比率始終高于2.0。當然，在開發軟件的時候同時做一件事是不切實際的，重要的是，充分利用工程師時間并不是一個一直有效的辦法。排隊理論的一個重要結果是，隊列中并非所有節點都必須充分利用，而是以最大限度地提高隊列的吞吐量。事實上，如果SoundCloud的工程師有一點空閑時間就好了。
④工程應該減少它的代碼清單
SoundCloud有著大量的代碼清單，減少清單是我們改進度量的一個好方法。
SoundCloud的團隊通過減少庫存，成功地增加了流量。內容ID小組在兩個月的時間內減少了其庫存，將開放PRs的每日平均提交數量從46個減少到不足5個，而這些提交的平均時限從14到少于1天。在此期間，團隊的周期時間從12天下降到3天。
重要的是，代碼審查不應該是倉促的行為，更確切地說，最好是在它到達審查階段時仔細和徹底地審查代碼，或者使用持續集成審查過程，將代碼合并到主分支中，而不被代碼審查阻塞。
⑤工程應該隨著時間的推移，減少bug的數量
監視和減少團隊系統中的bug數量對生產和周期時間有積極的影響。SoundCloud目前正在實現一個標準化的bug報告過程。
過度負載的產品隊列將從產品經理傳導到項目經理和工程師，并且，請注意，過度負載的傳導會引起單個工程師和多個工程師之間的調度問題。
產品和工程管理必須指引和支持改變其工作方式以改善流程，特別是一些已成為公司習慣的行為。
以下是針對產品經理的指導方針：
公司應該承諾一次可以完成更少的產品。理想情況下，團隊和產品領導層應該就每個團隊的產品數量達成協議。團隊應該在一段時間內減少產品特性。產品經理應該在一段時間內對每個產品進行優先級排序，一次一個特性，并鼓勵團隊盡可能快地交付產品。以下是針對工程師經理的指導方針：
工作團隊應該在一段時間內減少產品特性。工程經理應該意識到在同一時間不要將不同的產品特性寫到黑板上。他們應該鼓勵團隊同時專注于有限數量的特性，最好是一個。他們應該鼓勵員工將產品特性劃分為子任務，以便在團隊中共享，以便焦點得以集中。工程師應該在一段時間內完成更少的任務——如果可能的話，工程經理應該讓他們的團隊了解流程管理，并鼓勵他們專注于一項任務，直到完成為止。項目工程應該減少它的代碼庫存——工程經理應該檢查他們團隊的代碼清單，并鼓勵他們保持較少數量的清單。工程師應該減少bug的數量——工程經理應該監視他們團隊積壓的bug，并安排他們修復bug。以下是針對團隊的指導方針：
工程師應該在一段時間內完成更少的任務——工程師應該學習流程管理的基本知識，并在可能的情況下專注于一個產品特性。工程師應該減少代碼庫存——工程師一旦進入審查階段，就應該立即開始審查代碼，并在工作受阻時通知其他人。項目工程師應該監控并減少bug的數量——工程師應該修復bug !簡單地說，可視化控件作為PDKP的一部分內容，是為了幫助項目經理改進他們的產品開發流程。這些是在PDKP匯總表上顯示的，如下圖所示。
自從最后一支隊伍在2017年6月23日加入PDKP項目以來，SoundCloud的平均前置時間從平均106.4天減少到64.7天，平均周期時間減少了52％平均77.8天到37.2天。
從2017年6月23日起的總領先時間指標。
自2017年6月23日以來的累計周期時間指標。
這種下降與產品和工程領導力相關，成功地將SoundCloud團隊的WIP平均產品數量從平均每個團隊7.4個產品降低到每個團隊3.1個產品。
自2017年6月23日起，WIP產品數量的總體指標在下降
最近，工程師管理人員和工程師團隊成功地將我們的代碼庫存從平均約1200個提交減少到大約500個提交。
SoundCloud仍然有很大的發展空間來提高其產品開發流程。具體來說，團隊每次工作的產品數量，工程師每一次工作的問題數量，以及其代碼清單的數量需要進一步減少。
團隊工作的產品數量已經成功減少，但應該可以進一步減少。團隊一次平均只能生產4-5種產品，雖然整個團隊在同一個產品上同時工作并不是合理的，但每個團隊的工程師平均數量略低于五（大約五），這意味著還有改進的余地。
工程師在WIP中的任務數量沒有得到改善，應該減少。自2017年6月23日以來，平均工程師人數保持在2人左右，使這個數字接近1可能會降低我們的生產和周期時間。SoundCloud的代碼庫存量也仍然是一個問題，進一步減少這個數字是減少我們的生產時間和周期時間的又一個大機會，也就是說，SoundCloud公司已經大大改進了自身的產品開發流程。
總結
正如Artem所言，通過管理正在進行的產品開發過程來加快軟件交付速度，而不是通過加班來實現交付目標。產品開發過程是指產品開發從想法提出到部署形成的過程，良好的流程意味著產品要快速、連續地通過開發周期。
京公網安備 11010502049343號