部門開始推行敏捷了，採用SCRUM。其實SCRUM作爲一種方法論，並不難理解與落地，難的是人的觀念與習慣，如何轉變。作爲IT人員，其實都瞭解敏捷，做不到沒有任何藉口，只能是意願問題。但對於非IT企業的業務部門，接受敏捷思想確實有一定難度。因此落地上，產品運維階段，適合採用SCRUM。畢竟只是在IT內部玩嘛，對於業務是感知不到差別的，照常提需求、驗收，若是以前就有需求評審會的話。而對於項目，則較難落地。一是業務不跟你玩，業務不喜歡不確定性，喜歡按照既定流程穩紮穩打，而且人家沒時間陪你試驗新概念；二是涉及甲乙雙方，要嚴苛按照範圍、計劃走，敏捷若沒玩好，交易成本可以無限大。
有意思的是，部門去年推行過敏捷，通過項目管理軟件的kanban功能，要求各團隊把工作錄入到線上運作，結果不了了之。而今年通過海報形式，卻完美落地了。一方面是推行力度的加強，另一方面卻是由於方式的改變。線上kanban，不直觀、不顯眼，還需有人維護系統，有一定學習成本，還能找到系統問題從而拒絕使用，而換了貼紙，繞着辦公室一個團隊貼一張，第二天就全部門上手使用了。天天諷刺業務部門，excel郵件滿天飛，就是拒絕系統。好比拖拉機開的爽，轎車倒開不慣。所以有的時候，管理問題，線下比線上更具效果，雖然管理成本大。
Agile manifesto
individuals and interactions over processes and tools
working software over comprehensive documentation
customer collaboration over contract negotiation
responding to changes over following a plan
之所以互聯網適用敏捷，因爲適合是快速粗放增長的特性。一個APP一個月上線，生命週期半年，當然不用管文檔與工具。先出一版能用的軟件，搶佔市場，然後迭代。2B產品，特別是大公司的重量級產品，ERP能用十年，相關人員都夠換幾波的了，全靠流程化運作與充足的wiki支撐。或者涉及實施方的項目，全靠合同與SOW扯皮，能不專注在前期合同上嗎？又如擁抱變化，業務的變化是無止境的，項目的關鍵是控制變更，目的確定了，那就是以最短路徑到達，不能過分強調變化。當然敏捷的思想，任何角色、任何場景都是值得學習的。這裏強調的，不能爲了敏捷而敏捷，或者把其看做對傳統項目管理的革命。
Agile principles
-
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.我們的最高目標是，通過儘早和持續地交付有價值的軟件來滿足客戶。
-
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.歡迎對需求提出變更——即使是在項目開發後期。要善於利用需求變更，幫助客戶獲得競爭優勢。
-
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.要不斷交付可用的軟件，週期從幾周到幾個月不等，且越短越好。
-
Business people and developers must work together daily throughout the project.項目過程中，業務人員與開發人員必須在一起工作。
-
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.要善於激勵項目人員，給他們以所需要的環境和支持，並相信他們能夠完成任務。
-
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。
-
Working software is the primary measure of progress.可用的軟件是衡量進度的主要指標。
-
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該能夠保持恆久穩定的進展速度。
-
Continuous attention to technical excellence and good design enhances agility.對技術的精益求精以及對設計的不斷完善將提升敏捷性。
-
Simplicity–the art of maximizing the amount of work not done–is essential.要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。
-
The best architectures, requirements, and designs emerge from self-organizing teams.最佳的架構、需求和設計出自於自組織的團隊。
-
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.團隊要定期反省如何能夠做到更有效，並相應地調整團隊的行爲。
five activities
-
product backlog refinement；
-
spring plannning
-
what can be done?
-
how to get it done?
-
-
daily stand-up
-
what did i get done yesterday?
-
what will i get done today?
-
any impediments blocking me?
-
-
sprint review
-
sprint retrospective
-
what shall we start doing?
-
what shall we stop doing?
-
what shall we keep doing?
-
以月爲衝刺週期，因團隊規模小，採用了簡化版的會議形式，縮減爲三個例會：
-
月度版本會議（成果及問題；改善；下個迭代期計劃）2H
-
每日站會 15min
-
每週五總結會議 （這周做了什麼，下週計劃，任何阻礙/幫助）30min
three roles
-
development team
-
product owner
-
Scrum master
PO與SM，可以理解成一個做正確的事情，另一個正確的做事情；PO連接客戶與管理團隊，而SM連接管理團隊和開發團隊；開發團隊聚焦每一個衝刺期內的質量，及各衝刺週期的關係，不斷提升能力。目前團隊規模小，產品經理身兼PO及SM。。
three artifacts
-
product backlog
-
spring backlog
-
increment
產品積壓項面向功能點function，衝刺擠壓項面向特性feature
requirement management
-
user story：As a [a user role], I want to [accomplish a result], So that [I can get some business value]
-
3C
-
card
-
conversation
-
confirmation
-
-
INVEST
-
independent
-
negotiable
-
valued
-
estimated
-
sized appropriately
-
testable
-
-
PSPI: potentially shippable product increment
-
DOD definition of done
-
DOR definition of ready
重點是用戶故事，用故事點評估工作量，顆粒度如何衡量。
test driven work
-
TDD test driven develpment
relative estimation
agile planning &tracking
-
release level；
-
decide when to release what, at refinement meeting;
-
feature burn-up chart
-
-
sprint level;
-
burn-down chart
-
planning poker
-
-
daily
