一千萬個為什麽

搜索

新開發團隊負責人的流程指導



我最近接管了我們集團內一小組開發人員的領導。以前的團隊領導非常重視微觀管理,並以六周的瀑布式方法開展了開發流程。開發人員被分配工作項目,他們必須努力排除其他工作。他在這方面非常控制。不用說,這並沒有真正滿足商業用戶的要求。

展望未來,我們希望改變這一工作流程。受支持的應用程序非常成熟,只有少量到中等的功能改進。重點需要在交付修復/更改方面更靈活,同時允許並行地進行功能開發。

我們的團隊和環境如下。

應用程序/網站

  • ASP.Net網站
  • SQL Server 2012數據庫
  • SQL Server集成服務
  • SQL Server Reporting Services
  • 供應商提供2層胖客戶端應用程序(具有內置定制功能,所有更改均需手動遷移)
  • 供應商提供Silverlight Web應用程序(具有內置自定義功能,所有更改都必須手動遷移)

球隊

  • 4 dedicated developers
  • 1 first level support member (probably 15% dev work)
  • 1 application support member (probably 30% support, 50% dev, 20% analysis)
  • 1 DBA\球隊 Leader (probably 15% support, 60% dev, 25% analysis)
  • 1 Department Manager (probably 20% dev work)

明確的微軟商店(由總部授權)

  • TFS 2017(TFVC)
  • 所有源代碼都位於一個不帶分支的TFS集合中
  • Visual Studio 2015(計劃升級2017)
  • 具有一些交叉項目依賴性的多個解決方案/項目
  • 我們擁有控制權並支持服務器設置和配置

當前工作流程方法

  • Developers work directly against individual TFS Work Items
  • No "Sprint" or Release date limitations. There would be significant resistance against this. From a business point of view, that as one of the main restrictions to the timely delivery of fixes/changes in the past.
  • Management and Administration of processes needs to be very, very minimal
  • Source code needs to remain on-premises (for the short term at least)
  • All deployment should be as hands-off as possible (with the exception of the vendor applications)
  • When an item of work is ready for next environment it should be deployed.
  • Deployments into production environment requires sign off from Dev 球隊 and Business 球隊.

向所有關於我們如何最好地重組結構的建議敞開,讓我們能夠提供所需的東西。

幹杯 菲爾

轉載註明原文: 新開發團隊負責人的流程指導

一共有 1 個回答:

我懷疑自己遲到了派對,但我已經幸存了一些類似的場景,並可能會為您提供一些提示。這聽起來像你的團隊已經過度管理,並且一直對流程或規則產生敵意。

  1. 不要直接進入基於敏捷和sprint的開發。考慮使用看板,並將工作項目鏈接到史詩/更大的上下文。有時候,上下文將會是“破解/修復”,有時候會是功能。鏈接將幫助您更清楚地了解花費時間。 Kanban更可取,因為它可能是完成工作所需的絕對最低程序 - 它不會要求你用流行語,burndowns,估計和其他幹擾來威脅你的團隊。它可以讓你限制正在進行的工作量 - 我建議你從每個團隊成員的3-4件事開始,盡量減少它,直到你能夠達到持續流動的狀態。用這個看板來領導你的立場。

  2. 尋找機會激勵較小的交付批次,並通過自動化測試流程運行它們。使用此流程逐步改進代碼庫,並與發布經理建立信任關系,這些發布經理目前將摩擦引入交付流程,這會導致變更/批次大小增加,從而導致風險增加,從而“驗證”需要外部大門到生產。

  3. 分解整體存儲庫,然後分解整體應用程序。較小的應用程序也意味著較小的批量和降低的風險。

  4. 聽了很多。你的團隊受到毒藥經理的傷害,你的手上已經損壞了貨物。如果你進來太熱,你會失去信任。特別是在這個過渡的早期階段,建立信任和融洽關系是您獲得實踐經驗的關鍵。

  5. 請勿切換工具,因為其他人似乎比你的團隊更擅長使用它們。我認為有比團隊更好的工作流程嗎?你打賭!但不要因為迷信或個人原因轉換。了解你當前的工具鏈能夠阻止你實現目標,並確保在你開始之前,每個團隊成員都能理解底層概念。

  6. 準備好要花一兩年才能真正轉身。您需要對組織施加緩慢,可預測,穩定的壓力,以推動有意義的或長期的變化。