敏捷開發心法
•
0 likes•1,916 views
This document provides an overview of agile development principles and methodologies. It discusses concepts like Scrum frameworks, roles on agile teams, product backlogs, sprint planning, and user stories. Links are provided to external resources on these topics. The document also includes examples of writing user stories and estimating tasks in story points. Hands-on activities are suggested for practicing sprint planning and management using a Scrum board.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 敏捷開發心法
Similar to 敏捷開發心法 (20)
More from Bryan Yang
More from Bryan Yang (14)
Recently uploaded
Recently uploaded (20)
敏捷開發心法
- 3. BASIC WORKFLOW OF DEVELOPMENT https://admhelp.microfocus.com/octane/en/latest/Online/Content/Flows/flow_SW_Development.htm
- 5. https://interviewsteps.com/blogs/news/the-ultimate-list-of-141-project-manager-interview-questions
- 10. WHAT IS AGILE?
- 12. MINDSET FIRST https://www.linkedin.com/pulse/one-year-agile-teams-afrogleap-arthur-von-kriegenbergh/
- 15. W
- 16. 敏捷原則 . 我們最優先的任務，是透過及早並持續地交付有價值的軟體來滿⾜客⼾需 求。 . 竭誠歡迎改變需求，甚至已處開發後期亦然。敏捷流程掌控變更，以維護客 ⼾的競爭優勢。 . 經常交付可⽤的軟體，頻率可以從數週到數個⽉，以較短時間間隔為佳。 . 業務⼈員與開發者必須在專案全程中天天⼀起⼯作。 . 以積極的個⼈來建構專案，給予他們所需的環境與⽀援，並信任他們可以完 成⼯作。 . ⾯對⾯的溝通是傳遞資訊給開發團隊及團隊成員之間效率最⾼且效果最佳的 ⽅法。 https://medium.com/⽂文思不藏私/⽂文思不藏私-敏捷宣⾔言-12-原則-64ad7d592087
- 17. 敏捷原則 . 可⽤的軟體是最主要的進度量測⽅法。 . 敏捷程序提倡可持續的開發。贊助者、開發者及使⽤者應當能不 斷地維持穩定的步調。 . 持續追求優越的技術與優良的設計，以強化敏捷性。 . 精簡──或最⼤化未完成⼯作量之技藝──是不可或缺的。 . 最佳的架構、需求與設計皆來⾃於能⾃我組織的團隊。 . 團隊定期⾃省如何更有效率，並據之適當地調整與修正⾃⼰的⾏ 為。 https://medium.com/⽂文思不藏私/⽂文思不藏私-敏捷宣⾔言-12-原則-64ad7d592087
- 21. HOW TO BE AGILE?
- 23. EVERYONE IS A PIG https://www.safaribooksonline.com/library/view/learning-agile/9781449363819/ch04.html
- 26. 1. SET CLEAR GOALS 2. PROVIDE IMMEDIATE FEEDBACK 3. MAXIMIZE EFFICIENCY 4. ALLOW FOR DISCOVERY Jim Ramsey TEXT
- 37. BUILD A SCRUM TEAM
- 38. 在⽂文化中適應了了可預測性的⼈人，會相信他們可 以預測未來來，他們的⼯工作就變成了了藉著⽤用暴暴⼒力力 法強迫⼈人們跟資源讓那個未來來發⽣生。 ⽽而 SCRUM 的⼈人相信當遇到複雜的、有創意的⼯工 作，像是軟體開發，可預測性是不可能的。 Ken Schwaber TEXT
- 40. SCRUM VALUES
- 44. ROLES IN A SCRUM TEAM https://www.scrum.org/resources/blog/how-do-3-scrum-roles-promote-self-organization
- 45. PRODUCT OWNER
- 46. The Product Owner is responsible for maximizing the value of the product and the work of the development team. Scrum Guide TEXT
- 51. ALTERNATIVES 2
- 52. ALTERNATIVES 3
- 55. SCRUM MASTER
- 62. TEAM MEMBERS https://www.forbes.com/sites/stevedenning/2016/09/08/explaining-agile/#7480e4f9301b
- 63. https://www.netsolutions.com/insights/the-role-of-business-analysts-in-distributed-agile-projects/
- 68. AGILE TO CONTINUOUS DELIVER https://www.slideshare.net/QASymphony/where-testers-qa-fit-in-the-story-of-devops
- 69. LET'S SCRUM
- 80. CASE STUDY ▸ ⼩小明想和他家⼈人在暑假前去北海海道玩，請依照⼩小明的需求規 劃⼀一份⾏行行程表． ▸ 需求: ▸ 長輩喜歡⼾戶外⾏行行程 ▸ ⼩小明喜歡逛街 ▸ 想吃海海鮮，拉麵和燒⾁肉
- 81. HANDS-ON ▸ According to the needs of the customer, choose a product owner from your team members. ▸ Ask your customer 3 questions about the product.
- 82. PRODUCT BACKLOG
- 86. RELEASE MAP AND USER STORIES https://www.smashingmagazine.com/2017/09/comprehensive-overview-ux-design-deliverables/
- 88. USER STORY AND BACKLOG ▸ 3 Ws ▸ Who (user role) ▸ What (goal) ▸ Why (reason) ▸ 3Cs ▸ Card ▸ Conversation ▸ Confirmation
- 89. EXAMPLE ▸ AS a [User Role], I want to [Goal] so I can [Reason]. ▸ As a registered user I want to login so I can access subscriber-only content
- 93. WRITE A GOOD USER STORY https://www.farreachinc.com/blog/far-reach/2017/03/23/scrum-posters-(free-downloads!)
- 95. BUSINESS VALUE AND PRIORITY https://michaellant.com/2010/05/21/how-to-easily-prioritize-your-agile-stories/
- 97. HANDS-ON ▸ Write down 5 user stories and give each of them a business value. ▸ Please prioritize those user stories. ▸ Write down how to confirm them.
- 100. STORY POINTS http://agiledigest.com/agile-digest-tutorial/agile-estimation/ IMPORTANT: ONLY PEOPLE WHO WILL EXECUTE TASKS CAN ESTIMATE STORY POINTS
- 101. TIPS ▸ 相對估算 > 絕對估算 ▸ 粒度⼩小 > 粒度⼤大 ▸ 估算單位⽤用費式數列列當作參參考 http://www.codedata.com.tw/social-coding/estimation-with-dog-point-game/
- 104. ADVANTAGE OF THIS METHOD ▸ For PO/PM: ▸ 不⽤用擔⼼心被某些特定的 member 呼嚨或灌⽔水。 ▸ 評估過程中瞭解需求或任務在實作時，潛藏的難度在哪。 ▸ 瞭解需求是否還有需要說清楚或被誤解的部分。 ▸ For team: ▸ 不再是不做事的⼈人依照 deadline 給予⼀一個不合理理的時程限制。 ▸ 在還沒開始動⼿手進⾏行行任務之前，屬於開發⼈人員之間的知識交換。不論因此增加或減少 估算的數字，都讓需求更更明確，預估更更客觀。 ▸ 因為還不知道由誰認領此任務，所以客觀且有共識，透過過程也可以知道誰對此任務 熟悉度比較⾼高，實際進⾏行行時，可以結對編程或知道找誰詢問與協助。 http://www.codedata.com.tw/social-coding/requirement-story-point-planning-poker/
- 105. STORY POINT AND ROI https://www.scrumalliance.org/community/articles/2012/january/key-dimensions-of-user-stories
- 106. SCRUM BOARD http://www.agilebuddha.com/agile/printing-physical-scrum-board-from-atlassian-jira/
- 107. HANDS-ON ▸ Each sprint will be take 3 minutes. ▸ Put user stories in the backlog for next sprint. ▸ Convert each user story to tasks. ▸ Estimate story points of each tasks.
- 110. IF YOU FACE A PROBLEM LIKE THIS... http://lukeangel.co/project-management/whats-a-workback-schedule/
- 113. SCRUM BOARD WITH BURNDOWN CHART http://old.xpday.net/Xpday2008/sessions/SCRUM%20Board%20Game.html
- 114. MISUNDERSTANDING OF STORY POINTS ▸ Equating Story Points To Complexity, Uncertainty or Value. ▸ Translating Story Points To Hours. ▸ Averaging Story Points. ▸ Adjusting Story Point Estimates of Issues During Sprint. ▸ Never Story Pointing Bugs. ▸ Conforming To The Expert In The Room. ▸ Not Discussing Incorrectly Story-Pointed Issues In Retrospective.Not Discussing Incorrectly Story-Pointed Issues In Retrospective. https://medium.com/bynder-tech/12-common-mistakes-made-when-using-story-points-f0bb9212d2f7
- 115. REFLECT ▸ 這樣的做法在我們 team 裡⾯面可能遇到什什麼問題?
- 117. DAILY SCRUM
- 120. THE DAILY STAND-UPS ARE MORE THAN JUST ASKING WHAT YOU DID AND IF YOU’RE BLOCKED. IT’S ABOUT REACHING THE SPRINT GOAL! Patrick van Marsbergen TEXT
- 121. HANDS ON ▸ Let's develop (2 min) ▸ Please hold a stand-up meeting in 30 seconds ▸ Let's develop again (2 min) ▸ Please hold a stand-up meeting in 30 seconds
- 123. SPRINT REVIEW & RETROSPECTIVE
- 126. SPRINT REVIEW
- 127. HANDS-ON ▸ Please demo your project to the customer. ▸ Check what is not done in this sprint and move them to the "To Do" column.
- 129. RETROSPECTIVE QUESTIONS ▸ 是否滿意⾃自⼰己在公司內扮演的⾓角⾊色？ ▸ 你對公司整體的滿意度為何？ ▸ 為什什麼？ ▸ 在下⼀一段衝刺刺中，有哪件事能讓你更更滿意？
- 130. HANDS-ON ▸ Please hold a retrospective meeting and write down: ▸ what worked well ▸ what can be improved ▸ how to improve in the next sprint
- 131. HANDS-ON ▸ Let's do again from plaining this sprint!
- 132. RETROSPECTIVE
- 133. WHAT IS THE DIFFERENCE BETWEEN THOSE ROLES? https://www.infoq.com/news/2012/10/pm-scrum-master
- 134. WHAT IS THE DIFFERENCE BETWEEN THOSE ROLES? https://www.infoq.com/news/2012/10/pm-scrum-master
- 135. WHY SCRUM BOARD?
- 137. ABOUT SCRUM EVENTS ▸ Please share your experiences in Scrum event ▸ User Story ▸ Sprint backlog ▸ Daily stand-up meeting ▸ review ▸ retrospect
- 138. 【⽂文思不藏私】@笨蛋，問題不在「敏捷」！ ▸ 計劃會議（Sprint Planning）的⽬目的，並不在於『計劃完善』⽽而在於『溝通共 識』。 ▸ 精煉會議（Refinement Planning）的⽬目的，並不在於『技術分析』⽽而在於 『提前溝通』。 ▸ 每⽇日站會（Daily Standup）的⽬目的，並不在於『進度報告』⽽而在於『資訊同 步』。 ▸ 檢視會議（Sprint Review）的⽬目的，並不在於『展⽰示成果』⽽而在於『分享價 值』。 ▸ 回顧會議（Sprint Retrospective）的⽬目的，並不在於『檢討過失』⽽而在於 『學習⾃自省』。 https://medium.com/%E6%96%87%E6%80%9D%E4%B8%8D%E8%97%8F%E7%A7%81/%E6%96%87%E6%80%9D%E4%B8%8D%E8%97%8F%E7%A7%81-%E7%AC%A8%E8%9B%8B- %E5%95%8F%E9%A1%8C%E4%B8%8D%E5%9C%A8-%E6%95%8F%E6%8D%B7-7c200233f766
- 139. ABOUT AGILE ▸ Please explain those terms in Agile ▸ Deliver values ▸ Embrace change ▸ Self-organized team
- 140. 敏捷是需要向給想掌握事情的⼈人說 出深刻的實話，⽽而在把__、__與 ___看得很重的地⽅方，這種說實話 的能⼒力力是很難的． Claudio Caballero - CTO of Goodwill Group Foundation TEXT
- 141. SITUATIONAL THINKING
- 142. BIG USER STORY?
- 144. DEVELOPERS ARE AT THEIR BEST WHEN THEY CAN COMPLETE THE WORK AT HAND IN ABOUT ONE DAY. Johnny Appleseed TEXT
- 145. ▸ Big stories give pain ▸ Larger stories are more likely to be confusing. ▸ Big stories make it difficult to know what needs to be done next. ▸ Short stories give good feelings ▸ smaller stories are easier to understand. ▸ Small stories allow more work to get done.
- 146. SMALLER IS BETTER
- 147. SMALLER IS BETTER
- 148. SMALL TEAM AND MULTIPLE PROJECTS
- 149. SMALL TEAM, MULTIPLE PROJECTS: AN AGILE APPROACH TO PLANNING https://davidmarquis.wordpress.com/2011/12/03/small-team-multiple-projects-agile-planning/
- 150. COMBINE PROJECTS INTO VALUE STREAMS
- 151. PUT ITEMS INTO SINGLE SPRINT BACKLOG
- 153. LET VALUE STREAMS SMALLER THEN NUMBER OF MEMBERS ▸ floor(team size / 2) + 1 ▸ Team of 3: 2 value streams ▸ Team of 6: 4 value streams ▸ Team of 7: 4 value streams
- 154. FOCUS ON EACH PERSON https://medium.com/@anttihavanko/how-to-handle-multiple-projects-with-a-small-team-ebdfde5f6714
- 155. FOCUS ON EACH PROJECT https://medium.com/@anttihavanko/how-to-handle-multiple-projects-with-a-small-team-ebdfde5f6714
- 156. eXtreme Programming
- 171. KANBAN APPENDIX B
- 172. ▸ Visualizing the flow ▸ Limiting the WIP (Work In Progress) ▸ Measuring the Lead Time ▸ Optimize iteratively with data https://www.avantica.net/blog/2016/11/17/dont-stay-in-the-shu-box-agile-is-not-a-recipe-4
- 177. SCRUM BOARD VS KANBAN https://www.slideshare.net/tothenewtech/introduction-to-kanban-21088273/42-Emphasis_should_be_on_the
- 180. GOOD TO GREAT Johnny Appleseed