敏捷外包的14條原則
文／vikas hazrati 譯／金欣亮
雖然軟體專案的外包趨勢已經是乙個不爭的事實，但是還是有很多專案由於錯誤的外包而失敗了。拋開諸多優勢不談，軟體外包確實帶來了額外的複雜性、風險以及消耗。本文將基於實際專案經驗以及豐田公司的製造過程，討論如何把外包變成一種成功的模式，我們將這種方**稱為「精益敏捷外包」。
我們的目標是利用當地的廣闊人力資源，更加高效、迅速地交付軟體。鑑於scrum和豐田模式在開發新產品上的成功表現，我們決定採用它們來進行外包專案管理。豐田原則可以很好地被應用到任何軟體開發專案中。我們將在下面討論豐田模式，以及如何使用這些原則讓我們的外包過程「精益」起來。 這種保留了scrum和豐田模式的工作方法，幫助我們每天都在提高。
採用此方法開發的專案，是乙個中心社會保障機構的批處理系統。系統的工作流程是從稅務部門獲取老闆和雇員的資料，校驗這些資料，然後生成某人某乙個階段的收入申報資料。系統每個月要處理1600萬條資料記錄，每秒鐘大約50條資料。
原則1：制定乙個長遠的價值觀，並且堅持下去
我們開始外包專案的時候，心中存在乙個信念：我們不僅僅是為了這乙個外包專案而工作，而是心中有乙個長遠目標：通過努力，讓我們成為最好的敏捷公司，並且擁有穩定的、可重用的外包模式。這種模式可以使得整個軟體行業受益。我們不會採取任何危及專案質量的捷徑。 我們會積極創新，改進工作方式，提高整個行業的敏捷外包專案成功率。
原則2：建立連續的工作流程，使問題浮出水面
原則3：使用「拉」模式來避免過度生產
依照上面的原則，我們決定採用利益相關者來「拉」的模式，而不是讓團隊去「推」。畢竟我們的意圖是編寫具有商業價值的**，而不是為了完善**庫。如果「拉力」不是很強，我們就減少迭代的大小，或者利用剩餘的時間進行重構，以提公升開發過程和交付的質量，確保我們高質量地滿足客戶的需求。
原則4：平準化（heijunka）
豐田提出要減少資源的浪費（muda）、人員的過勞（muri）和分工的不均（mura）。 在外包專案中，它們的表現形式為：不必要的功能、過度的需求、在客戶和團隊間額外的抽象層；尋找不相關的資訊；測試沒能找出缺陷；與客戶低效率的溝通。我們要謹記這些，它們是外包專案中最大的浪費。
在實際專案中，為了去除浪費，我們只開發本次迭代的使用者故事，使用的故事卡片上也僅僅記錄了足夠開發使用的資訊；我們根據使用者故事進行程式設計，為了澄清業務細節，即使是離岸團隊也可以直接跟客戶取得聯絡；不管是開發人員測試還是客戶測試，我們都秉承測試優先的做法。為了確保工作的平準化，我們總是根據團隊的速度來衡量工作，並確保完成的使用者故事數量沒有不平衡的趨勢。在軟體專案中，使團隊成員精疲力竭是最有害的行為！團隊的速度決定了團隊的工作量以及每個人的工作內容。
原則5：建立停下來解決問題的文化（自動化）
我們文化的提倡：如果產生了影響交付質量的問題，團隊就要停下手中其他的工作並解決這些問題。
所有這些這不僅僅是對策，也是預防措施。
原則6：標準化過程
標準化是支撐持續改進、雇員授權、規章制度和過程的基礎，同時是支援組織學習的架構。我們建立的標準流程包括：使用tdd的開發、問題跟蹤和解決、構建和測試等等。這並不是說這些流程都是一成不變的，它們一樣是靈活且敏捷的。這些標準可以確保我們擁有穩定的平台，而且這個平台可以被團隊不斷完善。
原則7：使用視覺化的管理來避免隱藏的問題
我們的格言是：每一件事情對團隊成員都應該是可視的，當然對客戶也是如此。
我們在jira裡面為客戶現場和離岸團隊建立了公用的產品功能清單，公用的燃盡圖和問題日誌。客戶可以使用它來了解產品的問題，甚至檢視我們每天的詳細狀態。使用cruise control可以讓我們方便地了解構建的狀態。每次構建結束，乙個小兔子玩具會報告構建的成功與否。
牆和白板可以向客戶展示足夠的資訊。他們可以走到牆或者白板面前，10分鐘的時間，他們就能獲得足夠的資訊。
我們還在wiki上建立了乙個虛擬的團隊公告板，把所有的視覺化資訊都儲存進去。之後把有用的列印出來，貼到團隊的牆上。
原則8：採用適合團隊成員和過程的技術
真正的精益專案有2個關鍵特性：其一，它傳遞給開發人員最大數量的任務和職責，從而生產出有業務價值的產品。其二，它有著乙個缺陷跟蹤流程，保證在缺陷發生時立即處理。
乙個敏捷團隊最重要的資產是團隊成員，我們應該讓團隊成員採用最適合的技術而不是聽從某些技術鼓吹者的最佳實踐。例如，我們把整個表現邏輯從struts遷移到spring mvc，是因為後者在當前的背景下更加實用，並且這個遷移的決定是由整個團隊共同提出的。當團隊擁有自主權的時候，也是他們能夠做出最好的決定和承諾的時候。自組織的團隊知道如何採用適合的技術和流程來適應每乙個成員。
原則9：從團隊內部發掘領導者
人比體制更重要已經是廣為人知的概念。 我們致力於從團隊內部來提拔外包專案的領導者。我們會讓客戶現場或者離岸團隊中的一部分人去參加scrum master培訓，而不是從其他地方請來scrum master。毋庸置疑，這些人肯定是最了解團隊的人。
原則10：發掘傑出的團隊成員
無障礙的溝通、高效的團隊協作、形式追隨功能的團隊、良好的收入、頂級的工具、舒適的工作環境、勞逸結合的生活、持續的進步、崗位的輪換。 所有的這些在正確的精神指導下，將會建立明星團隊。
對於乙個高效的跨地區團隊而言，健康的交流是核心。為此，我們在專案早期會有很多探訪，目的是建立良好的關係，然後用定期的探訪來維持這種關係。
提出問題、談論困難、擔心無法按期限完成工作，或者對於來自上級的指令給出不同的解決方法。人們經常因為這些行為遭到責難。使團隊變得更加積極主動是一場艱苦的戰鬥，需要花費很多的時間。因此我們鼓勵多問問題。 一旦人們意識到他們有自由，同時也有責任來做決定的時候，他們會進一步做出貢獻，並因此成為傑出的團隊成員。
原則11：與合作夥伴和**商建立長期的合作關係
公平和互相尊重的商業關係，是和合作夥伴和**商長期合作的關鍵。 我們根據這個精神對客戶公開wiki和jira，同時也對負責該專案其他模組的軟體商公開。 這可以使我們清楚了解誰在做什麼，並且能夠同利益相關者和**商一起來制定明確的期望。 這樣做的好處是：我們建立了信任關係，保持了透明度，而且沒有隱瞞任何事情。
這不僅僅提公升了我們外包的可信度，從長遠來看，能為軟體行業提供乙個擴大合作夥伴的成功實踐，對軟體行業來說也是有積極幫助的。通過燃盡圖和sprint迭代的記錄，我們與合作夥伴互相了解和學習。
原則12：身體力行
親臨現場是了解真實的情況的最佳方式。所以我們團隊中沒有只說空話的設計師和架構師。無論他曾經擔任過什麼其他的角色，每個人都要寫**，這沒什麼可商量的。 這有助於我們條理分明地為自己和他人分派任務，根據實際的資料請教專家，分析並理解當前的形勢以及解決方案。
原則13：充分評估各種方案，達成共識之後迅速執行
我們積極地遵循一條原則：在充分考慮各種方案之前，不會選定任何方向。但是一旦我們選擇了正確的道路，我們就加速並且持續地走下去。
好幾次我們都試圖對各種各樣的issues尋求替代解決方案，比如如何使外包團隊理解荷蘭語文件。我們應該手動翻譯還是使用乙個能翻譯60%內容的工具？最後我們決定讓荷蘭團隊根據他們的文件在jira上建立一些issue，離岸團隊來研究這些issue，並且對此進行提問。這種方法非常迅速並有效。
原則14：通過深刻的反思和持續的改進，成為好學的組織
正是這條最重要的原則幫助我們達到了今日的高度。我們執行嚴格的迭代評價，深刻反思，對好的方面進行堅持，對可以提高的地方進行改善，從而使得迭代越來越好。我們渴求不斷地且及時地徵求客戶和團隊的反饋，從而高效地達到軟體的最終目標。 除此之外，當遇到任何問題的時候，我們會一直詢問「為什麼」5次，直到弄清了問題的根源為止。
總結在本文的最後，我想說：「我們仍然還在學習」。「精益生產」已經被成功地應用於軟體外包行業，但是仍然可以改善。豐田原則一旦應用於軟體外包，將會給現有的軟體外包模式帶來顯著的變化。我們將會通過不斷的改進，最終達成我們的目標——白盒精益敏捷外包。這種模式下外包的透明度和質量都將會達到極致。
最後對外包行業提乙個建議：在遵循scrum和豐田原則的時候，不要試圖稀釋其中的「精華」，把它們應用到你的工作上去，然後等著奇蹟發生吧。
敏捷外包的14條原則
敏捷外包的14條原則 文 vikas hazrati 譯 金欣亮 雖然軟體專案的外包趨勢已經是乙個不爭的事實，但是還是有很多專案由於錯誤的外包而失敗了。拋開諸多優勢不談，軟體外包確實帶來了額外的複雜性 風險以及消耗。本文將基於實際專案經驗以及豐田公司的製造過程，討論如何把外包變成一種成功的模式，我們...
敏捷開發之 12條敏捷原則
1 我們最優先要做的是通過盡早的 持續的 交付有價值 的軟體來使 客戶滿意。2 即使到了開發的後期，也 歡迎改變需求 敏捷過程利用變化來為客戶創造競爭優勢。3 經常性的交付 可以工作 的軟體，交付的間隔可以從幾周到幾個月，交付的 時間間隔越短越好 4 在整個專案開發期間，業務人員和開發人員必須天天都...
敏捷軟體開發的12條原則
1.最優先要做的事盡早，持續地交付有價值的軟體，讓客戶滿意 2.欣然面對需求變化，即使是在開發後期。敏捷過程利用變化為客戶維持競爭優勢 3.頻繁地交付可工作的軟體，從數週到數月，交付週期越短越好。4.在團隊內，面對面交談是最有效，也是最高效的溝通方式。5.在整個專案過程中，業務人員和開發人員必須每天...