|
原創(chuàng)阮小鬼 最后發(fā)布于2020-02-26 14:11:45 閱讀數(shù) 193 收藏 最近看了一些敏捷開發(fā)的書籍,，對(duì)敏捷開發(fā)有些初步的了解,。今天就想來談?wù)劽艚蓍_發(fā)與傳統(tǒng)的項(xiàng)目管理之間的區(qū)別。 傳統(tǒng)的項(xiàng)目管理也稱為瀑布流式管理,，學(xué)過PMP的同學(xué)應(yīng)該知道項(xiàng)目管理有5大過程組：?jiǎn)?dòng)過程組,，規(guī)劃過程組、執(zhí)行過程組,、監(jiān)控過程組,，收尾過程組。而5個(gè)過程組里面還有49個(gè)過程,，就拿范圍管理來說,，我就需要做的是 規(guī)劃范圍管理->收集需求->定義范圍->創(chuàng)建WBS->確認(rèn)范圍->控制范圍。例如：我們需要為客戶開發(fā)一個(gè)項(xiàng)目,，工作流程就是先與項(xiàng)目發(fā)起人一起定義項(xiàng)目章程,，然后開一個(gè)項(xiàng)目啟動(dòng)會(huì)議，確定這個(gè)項(xiàng)目的項(xiàng)目經(jīng)理與這個(gè)項(xiàng)目的地位。然后開始規(guī)劃各種管理,，編寫各種文檔（規(guī)劃范圍管理,，規(guī)劃進(jìn)度管理，規(guī)劃資源管理,，規(guī)劃質(zhì)量管理,，規(guī)劃成本管理等等），所有的文檔規(guī)劃經(jīng)過項(xiàng)目委員會(huì)評(píng)審確定后,。就可以進(jìn)入了項(xiàng)目的開發(fā),，這時(shí)候項(xiàng)目團(tuán)隊(duì)成員就開始實(shí)施需求分析，程序設(shè)計(jì)文檔的編寫,，經(jīng)過評(píng)審確定,，進(jìn)入開發(fā)，進(jìn)入測(cè)試,，最后交付,。這就是項(xiàng)目管理開發(fā)模式的其中一種：預(yù)測(cè)型開發(fā)。這種開發(fā)模式適合確定性非常高的項(xiàng)目,，這種管理方式可以大大提高項(xiàng)目的成功,。但如果使用在確定性不高的項(xiàng)目，就會(huì)是一個(gè)比較繁瑣的過程了,。比如你在開發(fā)的過程中出現(xiàn)了變更了,，就要開始走變更流程。如果變更影響了成本,，進(jìn)度,，范圍都要提交到項(xiàng)目委員會(huì)進(jìn)行討論確定要不要做，做就要更新上述中的所有文檔,。如果是大變更大到需要推倒重做,，那對(duì)程序員來說簡(jiǎn)直的折磨煎熬。還有不知道你們注意到?jīng)]有,，其實(shí)對(duì)于客戶來說,，這其中的管理流程都是透明的?？蛻羰亲詈笠粋€(gè)見到產(chǎn)品的人的,，也是最能決定產(chǎn)品是否成功的人。這是一個(gè)很大風(fēng)險(xiǎn),，所以里面就還有一個(gè)項(xiàng)目相關(guān)方管理,，管理客戶的期望。如果客戶見到產(chǎn)品才發(fā)現(xiàn)不是自己想要的,，那就很難受了,，這就是一個(gè)不成功的項(xiàng)目了。當(dāng)然啦，傳統(tǒng)的項(xiàng)目管理開發(fā)的方式可不止這一種,。除了預(yù)測(cè)型開發(fā)意外,，還有迭代開發(fā)、增量開發(fā),、混合開發(fā),。 因?yàn)閭鹘y(tǒng)的項(xiàng)目管理模式有了：無法一次性消化所有需求、懼怕需求變更,、不斷重做,。所以有了很多偏向敏捷開發(fā)，敏捷開發(fā)是歡迎變更,，持續(xù)交付價(jià)值,，快速反饋。在說敏捷開發(fā)的流程之前,，需要先說說敏捷開發(fā)的幾個(gè)方法論：Scrum,、極限編程、看板方法等等,。我這里分享的主要是Scrum,，Scrum是個(gè)專有名詞，它沒有中文翻譯,，沒有意思,，也不是縮寫。只需知道這個(gè)單詞是專有名詞,。Scrum有以下幾個(gè)概念： Product Ower(PO)-用戶/客戶/代言人,，就是可以做出業(yè)務(wù)決策的,。就是可以確定需求及其優(yōu)先級(jí) Scrum Master-熟悉Scrum流程的人,，指導(dǎo)和確保團(tuán)隊(duì)以Scrum方式進(jìn)行交付 Sprint-Scrum中對(duì)迭代的說法，一個(gè)項(xiàng)目或者產(chǎn)品的交付是由一個(gè)一個(gè)Sprint構(gòu)成的,。 User Story-用戶故事,。具有業(yè)務(wù)價(jià)值的交付單位，一個(gè)項(xiàng)目或產(chǎn)品是由多個(gè)用戶故事構(gòu)成的,。 Product Backlog-項(xiàng)目的代辦列表,，由用戶故事構(gòu)成。 Sprint Backlog-一個(gè)Sprint的代辦列表,，確定Sprint有哪些用戶故事,，框定Sprint的開發(fā)范圍。 一個(gè)項(xiàng)目或產(chǎn)品是由很多個(gè)Sprint構(gòu)成的,，而Sprint的周期是固定的,，一般都是2~4周，最好不要超過4周。在每個(gè)Sprint開始的時(shí)候,，PO都會(huì)和IT團(tuán)隊(duì)一起開會(huì),，PO會(huì)對(duì)Product Backlog中的故事進(jìn)行排序，IT團(tuán)隊(duì)對(duì)這些故事進(jìn)行估算,。因?yàn)镾print周期是固定的,，IT團(tuán)隊(duì)的成員數(shù)量也是確定。所以可以協(xié)商出哪些用戶故事放到Sprint進(jìn)行開發(fā),，從而確定了Sprint的開發(fā)范圍,。 接下來IT團(tuán)隊(duì)圍繞Sprint Backlog中的用戶故事進(jìn)行開發(fā)。IT團(tuán)隊(duì)每天都會(huì)進(jìn)行一次15分鐘左右的站會(huì),，站會(huì)只討論三個(gè)問題：昨天做了什么,？今天會(huì)做什么？遇到了什么問題,？注意：暴露了問題后,，私下再組織相關(guān)人員開會(huì)進(jìn)行討論解決方案，而不是在站會(huì)上進(jìn)行討論,，站會(huì)只負(fù)責(zé)盡早暴露問題,。怎么解決站會(huì)后再組織會(huì)議討論。 在Sprint結(jié)束后,，PO有會(huì)和IT團(tuán)隊(duì)聚在一起開Sprint評(píng)審會(huì)議,，IT團(tuán)隊(duì)會(huì)對(duì)PO展示這次Sprint的交付成果，PO有任何反饋或者需求變更都可以作為新的用戶故事放到Product Backlog中重新排隊(duì),，這就是敏捷開發(fā)應(yīng)對(duì)需求變化的方法,。縮短迭代周期就可以縮短反饋周期,，即時(shí)整個(gè)項(xiàng)目的方向錯(cuò)了也可以盡早發(fā)現(xiàn)和調(diào)整回來,，盡可能降低損失。IT團(tuán)隊(duì)可以在這個(gè)時(shí)候舉行回顧會(huì)議,，審視哪些地方在Sprint做的好的,，哪些地方需要調(diào)整的，然后訂下調(diào)整計(jì)劃,，在下個(gè)Sprint中進(jìn)行優(yōu)化調(diào)整,。 以上就是敏捷開發(fā)中的Scrum方法論的工作流程，與傳統(tǒng)項(xiàng)目管理是有挺大區(qū)別的,。但是沒有說那個(gè)管理的方式是最好的,，每個(gè)管理方法都各自有優(yōu)缺點(diǎn)。不同項(xiàng)目情況針對(duì)的使用管理方法才是對(duì)項(xiàng)目,，對(duì)客戶最好的,。最后給大家推薦一個(gè)關(guān)于敏捷開發(fā)的書《獵豹行動(dòng)：硝煙中的敏捷轉(zhuǎn)型之旅》,，這本可以幫助你了解敏捷開發(fā)的一些知識(shí)。 ———————————————— 版權(quán)聲明：本文為CSDN博主「阮小鬼」的原創(chuàng)文章,，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議,，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。 原文鏈接：https://blog.csdn.net/Ruan_Number3/article/details/104501987 資料來源：網(wǎng)絡(luò)搜集,、整理 |
|
|
