Scrum筆記

或許不能僅用開發角度(Development Team)去思考它

The purpose of the Scrum framework is to develop products and solve complex problems by using an empirical process that promotes rapid feedback.

Myth 3: In Scrum, releases are done only at the end of the Sprint

Sprint

感覺上是一種時間單位

The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of "Done".

The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created.

The Scrum Guide

和Release的關係

和production release cycles的關係可以和production release cycles脫鉤

和hotfix和urgent patch的關係

參考

和軟體開發的關係

Requirements Analysis System Analysis

Retrospective

提供一個較正式的場域可以==檢視==並==提出改善計畫== The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The purpose of the Sprint Retrospective is to - ==Inspect== how the last Sprint went with regards to people, relationships, process, and tools - ==Identify and order== the major items that went well and potential improvements - ==Create a plan== for implementing improvements to the way the Scrum Team does its work

The Scrum Master ensures that the event takes place and that ==attendants understand its purpose==.

Example

2020/5/28

:::info - problem - chaos commmits - type: process - plan - List related project names with "devops-manager" repository, and Maoji will create the new repos for the related projects individually :::

:::info - problem - PyCharm IDE license - type: tool - plan - Evaluate the price and limitation of PyCharm IDE license :::

:::info - problem - retrospective purpose - type: process - summary - Team-wise - frequency - We may make the Retro on every weekly meeting instead of preserving the specific time slot to do it. - We may forget the topic - There is no topic on the specific time slot and it will cause dead air - scope 1. Topic Sharing 2. Technical Discussion (Ex. System Infra Design) 3. Highlight team workflow’s good part and bad part - Project-wise - scope 1. Discuss about the questions of project - plan - Survey the agenda of Retro Meeting

:::

執行

先以定期和團隊全員在固定時間內進行閒聊作為第一個政策
- 藉這種方式，也能讓團隊在可能緊繃的開發生活中，做點歇息、喘口氣
- 一開始大家都聚在一起，會不會彼此不知道該怎麼聊起，導致眾人都乾在那邊，冷場冷的尷尬呢？會XD
這時候若有人願意分享一些做法或知識，就能成為一個好的開始。目的：==製造一個讓團隊交流的空間==
- 分享的主題可以是既有的知識、可以是某件事自己心目中的理想做法、可以只關於技術、也可以聊聊團隊合作上的小技巧
- 分享時，可以==多帶一點主見==，而不用擔心與其他人不同。相反的，這可能會製造出更多討論的機會，讓每個人都藉著主題分享自己的觀點與習慣或是表達心中的疑惑。只要==有個人能幫忙控場==
  - 控場的人儘量不要和分享主題的成員同一個，而是讓控場的人成為主持人
- 比如說限定每個人的發言時間，或是要求不要打斷別人的發言⋯⋯等等，讓大家能有條理地進行辯論，而不會變成吵架大會。這部分可以在分享開始前先彼此說好，讓團隊成員主動互相提醒
  - 只要能==營造一個能互相尊重發言權利的基礎==，就不太會有問題了
  - 在這個活動中，不是要爭出對錯，每個人都有習慣的方式和認同的哲學，沒有唯一解，重點是能讓彼此更加暸解

流程

分享主題=>團隊討論=>一個可落實的政策或明確的結論

團隊討論可以減少團隊對於這些做法沒有認同感，導致難以落實

營造一個能互相尊重發言權利的基礎

團隊成員主動互相提醒為主, 主持人(Host)控場為輔
討論的方式與規則上的共識(時間, 能否被中斷...)
- 舉例
  - 主講人把整個分享講完再進行，還是中間可以舉手打斷
  - 要能尊重現在發言的夥伴，等他發言完再接著講等等
  - 每個人的發言是否有時間限制，有的話大概多久

參考

Gitlab

Follow the https://docs.gitlab.com/ee/tutorials/scrum_events/

free tier Only have: Labels, Issues, Issue boards, Tasks, Milestones NO Burndown and burnup charts:https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html NO epic: https://docs.gitlab.com/ee/user/group/epics/ NO Iterations: https://docs.gitlab.com/ee/user/group/iterations/