Group items tagged

Filter: All | Bookmarks | Topics Simple Middle

Scrum懶人包 - 10分鐘讀懂Scrum與敏捷軟體開發入門（含中文英文名詞對照） - 敏捷進化趣 Agile FunEvo - 1 views

funevo.com/...hao-xin-shou-zhi-nan-introduce

project scrum

shared by 張旭 on 08 Nov 18 - No Cached

Daily Scrum（每日站立會議）：每天10-15分鐘不能超時
...

Cancel
Sprint（衝刺）：顧名思義，當團隊決定要哪些 Item 後，就著手去衝。
...

Cancel
大原則是 Sprint 內的 Sprint Backlog 不改變（有原則就有例外）。
...

Cancel
...6 more annotations...
Sprint 開始時，討論一下這個 Sprint 團隊可以交付哪些Item。
...

Cancel
Sprint 結束時針對產品的會議，PO邀請利害關係人對產出給意見，是要可用的軟體才算產出。
...

Cancel
Sprint Review 後，Scrum Team 成員（Dev Team 或包含 PO），針對這個 Sprint 團隊的工作模式討論改善，并定出下個 Sprint 改善事項。
...

Cancel
Product Owner（PO，產品負責人）
...

Cancel
ScrumMaster
...

Cancel
Development Team（Dev Team，開發團隊）
...

Cancel

今天拜飛機了沒？ - 談敏捷開發中的貨物崇拜 - 敏捷進化趣 Agile FunEvo - 0 views

funevo.com/...-cult-agile-min-jie-bai-fei-ji

project

shared by 張旭 on 08 Nov 18 - No Cached

張旭 on 08 Nov 18

"沒有溝通（產品的）願景和策略產品藍圖和發佈日期在一年前就由CTO規劃好了組織內沒有人跟顧客對談 CTO和利害關係人堅持所有的改動都要經由他們批准因為保密資安等理由，禁止使用實體的看板或告示利害關係人直接跟CTO對談，跳過Product Owner 由利害關係人來決定交付產品增量，而不是Product Owner 專案/產品只有在完成時才交付，而不是增量式的交付避免利害關係人直接跟開發團隊對談 Product Backlog是由一個產品委員會決定的就算對功能的價值有所懷疑，但還是硬上了（為了年終獎金…）業務為了成交，答應客戶增加目前不存在的功能，而Product Owner不知情就算是不重要的問題，也有固定的進度表和期限負責產品管理的角色沒有取得商業智能（BI）資訊的權限，沒有充足的資訊和數據幫助決定利害關係人使用需求文件來和產品與工程部門溝通 Product Owner大部分的時間都在撰寫和管理使用者故事（User Stories）在Sprint開始後不久Sprint Backlog就變了專門成立一個開發團隊來修Bugs和處理小的需求利害關係人沒有參加過Scrum活動（例如Sprint Planning和Sprint Review）主要是用『速率（Velocity）符合當初的承諾』來當指標評估Scrum是否成功開發人員沒有參與創造使用者故事同時處理的專案數量和工作會改變開發團隊的人數跟組成方式在Daily Stand up中團隊成員對ScrumMaster報告定期舉行自省會議（Retrospectives），但沒有改變隨之發生開發團隊並不是跨功能（Cross Functional），而要靠其他團隊或部門才能完成工作"

<div class="cArrow"> </div><div class="cContentInner">"沒有溝通（產品的）願景和策略產品藍圖和發佈日期在一年前就由CTO規劃好了組織內沒有人跟顧客對談 CTO和利害關係人堅持所有的改動都要經由他們批准因為保密資安等理由，禁止使用實體的看板或告示利害關係人直接跟CTO對談，跳過Product Owner 由利害關係人來決定交付產品增量，而不是Product Owner 專案/產品只有在完成時才交付，而不是增量式的交付避免利害關係人直接跟開發團隊對談 Product Backlog是由一個產品委員會決定的就算對功能的價值有所懷疑，但還是硬上了（為了年終獎金…）業務為了成交，答應客戶增加目前不存在的功能，而Product Owner不知情就算是不重要的問題，也有固定的進度表和期限負責產品管理的角色沒有取得商業智能（BI）資訊的權限，沒有充足的資訊和數據幫助決定利害關係人使用需求文件來和產品與工程部門溝通 Product Owner大部分的時間都在撰寫和管理使用者故事（User Stories）在Sprint開始後不久Sprint Backlog就變了專門成立一個開發團隊來修Bugs和處理小的需求利害關係人沒有參加過Scrum活動（例如Sprint Planning和Sprint Review）主要是用『速率（Velocity）符合當初的承諾』來當指標評估Scrum是否成功開發人員沒有參與創造使用者故事同時處理的專案數量和工作會改變開發團隊的人數跟組成方式在Daily Stand up中團隊成員對ScrumMaster報告定期舉行自省會議（Retrospectives），但沒有改變隨之發生開發團隊並不是跨功能（Cross Functional），而要靠其他團隊或部門才能完成工作"</div>

...

Cancel