是乙個框架，在此框架中，人們可以解決複雜的自適應難題，同時也能高效並創造性地交付最**值的產品，它是輕量級的，易於理解的，難以精通的
敏捷的精髓在於小團隊，個體團隊具有高度靈活性和適應性，當單個、幾個、多個和團隊在開發、發布、運營和維護成千上萬人的工作和工作產品時，這些優勢得以持續運作並發揮價值。
透明、檢視、適應 是支撐每乙個經驗過程實施的支柱
就像從【重新定義公司】提到的谷歌的開會模式，過程中的關鍵環節對於那些產出負責的人必須是顯而易見的，所有人都可以看到、聽到、感受到這些內容，去引發思考和想象，所有的過程不是某乙個人或領導們在參與或主導，而是每個人都在參與，都在未最終結果負責。
檢視則是對過程或階段性目標或結果的驗收和把控，我們不再是安排乙個任務，在最終交付的時候做檢視，而是把乙個大任務或活動切分成了很多細粒度的小因子，相應的目標進度，可以一目了然，這也就要求我們具備一項很重要的技能，對任務或工作的拆分，當前不管是敏捷，還是精益、亦或是pmp、p2，這些優秀的實踐，均開始強調這些，既然我們都不是萬能的，也都不是十項全能，那麼在需要別人協助的時候，把問題拆分，便是解決問題的最好方式。
適應是我們強調要靈活變通，不要死板，調整工作必須盡快執行如此才能最小化進一步的偏離，甚至於在我們制定計畫，執行策略或方案時，對方**的裁剪，去適應我們具體的場景，也是很關鍵的，敏捷、精益、p2理論均如是。
包含sprint 計畫會議、每日scrum 站會、sprint 評審會議、sprint 回顧會議
sprint 是 scrum的核心，其持續時間一般為乙個月或更短的時間，每乙個sprint內構件乙個「完成」、可用的潛在可發布的產品增量。sprint由sprint 計畫會議、每日 scrum 站會、開發工作、sprint 評審會議 和 sprint 回顧會議構成。
每個sprint都可以被視為乙個專案，為期不超過乙個月。
sprint 中要做的工作在sprint 計畫會議中做計畫，這份工作計畫是由整個scrum團隊共同協作完成的。sprint 計畫會議是限時的，以乙個月的sprint來說最多8小時為上限，scrum master 要確保會議順利舉行，並且每個參會者都理解會議目的，scrum master要教導scrum團隊遵守時間盒的規則。
每日 scrum 站會是開發團隊的乙個以 15 分鐘為限的事件。每日 scrum 站會在 sprint的每一天都舉行。在每日 scrum 站會上，開發團隊為接下來的 24 小時的工作制定計畫。通過檢視上次每日 scrum 站會以來的工作和**即將到來的 sprint 工作來優化團隊協作和效能。每日 scrum 站會在同一時間同一地點舉行，以便降低複雜性。
我在做cto和產品總監時，會要求每個產品研發團隊，每天晚上在當天工作結束前的10分鐘開始，團隊成員在站會前把當日工作進度更新完畢，站會時檢視進度，並主要聚焦於問題和經驗分享，以及資源協作和次日的工作調整與安排。
sprint 評審會議在sprint快結束時舉行，用以檢視所交付的產品增量，並按需調整產品待辦列表，在spint 評審會議中，scrum團隊和利益攸關者協同討論在這次sprint中所完成的工作，根據完成情況和sprint 期間產品待辦列表的變化，所有參會人員協同討論接下來可能要做的事情來優化處理。
（1）檢視前乙個sprint 中關於人、關係、過程和工具的情況如何
（2）找出並加以排序做得好的和潛在需要改進的主要方面
（3）制定改進scrum團隊工作方式的計畫
我們可以理解為覆盤，階段性的覆盤，可以幫我們查漏補缺，同時進行團隊協作和工作方式的優化、改進，以此方式不斷以階梯式或螺旋式上公升的方式推動產品迭代和團隊提公升
一名產品負責人、開發團隊、一名scrum master組成。正如現在敏捷、精益大行其道，所有模式的發展正遵循著以專案為中心——以產品為中心——以使用者為中心的發展路線，向前推進，有乙個產品負責人和scrum master來領導的開發團隊，會更專注於使用者增長和商業價值，開發團隊未來的頭腦中也應該會多一些使用者、商業的理念或認知，不再僅僅只有技術，或程式設計、**。
設定我們可以進一步想象，除開發團隊外，我們還會有運營團隊、售後團隊，那麼是不是跟增長黑客的理念吻合了呢，所以說大道至簡、世界大同，很多新的理念都不是那麼高深莫測的，從以前的部門職能團隊，到現在的自組織跨職能團隊，我們所要達成的是怎麼更好的服務客戶，怎麼更有效的創造商業價值。
未來的工作中，我們會看到更多的職能崗位發展成為負責人，就像產品負責人一樣，我們應該擔負起一定的職責，而不僅僅是執行完成工作，這麼簡單
產品負責人是負責管理產品待辦列表的唯一負責人，產品待辦列表的管理包括：
（1）清晰地表述產品待辦列表項
（2）對產品待辦列表項進行排序，使其最好地實現目標和使命，即我們所說的迭代次序、優先順序
（3）優化開發團隊所執行工作的價值
（4）確保產品待辦列表對所有人是可見、透明和清晰的，同時顯示scrum團隊下一步要做的工作
（5）確保開發團隊對產品待辦列表專案有足夠深的了解
在此實踐中，我們還看到了乙個職位scrum master，這個人對於團隊來說，是乙個服務型領導，主要來促進和支援scrum，通過他來幫助每個人理解scrum理論、實踐、規則、價值。
從其職責定位上來看，scrum master以各種方式服務於產品負責人，包括：
（1）盡可能確保scrum團隊中的每個人都能理解目標、範圍和產品域
（2）找到有效管理產品待辦列表的技巧
（3）幫助scrum團隊理解為何需要清晰且簡明的產品待辦列表項
（4）理解在經驗主義的環境中的產品規劃
（5）確保產品負責人懂得如何安排產品待辦列表使其達到最大化價值
（6）按要求或需要引導scrum事件
當然scrum master也要服務於團隊、組織，具體的職責可以檢視附件中的描述，怎麼模擬理解兩者的關係呢，就好像團長、政委、參謀長三者之間的關係，產品負責人就相當於團長，負責產品的整個生命週期，對目標和具體工作決策和領導，負全部責任，scrum master就相當於政委、參謀長，進行理論的宣導和策略的講解，同時制定具體的作戰方針，輔助產品在整個生命週期中各個環境高效、順利執行。 這樣的搭檔模式，才能讓團隊發揮最大效能，產品生命週期更順暢、高效，**或是多人決策，都不是乙個好的選擇。
談談 rm rf 後的幾點體會
目錄 事情始末 直接感受 間接影響 技術層覆盤 心態 習慣反思 平時經常開玩笑，刪庫跑路 刪庫跑路，今天我真的rm rf 了。早上來，乙個同事說要查日誌，但是日誌我又備份到雲磁碟了，我就想著把那一天的日誌wget下來看看，然後分析。本來是想放在 var log 目錄下去，但是我看了一下磁碟的根目錄可...
軟體過程管理的幾點體會
軟體過程管理的幾點體會 1 用例驅動 按照rup的理論，軟體開發過程是以架構為核心 用例驅動 迭代增量的開發過程。用例是rup rational unified process 統一軟體開發過程 統一軟體過程 中非常重要的工件，用於描述系統終端使用者與系統互動的過程，是制定迭代開發計畫的惟一依據，並...
專案開發中的幾點體會
結合工作，分享幾點在專案開發中的體會，是針對一線開發人員的 1 專案需求是怎麼產生的，使用的業務場景是什麼，開發周期是多長 2 在動手開發前，就要先和運維同事多溝通，接下來程式的部署，網路要求，頻寬要求，以及將來的維護，怎麼方便維護 3 開發過程中，任何業務流的改動都要寫下備註 4 具體開發中，伺服...