本文關鍵點
- 敏捷可以成功地應用於集成了軟硬件的產品開發中。
- 使整個過程敏捷化的真正挑戰，是在迭代過程中構建硬件組件的能力，今天已經有了許多的技術和方法論，使它在許多情況下都可能做到了。
- 必須讓開發過程靈活，可以將敏捷與瀑布和敏捷元素整合在一起使用。
- 產品負責人和scrum管理員一定要理解，敏捷必須適應工業環境(工業敏捷性)。
- 工業開發團隊技能的異質性比軟件的要大得多，並且複雜性也要更高。
- 我們想給大家講一個我們在意大利公司的經歷，這家公司位於威尼斯以西約60公里。
我們生產工業機械，需要更新許多產品，但使用的時間要比過去短得多。
我們將試着解釋爲什麼在開發新產品時，選擇了一種靈活的以敏捷爲主的方法，而不是其他更傳統的方法。
我們將告訴您我們已經從一個經典的按職能劃分的組織轉變爲一個具有跨職能團隊的組織。
在所有這一切中，人仍然是最重要的元素，包括產品負責人和scrum 管理者這些新角色，他們通過調整適應了工業環境，還有學着自組織的開發團隊，以及支持團隊中相關的人。
之前我們從未嘗試過回顧會，它的引入也帶來了很強的推動力，這些改進給我們帶來了令人非常驚訝的結果，我們正繼續將敏捷方法推廣到整個開發過程。
這種典型製造業的企業文化，仍然在接受着不斷的精益和敏捷轉變的衝擊，因爲這些新的範式還沒有被完全吸收。
爲什麼我們決定應用敏捷方法開發工業機械
布雷頓開發的工業機械是機械、電子、軟件和工業處理的集合體，因此它呈現出的複雜性已經超出了大家的想象。
布雷頓擁有三條業務線：天然石材加工機械、塊狀石板生產工業廠房、金屬及碳纖維樹脂加工五軸數控機牀。
我們分析了此類複雜產品開發管理的最有效方法。
爲了減少開發新硬件產品所需的時間，即使使用的仍然是經典的準生產、層層把關和瀑布的方法，但經過多年來的實踐也已經把開發的不同階段做了重疊。
換句話說，在整個設計階段完成之前，施工時間和供貨時間最長的部件(交付週期)就已經投入生產，在所有部件完成之前就已經開始組裝。
這種方法稱爲並行工程。
然而，這種方法帶來的好處是有限的，因爲瀑布的邏輯思想仍然停留在大多數人的腦子裏。
我使用這種方法有很長一段時間了，一直都很清楚它在某些情況下的弊端，所以15年前我能夠體會到精益產品開發的邏輯思想。
即使使用精益方法，也不是盡善盡美的，因爲它們適用於簡單或可預測的項目，但是用於複雜的項目，結果就差強人意了。
在那些年(2006年)，我參與了一個用於文檔管理的web軟件的開發，核心開發人員向我介紹了敏捷方法論。
我很熱衷於方法論，也意識到了新產品開發過程的複雜性。
我很自然就想到，即使是硬件產品，也可以用敏捷的方式開發呀。
這樣，階段的重疊機制會更加完整，因爲它們被分解成了更小的階段。
2008年，我開始在硬件產品開發中嘗試敏捷方法。
現在，我不知道還有什麼方法能夠實現階段的可持續重疊，就像敏捷方法那樣。
2012年，爲了應對壓縮開發時間的挑戰，我們在布雷頓開始了第一個將敏捷方法應用於複雜產品開發的實驗。
我們是如何將敏捷、精益和傳統方法結合起來的
我們採用了靈活的開發過程，把適用於不同開發階段的最佳方法進行了整合。
我們發現，願景、精益和產品畫布以及隨後使用用戶故事映射的待辦事項列表分解是非常有效的做法。
如今3D CAD設計和數字孿生使有效的虛擬化成爲可能，使硬件產品的早期開發階段非常類似於軟件產品。
一旦完成了包括成本分析在內的產品概念階段，構建或購買物理組件的階段就開始使用傳統方法了，如現代ERP系統的材料資源規劃(MRP)，這實際上是一種瀑布式方法。
這把物理構建變成了異步的，而不是像15天一個sprint那樣，以迭代和增量的方式持續開發。
以迭代和增量的方式完成組裝，並針對“組裝”及其“看板組裝板”修改了用戶故事映射。
以敏捷的方式進行測試和驗證，就像在組裝期間一樣。
如果有條件的話，我們還使用精益方法對材料和裝配區域進行可視化管理。
這個過程是個混合體，因爲它以協作的方式集成了敏捷、瀑布式和精益。
所幸有一個集成了瀑布式、精益和敏捷的定製化web版計劃軟件，我們可以讓8個產品開發團隊(大約100人)自組織、管理待辦事項，同時爲管理層提供里程碑計劃。
產品負責人和scrum管理員的角色
設計部門以前由幾個“組件團隊”組成，按照能力或他們所管理的機器類型進行劃分。團隊由一位團隊經理領導，他還負責協調新產品的開發階段，這些產品對他有直接的影響。生產和採購是分離的、獨立的。
組件團隊一刻不停地工作着，在訂單開發和新產品開發之間頻頻切換任務。
由於產品開發延遲成本巨大，所以開始招聘新的開發人員，以便即不影響訂單，也不影響新產品開發。
針對客戶要求的標準和定製版機器的開發，我們繼續保持了組件團隊，同時我們也創建了多個“跨職能團隊”，裏面包括有機械人員、電氣人員和軟件設計人員、估算人員、採購人員、生產和裝配人員(我們的職能團隊)。
在開發結束時，由PO和SM協調的“職能團隊”解散，其成員返回組件團隊。
每個團隊都是針對每個新項目選擇最合適的人員創建的。產品負責人是從銷售工程師中挑選出來的，他們爲銷售人員提供支持，由銷售人員向客戶提出我們的解決方案。
他們對市場有深刻的認識，他們能夠描繪出客戶和股東的利益，同時他們對產品也有深入的認識，從而能夠指導產品的開發。
“組件團隊”的團隊領導已經成了干係人，如產品開發總監、總裁、總經理等，這個角色可以創造很多幫助開發團隊的機會，而不是簡單地討論技術解決方案的產品負責人。法比亞諾·加佐拉(ABD2018的聯合主辦人)是布雷頓的一個業務部門的負責人。
最難引入組織的角色是scrum 管理者，因爲在公司裏從來就沒有過教練的角色。
我們於2015年在丹妮拉·里納爾迪的支持下開始了我們的項目，她也是2018年ABD2018大會的聯合主辦者。作爲一名外部顧問，她幫助我們弄清楚了scrum管理者的角色，以及從公司外部聘請現有scrum管理者的所有優點和缺點，並作爲一名女性支持着幾乎完全由男性組成的開發團隊。
她幫助團隊進行項目的分解，以及以迭代和增量的方式開發產品，這真是一場真正的革命。
一年之後，浮現出幾個需要內部scrum管理者的需求，所以我們招募了一些年輕的工程師，他們都有項目管理的學術背景，性格比較適合擔任這個角色。事實證明，這個決定是正確的，因爲它使我們的敏捷開發具有了可持續性。
一開始，scrum 管理員在有時間限制的會議中扮演了重要的推動者和組織者的角色。在觀看團隊工作時，發現了一些意外收穫。有些人在敞開心扉幫助別人，可一開始他們看起來那麼不情願這麼做。在日常站立會中，看到產品人員在爲團隊提供服務，在推進會議，這真是一個巨大的驚喜。
借鑑回顧會
我們地區的典型製造業公司都是由強壯的男性組成的，對於這樣一家製造業公司來說，回顧會可算是個最大的新元素了。
跨職能團隊中包括有年齡差異非常大的人，可能比父子之間的年齡差異還要大，對他們來說，把遇到的困難提出來可不是件容易的事。
並不是每個人都有勇氣在開會的時候敞開心扉，於是，丹妮拉開發了一種面對面的事後回顧會，通過它與最難相處的人交流。
換句話說，她以一種非常慈祥的方式，讓一些人有機會私下裏表達他們的困難。
團隊很多，但是scrum管理員仍然太少，所以我們的回顧會仍然開得很少。
最近新引入的年輕scrum管理者是sprint會議儀式的主持人，但還沒有足夠的經驗來主持回顧會。
通常，我們不會回顧每個sprint，即使這一直都是我們的目標，但是在項目的重要時刻我們會特別關注，也是就項目結束的時候。
回顧會主要反饋回來的意見如下。
一名產品負責人同時忙於多個開發項目，結果沒有爲團隊提供足夠的支持。感謝這條反饋意見，我們現在正在努力，爭取爲每個項目單獨配一個產品負責人。
開發團隊需要一個項目室，或者在整個開發期間至少有一個他們可以使用的角落。當產品開始進入實物階段，團隊要求得有個專用的安裝區域，就像項目室這樣的角落。
在整個項目期間，並不是一直都需要所有的技能。因此，開發團隊部分由始終在場的人員(核心團隊)和部分臨時人員組成，臨時人員僅在開發到了某些細節或特殊需要時纔到場（攻堅團隊）。這樣大家開會就不會那麼擁擠了，因爲團隊成員一般不會超過10人。
有的人以前喜歡一心多用，現在也明白了只專注於項目的必要性；當這不可能的時候，他們也不想一天處理多個任務，而寧可把一個任務分配到很多天。
通過回顧會，我們還從組件團隊的領導那裏收集了一些反饋，他們很難從以前開發人員、部分項目經理和訂單經理這樣的多重角色轉變爲一個干係人，僅僅去支持開發團隊。
一些組件團隊領導已經體驗過產品負責人的角色。但很快就意識到，他作爲干係人和團隊本身的外部支持，對團隊更有幫助，而不是還沒有做好充分準備就關注於爲客戶提供價值。
敏捷和精益爲布雷頓帶來的好處
我們相信，與使用所有傳統開發方法論的競爭對手相比，現在布雷頓的競爭優勢是新智能產品的靈活敏捷開發。
由於這種靈活、敏捷的開發，使我們在某些情況下已經將開發時間減少了25%。
公司第一次出現這樣的情況：在某些情況下產品成本目標更好了，也就是目標成本更低了；在許多情況下，已經完全實現了成本目標；只有在某些情況下，僅實現了部分成本目標。
我們在智能機器上做第一個實驗時，設立了兩個產品負責人，分別負責機器軟件部分的開發和硬件部分的開發。不出所料，兩個小組之間出現了協調和知識傳遞的問題。因此，我們決定在之後項目中只設立一個產品負責人，我們將與開發團隊一起支持這些項目，編寫軟件和流程故事。
我們大家都清楚，開發過程中的瓶頸是由於使用了標準的施工過程和經典的材料管理(MRP)方法。
於是，我們啓動了一個“工廠內工廠”的內部項目，將開發時間減半，這得益於專用的空間、永久性的跨職能團隊、新的渠道和新的施工方法。
因爲現在有了增材製造等新方法，或者專門的機器和部門，在某些情況下我們能夠在一個sprint中就構建出相對簡單的組件，而“工廠內部工廠”項目的其中一個目標就是儘可能在一個迭代中構建出硬件組件。
這隻適用於最初的原型，因爲對於系列產品來說，通常這些新方法比傳統方法要更加昂貴。
“工廠內的工廠”項目是在敏捷模式下管理的，它的另一個目標是改進目前已經在做敏捷開發的產品的所有階段。
這個工廠的主要目標是儘快發佈新的經過驗證的產品，爲系列產品做好準備。
我們的文化是如何改變的
我們的文化仍處於變革中，因爲我們是從2014-2015年纔開始全面改革的。
敏捷見到了成效，因爲它讓大家學到了知識，提高了創造力和生產力，這證明創建跨職能團隊是明智的選擇。
產品和設計師之間的關係好多了，因爲他們都開始清楚和理解了對方的工作。
有的時候，組裝階段需要創建一個新的組件，團隊在下午進行了構思和設計，晚上開始做，第二天早上就完成了，然後在中午就安裝到了機器上。
管理層並未從中干預施加壓力，而是團隊自主自發的，作爲經理，我們的支持方式只是讓大家能夠使用其他製造資源。
以前按作息規定下午5點30分就收工回家的人，如果有需要，會一直自發地工作到晚上8點。
在某些情況下，團隊成員之間的互幫互助使得scrum管理員這個角色變得似乎有些可有可無了。
從傳統的任務管理轉變爲藉助用戶故事的可交付管理極大地激勵着團隊成員。
Sprint評審看起來越來越像“有時間限制的設計評審”。
高層管理人員總是希望參與畫布板的編寫，並很有興趣接受邀請參與到sprint評審中。
銷售相關干係人與開發團隊之間的合作得到了極大的改善。
在開發新產品的過程中，從頭到尾所涉及的每個人都取得了顯著的成長，個人方面、專業方面，不一而足。
最後的想法
出於推遲向市場推出新產品的成本考慮，促使我們考慮比傳統方法更快的開發方法，即使第一個原型產品可能要付出更高的成本。
在開發新產品時，敏捷轉換最重要的方面還是人。
由於更積極主動的人的參與，實現了更好的結果和更好的產品。
敏捷是一種有效的方法，它可以促進社交學習，大家一起共享知識，因爲在一起工作的是擁有各種技能的人。“個體和交互高於過程和工具”是敏捷宣言中的原則之一，只有培養創造力和生產力，它才能真正行得通。
團隊氣氛有了顯著改善。所有的開發團隊都非常喜歡在一起工作，而不必與其他項目一起同時處理多個任務。
再加上從回顧會上獲得的意見，我們可以啓動組織項目“工廠中的工廠”，在條件成熟的時候，將敏捷模式推廣到所有產品階段。
最重要的挑戰之一將是，把敏捷性推廣到機器組件的構建(目前是使用經典方法構建的)，以及將敏捷思想推廣到產品開發之外的其他業務流程。
非常重要的一點是，所有的管理人員共同分享敏捷方法論。
今天，高層要求以敏捷模式開發越來越多的產品，這是一個強大的動力，但是在我們把這些新方法固化下來之前，還需要再謹慎些。
儘管如此，我們要想把整個產品開發過程敏捷化，還有很長的路要走，現在我們是把敏捷、精益和瀑布方法與數字技術的結合在一起使用的。
關於作者
克勞迪奧·紹林熱衷於組織性的創新。他是布雷頓s.p.a.的產品開發總監。這家公司有大約900名員工，在特雷維索附近生產工業機械。他以一種更加靈活的方式實現新產品開發，將敏捷、精益和瀑布式方法結合在一起使用， 並對開發過程進行了大量的數字化。克勞迪奧協調過一個公司項目，是由MISE(意大利經濟發展部)出資的一個關於數字轉型的項目，該項目涉及到集成18個IT平臺，數字化辦公室和工廠的工作。他還協調過另一個同樣由MISE出資的公司項目，開發支持工業4.0的“智能機牀”。
查看英文原文：Applying Agile for Developing Industrial Machinery