雖然這篇文章討論了scrum中的一些常見指導原則，但重要的是要記住這些指南是靈活的，應根據您團隊的需求進行塑造。
當我提到規則時，我指的是那些無法修補以適應特定背景的方面。例如，沒有產品負責人，開發團隊和scrum master，您就無法做scrum。
當我提到指南時，我指的是那些可能被改變以適應特定背景的方面; 但是，影響只能在實施後進行驗證。然後我們相應地檢查和調整。
例如，product backlog細化消耗不超過團隊容量的10％。容量是小時數，故事點數還是天數？嗯，沒有規則。scrum團隊自我組織並選擇最適合他們背景的東西; 遵循我們消耗的指導方針，不超過團隊容量的10％。
在這篇文章中，我將**一些將11個要素繫結在一起的指南，並讓scrum團隊靈活地將這些方面融入其背景中。
建議開發團隊的規模為3-9名成員。根據具體情況，可能會有更多人或更少。它的影響因團隊環境而異。不到三個開發團隊成員減少了互動，導致生產率降低。較小的開發團隊可能會在sprint期間遇到技能限制，導致開發團隊無法提供可能可釋放的增量。擁有超過九名成員需要太多的協調。大型開發團隊為實證過程提供了太多的複雜性。
我使用過的大多數團隊都使用了每日scrum的三個問題的格式：
這三個問題只是以scrum開頭的團隊的模板。只要他們專注於sprint目標的進展，開發團隊就可以按照他們認為合適的方式構建他們的daily scrum。
事件的時間框表示乙個月sprint事件允許的最長時間。指南是：對於較短的sprint，時間限制通常較短。
這是否意味著，對於為期兩周的sprint，sprint planning的時間限制為四小時，sprint review為兩小時，sprint回顧為乙個半小時？沒有。
只要滿足其目的，事件可以根據需要調整短/長，但它們不能超過最大分配時間。例如，sprint計畫為期兩周的sprint計畫活動如果達到目的可能會在兩小時內結束，如果不滿足，則可能會持續八個小時。
scrum指南建議使用燒毀圖表和累積流量等實踐來監控進度。但是，團隊可以完全自由選擇他們認為合適的任何練習。根據我的經驗，我見過團隊建立視覺路線圖，基於里程碑的進度，旅程線，釋放燃燒圖表等。我們還需要記住，在複雜的環境中，只有經驗資料才能幫助我們做出正確的決策。
在scrum的指南介紹了需要積壓的產品專案來進行估計。如何估算它們完全取決於scrum團隊。故事點，理想日，t恤尺碼，狗尺碼是一些方法。
scrum團隊可以做「沒有估計」嗎？當然，只要scrum團隊能夠起草支援經驗主義的計畫，建立透明度，並幫助團隊在sprint結束時建立可能可釋放的「完成」增量。scrum團隊自行組織選擇適合其背景的內容。
在「選擇的工作將如何完成？」部分下。對於sprint計畫，scrum指南提到：
開發團隊在sprint的頭幾天計畫的工作在本次會議結束時進行分解，通常分為一天或更短時間。然而，這通常有助於發展團隊這樣做。根據我的經驗，我看到幾個團隊沒有將他們的工作專案細分到如此細緻的水平。他們了解如何將功能轉換為「完成」增量。
scrum指南還描述了sprint review中的元素：
對於已經獲得資助一年的scrum團隊來說，在每兩周一次的sprint評審中審查其預算是否有意義？也許不吧。並非所有上面提到的元素都適用於所有scrum團隊。它們作為指導提供，以便scrum團隊可以選擇在sprint審核期間討論和觸及產品交付的各個方面，因為他們認為適合他們的上下文。
每個sprint的目的是建立乙個可能可釋放的「完成」增量。這意味著增量需要處於可用狀態並滿足scrum團隊的完成定義（dod）。
然而，將增量釋放到生產中的選擇由產品負責人決定。根據團隊的上下文及其建立的增量，scrum團隊可能決定每個sprint執行多個版本，每個sprint發布乙個版本，或者累積發布多個sprint; 無論如何優化產品的價值。
「完成」的定義有助於提高透明度，並對完成工作的含義達成共識。根據scrum指南，scrum團隊有望擴大他們的國防部並使其更高質量的更嚴格。
同樣，這不是乙個規則。取決於團隊的背景; scrum團隊可能會在每次回顧中重新審視它的國防部，或者可能繼續使用相同的國防部，除非它學會了新的東西以提高產品的質量。
這些只是scrum指南中的一些指導原則。我想提出這種區別，因為我經常發現scrum團隊與scrum規則和指南混淆。幾乎沒有什麼是常見的- 將sprint計畫的時間安排為兩個星期的sprint或開發團隊花費太多時間和精力將pbi分解為「任務」 - 其他人並不常見。我相信這篇文章將幫助團隊確定scrum的一些方面，他們可以修改這些方面以適應他們的背景。
Scrum 指導原則
雖然這篇文章討論了scrum中的一些常見指導原則，但重要的是要記住這些指南是靈活的，應根據您團隊的需求進行塑造。當我提到規則時，我指的是那些無法修補以適應特定背景的方面。例如，沒有產品負責人，開發團隊和scrum master，您就無法做scrum。當我提到指南時，我指的是那些可能被改變以適應特定背...
類設計指導原則
乙個類應該代表乙個邏輯部件，封裝資料和行為 不要只封裝行為，也不要只封裝資料。類是面向使用者的，為使用者提供服務 設計類時，首先考慮乙個類對使用者有沒有用，其次考慮乙個類要提供哪些介面來滿足使用者的要求。類應該向使用者提供少而準的介面 少即最少，目的是使類盡可能簡練。準即準確，目的是使類能準確完成任...
指導原則 閱讀原始碼
了解這個功能模組的設計模式追蹤函式呼叫時所傳遞引數 輸入輸出模型，抓住關鍵資料流 關注類的上下文環境了解函式的參與物件 類學會畫類圖和時序圖理清對應類的功能了解各類的耦合相關性嘗試理解所採用的設計理念時刻記住函式類的目的抓住全域性變數的線索 如static，threadlocal，特殊的資料結構 輸...