# Trello 專案管理 Case Management
## 目的 Objective
- 有效管理專案進度
Efficiency in tracking progress
- 增加溝通效率,透過比較快的回應或是給予回饋,可以使工作迭代的更順暢。
Increase communication efficiency, whether it's faster time in responding or giving feedback, it will make work iterations even smoother.
- 記錄過往的處理或討論的過程,讓任何人未來回來查看時,比較能了解來龍去脈。
Record details of discussion or how solutions came about, letting anyone who refers back to documents to better understand the ins and outs.
- 是一個可以互相合作,互相給予肯定,激發更好的創意與合作元素的地方
Allows collaborative work, reaffirmation, and overall inspires a more creative and cooperative working space
---
## 原則 Principle
- 給予正面與具體的回饋
Give positive, specific feedback
- 盡量即時反應
Respond as soon as possible
- 盡量透明、提供有意義的資訊
Be clear, provide meaningful information
- 只要會花時間做的,應該都要有對應的卡片、以及過程的記錄
If the task is more time consuming, there should be associated cards, providing the details of process
- Deadline Driven
- 因此當任何一個任務插隊時,就會去思考會不會影響原本的 Deadline 而去溝通
When there's a sudden pop up task, further consideration should be discussed if it will affect the deadline of the current task in progress.
---
## 敏捷 Agile
- 敏捷宣言 Agile Declarations
- `個人與互動` 重於 流程與工具
`Personal interaction` better than Process and tools
- `可用的軟體` 重於 詳盡的文件
`Usable software` better than detailed documents
- `與客戶合作` 重於 合約協商
`Partnership` better than contract agreements
- `回應變化` 重於 遵循計劃
`Adapting to changes` better than traditional plans
- 可以使用 Scrum 或 Kanban 來管理
Can utilize Scrum or Kanban to manage
---
## Board
基本上是以產品或是 Vertical 來區分。例如:
Basically using product or vertical to differentiate
- 產品 Product
- TSM/Cerebro
- Vertical
- Affordable Housing
- RTO 相關的 Issue 都放這裡,像是 Landing Page, Agent Tool, SEO 等
RTO related issues can be added here, such as Landing Page, Agent Tool, SEO, etc.
有兩個比較特殊的 Board 是提供給 Operation Team & Marketing Team 處理。
Two boards that specially provide Operation Team & Marketing Team resolutions.
- !Tech Tickets
- !Ops Request
----
### Board Templates
目前基本的 Template 裡有一些預設的 List
Currently basic Template include a preset list
- Backlog
- Todo
- Incoming
- In Progress
- Review / Staging
- Live Review
- Closed
---
## List
- 用來區分卡片的各個狀態
Used to differentate card status
- 卡片的流程,搬移的順序應該是由左至右
Sequence of card progress should naturally be from left to right
- 應該是以`拖拉`的方式來處理卡片
Use `drag and drop` method to arrange cards
----
### Backlog
- 不會被放進去算 Lead Time
Will not be included in Lead Time
- 新的 Feature Request
New Feature Request
- 還`未確認`的內容
Still having `unconfirmed` details
> 經過`確認`後,可以搬到 `Todo` List
After being `confirmed`, then card can be placed into `Todo` list
----
### Todo
- 會被算進去 Lead Time
Will be included in Lead Time
- 確認過的內容
Confirmed details
- 有設定 Priority
Set Priority
- 有設定初估的 Man Days
Set estimated Man Days
> 當準備要做時,可以搬到 `Incoming` List
When task is being prepared, card can be placed into `Incoming` list
----
### Incoming
- 最多應該只能放`5`個 Card
Recommended maximum of `5` cards
- 讓大家專注`最重要且即將要進行`的任務
Let everyone be aware `the more important upcoming` tasks
- 可以針對 Incoming 的任務,優先預先討論實作細節
To focus on Incoming tasks, can first discuss the details beforehand
- 需要按照優先權排序
Will sort based on priority
- 當任何人從 In Progress 把所有卡片完成後,優先做最高優先權的卡片
- When anyone completes a task from In Progress, continue next task with highest priority
> 當要開始進行任務時,可以搬到 `In Progress` List
When starting a task, card can be placed into `In Progress` list
----
### In Progress
- 正在進行中的任務
Task that is currently being worked on
- 每個人最多應該只能有`2`個 WIP
Everyone should only have a maximum of `2` WIP (Work In Progress)
- 應該以 Due Date 排序
Execute based on Due Date
- 原則上希望每個進行中的任務,不應該超過`5`個工作天
- Desired rule of thumb being that current tasks being worked on shouldn't exceed `5` working days
> 當開發完成後,可以搬到 `Staging / Tech Reviewing` List
Upon finishing development, card can be placed into `Staging / Tech Reviewing` list
----
### Staging / Tech Reviewing
- 正在 Code Review
Currently in Code Review
- Reviewer
- 或是程式已經被 Deploy 到 Staging Server
or code has already been deployed to Staging Server
- 需要 PM 來 QA
Requires PM to perform QA (Quality Assurance)
- 原則任何卡片不應該停留超過`2`個工作天
A rule of thumb that any cards shouldn't be put on pause exceeding `2` working days
> - 當 Reviewer 檢視完後,如果是技術任務,應該要 Deploy 到 Staging Server,並通知請 `PM` 測試
Upon Reviewer's completion on check up...
> - if task was technical - deploy to Staging Server, and notify `PM` to test
> - 當有人檢視完後,如果非技術任務,應該要 Deploy 到 Production Server,並搬到 `Live / User Reviewing`
> - if task was not technical - directly deploy to Production Server, and place card into `Live / User Reviewing`
----
### Live / User Reviewing
- 已經完成的任務,等待最後的 Verification
Completed task, waiting for final verification
- 已 Deploy 到 Production 的任務
Task already deployed to production
- 已完成的會議等
Already discussed, etc.
- 需要由 `User` 來檢視 Production Server 上的功能,確認功能正常運作,或 Bug 已被修正。
- Prompt `User` to check feature on Production Server and confirm if it is working properly, or bug has been fixed.
- 可以建立 Checklist 並設定 Member 與 Due Date 來提醒何時需要回來檢視
Can create a Checklist and set Members and Due Date to remind user to view the card
- 可以放上系統畫面的截圖
Can add photos of feature on the system
- 需要由 `Manager` 來檢視會議內容是否有完成
Prompt `Manager` to check if discussed details were completed
- 原則任何卡片不應該停留超過`5`個工作天
- A rule of thumb that any cards shouldn't be put on pause exceeding `5` working days
當因為 User 確認的時間過長時,可能之後才發現有 Bug 或沒完全符合預期,再搬回去 In Progress,會導致 Cycle Time 變長。但這樣也可以突顯出問題,也就是 User 可能因為太忙,或忘記確認。所以可以想辦法改善這個問題,來降低 Cycle Time。例如:
In the event that a User discovers a bug over an extended period of time or the feature didn't fulfill intended request, place the card back into In Progress. This will lead to extending the Cycle Time, however, doing so may also highlight the issue, where the User was too busy or forgot to QA the feature. There's an opportunity to improve this negligence, thus minimizing Cycle Time. For example:
- 也許是太早做這個功能,而 User 還不需要?
The feature was too early for its time, the User didn't need it yet
- 也許是 User 太忙,所以有太多 WIP 在他身上
The User was too busy, so there was queue of WIP piling up
- 工程師或 PM 要主動跟 User 頻繁地 Follow up
Developer or PM should frequently follow up with the User
- 也許是使用者不知道或不熟怎麼確認
It's possible that User does not how to initiate QA process
- 增加教育訓練或是撰寫文件
Increase educational training or documentation
- 也許是操作太過複雜,或是有其他的 Dependency 導致測試很麻煩
It's possible that operation is too complex, or other Dependency required to test are too bothersome
- 想辦法簡化操作
Think of ways to simplify operation
> 當確認沒問題後,可以搬到 `Closed` List
> Once confirmed that there are no issues, the card can be placed into `Closed` list
----
### Closed
- 已確認完成的任務、已修正的 Bug
Tasks that have already been completed, bugs that have already been fixed
> 當這個月結束之後,可以移到所屬的 `Closed-Month-Year` List
> At the end of the month, the cards can be moved into the `Closed-Month-Year` list
----
### Closed-Month-Year
- 即將要被封存的 List
List that is prepared to be archived
> 三個月前的 List ,可以被封存
Lists over 3 months can be archived
---
## Card
- 與某個卡片有關的討論,盡量優先在 Trello 上留言討論,而不是在 Teams
Related with any cards for discussion, use Trello as main source of communication rather than Teams
- 有 UI 功能的,需要放縮圖或影片,並提供好的命名或解釋
Features that involve the UI can include photos / videos that can include terminology and explanations
- Priority 高的 Card 應該優先放在前面的 List
Cards with higher priority should be placed higher on the list
- Deadline 快到的 Card 應該優先放在前面的 List
Cards with deadlines approaching should be placed higher on the list
- 當卡片有關於個人的通知時,在卡片上會出現一個紅色的鈴鐺 Icon
When there's a mention or new comment, a red bell icon will appear on the card as notification
Each card should describe the four factors you'll take into consideration:
- Description
- Expected outcome
- Level of effort
- Risks and dependencies
### Card Creation
- 可以使用 Card Template 來快速建立 Card
Card Template can be used to quickly create a card
- 必填資訊
Required fields to fill
- Title
- Description
----
### Description
根據不同類型的卡片撰寫描述。比較特定類型的描述建議如下:
Descriptions details depend on case by case scenario.
The most common details to include are:
#### Feature Description
- Title
- 定義好處
Define the benefits
- 使用者可以獲得什麼功能
What feature will the user get
- 解釋為何需要做
Explain reason for creating such feature
- 評估商業價值
- Evaluate value to business
- 有多少使用者
How many users involved
- 使用的頻率如何
Frequency of feature being used
- 多緊急
How urgent
- 開發的 Effort
Effort for development
- Description
- Feature 的上下文
Context of the feature
- 使用者如何使用
How it can be used by the user
- 需求的細節
Details of the requested feature
- 實際的例子
Provide a use case scenario
- 定義可接受的條件
- Define terms of tolerance
- 定義完成的條件
Define terms of completion
- 期待的結果
Expected results
- 預想的問題以及解答
Anticipated issues to be encountered
- Attachments
- Screenshots
- Demo videos
- What I have learned
範例 Sample
```
Feature: Account reporting
The account reports are primarily used by account managers
to control client credit risk. They also use these reports
to decide on eligibility for discounts and special deals.
Other users include:
* call centre operators, who use them to quickly look
at recent transactions to assist clients when on call
* accountants to audit end-of year tax reports
Scenario: risky accounts should be shown separately
Client relationship managers need a quick way of identifying
accounts that should not be allowed to get discounts, long
payment terms or large credit.
We currently do not have specific risk factors for those three
categories, but use the overall risk factor on the account (this
is likely to change in the future).
The Risky tab of the account reports should list all accounts
where the overall risk exceeds the account risk threshold, but
only those accounts.
Given the risk threshold of 0.5
And the following user accounts
| account id | risk factor |
| low-1 | 0.10 |
| low-2 | 0.49 |
| at-limit-3 | 0.50 |
| above-limit-4 | 0.51 |
| high-risk-5 | 0.99 |
When the client account report is generated
Then the following accounts should appear in the 'Risky' category
| account id | risk factor |
| at-limit-3 | 0.50 |
| above-limit-4 | 0.51 |
| high-risk-5 | 0.99 |
```
參考 / For reference: [Make a good feature description from a user story. Examples](https://specflow.org/challenges/feature-description-look-like-user-story/)
----
#### Bug Description
- Title
- Bug description
- Steps to reproduce
- Device and OS
- Links
- Expected behavior
- Actual behavior
- Impacts
- Root cause
- Solution
- Attachments
- Screenshots
- Demo videos
- What I have learned
參考 / For reference: [Write Agile Documentation: User Stories & Acceptance Tests](https://openclassrooms.com/en/courses/4544611-write-agile-documentation-user-stories-acceptance-tests/4810381-write-a-good-bug-report)
----
### Comment
溝通與記錄用途
Used for communcation and logging
- 溝通 Communication
- 說明
Instructions
- 提出問題
Bring up issues
- 回答問題
Response to issues
- 給予回饋
Provide feedback
- 進度追蹤 & Follow Up
Progress tracking & follow up
- 記錄 Logging
- 目前進度
Current progress
- 目前研究成果
Current R&D achieved
> Trello 可以用 Emoji 快速回應,可以善用此功能達到快速回應的目的,例如: :ok_hand:代表已讀,:+1:代表讚
Trello has emojis available for quick responses. These can be used as quick replies to comments.
For example:
:ok_hand: = "read"
:+1: = "like"
----
### Member
- 應該設定主要的任務負責人
Include members that are responsible for task
- 如果希望相關的人可以收到後續的通知
If it is desired for a user to receive notification
- 可以在 Comment 留言並 tag 他們的名字,Trello 會把這些人加到 Watch List
By tagging a user's name in comment, Trello will automatically at them to the Watch List
- Meeting 類的別 Tag 人,如果是為了通知的目的,可以在 Comment 裡 Tag 人
Tagging in cards related with meetings - if the purpose is to notify a user, then just tag the user within comments
---
### Label
有分不同的類別,同樣的類別使用同樣的顏色
Cards have different categories, which are then grouped by the same color
- Type
- 主要的分類
The main category
- **每個卡片都要有 Type**
**Every card must have a Type**
- 顏色: 黃色
Color: Yellow
- 範例: Feature, Bug, Meeting, DevOps, Refactoring, Operation, Document
Example: Feature, Bug, Meeting, DevOps, Refactoring, Operation, Document
- Product / Project / Module
- 用來方便區分產品或模組
Used to differentiate products or modules
- **每個卡片都要有**
**Every card must have a Product / Project / Module**
- 顏色: 橘色
Color: Orange
- 範例:
Examples
- Product: Skynet, Landing Page, User
- Status
- 用來記錄卡片最終的狀態
Used to record card's latest status
- 有特別想標記的才需要填
Tag optional when feel necessary
- 顏色: 綠色
Color: Green
- 範例: Done, Fixed, Paused, Duplicate, Need Info
Example: Done, Fixed, Paused, Duplicate, Need Info
- Aspect
- 用來區分是前端或後端 Repo
Used to differentiate frontend or backend repositories
- 有前後端分離的專案才需要填
Only necessary for projects with separate frontend and backend
- 顏色: 黑色
Color: Black
- 範例: Frontend, Backend
Example: Frontend, Backend
- Other
- 其他類別的
Other categories
- 有特別想標記的才需要填
Tag optional when feel necessary
- 顏色: 藍色
Color: Blue
- 範例: AWS, Twilio, CircleCI, Terraform
Example: AWS, Twilio, CircleCI, Terraform
----
### Custom Fields
- Man Days
- 預估完成的時間
Estimated working days
- 從開發到上線
From starting development to live production
- 從開始寫文件到審核完畢
From starting documentation to review completion
- Priority
- How to prioritize
- 可以參考 [Allthethings Prioritization Matrix](https://www.atlassian.com/team-playbook/plays/prioritization-matrix) 來區分優先權
Can refer to [Allthethings Prioritization Matrix](https://www.atlassian.com/team-playbook/plays/prioritization-matrix) as a guide for prioritization
- Video: [How to Prioritize Your Backlog More Efficiently in Jira | 6th Meta-Inf Atlassian Day](https://www.youtube.com/watch?v=uecsbriMzYk)
- Levels
- Immediate
- High Impact and Urgent
- 需要立即處理
Must handle immediately
- 可以先有 Work Around 的方法
Can have a Work Around solution
- **應該要在`2`天內完成**
**Should be resolved within `2` days**
- High
- High Impact, but not urgent
- Middle Impact, but a bit urgent
- Medium
- Nice to have
- Low
- Nice to have
- Code Complete At
- 需要搭配 Automation ,當卡片被移到 Staging / Reviewing 時,會自動更新時間
Paired with automation, card will automatically update time upon dragging card into Staging / Reviewing
- Lived At
- 需要搭配 Automation ,當卡片被移到 Live / User Reviewing 時,會自動更新時間
Paired with automation, card will automatically update time upon dragging card into Live / User Reviewing
- Closed At
- 需要搭配 Automation ,當卡片被移到 Closed 時,會自動更新時間
Paired with automation, card will automatically update time upon dragging card into Closed
----
### Attachment
可以放各式需要參考的內容。像是
Can add anything to be considered related with the context. Such as...
- 開發前或修復 Bug 前的情況
situations prior to development or fixing a bug
- 開發後或修復 Bug 後的情況
situations after the development or fixing a bug
- 第三方系統操作的畫面的截圖
Photos of using 3rd party platforms
- 相關的 Trello Link
Related Trello links
- Demo Videos
- 其他 Links
Other links
圖片的 Naming Format
Photo's Naming Format
```
[Project or Service]: [Module or Page] - [Description]
```
> 如果是同一個專案,可以省略 Project
If within the same project, project can be omitted
範例:
Example:
- Loggly: Edit Endpoint - Example
- Teams: Connector - Create Pingdom Connector Example
- Conversation Page - wrong conversations
- Twilio: Phone Number - Change phone number incoming call from webhook to studio flow
----
### Check List
可以設定 Assignee 與 Due Date (但好像沒法設通知)
Can set Assignee and Due Date (but unable to set notification)
- 可以用來追蹤任何需要 Follow Up 的事
Can be used to track progress and follow up
- 等待某個人給 Feedback
Wait for any type of feedback
- 上線後要觀察數據
QA data after live production
----
### Github
- Admin 可以透過 Trello Power-Ups 來加入 Github 的支援
Admin can use Github support features through Trello Power-Ups
- 每張卡片,只要有 Code 的改變,都要附上
Every card that involves changing code must be attached
- Github Issue
- Pull Request
---
## Notification
- 啟用`桌面通知`
Enable `Desktop Notification`
- 目的: 讓專案之間的溝通更有效率。
Goal: To allow more efficient communication between projects
- 步驟: Account -> Settings -> Enable desktop notifications…
Steps: Account -> Settings -> Enable desktop notifications…
- 被通知的情況
Cases of being notified
- 當被 Tag 時
Being tagged in comments
- Due Date 快到期時
Due Date is approaching
- Watch 的 Card 有新的 Comment 時
New comments when watching a card
- 通知鈴鐺頁面
Bell notification interface
- 可切換 `Filter by unread` 或 `View all`
Can switch between `Filter by unread` or `View all`
- 看過得可以按 `Mark read`
Can press `Mark read` for seen notifications
- 可以快速對 Comment 按 Emoji 表示,例如
Can quick reply comments with an emoji symbol, such as
- Like
- Okay
## Search
可以更快速的查詢到你要的卡片,除了基本的全文檢索外,Trello 還支援許多語法:
Can quickly search for desired card, other than using full-text keywords, Trello also supports a variation of keywords:
- `@name`: 可以輸入使用者的 id 或自己,例如 `@me`, `@eddie`
`@name`: can search using user id or self,for example `@me`, `@eddie`
- `#label`: Label, 例如 `#feature`
- `board:id`: Board, ex. `board:onr`
- `list:name`: List, ex. `list:todo`
- `has:attachment`
- `due:day`: ex. `due:day`, `due:month`, `due:3` (三天內會過期的卡片)
`due:day`: ex. `due:day`, `due:month`, `due:3` (cards due within 3 days)
- `created:day`: ex. `created:day`, `created:month`, `created:3`
- `edited:day`: ex. `edited:day`, `edited:month`, `edited:3`
- `is:open`, `is:archived`
- `description:`, `comment:`, `checklist:`
- `sort:created`, `sort:edited`, `sort:due`
## Filter
過濾目前 Board 的卡片,與 Search 功能比較起來,有比較豐富的 UI 可以操作,包含:
By filtering the board, compared with the search feature, has a richer UI to work with, including:
- Keyword, Member, Due date, Label
- `Exact match` or `Any match`
## Automation
方便設定自動化,包含:
Make life easier with automations, including
- Rules
- 可以設定 Trigger 與 Actions,也就是當 Trigger 條件發生時,可同時執行 Actions
Can set Trigger and Actions, when a Trigger's condition is met, it will execute an Action
- 例如:
Example:
- when a card is added to list "Staging / Tech Reviewing", set date custom field "Code Complete At" to now
- when a card is added to list "Bugs", sort the list by custom field "Severity" ascending
- Calendar
- 可設定週期性的 Trigger 與 Actions
- Can set expiration date as Trigger and Actions
- 例如:
Example:
- every month on the last day at 11:55 pm, rename list "Closed" to "Closed-{monthnumberlong}-{year}", and create a new list named "Closed" in position 10
- Buttons
- Card Button
- 例如 Example
- Mission Complete: move the card to the top of list "Live / User Reviewing", and mark the due date as complete
- Send To Review: move the card to the bottom of list "Reviewing"
- Board Button
- 例如 Example
- Monday Setup: Archive all cards in list "This Week", and move all cards in list "Last Week" to "This Week".
- Prioritize: Sort the cards in list "Doing" by custom field "Priority" descending.
- Email Reports
- Weekly Snapshot
- Due Soon
- Overdue Cards
- My Cards
## Power-Ups
目前常用的 Power-Ups 有
Currently most frequently used Power-Ups are
- Github
- 方便附上 Github Issue
- Easily attach Github Issue
- 方便附上 Github PR,同時可以顯示 PR 的 CI 整合情況
- Easily attach Github PR, simultaneously show the PR's CI integration status
- Card Family
- 可以在卡片增加 Child Card 或 Parent Card
- Can add Child Card or Parent Card
- Card Delete
- 可在卡片上快速刪除
- Can quickly delete the card