天天看點

靈活開發實踐的感悟

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

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

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

其次,我想說一下靈活的優缺點。如下:

靈活開發的優點包括:

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

靈活開發的缺點包括:

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

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

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

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

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

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

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

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

繼續閱讀