Scrum是敏捷開發原則下，目前在軟體產業裡常見的方法論。而由於Scrum只是個方法論，並沒有所謂的標準，各個組織的應用方式皆有不同。常見的應用(practice)，例如：spint-kick-off-meeting, daily standup, burn down chart, planning poker, retrospective。
零零總總的practice中，哪些最為重要當然眾說紛紜。考慮到Scrum的真正精神，以下三件事情是「最基本要有的」。也就說，如果這三件事情做不到，那麼其他事情做到也沒有用。
(1) 每個Sprint有交付具體產出
Scrum的Sprint都要有具體「可交付」的產出。sprint的開始，就應該以「結果」為計畫的導向，而此結果必須要是可交付的產出。
有些團隊會以Sprint長度不夠為理由，設定一個「並不能交付」的milestone作為該sprint的產出。如此一來會有幾個問題：(1) sprint結束的檢討，並不基於產出的事實 (2) kick-off下一個sprint的意義不大，因為前一個sprint並沒有真正可在市場衡量的產出 (3) PO會有充足的理由不參加demo以及下一個sprint的kick-off，畢竟這個sprint沒有有意義的產出，而如此一來PO就很容易不真正加入團隊。
Sprint不見得要固定長度，請參考這裡。
(2) PO有確實加入Scrum團隊
Scrum團隊成員有三個角色，team member, scrum master, product owner。其中最容易不在的人，就是product owner。許多軟體開發團隊，product owner就是PM。但無論如何，Product owner必須要真實參與團隊。
所謂真實，指的是所有standup應該參加，在團隊運作過程，能夠回答該sprint的需求問題，並確實知道sprint中間「不應該做的事情」以及sprint開頭結尾「應該做的事情」
更重要的是PO加入團隊之後，DOD(definition of done)的標準才會具有「市場一致性」。舉例來說，不成熟的軟體研發人員常會對事情做完有不同的定義：
「程式寫完只是還沒review，所以還沒merge」
「程式寫完測試也沒問題，只是QA還沒通過」
「功能搞定了，QA也沒問題，只是還沒...」
PO確實加入後，可以讓事情做完的定義，統一在於「可準備交付到市場」。換言之，所有和程式設計相關的工作：測試，相關文件，環境設定，certificate等等都會以「可準備交付到市場」為原則。沒有這個原則，跑Scrum很難達到預計效果，要達到這個原則，最基本的就是PO需要確實投入團隊。
(3) 每個Sprint結束之後有確實地檢討(Retrospective meeting)
這世界上沒有完美的團隊，也沒有不用修正的軟體開發方法論。每個sprint的確實檢討，是修正團隊，讓團隊趨於一致的唯一方式，而非強加訴諸任何規矩。請參考這裡
確實的檢討並不容易，要做到兩件事情：
(a) 基於事實檢討
(b) 不檢討不在場的人事物
基於事實的檢討
檢討的內容必須基於事實，不是基於感覺與想像。感覺和想像的情況如下：
「我感覺好像有點慢」
「不知道怎麼講耶 但這個事情不應該這樣做」
事實的情況舉例如下：
「這個sprint我們沒有按照當時說好的DOD的定義，所以有XX與XX項目，本來說完成了，後來隔幾天又說沒完成」
不檢討不在場的人事物
檢討確實是對事不對人，然而，事情都是人做的，不可能不檢討「人的做法」。不檢討「人的做法」只是鄉愿。
不過，要避免檢討不在場的人。
例如「因為UI/UX之前給的東西不正確，導致我們要重做某些事情」如果UI/UX是同一個scrum團隊，那麼檢討此項目當然可以。但要是不是同團隊就沒有意義。
因為，Scrum的檢討會議目的是產生「團隊要改善的項目」，而不是去讓非團隊的人改善。
Scrum的學習必然是從實際的經驗獲得，但經驗的獲得又必須從知識學習的取得為基礎，要成為看似不錯的Scrum專家不難，但要實際應用於專案中，並取得可重複成功的結果就不這麼容易了。
任何軟體專案或產品，達到高品質是開發團隊必然的目標。不過高品質並非垂手可得，它需要團隊的共識和努力才能達成。
確保品質有很多方式。過去常見的方式是瀑布式開發方式(waterfall)中，在程式設計師確定code complete之後，靠QA/QT/QC(註1)來執行測試，並且在測試週期中，驗證是否符合設計規格，並記錄追蹤問題(bug)，有時候甚且扮演催促修復的角色。因而，特別是大型團隊，專門「處理」品質的QA角色十分重要。很多時候，團隊可能面臨沒有QA的狀態，此時要如何確保品質呢？
為什麼會沒有QA
有時候，環境造就沒有QA的局面。例如，新創公司可能也只有5個人，無法有專責QA。又例如，大型企業中因資源分配不均，導致某些專案無法有專責QA。
但更多時候，沒有QA指的是，沒有能做「真正QA工作」的人。也許團隊裡面有許多人持有QA的職稱。但很可能僅做到QC/QT的工作(註1)。實務上，在軟體開發團隊中，實際做的事情其實比職稱來的重要。就品質的角度而言，QA大部分的時間應該花在開發循環「前期」或者「中期」。以Scrum中的Sprint來說，在kick-off時，QA應該花最多時間在定義DOD，決定產出的評斷標準，在sprint每天活動中，QA應該花時間在檢視產生的程式碼(code review)並且透過每個工作產出，主動改善現有品質。換言之，QA應該比單純的程式設計師，更會程式，更知道系統的交互作用細節，並能透過直接或間接修改程式，直接影響開發過程中的品質。因為，開發前中期的品質修正，效果好，成本低，遠比開發「後期」再來幾個測試循環來的有效！
簡要的說，能真正做QA工作的人，必須能比程式設計師團隊更會寫程式。起碼也要是「曾經」非常會寫程式。
如果團隊不巧沒有這樣的人，有三種方式可以在沒有QA的情況下確保軟體開發的品質：
方式一：Scrum
Scrum方法論中，概念上每個Scrum成員都是「同樣質量」。換言之，Scrum進行中重視的是產出，每個SPRINT的結果是「可交付的東西」。而Sprint中間要完成的細項，應該將品質涵蓋入內，而由自行取得該任務的人，完成其保證。
有許多作法和上面這段熬口的說明有關。首先，DOD (definition of done) 除了涵蓋unit-test之外，其實應該也涵蓋整合測試。如果不涵蓋整合測試，就應該另外有一個任務是專做測試。並且，每個story完成中，必定涵蓋這個story應該要有的使用測試(用以檢驗規格)以及回歸測試(用以檢驗是否有副作用)。這些測試，可以單獨成為一個工作，也可以作為DOD的一部分。
無論如何，基本概念是：「人人應該都可以生產程式碼，當然人人應該都可以測試」。實際執行時，或許有些人比較常「拿到」測試工作，但這並不代表這些成員就只是進行測試而已。有些人比較常拿到「寫程式性質」的工作，但並不代表這些人不負責品質。
Scrum的團隊重視每個Sprint的共同結果，此結構也讓沒有QA也能達到高品質。因此Sprint的長度不能太長，太長就會落入「團隊中自行區分QA和Engineer」的後果。
方式二：Pair Programming
Pair Programming是指兩個人一起用一台電腦，一個鍵盤來共同寫程式。這作法在2000年左右發展的Extreme Programming被大大推崇，不過能有決心推動的團隊並不常見。
由於Pair Programming讓每段程式碼至少都會被兩個人看過，而且在頭腦中想過。它可以避免大部分的低級錯誤(拼錯字)，也可以避免懶人錯誤(程式風格，漏寫unit-test)，然而，更重要的是它讓兩個程式設計師的真實想法，在執行同件事情的時候被「好好溝通」。而這更大幅避免對設計或需求的誤解。
Pair Programming似乎有效率和產能上的疑慮，但無論如何，它確實是在沒有QA的情況下，確保開發品質的絕妙方式。強烈建議閱讀一下wiki上的Pair Programming最下面的參考論文。
注意！
前兩個方式雖然符合敏捷開發的精神，並且能從系統結構層面，解決問題。然而，這兩種方式都必須要有結構性的改變，除非是剛剛成立的新團隊，要造成結構性的改變很困難，而且，即便做的好，也得花上其他心血才能有「能見度」，有能見度，才有所謂的功勞。
有兩個古時候的例子：
(a) 鶡冠子扁鵲：扁鵲曰「長兄最善，中兄次之，扁鵲最為下。」魏文侯曰：「可得聞邪？」扁鵲曰：「長兄於病視神，未有形而除之，故名不出於家。中兄治病，其在毫毛，故名不出於閭。若扁鵲者，鑱血脈，投毒藥，副肌膚，閒而名出聞於諸侯。」
(b) 孫子兵法：故善戰者之勝也，無智名，無勇功，故其戰勝不忒。
然而，對於一個軟體專案的主管而言，這些結構性的改變才是自己真正的價值。即便價值很難被衡量，但價值會永遠存在自己的手上。
如果短時間難以改變環境，可以考慮以下的方法三：
方式三：Part-time & Automation
工讀生(part-time student)和自動化測試(automation)似乎是兩個不同主題，但就確保軟體開發品質而言，把他們當做「一件事情」來處理，會有驚人的效果。
簡單的說，就是雇用3至4個優秀的工讀生，每週上班2-3天，組成工讀生團隊，執行測試任務，並且在熟練測試任務之後，開始進行測試自動化撰寫，並且在小組長(team leader)帶領下視情況參與更多品質管理的事情。這聽起來是個繁複的事情，但執行起來，遠比方法一二簡單。
其步驟如下：
(a) 選定一位以後想要朝專案經理或主管方向前進的優秀資深工程師，讓他作為工讀生團隊小組長
(b) 到各大學相關科系徵求大四以上的長期工讀生，一般來說，只要能妥善說明對他們未來就業的好處，通常可以找到足夠優秀的人。工讀生至少需要在職6個月以上。
(c) 組成團隊後，第一個月僅只需要熟悉目前軟體系統，第二個月才開始讓他們執行測試計畫，回報並記錄問題
(d) 在此過程中，由小組長指定測試內容和範圍，換言之，這段期間，其實小組長才是扮演QA的角色。而其他成員都可以將繁瑣的測試交給工讀生。然而，程式的品質仍然是所有成員負責，工讀生不在Scrum的範圍內，因此不「負擔責任」。
(e) 當測試進行2個以上SPRINT，工讀生應該已經開始覺得測試是很煩人的事情，但也應該知道品質對產品的重要性。這和在學校做專案計畫有天壤之別。因此，就可以開始由小組長領導工讀生進行測試自動化。
(f) 測試自動化並不期望把所有整合測試/回歸測試，100%統統自動化。只要把「簡單瑣碎」的測試自動化，通常就能節省一半以上的時間
(g) 通常六個月後，3-4人的工讀生團隊就能完成部分整合測試，和大部分的回歸測試。而下一輪的新工讀生，可以選擇從頭開始打造新的測試自動化，也可以接手前期工讀生做到一半的自動化。打造新的自動化通常可以用新的工具，新的角度來測試既存系統，可以讓品質在一次提高。接手前期工讀生的自動化，可以讓自動化範圍更廣，空出時間來做其他的事情
工讀生進行自動化測試的開發，對組織，對小組長，對工讀生有三贏的效果。(參考：實習生的三贏)
組織：讓沒有QA的團隊，能確保高品質的產出。除了要花些微的工讀費用之外，讓團隊成員能把瑣碎的事情下放給優秀的工讀生，使團隊成員能集中心力，但又同時負責個人生產的品質。同時，由於利用工讀生來培養小組長，讓組織能了解這個資深工程師，適不適合作為領導者，萬一不適合，頂多也是犧牲工讀生而已。
小組長：沒有人生下來就會當主管，當主管必須要有經驗，而工讀生團隊是主管最容易讓資深工程師測試自我的地方。因此小組長可透過這獨立運作的團隊，練習各種管理技能。
工讀生：大部分優秀的大四以上學生，都猜得到業界和學界的差異。許多人可能會在暑假應徵summer intern，然而其實短短兩個月，通常會做比較獨立的專案，雖然都很有趣，但是和在學校有很大的不同。加入實際開發團隊，即便只是做測試，也能了解「現實和學校」的差距，並且體會到軟體專案開發時，品質的重要性。讓有此六個月經驗的工讀生，更容易在未來找到更好的工作。
註1：關於Quality Control, Quality Test, Quality Assurance, test engineer, SQA的各種工作角色的區分，請參見wiki。然而，誠如前所述，工作角色名字不重要，做出事情才重要。
In certain scenario, a scrum project could allow different length of Sprints and still satisfies Timeboxing principle. It benefits an involving software product of build MVP, increase integration quality and make members even more focus.
Time-boxing is one of fundamental practices in Scrum methodology. Most of actions in scrum are time-boxed. It makes sure the project keep going and also lets members focus on current task.
Time-boxing is one of the cure of Parkinson's Law of Triviality for all kind of meeting. No matter it is Sprint kick-off or daily standup. I believe it should apply to not only project management but also other area of organization, as long as the timeframe is a consensus of members.
You can easily find the definition or discussion of how important time-boxing (or timebox) is in google. For example: this one or this one.
Timeboxing in Sprint
A Sprint in scrum also apply to time-boxing. Normally it means when project kick-off, all scrum members will decide how long is a Sprint. The recommended length is 4 weeks in software development. After that all Sprint will be in 4 weeks, no matter how many stories have done or what changes happened between Sprints. That also means if a project is in Sprint-11, 40 weeks was gone.
A fixed timebox sprint make process happens. But is it necessary to keep the same length of Sprint?
Still timeboxing but flexible in next Sprint
Timeboxing is still critical and should be applied in the moment before event start. Sometimes, we should not fix timeframe in project kick-off and keep for next 40 weeks or more.
In fact, every Sprint kick-off meeting should also discuss a timeframe of this specific Sprint.
Image a sprint-kick-off meeting. Everybody: Product Owner, Scrum Master, Scrum Members were together in this Sprint kick-off meeting, discuss stories and story-points. If PO select 3 stories: P1, P2 and P3 which needs 2 weeks, 1 weeks, 3 weeks. What team should do? The general practice should be keep P1 and P2 in this Sprint and also select a few lower priority task to fill up that one left week. However, there are a few drawbacks in this situation. Firstly, remember Parkinson's Law? members might extends the time for not select lower priority tasks which sometimes is not a bad idea. But secondly, if a scrum team keep doing select a lower priority to fill up time slot, it make the "priority" not "priority" any more.
If all members have consensus of flexible Sprint length, they can easily setup next Sprint to 3 weeks. And that Sprint will done P1+P2. Or with Product Owner's agreement, they can setup next Sprint to 6 weeks to complete all P1~P3.
In some scenario, the most beautiful way should be keep P1 in next sprint only. And this Sprint will be just 2 weeks.
Make MVP possible
Why do one story at one Sprint is a beautiful way? Well, in some scenario, we need to make MVP(Minimum Viable Product)...and keep make MVP for a while to identify market and make sure minimum waste. Unfortunately, no body can foresee the future. A quick/early delivery is the reason why MVP is useful and also the reason why it is good to stick a single story delivery in a single Sprint. To achieve that, we need flexibility in different Sprint.
The key person of MVP is Product Owner (PO). And to make MVP possible, the bottom line of scrum is to have PO's real participant. In reality, it is very very hard to PO to focus on what he needs to do. A single story delivery forces PO to make a decision of the real priority of backlogs. Since the team will really delivery a things in every Sprint and of course PO should then put the thing in the market. PO can't say: well, it is too early to go for market. Since this is his priority one! Priority one should go for market right away!
Why Quality improved?
Very simple, each Sprint with only one story has its own QA process and due to the complexity of change is short. we can easily fix integration issue or new defeat much quicker than a sprint with more than one story.
Agile: Feel comfortable to Adopt reality
An agile team should be comfortable to adopt changes and those changes should reflect to reality. But should still keep the critical concept. There is always a way to enjoy both without compromise to an uneasy method.
To be flexible in Sprint length doesn't mean to break Timeboxing. But it does break some rule from the regular Scrum training. Nevertheless, process is continuously improving is the bottom and spirit of Agile. Scrum master or organization leader should take responsibility to make sure the process could be tailored after retrospective.
Case Study
As developer manager of a enterprise software product, I modify a bit of product release method to make sure PO's backlog is a real priority to reflect market needs.
The result is since 2016/July to 2017/Mar (8 Month), we delivery 5 releases. The longest Sprint is 8 weeks and the shortest Sprint is 2 weeks. We actually complete 5 major stories and achieve following technical result.
(1) Quality: no side effect in these 5 release. Compare to previous fix Sprint length model much lower technical defeat in beta.
(2) Productivity: averagely, more code conduct per engineer compare to previous fix Sprint length model. However, at the same period of time, we enjoy more team building activity then before and very very very few overtime.
(3) Motivation: engineer could see the result (no matter good or bad) few weeks after delivery. Previous fix Sprint length model needs 3 to 9 months to know if our works really matters.
If you'd like to know more detail, please drop me email.
