不少人認為敏捷開發就是意味着快,實際上敏捷開發一點也不快,甚至更慢。但要說它快,也沒錯,它的快並不是體現在開發進度上。

開發進度

從開發進度上來說,敏捷的進度反而更慢, 更慢,更慢,來看看我們的開發團隊每天實際的工作有哪些?

  • 對PO給出的用戶故事進行評審(INVEST原則)
  • 為用戶故事編寫驗收標準, 並通過PO的評審
  • 編寫驗收標準自動化測試腳本
  • 編寫自動化單元測試用例
  • 編寫自動化功能測試用例
  • 編寫自動化集成測試用例
  • 編寫跨系統邊界的自動化集成測試用例所需的用例數據支持接口
  • 編寫功能實現
  • 確保本地能通過上述測試
  • 持續重構確保代碼符合代碼規範 (通過Rubocop的掃描)
  • 提交代碼合併請求並確保通過持續集成(Jenkins CI)
  • 代碼合併請求后,自動化部署至相應環境
  • 配置任務,每天自動跑全回歸(APP, API, 後台管理…)
  • 每周至少一輪人工手動全回歸測試
  • 迭代交付演示
  • 自主任務管理

我們只有開發團隊這一角色,並沒有專門做架構設計,測試的角色與人員。

開發人員的自我工作佔比評估,編寫功能代碼部分僅佔到一天工作量的40%甚至更少一點。

注意,我們每天的工作時間為 7.5 小時,並且,強制不加班,不加班,不加班。
至於為什麼這樣做,以後專門寫這方面的內容分享。在這裏只說,我們不加班的有效產出比以往加班的產出還要好。believe or not, up to you.

我們每個迭代,PO都會根據實際產能去調整我們的計劃,整個團隊在按照穩定可靠的速率交付增量。

我敢肯定,絕大部分團隊的快速推進做法, 至少在三到六個月內,項目進度能甩我們好幾條街。但是,在追求相同的質量標準和完成標準的條件下,未來六個月到十二個月,我們能追上並且甩他們的幾條街。

快速擁抱變化?

這點是真的,但是擁抱變化並不意味着亂變、頻繁的變。變化太頻繁,PO應當去面壁思過,好好冷靜一下。

敏捷總會老生常談的說 敏捷可以快速試錯,實際上我更傾向用快速糾偏與快速評估這個描述。

在我看來,敏捷的最大受益者是公司,老闆,出資人。為什麼這麼說?
我們是兩周一個迭代,每個迭代嚴格按照前面的工作去執行。在每一個迭代交付是,我都會同老闆一起評估,來回答如下幾個問題:

  • 我們的交付是否符合預期?
  • 產品的特性是否符合預期?
  • 產品的特性與預期不符,這個產品有無繼續的必要?
  • 如果有繼續下去的必要,接下來產品特性需要做哪些調整?
  • 團隊是否健康?是否願意繼續投錢這個團隊?
  • 期望團隊未來有哪些改進?

當然,上面這些是需要勇氣的。

也就是說,每個月老闆都有兩次機會,了解產品、項目的情況,並決定值不值得繼續投錢。

出現不利情況,發現產品沒希望或者團隊不行,能夠及早止損。而不是一味投入投入,等到發現不行的時候,投入已巨大時,是繼續投入呢,還是中止呢?

  • 中止意味着巨大的投入打水漂;
  • 繼續投入,還需要投入多少,多長時間,可能翻身,可能損傷更大,心裏完全沒底,寶寶心理苦啊;

出現有利情況,產品可行,根據實際用戶反饋,我們可以把資金投入在對用戶最有價值的需求上。

因此,敏捷的快,在於快速盈利與快速止損上。

當然,這些是建立在敏捷的價值觀之上的:

  • 勇氣 – Courage
  • 溝通 – Communication
  • 尊重 – Respect
  • 開放 – Open
  • 專註 – Focus

努力做一個有價值追求的有逼格的TALENT吧。