我們如何作為客戶的擴展分佈式團隊運行敏捷項目
已發表: 2018-12-14Computereconomics 最近的一份報告發現，在 2018/19 年期間，應用程序開發過程已成為見證最大外包機會的過程——全球 56% 的組織將其開發需求外包。
這種對外包移動應用程序開發需求的需求增加背後的原因與往常一樣 - 成本低於僱用本國開發人員所必須支付的成本，從而可以更加專注於主要業務，並提供更好的服務質量。
然而，即使外包在應用程序開發行業中佔據中心地位，我們發現當客戶計劃將其軟件開發項目外包到其所在國家/地區之外時，他們會表現出一些共同的擔憂。
在本文中，我們將研究 Appinventiv 如何使用分佈式敏捷開發週期與離岸客戶合作，從而實現更緊密的工作流程以及一致的風險和薪酬模型。
但在我們開始講述我們如何作為客戶的分佈式團隊運作並無縫工作以使我們成為他們擴展的內部技術團隊之前，了解分佈式敏捷團隊甚至意味著什麼是很重要的。
分佈式敏捷團隊是什麼意思
分佈式團隊是一個概念，用於解釋兩個或多個團隊跨越多個地理位置而不是一個辦公空間甚至一個城市的兩個辦公空間的事件。
分佈式敏捷團隊依靠數字技術無縫交互並朝著同一個目標共同努力——及時的項目交付。
為什麼企業投資移動應用開發分佈式團隊？
有很多原因促使企業投資分佈式團隊，原因包括：
- 他們國家缺乏熟練的開發人員
- 在對團隊建設進行投資之前需要測試市場
- 利用靈活團隊的好處，可以在擴展應用程序時增加並在需要結束時解散。
現在考慮到定義和需求，現在讓我們看看 Appinventiv 團隊如何作為客戶的分佈式團隊工作。 但在我們跳到那里之前，讓我們快速看看我們典型的分佈式敏捷團隊結構是什麼樣的——
Appinventiv 分佈式敏捷開發方法
很多時候，我們得到一個項目，要求我們與客戶的 FTE 密切合作。 在這種情況下，我們不要讓工作之間的距離以千里為單位，並且我們能夠實時做出改變並對發展過程採取行動，這一點變得非常重要。
我們如何確保及時交付而沒有零範圍的溝通滯後和誤解，這是一個問題，其答案在於分佈式敏捷方法。
適合小型和大型企業，當我們必須與位於其他地理位置且時區完全不同的團隊一起工作時，遵循分佈式敏捷最佳實踐非常方便。
讓我們看看我們在移動應用程序開發過程中應用的分佈式敏捷開發方法。
在我們相互介紹了所有團隊成員並協作了項目管理軟件之後，實際工作開始了。
我們制定了每日敏捷 Scrum 方法論的過程。 雖然在傳統意義上，Scrum 需要 15 分鐘的面對面站立會議，其中每個參與者分享他們的任務狀態並通知團隊他們接下來將要承擔的任務，但幾乎不可能在一半時遵循相同的流程團隊的成員坐在其他時區的其他地理國家。
為了在 Scrum 中保持面對面交互的精髓，我們所做的是在一個確定的時間舉行視頻通話，這適合團隊中從事該項目的每個人。 在屏幕共享的幫助下，我們的敏捷 Scrum Master在 Trello 或 Jira 等工具的幫助下運行虛擬 sprint backlog，使每個團隊成員都能了解項目的最新進展。
我們的經驗是，讓所有團隊成員都能訪問一個易於訪問和更新的任務跟踪平台是非常重要的。 我們還強調使用 Skype 或 Slack 等交流平台，讓每個人在兩個 scrum 時間段之間分享更新或詢問他們的疑問。
我們在日常敏捷和 Scrum流程中遵循的另一種方法是，對於每個不同的 Scrum，我們指定一個 Scrum Master。 因此，每個單獨的團隊都作為一個獨立的 Scrum 團隊，有一個 Scrum 主管和產品負責人——這個過程也被稱為 Scrum of Scrums。
在此，所有 Scrum 代表都對 Scrum 中的以下問題提供了答案——
- 自上一次 Scrum 的 Scrum 以來團隊已完成的工作
- 工作團隊計劃在下一次 Scrum of Scrums 會議之前做
- 球隊目前面臨的阻擋者
- 可能導致另一個 Scrum 團隊的阻礙。
該方法使從事該項目的所有主要人員能夠直接相互交流，這始終會導致從啟動階段到啟動階段的奉獻精神。 這確保了所有團隊之間的公開、清晰和透明的溝通，每個人都有發言權。
除了 scrum of scrums 之外的過程與我們在典型的敏捷方法中遵循的過程相同。
但是，我們的團隊與客戶團隊之間的距離相距甚遠，但我們必須盡可能無縫地工作，這一事實已經帶來了一系列我們通過採用分佈式敏捷所推動的學習。 讓我們看看這些學習是什麼——
我們從分佈式敏捷開發過程中汲取的教訓
1.分佈式團隊的創建是關於建立一種文化而不是一個過程
在分佈式團隊敏捷方法下，定義項目成功的因素並不取決於團隊成員的技能水平，而是取決於他們能夠一起工作的能力、他們工作的主人翁意識，以及最終如何它們與項目的目標密切相關——這是文化而不是過程形成的東西。
2.只有 SMART 項目才能成功
當一個項目必須由一個甚至不在同一個國家更不用說辦公室的團隊完成時，您為項目設定的目標遵循 SMART 是非常重要的——具體、可衡量、可實現、現實和時間框架，概念到 t。
3.在線協作工具沒有替代品
無論花費多少，您都必須依賴實時且延遲最小到零的在線協作工具。 在最終確定在線項目管理和交流平台方面，您無論如何不能懈怠。 您必須確保他們在技術上能夠滿足您的要求。
現在我們已經看到了作為分佈式團隊從豐富的工作經驗中吸取的教訓，是時候看看我們在這個過程中遇到的一些挑戰，以及我們如何解決這些挑戰以成為一個值得信賴的分佈式敏捷應用程序開發公司。
分佈式敏捷開發方法的挑戰以及我們如何解決這些挑戰
1.文化差異
通常分佈式敏捷軟件開發方法要求與來自不同文化背景的團隊合作。 由於不同的價值觀和修辭格，這種差異會引起摩擦。
我們的解決方案：我們在最初幾天與客戶的團隊密切合作，以便我們習慣他們之間的界限和背景。
2.時區差異
分佈式敏捷方法的關鍵是來自不同地理國家的團隊。 在這種情況下，由於時差而出現的通信差距是很常見的。
我們的解決方案：我們將分佈式團隊的敏捷概念作為其核心。 我們確定了一個來自所有國家的團隊都在場並活躍的時間。 為了實現全神貫注和全神貫注，我們要求我們的隊友在 Scrum 日改變他們的辦公時間，以便他們睡得好、專心。
3.缺乏“大圖”的共同觀念
由於地理位置、工作結構和政策的不同，大圖的想法可能存在差異——移動應用程序的最終目標。 這種差異可能會導致一些團隊成員缺乏興趣，而其他成員則更加感興趣。
我們的解決方案：在項目啟動時召開願景會議，並在每次 Scrum 中進行提醒，以便每個人都朝著同一個目標努力。
4.缺乏代碼所有權
沒有集體代碼所有權意味著沒有人擁有代碼，它屬於整個團隊，所以當出現問題時，責備遊戲就開始了。
我們的解決方案：我們應用版本控制系統來檢查誰在編寫代碼以及代碼的工作時間和效果。 這樣，圖片就完全透明和誠實了。
所以，這就是我們 Appinventiv 如何成為分佈在世界各地的客戶團隊的故事。
想討論如何提高分佈式敏捷軟件開發的水平？ 與我們的移動應用策略師聯繫。