User Story 和 DOR DOD筆記

[TOC]

User Story(US)

User Stroy Mapping

如何把US轉化成task的方法，請參考： Mapping method

Definition of Ready (DOR) 範例

DOR 不是Scrum Guide的一部分，但是對於team而言，是有幫助的 一般是針對US,也可針對不同的關卡

1. Legal

是否違反任何法律、公司或團隊規定以及法規

2. Analytics

例如：我們如何獲得必要資料來判斷客戶有使用這個功能

3. Helpdesk

例如：客服是否可以看到這個功能

4. Test Cases

至少要有定義最重要的test case

5. User Story is Groom and estimated

有通過refinement meeting(Grooming)或是可被估計的

6. EveryOne understands why the story is valuable

Team的每個人都知道這個US的價值

7. Story is as small as possible while still delivering value

盡可能分解成更小的US，而且還是會保留它的價值

8. Document new aggrements

文件化新的agreements

Definition of Done

幾種一般規範DoD的定義

選項以及範例

:::warning

1. Components deployed into development/staging environment

Components/packages have been deployed into <target environment>

2. Configuration points（CP） are integrated into deployment packages

Dependencies and integration points have been considered as part of deployment plan

* the value changes between environments 

3. Automated testing at minimal < fill in a percentage > code coverage in domain packages. 自動化測試涵蓋率

Automated tests cover <fill in automated testing coverage target>

4. Tested according to Product Owner’s Acceptance Criteria (minimally) 測試都符合PO接受標準

All Acceptance Criteria have been satisfied

5. Unit tests written at behavior level and passing 單元測試通過

Unit tests pass

6. Acceptance Criteria specified/updated and passing for each user story

Testing has been completed in accordance with Acceptance Criteria

7. Coding meets the department coding standards/automated checks 程式碼符合部門標準

Code meets team/group coding standards

8. Technical debt(design debt、code debt) is logged and made visible 技術債要能明確的被記錄和被看到

Technical debt associated with the user story has been identified

* 不充足的事前定義：需求仍然在開發過程中被定義，開發在設計之前就已經開始。這種做法的目的是節約時間，但常不得不以後返工。
* 商務壓力。商務角度需要在必須的改變完成之前就發布產品。因此開發的技術債務包括那些待完成的改變。
* 缺少流程或理解，從而商務上對技術債務不了解，不考慮後果就做出決策。
* 緊耦合組件。功能不是模組化，軟體不夠靈活應對商務上的變化。
* 缺乏測試套件。這刺激了快速高風險「湊活式」的修復bug。
* 缺少文件。寫代碼但沒有必要的支撐性文件。
* 缺乏合作。知識沒有得到共享，對新手缺乏監督輔導。
* 在兩個或多個分支上平行開發而累積了技術債務。由於工作最終需要合併兩個分支的代碼，拖延越晚，需要工作代價越大。
* 拖延做重構 – 重構拖延越晚，需要修改的代碼越多。
* 缺少與標準對齊。工業標準的特性、框架、技術被忽視。最終也必將遵從標準，做得越早代價越小。
* 缺少知識。開發者並不知道如何寫精緻的代碼。
* 缺少所有權。外包的軟體最終要讓自己的工程師去重構或重寫原始碼。
* 技術領導力差, 未深思熟慮的命令通過命令鏈傳達下來，增加了技術債務，而不是減少它
* 最後一分鐘規範改變。這有可能滲透到整個專案中，沒有時間或預算通過文件或檢查來發現它們。

9. Multiple team members (developers/testers) have reviewed tests cases。 測試範例有被review過

Test cases have been reviewed

10. New functionality doesn’t break existing functionality。 新功能不能破壞既有需求。

11. Comments in code are valid and useful。 註解是合法而且有用的。

Code comments are accurate and understandable

12. New and revised error codes added to documentation。 新的或修改過的錯誤處理要記錄下來

Changes to error handling have been documented

13. New features are assessed for architectural affects 有考慮過新功能對於架構上的影響

Architectural impact has been considered

14. All production code is peer reviewed (via code review meeting or pair programming)

Peer code review is complete

15. New features are documented, release notes updated。 新功能有被記錄下來，而且release notes有被更新完成

Supporting documentation has been updated

16. Code checked into repository has proper tracking (to feature/change request/user story)。 程式碼放回git的時候，能被追蹤對應需求或US

Code checked into version control with proper tracking to associated work item (user story, bug, etc)

17. Environmental changes have been documented and communicated to Operations Team。 環境的變更有被記錄下來而且跟營運團隊溝通過。

Operations/deployment considerations have been documented and communicated

18. Acceptance criteria have been tested on integration environment。 整合測試通過

Testing has been completed in an integration environment

19. API document has been evolved and checked into repository。 API文件有記錄下來，而且放入git

API documentation is accurate and under version control

20. Verification of acceptance criteria by developer and tester team members。 通過標準有被工程師和測試者確認

Two or more team members have checked for satisfaction of all Acceptance Criteria

21. Testing approves the user story。 US有被完整測試

The user story has been fully tested

22. No priority 1 or 2 defects open for the story。 沒有p1,p2等級的bug出現

There are no open defects associated with the user story

23. Story demo is prepared (db setup and script for demo sketched out)。 Demo的時候需要的環境或其他項目已經準備完成。

The user story has been demonstrated (or some other form of proof of completion has been provided)

24. Product Owner has seen a demonstration of the story and accepts it. PO已經看過程式demo，而且接受

The Product Owner accepts the user story

25. Integration test passed at system ecosystem level.

Integration tests pass in at least two environments

26. Infrastructure environmental changes noted and made visible。 變更項目被記錄下來

Configuration changes to environments documented

27. Stress tests pass。 效能測試通過

Performance/load tests pass

28. Deployment (with db rollback) procedures written。 Deploy and rollback 程式的步驟有被記錄下來

Deployment/rollback considerations have been documented and communicated

29. Release Notes written and delivered to Operations. Release notes有記錄下來，而且交付給營運team

Release notes have been reviewed and approved

30. Tasks for User Stories implemented accouding to description in Issue Tracking System. 工作項目的內容有記錄在追蹤系統

Tasks description is documented in Redmine

31. Remaining hours for each task = 0 剩餘小時數要改成0

Tasks description is documented in Redmine

32. Architecture Diagrams Diaster Recovery Plan Updated or tested 相關文件已經更新

:::

完成定義的第一種方式

針對不同的task

Coding 完成定義範例

:::info

1. 程式build，不會有錯誤
2. 程式完成，包含註解，而且在現在的版本是可執行的
3. 程式有經過團隊review
4. 程式有符合團隊標準
5. 有通過單元測試和系統測試
6. 是否有更新不同branch
7. 移除剩餘時數為0，狀態改成完成關閉
8. 是否按照Redmine的內容實作 :::

API 完成定義範例

除了Coding外，==plus== :::info

1. 更新API文件
2. 撰寫java或其他語言呼叫api的sample code :::

Bug 完成定義範例

除了Coding外，==plus== :::info

1. 小bug可直接先修掉，不用複雜流程
2. 還是要有sticker :::

Individual Study 完成定義範例

:::info

1. 說明研究的目的和原因
2. 研究成果（程式、ppt）
3. 價值和可運用點 :::

分析 完成定義範例

:::success

1. 團隊沒有不清楚的問題
2. 團隊清楚UAT的標準
3. 團隊清楚這個功能的價值
4. 文件格式或呈現方法符合團隊標準
5. 可參考 前面的DOR :::

文件 完成定義範例

:::success

1. 文件種類
2. 運用方式和目的
3. 文件符合團隊標準 :::

完成定義的第二種方式

針對不同的gate，從另一個面相看，意思是一樣的，只是強調的細節不太一樣

with a Story

• All code(test and mainline) checked in
• All Unit Tests Passing
• All Acceptance Test identified, written and passing
• Help File generated
• Functional Tests Passing

with a Spring

All Story Criteria, ==plus==

• Product backup updated
• Performance Testing
• Package, Class and Architecture Diagrams Updated
• All Bugs closed or Postponed
• Code coverage for all unit test at ?%+

Release to UAT

All Sprint Criteria, ==plus==

• Installation Packages Created
• Operations Guide Updated
• Troubleshooting Guides Updated
• Diaster Recovery Plan Updated
• All Test Suites Passing

Release to Prod

All UAT Criteria, ==plus==

• Stress Testing
• Performance Turning
• Network Diagram Updated
• Security pass validated
• Threat Modeling pass validated
• Diaster Recovery Plan tested