敏捷開發 做乙個合格的Scrum Master

scrum master: beauty and beast

scrum master在許多的專案開發中被視為專案經理，這其實是個誤區。同時我也經常看到有人主張將scrum master與專案經理完全區分，對於此我也不太同意。在我看來scrum master雖然並非專案經理，但是仍然肩負著很多專案經理的職能。那麼scrum master的職責究竟是什麼呢？該怎樣做才能成為一名合格的scrum master呢？以下六項，供您參考。如有不妥之處，歡迎**；）

管理scrum流程

這是scrum master最核心的職責，也是scrum master區別於專案經理的最顯著的特徵。scrum master需要維護每個sprint的流程，確保每個sprint能夠順利的實施以及完成。

首先，scrum master負責主持召開sprint期間的每乙個會議，包括sprint plan meeting， daily scrum meeting， sprint grooming meeting，sprint review meeting以及sprint retrospective meeting。

另外，scrum master還需要幫助po建立product backlog與sprint backlog，並確立其中每個story的優先順序。

最後，scrum master還需要幫助team清除在開發的過程中遇到的障礙。scrum master應該有乙個block list用來記錄team在開發中遇到的問題障礙，由scrum master自己進行管理並最終使得列表中的每一問題得到及時處理。

scrum master應該最大限度的保護team，以確保team不會被外界，尤其是po干擾。那麼scrum master該如何保護團隊呢？team在什麼情況下需要保護呢？

在每個sprint的初期制定計畫的時候，scrum master應合理的根據team的工作能力以及過往經驗，承諾工作量。不要盲目樂觀的給po承諾過量的工作。我就遇到過有的scrum master可能是對於team的能力估計不足，也可能是希望通過承諾更過的工作獲取老闆的芳心，承諾了太多的工作，結果導致team在sprint的後期連續加班，致使team的效率嚴重降低。同時由於時間的匆忙，急於交付，導致了專案的質量很低，最終形成了惡性迴圈。乙個好的scrum master在這個時候是應該要懂得如何與po「周旋」，獲取合理的工作量。這裡的「周旋」並非消極怠工，故意減少team的工作量，這其實是通過安排合理的工作量來使團隊達到最大的工作效率，同時不會傷害team的積極能動性。這是乙個良性的迴圈。

我們都知道，需求的變更對於每乙個開發人員來說都是噩夢，而敏捷誕生的其中的乙個很重要的原因就是為了解決這一問題，讓開發者擁抱變化。然而在我們採用敏捷開發的專案中，經常可以遇到product owner越過scrum master，直接找到team, 對他們指手畫腳，發號施令。這個時候，scrum master應該像「猛獸」一樣將po「吼開」，以避免team受到「傷害」。需求改變可以，但是不應該在sprint的過程中干擾team, 可以在daily scrum meeting或者sprint plan meeting上提出，共商解決方案。我覺得scrum master對team在很多時候都應該有一種「護犢子」的精神。確保team神聖不可侵犯。

有效溝通

很多時候scrum master起到了一種「承上啟下」的作用。一頭面對的po以及自己的老闆，另一頭面對的是team。很容易使人感覺scrum master彷彿在夾縫中求生存，容易兩邊都不討好。因此，溝通藝術的重要性不言而喻。如何說服po，使得老闆滿意，並且讓team開心，這是一門學問。對於此，下面幾點可以作為參考：

1. 面向老闆：

應定期及時的通報專案的狀態與進展，不要等到老闆親自來問，可以通過**以電子郵件的方式傳送。主要匯報進展狀態，避免過於細節的內容；

遇到問題，應及時上報，使得問題在出現時就能得到重視，並被及時解決。如果等到截止時間才發布壞訊息，那麼就給了你的老闆對你進行微觀管理的機會。

最重要的一點，應以身作則，態度端正；

充分了解team中每個成員的能力狀況，防止出現工作量盲目承諾的問題；

通過daily scrum meeting讓team中每個人都能明確了解最新的進展與形勢；

遇到問題，應對事不對人。

此刻開始，scrum master更像是乙個專案經理。無論是質量，進度還是團隊建設都更像是專案經理的職責。對於team來講，這時的scrum master不再是那個「保護」我們的人，而變成了那個「收保護費」的大佬。然而，在實際專案中，scrum master確實要承擔這些職責，只不過有些已經融入到日常的scrum流程中去了。

關於質量的管理，我想其重要性不言而喻。質量是決定了產品的命運。那麼如何把關質量了。在敏捷實踐中，如下的經驗可供參考：

1）欲速則不達。不應過於強調速度，應保持合理的開發節奏，才會使得產品質量具有一定的保障。scrum流程在每個sprint應統一完整，使得team形成習慣，最終達到良好的開發節奏。

2）制定coding style，並堅持**審查。**的規範非常重要，好的**可以提高整體團隊的開發與溝通的效率。好的**會說話。**審查可以結對完成，只有審查通過，才可以提交**。可以通過建立pull request來進行**的審查，通過之後，再merge到**庫中去。

3）寫單元測試。單元測試的重要性我想大家都明白，只是很多人覺得寫起來痛苦，麻煩，占用開發時間。有了單元測試，你的**才是經得起考驗的**。

4）冒煙測試。在每天下班之前，停止push**，然後進行冒煙測試。冒煙測試成功之後，才會下班回家。這是一種很好的方法，它保證了每天功能都是可用的，從而確保了質量。

5）自動化測試。它的好處，不用多說，誰用誰知道：）

6）提早整合，以便頻繁獲取反饋。這樣的好處在於我們可以及時的得到使用者的需求反饋，進而能夠及早修正。

7）最後，我要強調一句：不要加班，不要加班，不要加班。

跟蹤進度

進度管理是scrum master的又一項專案經理職責。對於scrum中進度的監控，我們有很多的方法，也非常有效。

先說工具，敏捷開發中，比較傳統的跟蹤進度，同時使用也非常廣泛的一種方式是story board（故事版）。這種方式簡單直觀，非常有效。即使現在已經湧現了很多非常優秀的電子管理工具，許多團隊仍然對它情有獨鍾。近些年一些電子的跟蹤進度的srcum工具出現了很多。比較有名的像是jira. 它的使用也非常的簡單直觀，而且功能非常豐富強大，強烈推薦大家使用。

另外，我們可以通過daily scrum meeting獲取到team每天的工作進展。此時我們可以根據進展進行一些必要的調整。

團隊建設

團隊建設是專案開發中絕對不容忽視的一環。團隊凝聚力如何，直接影響了整個團隊的戰鬥力。因此，建設好團隊，是每個scrum master的重要使命。

那麼如何有效的進行團隊建設呢？

1）放權。敏捷開發的其中的乙個重要的特徵就是團隊自組織。團隊自組織的優勢就在於，通過放權給團隊，讓它們自主的思考，設計開發，不對其干預，從而使得團隊中每個人具有成就感，進而提高整個團隊的積極能動性。

2）打造學習型團隊。乙個方法就是通過團隊內部知識定期分享的方式，使得每個人都能可以學到新的知識，從而逐步使得團隊成長。比如每週五的下午4點，可以利用一小時的時間，讓團隊的成員舉辦知識講座。通過這種形式，大家的積極性會變的很高。可以約定分享的內容並非一定是技術方面的，也可以是生活娛樂等，只要大家感興趣就好。這樣做的好處在於不僅提高了團隊的技術能力，也使得團隊之間能夠更輕鬆愉快的交流，從而提公升團隊的凝聚力，戰鬥力。

3）最後，提高團隊最有效的乙個方法，那就是乙個字：吃；）這是拉攏吃貨們的大好時機。當然這個需要經費，不過方法總會有的，***；）

怎樣做乙個合格的網民

在網上成千上萬的mm中間，怎樣讓很快記住你呢？以我的經驗而言，要想在在最初的交往當中給對方留下比較好的印象，應注意以下幾點 第一，要真誠。當然不是是你真的真誠，而是看上去很真誠，當問你的年齡和職業的時候，你就告訴他 當然是假的 假姓名呢，要等交往到一定程度 他問到第三或第四遍的時候再說，名字盡量普通...

敏捷開發（一）敏捷開發和Scrum

工作的軟體是首要 進度度量標準。敏捷過程 提倡可持續的開發速度。責任人 開發者和使用者應該能夠保持乙個長期的 恆定的開發速度。不斷地關注 優秀的技能和好的設計會增強敏捷能力 簡單 盡最大可能減少不必要的工作 是根本的。最好的構架 需求和設計出自與 自組織的團隊。每隔一定時間，團隊會在如何才能更有效地...

敏捷開發學習 Scrum 一

敏捷軟體開發宣言 個體和互動高於 流程和工具 工作的軟體高於 詳盡的文件 客戶合作高於 合同談判 響應變化高於 遵循計畫 1.sprints 敏捷單元 a.scrum專案週期以一組迭代週期sprints組成 b.迭代週期 2 4周 c.sprints每乙個迭代都包含產品的設計,開發,測試 1.rol...