我聊聊我對敏捷開發的看法

什麼是敏捷開發

敏捷開發實際上並不是一種開發模式,而是一種理念,一種理念,理念。敏捷開發提出了十二個準則,符合這十二個準則的交付模式都叫做敏捷開發。十二準則如下

儘早交付有價值的軟體

歡迎需求變化,讓軟體更有價值

頻繁交付可使用的軟體,建議採用較短週期交付

專案過程中,業務人員和開發人員每天在一起工作一段時間

支援專案團隊工作

面對面交談是傳遞訊息效果最好和效率最高的方式

可工作的軟體是專案進度的首要衡量標準

敏捷過程促進可持續發展。專案主要干係人,開發人員和使用者應該能一直保持節奏

持續關注卓越技術和良好的設計,提高敏捷性

以簡潔為本,極力減少不必要的工作量

最好的架構、需求和設計會從自組織團隊中湧現

團隊要定期反思如何變得更高效,然後相應地調整自身

上述準則說得很繞,很模糊,其實也很直白。彙總成一句話就是減少不必要的工作量,持續交付可使用且有價值的軟體。如果學習過精益思想的同學,甚至完全不需要理會敏捷開發到底是啥東西。

實踐思路一:面對面交流,提高效率

剛來的研發小夥子中,有兩個總是喜歡自己悶頭幹【這可能是很多剛步入工作的人的通病】。即使需求有問題,即使自己思路不明確,卻還是想自己再努力努力。不僅需求上,就算是編碼過程中有遇到沒有頭緒的bug,也應該及時尋求幫助,而不是自己苦苦猜測驗證,這會浪費自己的時間,浪費團隊的時間。主動提高溝通,遇到問題及時尋求幫助。只要不是同一個問題重複問,沒有人會介意的。

實踐思路二:提高需求質量

目前所在團隊,大多為新人,因此存在幾個致命的劣勢:

當前專案對業務知識要求較高,剛來的產品並不熟悉業務

研發框架封閉且老舊,開發存在一定困難

大家對庫表的理解並不深刻

同時也存在一些優勢

使用者對業務極其熟悉

使用者明確知曉自己想要什麼。

原先的開發模式,產品拿到使用者的需求,往往在確認互動沒問題的基礎上便安排給開發【因此產品並不瞭解業務,也不瞭解庫表結構】。開發拿到需求,在確認互動沒問題的基礎上進行開發【因為也不瞭解庫表,欄位關聯關係】。導致在研發過程中出現需求因為資料不支援而無法實現,或因資料關聯複雜,程式碼白寫,或因需求表述不明確,導致開發過程中出現滯留現象或者返工現象。

針對這一問題,我想做兩件事。

產品必須確認需求中的資料欄位是否能取到,可要求研發協助。在拿到需求初期便抓住使用者解決問題並完善文件【只有寫出來的東西才能保證不會自己騙自己】,避免後續與使用者的互動滯留。

經過一段時間的互動,產品可熟悉部分業務,與使用者和開發的交流會比之前順暢,此時會削弱文件質量的要求,文件只需留有主要內容。開發與產品透過面對面交談配合共同實現需求即可。避免無意義的編寫文件時間。

實踐思路三:結對程式設計

結對程式設計指兩個人負責一個模組,一個主一個副。這看上去是一個浪費人力的舉動。實際上並不是的。目前我使用結對程式設計目的有兩個

第一:團隊中有水平較低的人A,和另一個水平較OK的人B。 由B來輔助A做業務實現,一來能提升A的水平,二來就算A真的扶不起來,那把A換掉的成本就顯得比較低了。透過這種隱形的交接會使人員流失時的成本變小

第二:我打算逐步結對,使團隊中的每個人都儘量熟悉多的模組,為了達到任何人都能做任何業務功能的地步。因為我們的功能交付已經實現了短期階段性交付(使用者如此要求)。因此在任何人都熟悉每塊業務程式碼時,我們能夠承受住客戶針對某一塊具體業務的大量需求。人員配置更靈活、。

實踐思路四:測試前移

我想讓測試更早地干涉到研發中。因此每個需求都會要求研發做拆分解耦【敏捷開發黑話叫做拆分故事點】。每完成一小塊有業務價值的功能,測試就介入。如此可提高測試質量與測試效率,避免研發壓榨測試時間,到最後改bug的時間也沒有【畢竟早測早改,加班也要改完。要不然交付在即再改bug,那就壓力很大了】

後續還有一些規劃,比如說兩週一次的回顧會議,這是極其重要的,比如每日站立會(酌情而定,我會發表一些我的見解),比如工具支援。等下篇文章再講吧

以上四點是目前正在做的,剛起步,有效果,但不是最終效果。因為這些要求稍微正常點的公司都實現了,只是小弟當前的公司有點那啥而已。

peace and love