很多人可能都聽說過敏捷的scrum框架，其中的一部分人可能了解scrum為何物，有的可能已經在專案中實踐過scrum。 那麼， 在本文中，我們來討論一下有哪些方法可以拿來破壞你們的scrum專案，當然如果你珍惜現在的機會，那麼也本文可以如何讓你的scrum專案走向成功。
本文不會詳述scrum基本原則，如sprint，每日站會，視覺化任務板和燃盡圖等，因為如果你正在實施scrum，顯然這些原則都是你必須要做的事情，這裡無需多言。
1、沒有回顧會或者過場面的回顧會
如果沒有sprint回顧會，我們怎麼可能把專案做得更好呢？顯然回顧會是必需的，因為通過每次衝刺後的回顧，每個團隊成員聚到一起，溝通上一次衝刺階段我們有哪些事情做的比較好的，哪些事情可以做得更好。當然了，最重要的是我們必須檢討那些做得不好的事情，特別是錯誤，然後從中吸取教訓，制定改善方案，在下乙個衝刺階段去改進。如果不這樣做，那麼回顧可以說是沒有多大意義的。
2、糟糕的產品負責人（product owner）
產品負責人（product owner）要時刻處於就緒的狀態，參加到每日站會，sprint回顧會和sprint計畫會，但產品負責人不應該在sprint計畫裡去估算待辦事項，因為待辦事項的估算是團隊的責任，是團隊一起去估算的。產品負責人要能夠根據業務和情況的需要對待辦事項進行優先順序排序。產品負責人管理產品願景、發布路線圖和投資回報。並以一種足夠清晰的方式去闡述使用者故事，讓團隊成員能夠準確的迅速的明白其中的意思。sprint待辦事項中不應出現正在進行變更的任務。
3、糟糕的敏捷負責人（scrum master）
敏捷負責人（scrum master）不是團隊的領導，這一點必須要注意了，因為敏捷其中乙個基本原則是：團隊信仰自我管理並支援自我管理，因此scrum master並不是乙個團隊的領導角色，而是在團隊需要的時候，作為乙個領航者引導團隊、管理流程、推動盡早交付客戶價值。如果團隊成員沒能通過討論達成一致，scrum master應該做出最終的決定。scrum master應該能夠羅列出限制團隊效率和進展的障礙清單，並盡快消除這些障礙，讓團隊保持足夠專注，並通過持續改進，保持各項事情順利進行。
任務不應分配給成員，成員應該主動去接任務。
4、scrum會議耗時太長
在每日站會中，每個成員都應該說出昨天做了什麼，今天將做什麼以及遇到什麼障礙了，這就是站會全部的內容。站立不應該用來討論問題或者嘮嗑其它無關事情，陳述內容不必提供詳細資訊。如果需要成員提供詳細資訊，務必在站會結束後單獨詳聊。站會時間盡量不要超過10或15分鐘，具體情況還要取決於團隊規模（如果團隊人數太多咋辦，可以參考亞馬遜兩塊披薩的故事）。
回顧會和sprint計畫會議也應該限制在一定的時間範圍。
堅持scrum會議的精髓，不要會議搞得又臭又長。scrum雖然是乙個很有趣的框架，但它終究不是乙個遊樂場，基本原則要遵守。
5、完成的錯誤定義
在每個sprint結束時，生產的軟體產品應該是處於往生產發布就緒狀態，隨時可以演示。這就要求軟體必須進行過測試，不僅是要通過單元測試和整合測試，還要通過使用者測試/手工測試。生產軟體是乙個複雜的活動，對於所有的團隊成員來說，確切的理解對於給予的專案來說什麼是「完成」了是非常重要的。
6、沒有快速跟蹤
scrum master應跟蹤團隊速度，如果團隊前進速度放慢了，scrum master必須採取一些措施，通過著名的豐田tps系統5問分析法或ishikawa魚骨圖定位到問題根本原因。
7、sprint裡的瀑布（交付半成品）
100％完成75%的故事勝過完成100％故事的75％（完成定義參考第5點），因為後者交付的都是半成品，不可靠甚至不可用的產品。故事是屬於整個團隊擁有的，不是個人，測試人員也是團隊的一員。
8、積累技術債務
必須要避免技術債務，軟體大師martin fowler形容技術債務是「因為選擇了快速但很髒的技術實現，在未來的開發裡我們就不得不付出額外的工作去修復」，否則會在最後出現更多缺陷。在技術債務的影響和快速交付的要求之間可以平衡處理，但是盡量把最核心的技術債務在本次迭代完成，常用的做法是把技術債務作為技術需求對待。重構（或者重新設計）應該在需要時立即進行，因為如果在最後專案完成階段才去做這些事情，花費時間太多成本太高了，越晚修復成本越高。bug要盡快修復。
9、中斷/繞過產品負責人（product owner）
團隊應該保持專注，也就是說太多的中斷將會影響團隊交付。當然可以要求團隊成員中途來支援一下別的事情，但如果是新功能應向產品負責人提出，而不是繞過產品負責人直接向成員提出實現新功能的要求，應該由產品負責人將新功能需求新增到待辦事項中並重新考慮優先順序。如果這是一項重要功能，產品負責人可以安排團隊在下一次衝刺結束時交付該功能。
10、沒有分析/文件
scrum並不意味著可以不進行分析或者不應該編寫文件了，只是分析和記錄文件的方式略有不同：這是乙個持續過程。待辦事項裡的故事點應該要足夠的清晰詳細，以便團隊在sprint計畫會中進行任務拆分和任務估算（故事點將在sprint中去實施，所以它要足夠的詳細才能保證準時交付）。故事點在專案開始時不應過於詳細（但仍然要清晰），但在建立待辦事項時需要估算故事點要其必須足夠詳細。
給想要實施scrum並且想成功實施的建議/結論：
scrum不是一顆銀彈，沒有一種方法可以定義n多個規則然後就可以解決所有問題。相反，它是乙個定義了一些最佳實踐的敏捷框架。當然，你必須遵守其基本原則才能使其發揮作用，忌諱一上來就把框架流程修改得面目全非，並美其名曰結合自身特性實施scrum，其實你可能並沒有通過正確的實踐來驗證標準的scrum框架並不適配你的專案。但是具體如何實施（比如我們什麼時候開每日站會，任務卡怎麼設計，......）取決於你，可能因專案而異。
敏捷就是無招勝有招
摘自 敏捷究竟是什麼？敏捷到底是什麼？敏捷是關於以下三件事情的 1.最重要的，敏捷是一門社會工程學。這是敏捷最大的特點。它關注的是，如何以乙個團隊的形式開展工作，如何激勵團隊成員，如何相互合作等等。2.敏捷是輕量級的。rup完全依賴顯性知識，與此不同，敏捷還依賴隱性知識。在rup中，我們設法把我們認...
敏捷就是無招勝有招
摘自 敏捷究竟是什麼？敏捷到底是什麼？敏捷是關於以下三件事情的 1.最重要的，敏捷是一門社會工程學。這是敏捷最大的特點。它關注的是，如何以乙個團隊的形式開展工作，如何激勵團隊成員，如何相互合作等等。2.敏捷是輕量級的。rup完全依賴顯性知識，與此不同，敏捷還依賴隱性知識。在rup中，我們設法把我們認...
ubuntu8 1 04速成手冊1 0
剛從xp轉到linux系統下面，建議使用ubuntu，相對來說，比較容易入手，同時國內的更新源也比較多，如果有問題的話 url 這裡完全能解決。首先介紹一下ubuntu的軟體安裝大概幾種方式 1。deb包的安裝方式 deb是debian系linux的包管理方式，ubuntu是屬於debian系的li...