基於版本控制的分散與聚集軟體開發流程 - industriallogic

banq發表於2021-09-15

在涉及大量工作的軟體過程中，有一種普遍的管理人員的方法，以確保每個人都能獲得適合其才能、知識、技能和經驗的任務。
對於軟體產品的給定功能或修改，高階技術人員將制定出可能成功並適合業務架構的設計。然後，這位大師將工作劃分為需要由個人完成的任務。
通常，優秀的技術大師會考慮他們團隊的技能，並根據個人技能線劃分工作。有些人會沿著元件線劃分工作，然後根據他們最瞭解的元件考慮將給哪個團隊成員分配哪個部分來工作。
分配工作，然後團隊成員在完成當前任務列表時執行新工作，根據需要向高階人員提問，並希望（在許多但不是所有組織中）獨立測試他們的作品。
這項工作在版本控制系統（例如git）的各個分支中完成，並在票證系統（例如Jira）中進行跟蹤。
當所有的部分都完成並且程式碼都經過審查後，然後將這些部分整合併合併到一個共同的開發分支中。在一起測試這些部分之後，它們被合併到一個主（主幹）分支或一個釋出分支。
換句話說，
  • 軟體作品首先被分成若干塊
  • 那些散落在各個團隊成員的碎片
  • 一旦所有的碎片都完成了，它們就會被收集起來
  • 這些軟體被合併/整合
  • 組合程式碼經過測試
  • 當組合解決方案工作時，它被部署

我們稱這種工作方式為分散-聚集開發Scatter-Gather。
  

它有什麼吸引力？
吸引人們的原因有以下幾個：

  • 個人可以獨立工作（大多數情況下），他們之間幾乎沒有閒聊或協調。
  • 理想情況下，大部分工作是並行完成的。
  • 工作產品被分配給具有專業知識水平的個人，從而有效地利用資源
  • 個人對他們的工作負責和負責，這使得為了績效管理目的，更容易分辨每個人的技能水平和優勢（或劣勢）。

理想情況下，我們應該看到工作以最大並行度快速完成，因為每個任務都交給最能及時完成的​​人，如果變更設計良好且任務被很好地理解，那麼在以下時間組裝變更結束不應該太困難或不合時宜。
 

缺點問題
有幾個值得注意的問題需要指出：

  • 時間分佈：工作通常不是並行完成的，因為每個人都有一個與各種故事相關的任務列表。任務列表的長度和順序可能因人而異。完成工作可能需要更長的時間，因為工作分散在待辦事項列表中。
  • 筒倉形式：每個人都傾向於在他們熟悉的給定空間中工作。個人傾向於收集系統有限片段的非常具體和深入的知識。工作往往需要排隊等候專家，延遲完成。
  • 磚塊製作（基於赫芬頓郵報文章中提到的一個古老寓言）：開發人員參與制作程式碼片段，而不是端到端整合和頻繁釋出。
  • 不鼓勵協作：個性化、個性化的任務不太有利於整合程式設計。此外，由於每個開發人員都有自己的工作要做，他們無法在不將自己的任務置於未完成風險的情況下加入其他人的任務。出於這個原因，單個任務的分配稱為解組。
  • 預設計師的負擔：領導者不僅必須提前（通常單獨）進行設計工作，而且他們還必須瞭解如何最好地將這項工作分配給團隊成員。隨著故事的進展，他們還負責回答有關實施、整合和業務案例的任何問題。
  • 後期測試：在每個部分完成之前，該功能不作為完整的端到端流程存在，因此端到端測試必然會延遲。
  • 失去機會：團隊成員不會同時看到整體設計，因此他們發現缺陷或機會的能力受到阻礙。
  • 遲到的驚喜：原始設計中的任何缺陷或工人對設計的解釋都會在整合過程中遲到出現。如果問題需要返工，返工將破壞必須修復缺陷的個人的任務列表。
  • 模糊狀態：任何整個工作的進度都是分散式和孤立的。所有的部分什麼時候開始？所有部件什麼時候完成以便我們可以整合它們？在日曆時間內，我們什麼時候可以在生產中看到此功能？

 

預測很難，而且越來越難
軟體領域的公司試圖透過更精確的估計來管理可預測性和質量問題，但這是徒勞的。導致可預測性問題的並不是低質量的估計。
可預測性的最大問題是意外地內建在分散 - 收集系統中。
考慮到他們將在不同時間處理任何給定的故事，他們中的任何一個都可能被遲到的問題或緊急情況以及任何整合問題打亂，因此參與完成該功能的所有開發人員預計會累積多少進度延誤直到所有的部分都完成後才會被發現？

詳細點選標題

相關文章