敏捷中，最重要的是什么呢？基本上所有的教材都會說，敏捷是以人為本的，以團隊為核心的。第一，敏捷不提倡加班，第二，敏捷讓團隊自管理，第三，敏捷中的領(lǐng)導都是服務(wù)員而不是命令者。是不是看著很激動呀，敏捷對員工這么友好嗎？沒錯，相比傳統(tǒng)的項目來說，在敏捷中做項目是快樂開心的。那么，要實現(xiàn)敏捷，我們的團隊需要怎樣的領(lǐng)導與團隊環(huán)境呢？
首先，公司上層的支持是非常重要的一環(huán)。沒有上層領(lǐng)導的支持，一切敏捷都無從談起。為什么這么說呢？因為敏捷真的和傳統(tǒng)的項目開發(fā)非常不同，甚至很多東西都是讓人感覺不可思議的。即使是現(xiàn)在的我看來，結(jié)對編程這種敏捷方法依然還是無法進入主流。畢竟讓兩個人去盯著一個電腦屏幕，編輯同一段代碼這種美好的事情在國內(nèi)的互聯(lián)網(wǎng)公司中還是很難實現(xiàn)的。有這兩個人力當然還是需要在996的基礎(chǔ)上讓他們完成4個人的工作，這樣才能更符合老板的利益嘛。
所以說，如果你在這樣的一個狼性的公司工作，很多敏捷中的美好實踐肯定是無法實現(xiàn)了。但是，它們又很善于利用敏捷中的其它概念，比如迭代周期完了就得發(fā)布，你完不成就得加班，事后的迭代回顧又變成了批斗大會。類似的情況簡直數(shù)不勝數(shù)。
說實話，真正的幸福的敏捷公司、敏捷團隊，恐怕真的只能是聽說、傳說了。
當然，夢想總是要有的，萬一實現(xiàn)了呢？作為項目經(jīng)理的我們，在學習到了后續(xù)的敏捷實踐之后，還是要盡可能的說服老板在公司中多多嘗試，多多實踐。這也非?？简炍覀児芾砀上等说乃胶臀覀兊能泴嵙?。爭取領(lǐng)導團隊和老板的支持，是在任何公司中要推行任何制度方法的必經(jīng)之路。這一點，無法逾越，也是我們要面臨的最大的考驗。
雖說項目經(jīng)理帶著經(jīng)理兩個字，但在敏捷中，項目經(jīng)理還真不如不加這兩個字。其實，在 Scurm 中，就正式放棄了項目經(jīng)理這個稱謂，取而代之的是 Scrum Master ，也就是 敏捷教練 。由此也可以看出，在敏捷中，管項目的不一定是個經(jīng)理，如果不是經(jīng)理，那么也就避免了一些問題，特別是傳統(tǒng)項目管理中的集權(quán)命令式項目經(jīng)理的問題。
在傳統(tǒng)的項目管理中，項目經(jīng)理除了要做規(guī)劃，要整合各方干系人和資源外，還對項目團隊有著一定的權(quán)利，甚至一個項目經(jīng)理可以左右項目的生死。不過，在 PMP 中，項目經(jīng)理定義的也是以服務(wù)團隊為主，需要善于運用職位權(quán)利、個人魅力、專家權(quán)威等各方面因素讓團隊成員團結(jié)在你的領(lǐng)導下。
在敏捷中，完全提倡的是一種服務(wù)型的領(lǐng)導風格，就像敏捷教練這個稱謂一樣，只是教練，給你提供方法而已，除此之外，沒有別的了。
在敏捷中，我們需要的是一種敏捷的領(lǐng)導力，比如說，我們更加關(guān)注的是人，而不是這個人的績效，對于績效來說，我們更加關(guān)注的是效果。而在控制過程中，我們的領(lǐng)導力體現(xiàn)的是授權(quán)，這個授權(quán)可能是對整個團隊的授權(quán)，我們相信的是團隊整體的力量。
在整個項目的開發(fā)過程中，始終以一種指導的形態(tài)出現(xiàn)。不說出答案，只點出問題和提示。發(fā)現(xiàn)團隊成員做事的原因和動機，理解他們的需求。通過項目目標和任務(wù)對整體進行調(diào)整以項目要求。
另外，管理和領(lǐng)導是兩個概念，管理更偏重于對人和事的束縛，而領(lǐng)導更偏重于對人和事的期待。管理更多的是指揮、命令和控制，而領(lǐng)導 是讓人們?nèi)プ鏊麄兿胱龅氖虑?。這是相輔相成的，在敏捷中，我們不排斥管理，甚至在很多情況下管理是有其重要作用的。但是，我們更看重的是領(lǐng)導力。沒有什么比讓員工自發(fā)自愿的來完成工作更棒了。所以，做為敏捷的項目管理來說，激發(fā)團隊，創(chuàng)建更多的環(huán)境來滿足員工對于工作的欲望，是一個好的項目管理者所應(yīng)該具備的能力。
服務(wù)型領(lǐng)導是怎樣的一個概念呢？這個還真是敏捷提出的一種領(lǐng)導類型的概念。就像上述的敏捷領(lǐng)導力中所說，敏捷更看重管理者的領(lǐng)導力，而這個領(lǐng)導力中最重要的就是為團隊成員創(chuàng)造條件以激發(fā)他們的戰(zhàn)力。因此，管理者，或者說團隊的領(lǐng)導，就要服務(wù)于這個團隊，也就順理成章的成為了這個團隊的“仆人”。也即一個服務(wù)型的領(lǐng)導，具體來說，服務(wù)型的領(lǐng)導要做到：
保證團隊不受干擾
移除工作中的障礙
溝通項目愿景
為團隊帶來食物和水（后勤保障）
不管做什么項目，不管采用什么類型的項目管理方式，團隊都是一個項目開發(fā)過程的重中之重。畢竟沒有團隊，沒有人，這個項目從何做起呢。
在傳統(tǒng)的項目管理中，有職能型組織、項目型組織和矩陣型組織三種。一般的項目團隊可能會包括在這三種類型的組織中。在敏捷中，其實我們更偏項目型的組織，但它又并不排斥別的組織形式，職能型的項目團隊成員也是可以加入的。甚至一些測試工程師也是多個敏捷團隊所共用的，這一點在敏捷來說，并沒有什么問題。
而在敏捷中，更關(guān)注的是團隊的組成以及工作的方式。就像下面我們將要討論的問題。
何為自組織團隊呢？
其實這和管理學大師德魯克還有點關(guān)系，因為他提到過：“知識工作者必須要自我管理。他們必須要有自主權(quán)。”
對于敏捷來說，它誕生于軟件開發(fā)行業(yè)。眾所周知，軟件行業(yè)本身就是典型的知識工作者聚集的地方，很多業(yè)界大佬都是碼農(nóng)出身，試想，如果他們當時在開發(fā)的過程中，沒有自主的管理和決策能力的話，能成就當前的事業(yè)嗎？所以說，其實敏捷的基因早就已經(jīng)出現(xiàn)在了各家公司中，只是被少數(shù)的人把握住了，而被另一批人發(fā)現(xiàn)了形成了一套理論而已。
自組織的團隊，其實就是能夠自我抉擇如何更好地完成工作，說穿了，要給自組織的團隊足夠的授權(quán)。管理者和敏捷教練都不一定能夠有完備的領(lǐng)域知識，團隊中的某個人也不一定有，但組成的這個項目團隊，應(yīng)該是要具備這個知識能力的。所以，放手讓團隊來獲得一些權(quán)利，讓他們能做一些決定，也不失為一種很好的激勵手段。這也和前面講過的 服務(wù)型領(lǐng)導 的概念一致。
要想達到自組織的境界，對成員的能力其實也是一個不小的挑戰(zhàn)。敏捷中最期望得到的是 “T” 型人才。也就說，這個團隊成員要對某一個領(lǐng)域有深入的理解，也要對所有的方面都有粗淺的認識。比如說，一個測試人員，在產(chǎn)品人員出現(xiàn)問題的時候，也能夠幫忙編寫維護一些產(chǎn)品文檔。或者說一個開發(fā)人員，也可以去做一些測試工作。
不過，這里并不是說每個人都要成為 “全棧” 。很多 “全棧” 工程師，其實往往更多的情況下是什么都懂但什么都不精。這樣的人才不是敏捷團隊所歡迎的，記住，“T” 中的那一個豎，也就是精通的那個領(lǐng)域也很重要！
至于說在公司組織中，如果找不到這樣的人才呢？那就要考驗項目經(jīng)理或者敏捷教練的能力了。要自組織，要這種 “T” 型人才的根本目的，其實是為了實現(xiàn)小團隊、實現(xiàn)用戶故事的評估、實現(xiàn)迭代規(guī)劃、實現(xiàn)內(nèi)部的高效交流溝通的目的。如果實在找不到這樣的人才，那么普通的人員只要能夠達到真正意義上有意義的溝通，其實也是沒有問題的，這些也可以通過各種敏捷工具來實現(xiàn)，大家也不必拘泥于此。
團隊的具體結(jié)構(gòu)當然是有能夠為項目提供助力的人員組成，比如在軟件開發(fā)中，軟件工程師是必不可少的，測試人員也是不能沒有的，而在 Scrum 中，也有專門的 Product Owner ，也就是產(chǎn)品負責人。此外，其他的人員就視項目情況而定。
在敏捷團隊中，我們推薦的是小而輕的團隊，所以團隊人數(shù)不宜過多。如果是非常大型的項目，也可以拆分成多個小的敏捷團隊。這個我們在后面會講到，每日站會的時候，最好不要超過 10 個人。如果有多個團隊，那么就是在每個團隊中選擇一個人（多為教練或產(chǎn)品負責人）進行多團隊間的每日站會，同樣，也不要超過 10 個人 。
同時，我們還要區(qū)分哪些人和哪些團隊對項目有著至關(guān)重要的影響。在敏捷的各類書籍中，都流傳著這樣一個故事。豬和雞要開一個餐館，雞出的主意說我們就賣火腿和雞蛋，豬想了想覺得不對勁呀，對雞說：“我付出了全部，而你只是貢獻雞蛋，這不對呀”。以故事的形式來說明一個問題，這在 XP 中就稱為 “隱喻” 。這個隱喻說明的是什么呢？其實就是說，項目中的團隊成員都是“豬”，是全身心投入的，而一些其他干系人，只要不是在項目團隊中的，其實都是雞，他們只是偶爾參與。我們需要傾聽他們的意見，甚至將他們的意見當做是重要的參考資料，但是，別忘了，我們是“自組織”的“全身心付出”的敏捷團隊。
今天的內(nèi)容其實是針對想要實現(xiàn)敏捷的組織或者個人來說，首先需要考慮的一些問題。比如上級領(lǐng)導的支持、敏捷應(yīng)該如何管理以及敏捷團隊是個什么樣的。在后面的文章中，我們還會詳細的學習這些內(nèi)容。先有個底子，將來才好更加深入的理解嘛。下一章將會是大家非常感興趣的內(nèi)容，也就是幾種敏捷框架的介紹，其中會重點介紹 Scrum ，千萬千萬不要錯過哦！
參考文檔：
《某培訓機構(gòu)教材》
《用戶故事與敏捷方法》
《高效通過PMI-ACP考試（第2版）》
《敏捷項目管理與PMI-ACP應(yīng)試指南》
PMI-ACP
聯(lián)系客服
