敏捷知識入門
迭代
程序員聽到產品經理常說的話之一大概是——“這個需求很緊急,需要馬上處理!”,當初剛成為一名程序員小白的我,驚慌失措。當然我算是比較幸運,有導師替我頂住一切,“他的排期滿了,這個需求我們先放到下個迭代再實現吧!”
后面自己慢慢熟悉了這樣的工作模式之后,再遇到產品經理類似的場景的時候,也不會再驚慌了。因為總能聽到一個聲音在耳邊響起,“...,這個需求我們先放到下個迭代再實現吧!”
什么是迭代?為什么需要迭代?迭代有什么好處?迭代就在那里,知道它的存在,但是我卻無法用恰當的詞匯來描述它。
后來,后來~,我總算學會了什么是迭代,可惜你早已~~~(不好意思,情不自禁)。
后來在自己好奇心的驅使下,慢慢了解了一些項目管理的知識,所有的困惑便不再是困惑了。所以作為一名程序員,了解一些項目管理的知識,很正常吧!
其實前面描述的是敏捷開發模式下一個很常見的場景。
敏捷的價值觀和原則
這里的敏捷(Agile),指的是一種軟件開發模式,是一種以人為核心、迭代、循序漸進的開發方法,是擁抱變化的開發流程。
敏捷運動的推行者們根據自己的實踐,在價值觀和原則上達成了共識并發發布了敏捷宣言:
我們一直在實踐中探尋更好的軟件開發方法,身體力行的同時也幫助他人。由此我們建立了如下價值觀:
- 個體和互動高于流程和工具
- 工作的軟件高于詳盡的文檔
- 客戶合作高于合同談判
- 響應變化高于遵循計劃
也就是說,盡管右項有其價值,我們更重視左項的價值。
同時也確定了敏捷開發的判定標準,即敏捷的12大原則:
1. 我們最重要的目標,是通過持續不斷地及早交付有價值的軟件使客戶滿意。
2. 欣然面對需求變化,即使在開發后期也一樣。為了客戶的競爭優勢,敏捷過程掌控變化。
3. 經常地交付可工作的軟,相隔幾星期或一兩個月,傾向于采取較短的周期。
4. 業務人員和開發人員必須相互合作,項目中的每一天都不例外。
5. 激發個體的斗志,以他們為核心搭建項目。提供所需的環境和支援,輔以信任,從而達成目標。
6. 不論團隊內外,傳遞信息效果最好、效率最高的方式是面對面的交談
7. 可工作的軟件是進度的首要度量標準。
8. 敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持步調穩定延續。
9. 堅持不懈地追求技術卓越和良好設計,敏捷能力由此增強。
10. 以簡潔為本,它是極力減少不必要工作量的藝術。
11. 最好的架構、需求和設計出自自組織團隊。
12. 團隊定期地反思如何能提高成效,并依此調整自身舉止表現。
迭代與敏捷
上面提到的迭代其實只是敏捷實踐中SCRUM開發流程中的一個很小的環節。
通常一個迭代中,在迭代開始的時候,會進行一個迭代計劃會。
(1) 迭代計劃會上,產品負責人(Product Owner)和團隊會從具有優先級順序的產品待辦事項列表中,選擇優先級高的用戶故事,并進行任務拆分,并創建迭代待辦事項列表。團隊成員領取任務,并進行任務排期故事點估算,畫出任務燃盡圖。
迭代沖刺(Sprint)過程中,團隊再更新相應的任務板,并召開每日站會,溝通進度以及遇到的問題(昨天做了什么?今天要做什么?遇到了哪些問題?)
迭代完成則會召開迭代評審會和回顧會。
(2) 迭代評審會上,團隊成員演示所完成的工作成果,產品負責人(PO)則決定是否接受用戶故事。對產品關注的相關方則可以提出意見或建議,項目經理則將相關意見和建議記錄下來,并在后續的回顧會或下一迭代的計劃會中討論和處理。
(3) 迭代回顧會上,則需要總結工作中的經驗教訓,找到可以改進的工作,并調整將來的工作,將可改進的工作納入到產品待辦事項列表,一遍后續的過程中執行。
整個過程中,Scrum Master則承擔者教練的角色,指導敏捷實踐,并幫助團隊解決困難、清楚障礙。
在敏捷團隊中,團隊的成員都是通才型人才,合作更加緊密,具有良好的自組織能力。
總結
在現在的軟件開發中,為了應對快速變化的市場需求,并向客戶盡早交付有價值的產品,很多項目團隊都會采用敏捷的開發方法。
敏捷開發的SCRUM實踐中,項目團隊成員具有更好的自組織能力,是通才型人才。產品負責人和團隊緊密合作,Scrum Master為團隊提供敏捷實踐的指導,幫助團隊解決問題、清除障礙。