敏捷項(xiàng)目管理基礎(chǔ)筆記分享

1.敏捷項(xiàng)目管理基礎(chǔ)

1.1?項(xiàng)目管理和迭代開發(fā)方式項(xiàng)目的定義：一系列活動(dòng)，有一個(gè)明確的目標(biāo)或目的，并且必須在特定的時(shí)間和預(yù)算內(nèi)依據(jù)規(guī)范完成

項(xiàng)目管理：運(yùn)用技能，方法與工具，為滿足或超越項(xiàng)目有關(guān)各方對項(xiàng)目的要求與期望，所開展的各種計(jì)劃，組織，領(lǐng)導(dǎo)控制等方面的活動(dòng)。

項(xiàng)目的三角：

范圍：要求做什么，也規(guī)定了不能做什么

時(shí)間：必須完成的時(shí)間框架或最后期限

成本：可用于項(xiàng)目的費(fèi)用

質(zhì)量：

產(chǎn)品的質(zhì)量：項(xiàng)目的可交付成果的質(zhì)量

過程的質(zhì)量：項(xiàng)目管理過程本身的質(zhì)量

項(xiàng)目管理的目的：在有限的資源投入條件下，在要求的時(shí)間內(nèi)完成既定的項(xiàng)目目標(biāo)。

迭代開發(fā)模式

迭代式開發(fā)也被稱作迭代增量式開發(fā)或迭代進(jìn)化式開發(fā)，是一種與傳統(tǒng)的瀑布式開發(fā)相反的軟件開發(fā)過程，它彌補(bǔ)了傳統(tǒng)開發(fā)方式中的一些弱點(diǎn)，具有更高的成功率和生產(chǎn)率。

在迭代式開發(fā)方法中，整個(gè)開發(fā)工作被組織為一系列的短小的、固定長度的小項(xiàng)目，被稱為一系列的迭代。

每次迭代都包括了定義、需求分析、設(shè)計(jì)、實(shí)現(xiàn)與測試。采用這種方法，開發(fā)工作可以在需求被完整地確定之前啟動(dòng)，并在一次迭代中完成 系統(tǒng)的一部分功能或業(yè)務(wù)邏輯的開發(fā)工作。再通過客戶的反饋來細(xì)化需求，并開始新一輪的迭代。

1.2?Scrum方法——3 3 3 5

3個(gè)理論支柱:

-高透明性(Transparency)

- 檢查(Inspection)

-適應(yīng)(Adaptation)

3個(gè)工件:

-產(chǎn)品待辦列表

-迭代待辦列表

-潛在可交付的產(chǎn)品增量

3個(gè)角色:

-產(chǎn)品負(fù)責(zé)人Product Owner

-Scrum Master

-開發(fā)團(tuán)隊(duì)

5個(gè)事件:

-迭代計(jì)劃會(huì)議? ? ? ? ? ? ? ? ?-迭代

-迭代評(píng)審會(huì)議? ? ? ? ? ? ? ? ?-每日立會(huì)

-迭代回顧會(huì)議

1.3 KANBAN方法

看板：一種可視化流程管理系統(tǒng)

三個(gè)原則：可視化，限制在制品，管理流動(dòng)

五個(gè)核心實(shí)踐：

可視化工作流（價(jià)值流）：工作流程，由各種工作項(xiàng)構(gòu)成

限制在制品數(shù)量：工作項(xiàng)在本狀態(tài)數(shù)量的上限，取決與整體團(tuán)隊(duì)的能力

度量與管理流動(dòng)：讓價(jià)值流動(dòng)起來，方法：累計(jì)流量圖

協(xié)同改進(jìn)：整個(gè)團(tuán)隊(duì)一起合作

顯示化流程規(guī)則：不同狀態(tài)轉(zhuǎn)換的規(guī)則

Scrum方法還是KANBAN方法都是為了順暢，高質(zhì)量地交付有用的價(jià)值

大家可以在華為云DevCloud平臺(tái)中體驗(yàn)：https://devcloud.cn-north-4.huaweicloud.com/home/projectSeries

1.4 風(fēng)險(xiǎn)管理? ? ??風(fēng)險(xiǎn)管理規(guī)劃是指決定如何處理并進(jìn)行項(xiàng)目的風(fēng)險(xiǎn)管理活動(dòng)

四個(gè)階段:

1.風(fēng)險(xiǎn)識(shí)別

2.風(fēng)險(xiǎn)分析

3.風(fēng)險(xiǎn)應(yīng)對計(jì)劃

4.風(fēng)險(xiǎn)監(jiān)控和控制

2.?需求管理與版本規(guī)劃

2.1需求收集與分析：

需求的定義:? IEEE軟件工程標(biāo)準(zhǔn)詞匯表(97年)中定義需求為:

?用戶解決問題或達(dá)到目標(biāo)所需的條件或權(quán)能(Capability).

?系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。

?一種反映上面(1)或(2)所描述的條件或權(quán)能的文檔說明。

軟件需求包括以下幾個(gè)層次:

?業(yè)務(wù)需求

?用戶需求

?功能需求

?非功能需求、軟件需求規(guī)格說明等

2.2需求管理流程： 需求收集–>需求分析–>需求分解與澄清–>需求優(yōu)先級(jí)與排期

2.2.1需求收集：

? 原始需求–>用戶需求

? 需求獲取的方法： 文檔與數(shù)據(jù)，訪談，調(diào)查問卷，原型，需求討論會(huì)，競品分析

2.2.2需求分析：

? 用戶需求–>產(chǎn)品需求

? 針對待開發(fā)軟件提供完整，清晰，具體的要求，確定軟件必須實(shí)現(xiàn)哪些任務(wù)

? 工具：影響地圖：why who how what

2.2.3基于用戶故事的拆分與澄清：

需求層級(jí)：

? Epic Story史詩故事：產(chǎn)品的主干任務(wù)，非常大

? Feature特性：描述了產(chǎn)品的具有一個(gè)完整的功能，特性也比較大，持續(xù)數(shù)周，橫跨幾個(gè)迭代

? 用戶故事：特性一般可以拆分為多個(gè)用戶故事，每個(gè)用戶故事都對用戶有價(jià)值。但是單個(gè)用戶故事卻可能不能被正常使用或者是整個(gè)功能的細(xì)分場景

? 三要素：角色，活動(dòng)，價(jià)值

? 角色：誰使用這個(gè)功能

? 活動(dòng)：需要完成什么樣的功能

? 商業(yè)價(jià)值：能帶來什么樣的價(jià)值

? 格式：AS a，I want ，so that | 作為一個(gè)<角色>，我想要<活動(dòng)>，以便于<商業(yè)價(jià)值>

3C原則：

? 卡片（Card）:用戶故事寫在小的記事卡片上

? 交談（Conversation）：用戶故事背后的細(xì)節(jié)來源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通

? 確認(rèn)（Confirmation）：驗(yàn)收測試確認(rèn)用戶故事被正確完成

云原生 DevOps

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。