no optimal, tool show tool builder though.

type

milestone 的 定義很混亂，這個定義算清楚。

- [epic vs milestone](https://gitlab.com/gitlab-org/gitlab/-/issues/6222#note_660926620)

## 要自己考慮的事

- epic 和 產品 的距離?
- 我們買產品，是為了feature 沒錯。
- 產品本身的小功能可以被分拆再賣出
- epic 和 project 的差別？
- project 定義的是管理，同時和有時間。
- project 的 目標是 feature 沒錯。
- epic 和 library 的差別？
- library 可以是 feature set，也可以是單一feature 就構成library。
- library 和 產品的差別？
- library 可以作為產品，或產品的一部分。但產品的定義不侷限coding。

project 是當一組 feature(user story) (>=1) 的構建過程需要被控制時，產生的單位。他是 full system (controller + plant)。所以project 的 scope 是被選定的。

define: **project is management unit.**

sub project 就像 cascade control 的子系統一樣。

所以一個lib 對應一個project 是不錯的 heuristic pratice。因為一般coding 時，本來就會被相關功能放在同一個lib (高內聚)，相關表示是同一個 plant。

But this heuristic not always optimal, e.g. if 2 library are very similar or close. management them in same project may be a better solution, since they interact each other intensively.

A product is a good heuristic for project unit, too.

product, or 接到的案子 肯定也是 feature 單位，可能需要很多 sub feature (在coding長對應到 several lib)，所以就是 parent of several sub project。

當然feature should be able to share。if feature is building, therefore belong its own subproject, subproject should be able to share across several project too。(如果 library 已經完成，不須管理，那就也無須納入)

### project hierachy example

以下每個entry 都是 project

- general concept
- sub conecpt 1 implement lib
- sub sub concept 1 implement lib
- product 1 from sub concept 1
- its require knowledge will not across sub concept 1
- sub conecpt 2 implement lib
- product 1
- product project can select sub concept project as relationship
- product 1 required knowledge will not across `general concept`.
- product 2

## 分類

沒有條件的時候永遠 feature 優先，時間之後在說。

空間上（feature）
- epic
- user story
- minimal valuable feature combination。
- 可以 demo 給工程師。
- 可以 作為一個有使用價值的功能
- 應該丟給 product owner 看(scrum)。
- task
- execution unit
- task
- excution unit too, if parent task better splited.

時間上
以下都是time box，一個 feature 當然可以屬於很多 time box。
- milestone
- ~2 month (depend on industry)
- sprint
- ~2 week (depend on industry)

[Manage versions](https://www.openproject.org/docs/user-guide/projects/project-settings/versions/) ，不是 management 不要用。可以預設能 release 就是 1.0 版，然後劃分feature 在不同版 release。避免好像單純無窮盡 implement feature。