DOJO004

  • Dashool 創辦人
  • 喜歡調酒
  • Rails、Nextjs、TypeScript

“敏捷”真的無敵嗎? 任何事都可以套用敏捷嗎?

自我成長

相信在軟體科技業從業的各位,應該都有聽過”敏捷”一詞。
我對於敏捷的印象就是,"快”,相信不論套用在任何事物上,都可以加速運行。
但在這次參加完 GDG 舉辦的 “創造團隊敏捷力”之後,我對敏捷整個大改觀!
接下來我簡單分享我對於敏捷的看法,以及這次活動的收穫吧。

敏捷對我來說是什麼?

曾經 "敏捷” 對我來說,就是快,不管在任何事情上只要套用敏捷的方法,就可以將原本十天才能完成的事情,濃縮至七天甚至五天。
但敏捷的目的並不是要快,而是"適者生存”,追求質量以及高效。
藉由每天簡短的 Daily Scrum(站立會議),透過面團隊對面的溝通,讓團隊成員互相了解目前開發的現況,查看是否有成員遇到困難,並檢視是否與當初設定的目標有所偏離。

敏捷真的無敵嗎?

我知道許多人會將敏捷與瀑布式開發放在一起進行比較,但我認為敏捷是一種概念,並不能與 ”瀑布式”開發” 這種 “模式”,相提並論。
就我看來,沒有什麼無敵,只有合不合適而已。
或許在多數情況下,善於變化的 ”敏捷”,更適合在大環境中生存下來。

任何事情都可以套用敏捷嗎?

是的,我認為任何事情都可以套用敏捷,因為它是一種 ”概念”。
小至家事的分配,大至企業的營運,我認為都能夠套用敏捷。

在導入敏捷時被團隊成員明顯的反抗?

在這次的活動當中,讓我印象深刻的問題就是這個了。
我還記得那位同學是這樣說 : 我想要為我的團隊導入敏捷,但有幾個同仁提出了,以前的方式也不錯,為什麼現在要改方式了呢?
講師給出的回覆是 : 不要讓同仁知道你要導入敏捷。要偷偷的做!
不得不說真的是高明!
因為人性是懶惰、保守、害怕改變的,若之前使用的方式沒有遇到什麼大問題,為什麼要改呢?
事實可能是,導入敏捷之前,產品的應對、開發效率低下,導入敏捷之後就可對其優化、改善,但可惜的就是,沒有意識到這個問題的成員甚至是主管。
所以,在沒有共識以前,不要讓同仁知道我們要”導入”敏捷,而是透過慢慢的小改變,漸漸地導入敏捷,這才是最好的方式!

結論

我在實際體驗敏捷的開發流程之後,發現這很符合現在 Z 世代人的價值觀,”尋找自我價值”。
透過敏捷的開發方式,不僅可以立即發現開發上的問題,我認為最大的收穫是可以讓夥伴參與這個開發流程,產生歸屬、認同感,而不僅僅是當碼農而已。
想更了解敏捷的朋友,我認為這篇文章寫得很詳細,可以參考一下:

敏捷的四大原則

個人與互動 重於 流程與工具
可用的軟體 重於 詳細的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計畫

敏捷的 12 宣言

  1. 我們的首要任務是通過早期和持續交付有價值的軟件來滿足客戶。
  2. 歡迎不斷變化的要求,甚至是開發後期。敏捷流程利用變化來實現客戶的競爭優勢。
  3. 經常提供工作軟件,從幾周到幾個月,優先考慮更短的時間尺度。
  4. 業務人員和開發人員必須在整個項目中每天一起工作。
  5. 圍繞有動力的個人建立項目。為他們提供所需的環境和支持,並相信他們能夠完成工作。
  6. 向開發團隊內部和內部傳達信息的最有效和最有效的方法是面對面交談。
  7. 工作軟件是進步的主要衡量標準。
  8. 敏捷過程促進可持續發展。贊助商,開發者和用戶應該能夠無限期地保持穩定的步伐。
  9. 持續關注技術卓越和良好的設計可提高靈活性。
  10. 簡單性 – 最大化未完成工作量的藝術 – 至關重要。
  11. 最好的架構,要求和設計來自自組織團隊。
  12. 團隊定期反思如何變得更有效,然後相應地調整和調整其行為。

版權所有 © 2023 DOJO004

Deployed on Zeabur