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