略有耳聞

行業變化真的很快~思想更新迭代更是應接不暇。

我在最早最早聽到敏捷開發的時候是2014年，入行剛剛兩年。

猶記得當初領導引出這個話題，大家討論開來。

“咱們敏捷不起來，那是外國玩的東西”

“敏捷就是快，極限程式設計，到時候程式碼都是坑。還得重構”

其實很多對話已經很模糊了。但是整體的氛圍就是，想玩會把自己玩死。

當時作為一顆小白菜的我~，完全聽不懂他們在講什麼。只能從字面意義去暢想。

敏捷--就是快速的意思唄，快就對了。

極限--是不是就是給你個需求你能超出極限幹出來。

這太恐怖了。後面這個話題慢慢就不知不覺中煙消雲散

痛苦

對敏捷的認識，我的思想依舊停留在之前的認知。一直沒有人討論，也沒有過自己主動補充。

主要原因，周圍的人習慣了這種跨度長，按部就班的迭代方式。

即便是有人提出過異議，依舊還是寡不敵眾，重回其道。

2017年11月 到 2019年元旦，這是我感觸頗深的一段時間。

因為分組原因，起初有一個很不起眼的系統放在了我們組，然後這個系統從無到有，我們進行快速開發上線。直到我一個人維護這個系統兩年。

後面因為我還有另外一個重要的工作，使得這兩個工作項，在衝突中迭代，在痛苦中來回切換。

其中的痛苦對於沒有管理經驗的我來說真的是煉獄。

我向管理層提出了我的想法，是不是可以改變一下這種節奏？

通過深思熟慮我從.NET組轉到了php組（可以理解為也是技術棧的完全切換），就是我們說的轉語言。

但是轉過的我，依舊痛苦。需求不斷，我依舊使用C#迭代著這個內部系統。

10月份接到一個高層領導們提出很多需求，準備一個大版本迭代。必須在元旦前上線。

首先：

人不夠 -- 找外包和我一起來做

時間長 -- 砍掉估時的一半，加班做

資金 -- 外包2人，算是增加了預算

結果可想而知：

好在上線了（元旦加了幾天班，一個外包沒來，另一個最後一天因為胃不舒服回家了）

我現在想起元旦自己一個人在一個專案群裡回覆著4~5個測試（系統測試、效能測試），

一個人改著bug，改完bug列表，重新整理後馬上又多了幾個bug的崩潰。

php組的領導也確實幫不上忙，默默陪著我，協調資源和處理其他問題。多虧領導的陪伴，要不我真的能放棄。

這個時候，我的小孩出生也有4個多月了。

那一年的8月，也就是2018年8月，我從老東家離職。

我給我的理由是：離家遠，想早點回家看孩子。

這個理由真的很牽強。我真的感覺倦了，感覺無休止地看不到頭，感覺自己更加迷茫。

反思

我從上一家公司離職後，到現在一年多。我才慢慢體會到我所說的痛苦都是有原因的，而且完全可以避免和克服。

入職新公司，參與了一個專案，並嘗試著管理一個專案。公司有整個專案週期的管理流程。

我從流程中學習如何管理專案。經過一年多的學習和轉變，我學習著分析當初我的痛苦。

沒有專案管理經驗的我

因為我最熟悉程式碼和業務，所以組織外包分配任務。但是沒有經驗和想法的我把這個專案管理得一團糟。

我應該可以更加清晰地分配任務，使得任務相對獨立。

我也可以更加詳細地拆分任務，因為我對邏輯非常熟悉，所以可以將複雜操作拆得更加詳細

我在專案中開發，無法脫身，完全可以從上層角度來提前協調資源。

我當時的技術面比較窄，無法從更高的技術角度看代專案。

我知道當時的外包很貴，領導可能出於預算，分析了任務量，確認了2個外包。

整個開發沒有層次，測試都在最後一擁而上，我們不得不在群裡說著這個功能的實現細節。然後測試再去測試。

對這個專案預估不足

沒有預估到這個內部系統如此複雜的業務纏繞

沒有預估到這個系統整個迭代如此混亂，沒有節奏，沒有章法。

心態

一開始我就輸了，輸在了心態

我總是想著2年的系統沒有文件，重構是完不成的。

我總是想著完不成也有理由，因為A,B，C

遇到困難或在極其艱難的時候，沒有正面困難的勇氣，我選擇了抱怨和唉聲嘆氣，我選擇了消極應戰。對，我的士氣確實沒有了。

如果

如果，再有如果，我使用一些專案管理的方法和在實踐中總結的方法，再次迭代這個專案，那結果會是怎樣？

如果我再負責一點，把模組拆開，任務分細，即便是外包來做，也不會被專案嚇到？

如果我在開始前，做了詳細的專案迭代規劃，可以先交付什麼，後交付什麼，前後沒有大的關聯。測試資源可以儘早介入。

如果我在開發前，做好風險準備以及應對方案，是不是開發中有時候就不會那麼被動？

我總結就是：層次、心性、管理

為什麼是這三個詞，這也是我覺得我從一個普通程式設計師轉變成初級管理的一個總結。

層次：我當初壓根就沒有轉管理的這根線，所以分析問題都是從自身角度，層次可想而知。

心性：做好了轉管理的準備，心性也要做好準備，遇到棘手的問題，客戶的催促。我必須放下抱怨、冷靜分析選擇最合適的解決方案。

管理：我思想和心裡都做好了準備，我確實需要一些指導，比如老領導的幫帶，一些書籍的閱讀。從認知上再次提升

       剩下的就是在實踐中不斷打磨自己的認知和理解，總結後再嘗試。

重新定義自己

2018年8月中旬來到現在的公司，這裡我接觸了一些專案管理的流程。

我嘗試管理專案，我嘗試總結問題，我嘗試全域性分析。

這一年我犯了很多錯，回過頭髮現當初的自己是多麼幼稚不堪。

還好，我在同事和領導身上，慢慢學習他們的優點和經驗。

如何管理專案、把控流程、協調資源、拆分任務

如何和上級溝通

如何和同事更好協作

如何把自己身上的任務合理分下去，同時關注帶的人的成長

比如購銷合同一個緊急專案，如何跨部門協調，如何在緊急情況下做出合適的方案並協調資源。

... ...

重新認識敏捷

2019年3月，我們部門來了一個新同事，瞭解到他之前公司一直是敏捷開發。

我們時不時一起討論敏捷開發等相關問題。

“我們的任務是儘早持續交付有價值的軟體，並讓使用者滿意”

這一敏捷宣言，細細品味，確實蘊藏了巨大的能量。

圍繞著這一句話，我們可以想象到很多的方面進行改進，以接近這一宣言。

使用者為中心

價值導向

持續整合

優先順序

自主管理

協作溝通

以人為本

等......

我們所使用的這些方法和策略，就是在慢慢打造更高效的團隊。發揮價值。

發揮價值，然後慢慢改造流程，發揮更大的價值。

就是在一個迴圈往復中，螺旋上升。

起初會有不適應，因為人都是有惰性的，組織和規範都是有平衡的。

敏捷的這些思想，無時無刻地衝擊著這些人性、組織以及規範。

當在堅持實行的過程中，信任他人，成就他人，這樣慢慢激發人性的能量。團隊收穫的是能量，個人收穫的是成長。

堅持實行敏捷，是一項艱鉅的任務。這需要團隊不斷磨合，不斷找到合適的相處方式，找到每個人的能力成長點，並激發它。

敏捷最終落腳的地方是人，所以如何將敏捷這些思想，灌輸給團隊。然後沿著方法論嘗試、總結、修改、再嘗試。

這樣的敏捷，我不確定是不是也是敏捷的一種。

總結

不斷實踐，不斷吸收，不斷激發，不斷優