久久亚洲专区,玖玖精品在线视频,天堂中文在线官网

摘要
        在微處理器行業中，產品開發工程設計（PDE）團隊提供相關測試來進行經濟實惠的設備檢驗和分類。PDE 夾在實際設計團隊和工廠制造團隊之間，由于缺乏對于（團隊級別的）期限、范圍、需求或可交付產品的控制，他們時常承受著巨大的壓力。
       為了更好地協調PDE 內各個子團隊的工作，總數約50人的7個團隊自主探索了一個協調度更好的方式來進行產品開發。要實現這種協調和整合，筆者認為Scrum 是可以采用的項目管理框架，同時還要結合敏捷工程設計的實踐。本文說明了該企業對于Scrum 的學習和探索，以及這項投資的結果。
介紹
       在采用“敏捷”和Scrum 方式的軟件工程設計領域中，存在大量實踐。其中許多實踐針對利用小團隊的中小型企業，他們采用面向對象的語言開發軟件。位于美國俄勒岡和太平洋地區（OAP）的PDE 團隊是一個大型企業，需要跨越多個團隊和站點、跨越多種文化和環境來實施Scrum 和“敏捷”軟件開發。我們的工作產品是一款在自動測試設備（ATE）上運行的測試程序。ATE 擁有專屬的操作系統和接口語言，這有礙于我們使用行業標準和現有的軟件驗證解決方案。事實上，我們正在一個使用專屬語言的環境中工作，而且既沒有現成的單元測試框架，也無法進行離線測試。此外，長期以來我們一直深受以下問題的困擾，包括需求探討、過度承諾、未趕上時間安排、日以繼夜的工作周、士氣低落和很高的職員流動率。
       長久的構建和制造歷史導致Intel 具有濃厚的瀑布式軟件開發的文化氛圍，而且他們普遍將瀑布式軟件開發視為通向成功的先進途徑。團隊通常以孤立的職能“豎井”（functional silo）形式進行組建，遵照時間安排定期將可交付的產品移交給其他職能豎井團隊。其結果就是：某些團隊在產品生命周期的后階段承受著巨大的重負，而且在項目末期存在著很高的職員流動率。最終導致每個團隊收納各種領域專家，他們所具有的技能很少與其他團隊成員一致。因此一個團隊中的各個成員很難成為搭檔共同負責一些任務。
       盡管面臨那么多挑戰，我們還是決定勇往直前，不過準備采用不同的方式來管理項目，以便更好地團結測試團隊，更順利地交付我們的工作產品。在項目的初始階段，我們選擇為企業引入Scrum，其中大部分工作為硅前（presilicon）基礎設施的開發和一些準備工作。如果我們能夠在第一階段使Scrum有效地運作，我們認為在一個項目相對平穩的階段中習得的實踐可以為我們指明方向，通往壓力更大的執行階段——在此期間，日常工作量完全取決于實際硅片的健康狀況、不斷變化的外部商業景氣、以及客戶對于設計、生產和制造的要求。

第一階段：針對硅片的準備工作
       第一個要進行轉變的小組包括六個團隊和許多子團隊。一開始我們聘請了CollabNet 提供Scrum 教學和培訓。大約20個小組的負責人和技術負責人參加了為期兩天的ScrumMaster 認證培訓，以便深入了解Scrum 的原理和實踐。遺憾的是，三名高級經理錯過了這次培訓，導致其后的轉變流程中出現了不少障礙。負責人的參與對我們的成功而言至關重要。由于我方三名職位主要負責人缺席了首次培訓，導致他們對于我們設法做出的改變缺乏一定認知。
       培訓結束后，參與者們出席了一個回顧會議，在CollabNet 代表不在場的情況下討論了他們對于Scrum 項目管理方式的看法、保留意見和接受程度。團隊負責人同意在質疑新流程是否有效之前或按照Intel 需求對其進行定制之前，先用三個月時間“按照規定”來實施Scrum 原理和習慣。我們組建了一個流程行動團隊（PAT）來監控試點團隊內的Scrum 開發，并為流程中遇到的問__________題提供技術支持。即使達成了上述協議，我已然能夠感覺到企業中支持Scrum 的人員分成了“豬”和“雞”兩派。
       小組和團隊負責人作為所有七個團隊的“產品負責人”，而我作為ScrumMaster（Scrum 主管）。我強烈地意識到Scrum 是要在這些團隊內實施的重要框架，我愿意承擔風險來支持這種框架。雖然承擔這種風險的結果十分樂觀，但要管理七個團隊來實施Scrum 長達整整一個季度，這使我差點撐不下去！
       我們與CollabNet 顧問Michael James 和Dan Rawsthorne 一起研究，認為有一個自愿擔當ScrumMaster 的人員對于各個團隊的成功和穩定至關重要。首先，我們和Intel 管理層協商，以便確保ScrumMaster 這個職位在績效評估體系中需要發揮的重要作用：是簡化并促進Scrum 流程而非注重于管理經費。然后，那些報名擔任ScrumMaster 職位的人員對于他們要負責的團隊在技術方面不存在厲害關系。這有助于避免在他們的技術項目和促進Scrum 流程的職責之間產生任何利益沖突。預算的存在不是讓ScrumMaster 為了促進ScrumMaster 的工作而放棄其自身的工程設計工作。不過，可以向報名擔任ScrumMaster 的人員提供支持來適應職責的變化。
       三個月過后，又有三個額外的ScrumMaster 來管理七個團隊。此外，第八個團隊自愿開始使用Scrum。大約五個月過后，調整所有Scrum 團隊中的工作量是我們面臨的最大挑戰之一。在增加后來逐漸組建而成的額外五個團隊之前，企業必須了解有關如何管理多個團隊間相互依賴的更多知識，并實現團隊間更好的交流。
       我們再次聘請了Danube 為原先上過ScrumMaster 認證培訓課程的員工和錯過第一節課的高級經理教授有關對于Scrum 的工作量調整進行定制的課程。此次為期一天的培訓不僅回顧了發布規劃和沖刺規劃的主要原理，還著重說明了如何跨多個團隊調整工作量。我們再次采用了“學習、嘗試、檢驗和適應”的方式來調整工作量。
       學完一些有關工作量調整的“先進實踐”后，我們開始分析團隊中的問題，并嘗試采用一種課堂上學會的調整模型，然后根據團隊的實際環境對其進行定制。增加一些新職位來處理技術性依賴問題，并管理逐漸產生的更多部門后，該小組在一年內擴展成12個Scrum 團隊，每個團隊擁有5-9名開發人員。
       我們與CollabNet 顧問討論后得出：促成企業成功轉變的兩大因素是自愿性和自組織。雖然我們要求被委任三個月內“按規定”實施Scrum 的團隊遵照關鍵原理和實踐，顯然適應比遵循更加重要。管理層所表現出的“請先試一下”的這種態度促使團隊能夠更好地接受。三個月試用期過后，這些團隊被給予很大的自由，在每個沖刺中對自身進行組織和管理，并檢驗和適應他們采用的方式。雖然這些團隊必須在一起工作，他們擁有盡可能多的自由來決定有效的方式。每周在與所有產品負責人和ScrumMaster 舉行的PAT 會議中，我們討論了偏移問題，但沒有對其做出評判。我們在這一階段的目標是團結和整合，而非達成一致。
       可視性對于這個流程而言也是一個重要因素。內部的“維基”（Wiki）允許團隊編寫文檔，指明哪些方式和信息對其很有幫助，哪些不太奏效，并對實踐提出建議來更好地適應Scrum。
       “按規定”實施Scrum 是讓所有團隊接受并采用Scrum 的一個必要環節。不過，就OAP 這種規模的企業而言，必須符合企業的某些組織結構和特定需求。長達三個月的試用期過后，我們對Scrum 方案做出了一些修改，使其能夠符合并適應我們的文化和環境。首先，團隊必須定義對其目標有用的角色。我們定義了以下角色：
· 業務負責人：高級經理或工程師負責人，主要職責是監督多個團隊或為所有團隊協調技術問題。業務負責人設置“路線圖里程碑”（發布規劃）并定義每個里程碑的“所需”功能。Scrum 團隊仍然可以根據他們的速度對承諾的任務量進行調整，以便實現功能目標。
· 產品負責人：通常就是小組管理員。
· 技術負責人：技術負責人來自各個職能團隊，他們可以共同處理整合、依從性和結構問題，來確保團隊間相互關聯的產量是一致的。技術負責人舉行特別會議來將“史詩”分解成可以在各沖刺階段中完成的“故
事”。
· ScrumMasters（Scrum 主管）：跨團隊工程師，對于他或她作為ScrumMaster 的項目團隊沒有特定的利害關系。這有助于控制ScrumMaster 不合理的鞭策，使其在技術性解決方案中保持中立。
· 團隊：團隊負責此測試包的特定產量，很少與跨職能團隊成員共事。幾乎始終是一個孤立的職能豎井團隊。
· 臨時工：具有專門技能的小組成員，多個團隊每次僅在一兩個沖刺階段中需要這些技能。他們在各沖刺的交接時期加入或退出。
· 溝通人員（Conduit）：這類團隊成員既可以是承包總監（contractorsupervisor）也可以是遠程團隊的本地成員。溝通人員可以比常規的團隊成員簽署更多的故事點（story point）工作量。
· 故事負責人：了解如何完成一個“故事”的技術專家，他可以分配任務，也能要求特定的團隊成員參與進來以便完成這些任務。他能準確告訴您“故事”的狀態和進展。
最后，在這一產品開發階段中，整個Scrum 團隊小組從本質上而言都是其自己的客戶。我們只是在構建基礎設施以便支持硅片調試和制造。在項目的第一年里，基本不存在要求特定功能的外力。這使我們很難區分業務價值的優先級。因此，產品負責人和業務負責人設法通過預估業務價值和整體優先級來區分這些功能的優先級，大致上類似于依存性管理戰略。
       到第一年末，Scrum 已在我們的企業內扎根，成為我們工作規劃和需求管理的默認框架。PAT 已獲得關于“定制的Scrum 方案”是否奏效的大量數據。馬上就要進入硅片階段了。該流程能頂住實際的業務壓力嗎？還是在實踐中會趨于“舊”方式而將這個新流程“扔出窗外”？
第二階段：硅片階段的生存考驗
       對于產品開發工程師而言，處理第一塊硅片是十分艱巨的時刻。當硅片出現時，所有需求都不太明確，需要我們花費數周時間來收集有關硅片設備的必要數據，以便決定如何實行該項目。
       根據在第一塊硅片上發生的情況，我決定重新“檢驗并調整”我們公司所采用的Scrum 方式。我所看見的情況真的令我十分震驚。我有一個Scrum 團隊已恢復他們的舊習慣。其他一些Scrum 團隊決定對第一塊硅片采取Scrum 方式不過都陸續失敗了。其余那些堅持使用Scrum 方式的團隊就像試圖抓住救生圈的溺水者。
在這種環境下不可能繼續保持我們為期兩周的沖刺，大多數Scrum 團隊轉而采用了為期一天的沖刺。他們每天用一小時時間來開會，回顧和探討過去的情況并規劃接下來24小時要完成的任務。在處理第一塊硅片的重壓下，Scrum 的四個會議被濃縮成一個會議。不過，當我出席這些會議時，我發現Scrum 所主張的關鍵舉措都在有條不紊地進行著，包括基于業務價值的優先級區分、團隊規模的調整、任務范圍不超過“產品訂單（backlog）”的內容、改善流程并回顧工作成品等，只不過是隨著對于設備認知的增長，以更小的規模和更快的速度進行著這一切。
       在企業的所有負責人和經理都會出席的每日調試例會中，每次有任何專門的需求被提出時，我就會聽到產品負責人詢問：“產品訂單中存在針對這個需求的故事嗎？”我還發現不少開發人員抓住項目執行人或產品負責人并將他們拖拽到測試設備前，以便親眼證實添加到他們程序中的內容是符合其驗收標準的。
       這一高強度的調試和開發階段持續了幾周。在該階段末期，存活下來的Scrum 團隊看上去安然無恙，并將他們的沖刺周期像手風琴一樣重新延長至兩周。他們在周五舉行的調試會議上宣布了上述變更，并在下周正式實行，這種為期兩周的沖刺延續至今依然十分有效。
第三階段：為制造做準備
隨著硅片的狀況日漸健康，我們開始為制造做準備，我發現在硅片階段后期這種環境下，職能豎井Scrum 團隊被任務移交（handoff）搞得疲憊不堪。每當職責、知識、行動和反饋相互分離時，就會產生任務移交：
· 第一個人決定要做什么（職責）；
· 第二個人定義如何完成上述任務（知識）；
· 第三個人執行任務（行動）；
· 第四個人驗證工作（反饋）。
此外，康威定律（Conway’s Law）指出：那些設計系統的企業受著產品設計的約束，而產品設計正是其企業通訊結構的縮影。我知道跨職能團隊是Scrum 方式所規定的一部分，我感覺他們能夠消除上述特定障礙，但是目前還未找到可行的解決方案，以便在企業內形成這種有效的組織。這時，我注意到團隊成員組建了若干“特別行動組”（Task Force）來處理硅片內容問題。在Intel，“特別行動組”是一個為了解決危機而形成的跨職能團隊。如果派您加入“特別行動組”，那是因為您是某一領域的專家。您必須先放下手頭任務，立即投身于這個小組并為了成功完成該小組特定的任務盡心盡力，而且您無權拒絕。如果不改變企業的組織結構，我不知道如何獲益于“特別行動組”的跨職能特點。
于是，我和Mary 與Tom Poppendieck 為該團隊安排了一些“精益產品開發培訓” ，“精益”培訓向我們透露了一個有關如何在這一階段有效使用Scrum 方式的重要線索：
· 保留職能團隊：這些是十分有用的企業組織結構，因為團隊中既有知識理論專家又有技術專家。還為Scrum 團隊成員在項目間提供了一個類似于“家”的場所。
· 創建跨職能的“功能”性Scrums 團隊：職能團隊向跨職能的功能性Scrum 團隊出借盡職盡責的專家。跨職能的Scrum 團隊成員在沖刺期間需要全部地投入工作，不受其職能團隊經理的制約。
當我聽到這兩點時，真有一種英雄所見略同的感覺。跨職能Scrum 團隊就是不存在危機情況的“特別行動組”！
我們快速對一種內容類型進行了試驗，結果團隊成員都十分贊賞這種方式，它不但大幅度減少了任務移交，還促使團隊成員一起處理問題。此外，知識的傳遞和交流也變得十分順暢。如果在一個沖刺中不需要一個特定團隊成員的職能，他可以和另一個團隊成員搭檔，通過相互培訓來做一些力所能及的事情。
需要再次重申的是，時機就是一切。在我們年度現場會議中，非常及時地收集了有關跨職能團隊試點的大量數據。
這是一個好機會來影響企業的領導，而且可以適當地對Scrum 方式做出調整和更正，使其能夠比從前更有效地運作。我陳述了我的觀察和見解，并提交了單個跨職能團隊試點的早期數據，最終使企業領導批準了這種組織結構。事實上，所有反對者和企業內未表決的那部分人都接受了跨職能的Scrum概念。這使我們的流程新增了5個Scrum 團隊，而且在兩年后擴展到18個！
回顧：
我已使用了簡單的（+）和（-）符號來明確說明哪些做法有效，哪些無效。
對于任務的完全定義（+）
由于我們沒有編程語言，我們沒有單元測試框架或離線回歸。在微處理器產品開發中，單元測試意味著測試硅片單元！這促使我們專注于編寫故事，當然重要的任務是編寫良好的驗收標準。驗收標準（AC）通過詳細說明實現客戶滿意度的需求來完整定義任務。
我們還實行了一個輕量級的驗證環節，我們將其稱之為“成對評審（PairReview）”。要完成一個故事，開發人員和產品負責人或項目執行人必須坐在一起探討并對要符合的驗收標準達成一致協議。我們通過“添加項”、“挽救項”和“遺漏項”這種形式來收集有關這一活動的簡單衡量指標。
添加項是指項目執行人或產品負責人在“成對評審”過程中加入故事的額外驗收標準，被當前沖刺周期內的開發人員所接受，而且可以作為針對模糊的故事驗收標準的一項指示。挽救項是指在這個沖刺中創建并在稍后捕獲的問題。遺漏項是指在上一個沖刺中創建并在當前沖刺中找到的問題。挽救項說明驗證過程是否在有效運作，而遺漏項則表示該過程仍需改進。
此外，我們必須定義的驗證過程。該驗證不能泛泛而談，因此每個Scrum 團隊必須為驗證規則建檔，尤其要定義需要驗證哪些針對其工作產品的任務。驗證必須確保“故事”在相關工作產品中能夠有效地運作，而且通常涉及的一項內容是在測試環境中運行這些設備。
只有完成了所有任務并通過了驗證和檢驗才算完成一個“故事”。
概不“賒欠”（+）
在為下一個沖刺確定速度時，不會對基于上述定義未完成的故事網開一面。這似乎過于嚴厲，但是必須強制團隊重視驗證和檢驗需求，并確保他們的預估中包括這些步驟。此外，還必須強制團隊重視他們的承諾。如果您承諾會完成任務，但是您只交付了90%的任務，那就表示您失敗了。
為期9天的沖刺（+）
我們的沖刺周期為9天，并在每周五舉行評審、回顧和規劃會議。這能使團隊在每周末脫離沖刺，有助于改善Scrum 團隊的生活質量，并提高他們的士氣。另一方面，每周末處于沖刺的中段，便于團隊成員決定他們是否需要在周末工作以便達成其目標。前半年極少發生這種情況，我們已實現了平穩持續的步調和節奏。
步調（+）
為期9天的沖刺這種步調允許產品負責人、業務負責人和團隊在必要時在頻繁的間歇里改變方向。該步調通常有助于減少我們在以前項目中所發現的需求量過重問題，而高級經理也能在每周五逐漸了解團隊能夠生產出的實際工作產品。我們收集的數據表明：當沖刺被嚴重打斷時，將丟失10%-20%的速率。我們將其稱之為“沖刺中斷稅”。如果沖刺在第一周被打斷，將丟失10%的速率，如果沖刺在第二周被打斷，將丟失20%的速率。必須讓經理們注意到這份統計，使他們避免破壞規劃周期的步調。我們還增加了一個規定：如果對當前沖刺做出任何更改，都必須重新考慮和協商任務范圍。此外，在出現必要的打斷時，管理層也要積極響應，他們通常一起探討并換出一些沖刺產品訂單中的項目。
團隊中的產品負責人（─）
為了促進產品負責人和團隊間更好的交流，我們允許產品負責人作為各個團隊的成員加入。在某些情況下，這十分有效，不過在另外一些情況下，產品負責人對團隊進行了微觀管理，他們指定日常任務，阻礙了團隊成員間真誠的交流與溝通。這導致團隊舉行秘密會議，在產品負責人/職能經理的視線之外討論實際的組織結構障礙。雖然這些問題會在日后解決，但它們嚴重削弱了團隊的自組織能力。當我們組建跨職能Scrum 團隊時，我們禁止了這種實踐。
集中式的Scrum 工具（+）
Scrum 要求通過簿記來生成有用的衡量標準，例如每日的燃盡圖表。實踐表明的確如此，尤其是多個Scrum 團隊在您企業內同時運作的時候。擁有一個開放訪問的集成式工具對于轉變的成功而言十分有益。在采用Scrum 方式的初始階段，我們找不到支持Scrum 的工具，因此我們創建了自己的工具。我們從XPlanner 著手，并利用Java 和SOAP 從各方面對其進行了自定義，我們將最終成品稱為“XPlanner2”。根據這些學習所得，我們創建了一個定制的Windows 應用程序。這款集中式工具一直作為一個鑰匙啟用器，用來管理多個團隊。我認為您必須擁有工具來實現并促進大規模的Scrum 團隊，由于現在已提供多種現成且愈加完善的工具，我已不再采用自創的工具了。

服務熱線：021-62650520

深圳 0755-23706296

北京 010-82359258

上海 021-62650520

總機 021-52653259

關于億道公司簡介發展歷程企業文化

產品中心

客戶案例

資源中心試用下載 FAQ 安裝文檔技術文檔技術視頻網絡研討會

新聞資訊億道動態市場活動技術資訊

聯系我們

資源中心

掃一掃關注公眾號

滬公網安備 44030602004326號

一二三四在线视频_久草免费福利视频_国产在线欧美日韩_天天综合网天天综合_a一级网站_www.欧美日韩_91最新国产_欧美性一区二区_精品一区二区三区成人免费视频_香蕉久久久久久