靈活開發實踐的感悟

工作中采用靈活開發已經好幾年了,在實際采用這個開發模式遇到了較多問題,使我不得不重新反思靈活開發。個人認為現如今，多數公司采取靈活開發，失敗的風險反而會幾何倍數提升。

首先，請允許我簡單的介紹一下靈活開發，很多人并不想看這個，但基于知識的連貫性，我依舊不得不說這點。靈活開發的概念如下：

• 什麼是靈活開發？靈活開發是一種疊代式的軟體開發流程，強調快速反應、快速疊代、價值驅動。
• 為什麼要使用靈活開發？靈活開發能夠快速響應客戶需求，通過短增量完成工作來縮短DevOps生命周期。
• 誰使用靈活開發？許多大型公司為了提高産品的開發效率，已經漸漸在開始運用靈活開發。
• 在哪裡使用靈活開發？靈活開發起源于美國，但現在已經在世界範圍内被廣泛采用。
• 何時使用靈活開發？當需要快速響應客戶需求并縮短DevOps生命周期時，可以采用靈活開發。
• 如何進行靈活開發？靈活開發通過在短增量完成工作（通常稱為沖刺）來縮短DevOps生命周期。沖刺通常長達一到四周。
• 靈活開發的成本是多少？這個問題的答案會因公司而異，在部分公司是無窮。

其次，我想說一下靈活的優缺點。如下：

靈活開發的優點包括：

• 更快地傳遞價值
• 更低的風險
• 擁抱變化
• 更好的品質
• 持續改進
• 更高的客戶滿意度
• 更高的團隊滿意度
• 更大的靈活性

靈活開發的缺點包括：

• 很難進行準确的資源規劃
• 很難準确地定義“輕量級”或必要的文檔
• 很難把握整體産品的一緻性
• 很難預測有限的終點

然後，這裡我着重說一下其缺點。各個公司在推行靈活開發的時候，都遭遇了一系列的困難，是以往往在各公司都在不停宣傳靈活的好處。這裡我先列一下目前已知，不适合使用靈活開發的情況，

• 需求極其明确的項目，可能沒有必要使用靈活開發。
• 項目成員衆多時，靈活開發并不适用，這往往會導緻團隊成員不清楚自己要做什麼事、為什麼這麼做、這樣做解決了什麼問題都不清楚。
• 項目團隊人員不能實時快速溝通交流的時候靈活開發不适用。靈活開發原本就缺少很多的文檔，如果團隊成員溝通不暢，或者沒有明确負責的功能點，經常交叉開發，而産品和項目經理不能很好管理組織各處的業務，就會導緻沒有人清楚系統的實際邏輯。
• 集中的指令式管理方式，并不适合靈活開發。而這在現如今大多數采取靈活開發的公司，這是很常見的，這些公司由産品、項目經理主導，經常隻下達一系列的指令，下面的人蒙着頭開發，當決策失誤，就讓研發人員加班解決，因為在他們看來，是開發人員不夠“靈活”，不能跟上需求的變化。

産品研發是企業構思、設計實作産品的過程，企業需要依據市場需求、行業環境和企業戰略等多方面來設計産品開發流程。産品研發需要遵守一些基本原則，例如MVP原則，簡潔原則，核心體驗原則，資料導向原則，統一需求原則和系統效應原則等。

MVP原則指的是通過提供最小化可行産品擷取使用者回報，并在這個最小化可行産品上持續快速疊代，直到産品到達一個相對穩定的階段。簡潔原則指的是專注于核心功能，簡化使用者體驗。核心體驗原則指的是在核心功能上做得足夠好，再去延伸其他功能。資料導向原則指的是依據資料來降低錯誤機率。統一需求原則指的是統一需求出入口，避免需求滿天飛。系統效應原則指的不僅僅是在産品設計和技術選型的系統性，還包括圍繞産品上構想到售前、售中、售後的全鍊路的問題。

最後說一下我最近遇到的問題。

• 指令式管理方式：在開發過程中，對于存在疑問的點，産品和項目經理往往表現的很不耐煩，不能清晰明确地給出需求，隻想下達一個指令，我們執行。之後的一切問題，以bug形式輸出到研發團隊。
• 産品和項目經理并不關心需求：不關心不在乎需求，讓客戶和使用者來試錯，并不在乎産品是否合理。即使讓研發在車轱辘上放上方向盤，将車輪放在車裡也沒關系，畢竟對于産品和項目經理而言，靈活要擁護變化嘛，有什麼問題讓研發改就行了。
• 産品和項目經理限制研發對需求的了解：當研發質疑需求時，給出的答複有時是以現場有，以現場為主，有時和現場不符了，又說以我為主，當研發人員覺得需要明确的時候，有時回怼：你說，去問誰？你自己去問。有時回怼：我們看過現場，你們沒看過，照着做就行了。有時說：這些是要保密的，你們照做就行了。
• 開發大半年了，底層模型仍舊沒有确定，系統的分類規則，各對象的關聯關系依舊不能确定，回複是：後面實際落地還是會大改的。
• 需求無法把控，産品自己也隻管輸出客戶使用者提出的需求，人員都是誰有空誰改，有時改了一半，又被調去做其他需求。沒有人能說清楚某一塊的需求，設計邏輯，實作邏輯等等。
• 研發無法規避這種管理造成的種種問題：在每個需求變更的過程，及變更後，研發仍需解答産品和測試提出的各種問題，仍需按照目前給出的邏輯，調整修改代碼，仍然要在極短時間内分析，開發，配合測試并修複提出的問題。整個系統不是PPT，仍然有很多邏輯，推翻重做帶來的工作量似乎理應研發買單。
• 産品和項目經理的輸出以下達指令，給上司寫各種材料為主，而這些并不面向開發，對于系統的研發毫無建樹。
• 經典問答： 研發：你這明顯不合理啊？ 産品：不合理你先做，後面變了，你可以指着這個罵我，說這是我說的吧？ 研發：罵你是不是就不用改了？ 産品：那不行。

• 産品什麼都想要：産品沒有定位，沒有亮點，但是什麼都做，處處展現着我們的無知......

我們這家餐廳,大堂的經理不能明确說出來客戶想吃什麼就算了,還夾雜着許多自己的口味,還不停地換食材,換搭配,滿漢全席都快做完了,還沒搞明白客戶使用者的需求和痛點......甚至端出一盤盤在極短時間内開發出來的新菜,還要大廚保證每道菜的品質,為每個他們的錯誤決策買單......阿門,剛剛那道九轉大腸,産品要求保留大腸原始的味道......這真的不能怪大廚呀,希望客戶和使用者不會被惡心到......不停研發新菜,也許湊巧就成功了,不是嗎?然後就可以當做經典案例大肆宣傳了~~~加油吧,chatGPT,你适合這種忽悠産品的場景,快快發展起來吧,讓他們自己惡心自己去。