我所理解的敏捷
首先說明，我既不是公司管理高層，也不是經(jīng)驗資深的開發(fā)人員。
只是一個短暫實習(xí)對未來充滿好奇的學(xué)生，而這些所思所想，也僅僅是自己的對龐大的軟件體系的一點(diǎn)好奇而已。
思考源泉
最近看了本書《敏捷開發(fā)·一千零一夜》，其中感悟已經(jīng)如下導(dǎo)圖所示：
這本書并沒有介紹敏捷開發(fā)的基本知識，而是根據(jù)多人的經(jīng)驗整合成的關(guān)于 如何從傳統(tǒng)行業(yè)轉(zhuǎn)型到敏捷開發(fā)，以及敏捷如何實施。
這些故事對于那些還在使用傳統(tǒng)開發(fā)體系，比如瀑布模型、V模型，而想轉(zhuǎn)型到敏捷開發(fā)的朋友有所幫助。
書中一句話，“成功很難復(fù)制，失敗多有跡可循”，有收獲就好。
敏捷過程
（以下均是個人理解，每個公司具體情況都有所不同）
傳統(tǒng)行業(yè)的大體流程如下：
1 各種分析，各種計劃，各種文檔
2 開發(fā)
3 測試
4 交付
交付的時候問題出來了，按照當(dāng)初的需求，交付的產(chǎn)品不符合用戶的期望，于是開始提出各種各樣的要求。有的小改動還可以滿足，大的改動基本上不可以。不過有之前的需求文檔，如果完全的按照需求文檔來開發(fā)，也不會產(chǎn)生太大的偏差，但是最后客戶總是會提出各種各樣的需求。
而對于這種瀑布模型如果想要進(jìn)行某些修改，流程也是很麻煩的。
這樣的過程，在傳統(tǒng)行業(yè)比如軍事或者航天還比較好一些，因為他們的需求與客戶最后的效果可能偏差不是很大。但是互聯(lián)網(wǎng)公司就不同了，每一個小的細(xì)節(jié)都要受到用戶的反饋，而開發(fā)者或者產(chǎn)品經(jīng)理所設(shè)計的需求顯然不能滿足廣大用戶的要求。
?
因此敏捷開發(fā)出現(xiàn)了，提倡擁抱?變化?與?反饋?，以盡量短的迭代周期接收用戶的意見進(jìn)行反饋，并盡快的交付一個可用的產(chǎn)品。
那么一般的敏捷開發(fā)，也會按照下面的部分進(jìn)行（每一項都不是必須的，按照特定的情況有所不同）：
1 短迭代周期：
這個是最基本的敏捷要素了，開發(fā)周期短，一個迭代一般就是1~4周，在一個迭代的時間內(nèi)，要做到開發(fā)、測試、發(fā)布可用版本。
這就導(dǎo)致：一方面文檔缺乏；另一方面有時候開發(fā)任務(wù)繁重，測試與開發(fā)質(zhì)量差，潛在BUG多。
2 每日站會：
每天早晨大家聚在一起，說說自己昨天做了什么？今天要做什么？有什么技術(shù)難點(diǎn)？等等，一方面可以交流技術(shù)，另一方面別人如果有相關(guān)的經(jīng)驗也可以給予指導(dǎo)，避免重復(fù)造車或者繞彎路。
3 白板：
這個白板一般就是貼上開發(fā)相關(guān)的標(biāo)簽，比如什么要做，有什么問題，正在解決什么等等，方便大家交流；也可以快速定位開發(fā)瓶頸。
4 拆分用戶故事：
這里的用戶故事也就是業(yè)務(wù)需求，把業(yè)務(wù)需求拆分成一個個的小任務(wù)；一方面方便預(yù)估工作量；另一方面方便開發(fā)人員認(rèn)領(lǐng)任務(wù)；另外，也可以根據(jù)優(yōu)先級排序，有限那些優(yōu)先級高的任務(wù)。
5 迭代會議：
用于演示或者進(jìn)行代碼復(fù)查，以及結(jié)果討論等等。
6 迭代燃盡圖：
顯示開發(fā)的進(jìn)度，從而幫助scrum master督促開發(fā)進(jìn)度，了解開發(fā)瓶頸。
7 0迭代的設(shè)計：
在0迭代周期，應(yīng)該設(shè)計一個短小精悍的系統(tǒng)架構(gòu)，然后不斷的修正完善。切忌一開始就想設(shè)計出大而完美的產(chǎn)品架構(gòu)，這樣設(shè)計出的基本后來都會被推翻，反而是浪費(fèi)時間。
?
上面所說的一些敏捷事項，也僅僅關(guān)于快速開發(fā)，為了方便與用戶交流，還需要提供給用戶一個可交付的版本，從而得到反饋進(jìn)行修正，這才是敏捷最終的目的。
因此?持續(xù)集成 就成了敏捷開發(fā)中不可缺少的技術(shù)：
關(guān)于持續(xù)集成可以參考之前的博客：CI持續(xù)集成的魅力
?
不過敏捷開發(fā)并不是軟件開發(fā)里的銀彈，不可能解決所有的問題。
如快速迭代周期，就有可能導(dǎo)致估算的任務(wù)不準(zhǔn)，開發(fā)任務(wù)有時繁重，質(zhì)量下降，從而導(dǎo)致后期的維護(hù)成本上升。
而如此快速的開發(fā)，快速的修正，也會導(dǎo)致相關(guān)文檔的稀缺。
還有很多問題，但是關(guān)于質(zhì)量還是應(yīng)該從開發(fā)人員本身抓起，不可能以來測試來提高軟件開發(fā)的質(zhì)量，有本書中說這樣一個觀點(diǎn)，“測試出的BUG越多，那么潛在的BUG也會越多”，因此并不是測試出的BUG越多，軟件質(zhì)量就越高。
敏捷僅僅是為了適應(yīng)用戶的想法，應(yīng)需而變所產(chǎn)生的軟件開發(fā)體系，他并不是開發(fā)軟件的工具，而僅僅是一套思想，因此如何快速的開發(fā)出符合自己公司業(yè)務(wù)需求的產(chǎn)品才是敏捷與軟件工程想要解決的問題。
推薦書籍
《硝煙中的Scrum和XP》
《贏》 杰克·韋爾奇
《敏捷無敵》
《IT項目管理那些事兒》
《精益創(chuàng)業(yè)》
《跨越鴻溝》
參考
【1】敏捷開發(fā)XP：http://blog.sina.com.cn/s/blog_4ac69eaa0100r45w.html
【2】敏捷開發(fā)Scrum：http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html
【3】PDCA戴明環(huán)：http://baike.baidu.com/link?url=fnVUmTobSMtHApM61g7Ul_lyia8QEIM_MztOLJ89LncZK-eNwXTx69-WZPN-4ClpS_YWpIUcJpn_7GAcvvNh4K
【4】敏捷宣言以及12條原則：http://developer.51cto.com/art/201009/225390.htm
【5】SOLID原則：http://www.cnblogs.com/ShaYeBlog/archive/2013/08/05/3237529.html
轉(zhuǎn)載于:https://www.cnblogs.com/xing901022/p/4515091.html
總結(jié)
- 上一篇： 写在最前面
- 下一篇： MYsql优化where子句