1. <optgroup id="dbbky"></optgroup>
  2. PMP
    為了更好的用戶體驗,并能正常使用所有功能,我們建議您使用 Chrome瀏覽器(點擊下載>>)
    資訊首頁
    直播課堂
    視頻課程
    學習包
    題庫

    首頁 > PMP > PM創造營 > 敏捷是什么?為什么要使用敏捷項目管理?

    敏捷是什么?為什么要使用敏捷項目管理?

    • 劉政
    • PMP
    • 2019-08-01
    • PMP交流群: 685352740
    摘要: 敏捷是什么?為什么要使用敏捷項目管理?下面是PM創造營談論的具體內容,更多PMP考試相關資訊可關注希賽網。

    1564649101(1).jpg

    分享嘉賓:大懶

    1564649129(1).jpg

    大家晚上好,有幸接受這個邀請,去給大家說一說,就是關于敏捷的事情,敏捷這點兒東西呢,我其實也是一個失敗者。但是呢,在失敗的過程里面也找到了一些正確的方法,希望能通過這個機會呢,把更多的信息告訴大家。

    1、什么是敏捷

    很多老板在選擇用怎樣的開發模型去開發,特別是開發軟件的時候,總有這樣一個誤區。我們使用了敏捷方法之后,可以更快的去交付產品,可以縮短產品研發的生命周期,可以節省成本。這個理解是有偏差的。

    首先給大家說明這個問題,敏捷不一定會很快

    為什么不一定會很快呢?假設我們是一種迭代開發的模式,我們用很多的迭代去開發同一個產品,大家想象一下,是不是每一個迭代里邊都會有一個小瀑布呢,那么在每一個迭代里面的測試,開發,設計,這些環節是不是都要重新再來一遍呢,所以說敏捷,它不是一個能夠更快交付的模型,而是一個能夠更頻繁交互的模型。

    第二,敏捷不一定會節省成本

    其實明確的說,敏捷這件這種行為是非常昂貴的,這與他的研發模式和行為方式有關系。待會講到敏捷需要一個什么樣的團隊,敏捷會需要什么樣的測試方法,或者是成本核算方法。包括風險識別方法,包括需求控制的方法,對這些方法的使用過程里面可能會產生額外的成本。而這些成本會造成敏捷的成本相對增加。

    但是呢,敏捷不是為了節省成本和快速開發縮短開發周期而誕生的。

    2、為什么要使用敏捷

    我介紹一下這個敏捷模型,這個模型能很好的告訴我們,為什么要使用敏捷去解決問題。

    1564649159(1).jpg

    這個東西就叫Stacey矩陣,或者叫Stacey模型。

    這個模型里面分四個部分,一部分叫Simple,just do it。第二部分叫Complicated,然后空白的部分叫complex,右上角那個我把它叫混沌,混沌的問題咱們不去討論,實際上我們在軟件開發里面,要做的事情就是三體里面講的,叫降維打擊。

    在這個過程里,我們將復雜的東西劃到一個相對簡單的區域去解決。然而呢,對于一些很復雜的情況,比如說,我們需求很不確定,我們也不確定用什么方法去做這些事,我們就用敏捷方法去做。敏捷方法是什么呢,就是持續學習,持續迭代,持續規劃這樣一個方法。

    這是一個實用的非預定義過程。

    有同學問,敏捷項目和傳統項目的區別,如何進行混合應用,相互取長補短?傳統項目即預測型項目。

    我們在預測性的項目里,做的事情是這樣的。首先有一個發起人,然后我們做一個詳細的計劃,然后強制團隊,或者說責令團隊按計劃去進行,然后在中間控制變更,按規定測試,結項等等,最后交付產品。

    然而,敏捷不是這樣的,一個敏捷軟件的開發往往在敏捷初期,是不會預見到幾個迭代之后的軟件需求的。它往往是,以最小可行性產品,MVP,去交付給客戶。也就是說我們用最基本的模型,最基本的能用的東西給客戶去用,從而不斷的得到客戶的反饋,不停的迭代,改進,或者重構。這就是擁抱變化,或者叫檢查和適應,敏捷和傳統項目的一個比較好的區別的詮釋。

    所以敏捷,其實是一種輕量型的,最開始確實是用在軟件上的,軟件開發原則。它是一種方法,一種思想,是一種迭代的研發模式,而且是增量的,是一種一定時間盒的,以價值為中心的。

    敏捷是一種適應復雜情況、不靠譜客戶的,一種持續學習,持續增量的迭代模型。

    敏捷有一個特別著名的東西叫做敏捷軟件開發宣言,這個當時在2001年發布的時候,推動了硅谷的一個改革。

    http://agilemanifesto.org/iso/zhchs/manifesto.html

    1564649193(1).jpg

    敏捷宣言里面提到了四點價值觀,這四點價值觀大家看看就行了。他最重要的一句話,盡管右向有其價值,我們更重視左向的價值。說白了就是,你一切從客戶出發,一切從變化出發,一切從成果出發,一切從價值出發,比你那些花里胡哨,按規定來的這些東西,更有價值。

    它是一種價值觀,也代表了這一幫人的一種處事方式。

    3、 敏捷Scrum框架

    下面介紹一些敏捷的方法,因為它是一種價值觀,是一種思想,所以說有很多大牛,開發了一系列敏捷框架。

    1564649214(1).jpg

    目前有有記載的,著名的敏捷框架有30多種,非著名的那可能好幾百種都有。今天主要介紹就是那朵云彩,Scrum框架。

    Scrum框架是在當今的軟件開發界里面應用得比較廣的一種框架,也是國內能看到的,大多數的敏捷在線項目管理工具的范本。

    目前這個框架呢,有一個叫Scrum聯盟的組織,在負責維護和管理。這個組織,每年會有一些認證,每年開一些會議,會定期地去更新這個框架。最新的這個框架A4紙打印出來只有27頁。大家可以看到其實沒有什么內容,里面寫的就是一些原則和方法。

    Scrum框架的思想來源于一個著名的思想叫精益思想,這個思想是豐田在上世紀80年代提出來的。這個思想有兩個重點,一個叫,respect people,尊重人;另外一個叫Continuous improvement,也就是持續改進。實際Scrum框架也是秉承的這樣的原則。

    1564649243(1).jpg

    Scrum框架大概是長這個樣子的。它里面有一個3355的原則,就是三種角色,三種工件,五個會議,五條核心價值觀

    1.第一個"3"

    左上角這三個圈兒就是我們所說的這個3355中的第一個3就是三種角色,在Scrum這個框架里面我們會給團隊分配這三類角色,第一類叫Scrum master,不是一類啊,這是一個人;第二類叫產品負責人Product Owner;第三類叫團隊,Team。

    Scrum master在這里不是項目經理的意思,他更像是這個團隊的保姆,他要負責整個團隊的鼓勵工作,為團隊服務,給團隊提供理論支持,引導團隊。更像是教練的一個工作。

    Product Owner是這個Scrum團隊里邊兒唯一一個經過授權的人,他負責的是整個產品。整個產品開發做什么,不做什么,哪一部分在哪個時間點交付的這個工作,也就是說,負責構建產品待辦列表。

    在Scrum里頭,這個團隊是近似于全功能的跨職能團隊,其實敏捷對團隊的要求是非常高的,這也是他成本高比較貴的原因之一。

    舉個簡單的例子,我們可能會在敏捷團隊里面要求產品開發人員去編寫測試用例,甚至是去執行這樣的測試用例。甚至是我們測試人員也要去寫這種行為分析用例,要寫代碼。所以說最理想的Scrum團隊的Team,每一個人都應該是通才。

    上面這一段就解決了“常用的敏捷架構是什么樣的,團隊是什么樣的”這個問題。其實我覺得任何一個團隊都有可能會去變去轉化成自己的團隊,只要你有合理的配置,然后一個足夠能引導你進入敏捷開發空間的這樣一個人就可以了。

    2.第二個"3"

    Scrum的3355的第二個3也就是三個工件。

    ①第一個工件,叫產品待辦列表(Product Backlog),它其實有點兒像我們現在產品開發中講的需求池的概念,通常來講,我們會把所有需求一股腦的扔到這個列表中去,但是這個列表會有一個與傳統的需求池不一樣的地方。這個列表里面所有的需求,都是有價值的,有次序的。

    ②通過我們價值的體現,包括我們對它的排序。我們就會得出這樣一個結論,我們應該先做什么,后做什么,于是就有了第二個東西,我們叫做Sprint backlog,這個東西,翻譯成中文就是沖刺待辦事項

    ③然后我們看第三個工件,在那個大圓圈右邊兒,叫潛在可交付產品增量,這個東西大致的意思是,我們在做產品的時候,是一個迭代增量的過程。

    比如說我的需求是通行,從A地到B地,我們傳統的做法是定一個需求,這個需求可能會很大,比如造一輛汽車去進行通行,通常在傳統里面,我們會先造一個輪子,再造一個底盤,然后再造一個殼兒,再往里面填充起來。

    但是對于敏捷來講,不是這樣操作的。增量交付一個很好的例子就是這個通行問題,我們先造一個滑板車,先能滿足這個用戶的需求,然后我們再造一個自行車,更加的便利。然后我們再造一個摩托車,最后我們再造一個汽車,最終交付給客戶。

    1564649271(1).jpg

    從這一點上我們來看,這個敏捷實際上在交付用戶的使用價值,或者說在交付用戶的價值。

    3.第一個"5"

    ?

    我們在這個敏捷里邊兒有五個會,

    ①第一個叫Scrum計劃會議,把產品待辦事項列表里面的東西決定哪些可以在Scrum計劃會議里邊兒解決掉。

    ②第二個會議,我相信很多的企業,很多的團隊在做,叫做每日站會

    這個站會通常都問什么問題呢,我昨天做了什么,今天我要做什么,我遇到了什么問題,通常都是這樣的對吧。但是我想告訴大家的是,大多數團隊開這個會的時候,問的這三個問題都是不正確的,我們去看原文:

    第一個問題:What did I done yesterday that helped the Development Team meet the Goal?

    第二個問題:What will I done today to help the Development Team meet the Goal?

    也就是說在敏捷開發這個環境里面,我們不會講我做一件事情,做了百分之多少,在敏捷的世界里沒有百分之幾這個概念,它只有零和一。沒完成就是零,完成了就是一。所以他的問題會說,我為了我們團隊的目標,昨天做了什么;我為了我的團隊目標,今天我要完成什么。

    ③第三個會議叫做Sprint評審,Scrum review。這個會議就是來評價你迭代的這個產品,是不是可以納入到潛在可交付的產品增量,這還是個潛在的,還是不可交付的,經過了這個會,你能不能交付這個事兒就能定了。

    ④第四個會議叫Scrum回顧。希賽發過一篇文章,里面有一部分講回顧(文章后附該篇文章的鏈接)。那就是敏捷回顧的一部分,叫做帆船工作法,或者帆船回顧,有興趣可以翻回去看一看。敏捷回顧對敏捷這種活動來講是非常重要的,應該說是在這幾個敏捷Scrum的活動里面是最最重要。通過回顧,我們不但能夠找到過去的一些缺點和失誤,還能發現一些優點,并持續的改進下去,這對于敏捷團隊尤為重要,為什么呢,因為敏捷這件事,第二個原則就是要持續的改進。

    ⑤第五個會議是一個持續的活動,這個活動叫產品列表梳理。說白了就是收集需求。因為敏捷相對于傳統開發,這個需求不是那么穩定。但是我們講擁抱變化,我們擁抱變化,不是為了讓需求蔓延。擁抱變化,也不是為了讓項目鍍金,擁抱變化的意思是要讓項目符合用戶的價值,要讓項目達成既定的目標或持續改變著的目標,我們要對這個需求做調整,這件事才叫擁抱變化。

    4.第二個"5"

    對于Scrum來講還有五條價值觀,專注,公開,承諾,勇氣,尊重。

    4、敏捷實踐

    另外給大家介紹一下敏捷實踐,敏捷實踐是很有意思的,其中有一個叫結對編程,是極限軟件開發里面的一個活動,兩個人用一臺電腦去編,一個人寫,一個人看。

    這個事兒從敏捷的角度來講,是一個代碼review的過程,實際上是替代了代碼評審。

    但是同時還有一個更大的價值,我們把一個初級工程師和一個高級工程師放在一起,這兩個人的水平會無限趨近,水平低的會往水平高的趨近。

    Scrum指南的網址有很多版本,大家可以去下載看一看。https://scrumguides.org/

    5、QA

    Q:敏捷這一概念是否像咱們群的口號一樣:一切皆項目,是否敏捷這一概念一切都適用?

    A:這個不盡然,因為,就比如說我們學PMP,有個事業環境因素,意思就是每一種情況,都不一樣,團隊也不一樣,項目也不一樣,實際上我們現在有很多的很多敏捷框架,好像可以解決各種各樣的問題。在敏捷開發的早期,布道的老師們包括敏捷宣言的翻譯者,給人講課的時候,他說敏捷可能會適用于產品開發項目和小團隊開發項目。所以說最初的Scrum文檔里頭,他會講你的團隊規模要保持到七加減二。

    為什么是七加減二呢,因為這個是有一個臨界值,大家學過溝通管理里面團隊溝通的項目公式N*(N-1)/2。所以七加二,正好是一個臨界點。但是對于現在的項目來講,使用小團隊,小迭代已經不能滿足很多企業的要求。比如說,網易阿里騰訊,大家都在用敏捷的方法開發大型項目。所以現在有很多的敏捷理論,比如說LeSS啊,比如說SAFe啊,這種理論會支撐著他們去做大型項目的敏捷。

    敏捷團隊有個行為叫自組織,就相當于團隊七個人,每個人都是項目經理,每個人都是干活的,每個人都是測試,每個人都是各種各樣的角色。所以說對于敏捷這件事兒來講,質量是由整個敏捷團隊來負責,不是有哪個人去負責,成果也是有整個團隊去負責的。

    Q:敏捷項目如何做到過程文檔規范?

    A:這個事情我給大家講一個故事,我們在第一次CMMI三級評估的時候,我們把快速模型,也就是敏捷基于Scrum模型的方法融入到了CMMI的方法里面,然后對它進行文檔規范化。但是這件事兒呢,失敗了,失敗的原因第一個團隊問題,第二個就是他與當時的CMMI一些理念,是有沖突的。

    那么,對于文檔規范化的問題呢,敏捷里面有一個這樣的思想:我們所有的敏捷開發團隊都應該有一個信息源。這個信息源應該是所有敏捷團隊成員及其相關的所有成員,包括你的領導們,都能看到。信息源上應該有項目里面的能夠展示的所有信息。

    我舉個例子啊,如果非要把過程文檔化,我的建議是用系統去做,一個管理系統去做,用看板去做,然后呢,不要太追究這個形式,要看你文檔規范化管理的目的是什么,是要管控流程,還是要管控某一件事兒,所有的這些東西在信息源上做相應的展示就可以了。

    Q:敏捷項目和傳統項目的區別,如何進行混合應用,相互取長補短?傳統項目即預測型項目。

    A:這個是很多團隊,包括我在內也在不停研究的一個事兒,我的觀點是這樣的,我們適當的在團隊內推行一些敏捷的行為和活動,從而引導團隊去用敏捷的思想。或者說相對敏捷的思想去思考問題,在團隊層面上先建立一些敏捷或者敏捷行為的習慣。

    當然,在這個過程里面可能會比較痛苦,可能會造成效率的下降,但是這是敏捷轉型的一個必經階段。在敏捷轉型中,授予團隊的首先是行為,然后是理論基礎,然后再是架構和方法。我覺得這樣推廣比較好,團隊也能很嚴謹,比較能夠接受。

    Q:敏捷項目中的風險如何識別和把控?

    A:首先從傳統意義上來講,這些風險的來源在哪兒,作為一個項目來講,我們風險來源無非就那幾項。首先你的風險來源肯定會有一個歷史數據的風險對照表。

    那對于敏捷來說,這是什么呢,還記得我們敏捷有一個回顧活動嗎,在回顧活動中,我們會識別一些阻礙,會識別一些暗礁,不知道暗礁是什么同學,可以補個課https://mp.weixin.qq.com/s/wvnw56ENY0wHYLkUM6yd2Q

    這是其中一個來源,另外一個來源呢,我們之前講了敏捷有個sprint計劃會議,在計劃會議里面有很多活動,其中一個活動,就是討論需求的價值。因為敏捷活動需要交付價值,我們在需求層面上要充分討論需求的價值,那么需求的風險會降到,怎么說呢,需求變動的風險其實很大,但是他可能會降到零概率。

    然后就是一些其他風險來源,比如說人的風險,設備的風險,資源的風險。。。這些風險,應該是能在團隊內部消化的。對于控制這樣的風險,作為一個敏捷團隊來說,應該自己能夠去識別,能夠去控制,而且能夠在會議里面解決掉。

    站會要提三個問題,第一個問題:what did I done yesterday;第二個問題:what l will down today;第三個問題:我遇到了什么樣的阻礙和困難。

    Q:敏捷項目里面有哪些活動是可以推廣的?

    A:最簡單的就是站會,另外一個覺得比較值得推廣的就是用戶故事和用戶故事地圖

    用戶故事從根本上來講就是一個需求,就是作為一個什么樣的用戶,需要一個什么樣的東西,以解決我什么樣的問題。對于敏捷來講,他的需求是有一個invest(要求)的,看下圖

    1564649303(1).jpg

    用戶故事有一個3C原則,第一個叫card,也就是說寫在卡片上;第二個叫conversation,對話;第三個叫confirmation。它實際上是寫在卡片上,用來激發產品或者需求討論,從而達成各方一致的行為。

    用戶故事實際上就是這個用戶行為的一個集合,就像這張圖里面,左上角是一個客觀條件,是一個人物畫像,女人30歲,一條狗。然后她起床會做哪些事兒,洗漱整理會做哪些事兒,照顧家人會做哪些事兒,然后哪些事兒是按順序做的。這對于用戶行為需求一樣也適用。

    我們擁抱變化的同時,我們就要去適應這種變化的發生,在這個時代很多不確定因素會使你的需求變得越來越不穩定。

    作為產品經理,你的責任是盡早的去識別變更。而作為研發團隊,你的責任是需要使用更靈活的框架,或者不斷的減少你的技術債,去適應這樣的變化。

    Q:敏捷項目如何估算確定項目交付期

    A:通常來講,我們做傳統的估算,無非就是經驗估算法,Delphi估算法,功能點估算法。我們估算出來的結果是一個絕對的值,也就是說,我估算的東西,要么是我工程的規模,要么就是完成這個工程使用的工作量(人·天)。

    但是對于敏捷來說,通常來講估算的都是故事點,或者說是一個相對的變量。我會在一個敏捷團隊的內部定義一個叫“1”的東西作為一個標桿,然后針對這“1”去做相對估算。

    比如說我有一個“1”,我有一個功能,可能是1.5,可能,2,可能是4,可能是8,通過這樣的估算,我們能估算出來我這一些的需求,這一堆的故事需要幾個“1”。

    在迭代的初期,我們會試著把幾個這樣的東西放到一個迭代里頭,通過迭代的不停的迭代,兩個,三個迭代之后,這個“幾”能夠放在迭代里頭的這個“幾”,就相對穩定了。可能我們第一個迭代能做八個,放了十個進去,我們只做了八個;第二個迭代我們只往里放八個,我們發現八個相對也挺高,我們只能做七個;第三個迭代我們做了七個,第四個迭代我們也做了七個。那么,這個團隊的迭代速率就是七。

    那對于一個穩定的敏捷團隊來說,你知道了你的速率是多少,同時,你也能知道你產品規模的這些點是多少,那你的交期就可以確定了。

    Q:敏捷項目如何快速、準確評估項目預算

    A:我們用的敏捷估算方法都是很好玩兒的方法,比如說有撲克估算法,T恤估算法,大小杯子估算法等等。

    這種敏捷估算撲克是專用的,在網上可以買到。第二個叫T恤估算法,就是用大小來估算,具體方法比較復雜,大家有興趣的可以去查一查。

    話說回預算的問題,對于敏捷團隊來講,不會做一個初始的預算,規定我的預算是多少,通常來講,我們在項目的初期會訂一個預算目標。這個目標是一個用經驗值來做出來的,或者大家共同認同的一個目標

    那你在敏捷迭代活動中或敏捷開發活動中,你的所有活動可能就要圍繞著這個目標去做。

    Q:敏捷開發的缺點?

    敏捷開發的缺點很多,我挑重點的說。

    ①敏捷開發對于某些團隊是絕對不適應的。比如說,一個臨時的團隊,敏捷團隊最好是相當的穩定。如果我的團隊里面有個人很不穩定,他隨時都可能會離開。那么這個團隊就不適合做敏捷,甚至說我覺得應該把這個人提前踢出團隊,再去考慮敏捷這個事情

    ②然后敏捷對團隊的要求是非常高的,首先這個團隊里面所有人都得水平相當,然后所有人的溝通能力和協作能力都要非常強。

    ③另外呢,就像剛才一同學說的,如何做好敏捷文檔規范化。敏捷宣言里面有句話叫,使用的軟件勝過詳盡的文檔。敏捷對文檔的規范化或者文檔的作用,看得不是太重,但是實際上它是有一定的文檔規模的。但是就是這個文檔的不完善,對新加入敏捷團隊的人是一種挑戰,還是剛才那個穩定性問題。

    文檔的缺失實際上會給后期的維護,二次開發等等帶來一定的困擾。我會建議團隊去單獨抽出一個人去做這些事情。

    ④還有一個缺點就是,我見到的大多數敏捷團隊都有冗長的技術債要還。就是因為沒有一個足夠靈活的軟件框架來適應足夠多的變化。

    ⑤最后假設我們不斷給用戶交付用戶覺得有價值的產品,這個時候用戶是持續滿意的。反之如果我們交付的是用戶不怎么喜歡的產品,用戶是不是就持續不滿意了。實際上用戶持續不滿意,還是有去改進迭代的空間。但是我們要考慮到不滿意是因為技術債,還是因為質量崩塌,還是因為團隊不穩定,還是因為需求等等。

    ⑥很多的敏捷團隊還會產生質量崩塌的情況,從質量來說,我還是覺得傳統的方式比敏捷的要好一些,因為他的管控力度,包括過程管理,結果驗證這些東西,還是比較好的。

    但是敏捷在質量中還是有一些辦法的,下面介紹幾個跟質量相關的工具:

    第一個叫TDD,測試驅動開發,就是先寫測試用例,然后再寫代碼,然后找到一個比如jenkins那種的持續集成工具上跑一下你的測試用例。

    第二個叫行為驅動開發,這個通常來講是有測試人員去做,行為驅動開發一個比較好的工具,叫cucumber(黃瓜)。它是一種以用戶為角度的行為測試工具,這個去迎合和測試業務場景是非常好的。

    Q:采用傳統瀑布模式開發的項目可以敏捷嗎,怎么操作?

    A:先行為導入,然后知識導入,然后再價值導入,然后再知識導入,這樣一步步潛移默化的去改變他們的行為方式。

    瀑布模式開發的項目可以敏捷嗎?這個東西也不盡然,這個得看項目類型和團隊行為方式。如果一個企業,一個團隊想做這種敏捷轉型,我的建議一直都是你去找一個專業的教練幫助你去做,不要自己看本書就做,很多敏捷轉型因為這個失敗,這個很容易失敗。

    Q:今后敏捷是否更受企業的青睞?

    A:不僅谷歌微軟在用,國內的大廠也都在用。這個就沒有什么討論的了。

    6、看板

    補充一個看板的知識,看板這個東西其實也是挺重要的,在如果有同學學ACP,ACP推薦的書有一本就是看板。

    看板就是我發的這張圖,這就是一個最簡單的看板。看板有兩個作用,第一個作用叫價值流動,第二個作用叫限制在制品

    1564649508(1).jpg

    看板就是每天在開早會的時候,把各個工作改一改狀態,就是這么簡單的一個事情。看板其實做了敏捷中的很多事,它起到了信息發射源的作用,也就是說,團隊中的所有成員都能通過這個看板看到這個項目的進度和項目實時的情況,而且能夠知道我在這個項目的哪一列上,或者說在哪一個狀態上有遲滯了。

    有興趣的同學可以去看那本兒看板方法,里面講的很詳細。

    最后分享一個看板實踐這本書的讀書筆記

    1564649524(1).jpg

    想要加入PM創造營的小伙伴可以點擊:【PM創造營招募】

    更多PM創造營文章請點擊:往期PM創造營話題討論結果匯總

    • 本文標題: 敏捷是什么?為什么要使用敏捷項目管理?
    • 本文鏈接:

    近期直播

    羅福星

    09-29 19:30-21:30
    PMP?考試介紹

    PMP

    立即預約

    趙羽

    09-26 19:30-21:30
    消防安全技術實務模擬考講解

    消防安全技術實務

    進入課堂

    張斌

    09-26 19:30-21:30
    2019年一建水利水電真題解析

    水利水電工程

    進入課堂

    胡秋萍

    09-26 19:30-21:30
    2019年一建機電真題解析

    機電工程

    進入課堂

    陳翔

    09-26 19:30-21:30
    2019年一建市政工程真題解析

    市政工程

    進入課堂

    李碧茹

    09-26 19:30-21:30
    2019年一建公路工程真題解析

    公路工程

    進入課堂

    邵春寶

    09-26 19:30-21:30
    2019年一建通信與廣電真題解析

    通信與廣電工程

    進入課堂

    宋一果

    09-26 19:30-21:30
    2019年一建建筑工程真題解析

    建筑工程

    進入課堂

    羅卜

    09-26 19:30-21:30
    2019年9月基金從業《基金基礎知識》真題試卷分析

    證券投資基金基礎知識

    進入課堂

    距離2019-12-07 考試還有

    • 7
    • 1

    題庫

    考試報名
    準考證
    成績查詢
    PMP考試
    證書領取
    Project
    PM創造營
    哥要色哥要射