本人就職的是乙個三線城市金融軟體外包的小公司，主要在做專案管理，因為服務行業的特殊性和公司技術水平，目前專案開發實施中仍然按照傳統瀑布和快速模型開發模式，對於敏捷開發和devops屬於只聞其名。但最近接觸到一些專案招標檔案中，要求系統建設全生命週期應滿足敏捷及devops的要求。且最新接觸的一些專案實施中客戶也要求專案快速上線，然後再進行迭代開發。
網上查閱了敏捷開發和devops的一些概念，其中敏捷開發主要的四個核心思想：
（1）強調面對面的溝通，人和人的相互交流勝於任何流程和工具
（2）把精力集中在可執行的程式上，可以執行的產品勝於編制綜合性文件，強調了原型、模型、demo等的重要性
（3）團隊合作和團隊激勵，合作勝於談判，敏捷開發能將需求、開發、測試等全部團隊成員融合成乙個整體，大家都是一條線上的螞蚱
（4）超強的適應能力，適應變化勝於按部就班，敏捷開發的特點就是快速
而devops這塊具體的準備諮詢下公司內部的專業人士，這裡就不做思考了。
初步了了解敏捷開發的概念，它的優勢我就不多贅述了，我主要對它在傳統金融外包軟體專案中運用的可能運用困難進行一些思考：
1.需求文件的定稿：傳統專案實施中需求分析確認書屬於必備的產出物，是專案驗收的根據之一，是開發的前置任務。如果採取敏捷開發，需求分析書一值處於動態，對於後期專案驗收會否造成困擾。
2.工期是否縮短：對於公司來說乙個新技術，新思想的運用必然希望伴隨著效率提高，成本的降低。而敏捷開發實際實施中，會不會因為動態的需求導致工期的延長。雖然可能客戶的體驗有所提高，但是專案週期拉長，成本增加，這與目前的考核制度就相悖。
3.實施團隊中人員素質：目前公司的人員構成主要是本地的軟體人員，難以吸引到外部的優秀人才，大都都是我種內部培養、晉公升的，沒有大公司的經歷，基本上屬於野蠻生長。主觀的意願、技術等能否達到要求需要進一步論證。
4.客戶的接收程度：相對封閉的軟體環境，客戶能否接受這種方式也屬於乙個待驗證的問題。具體到實時交易系統，我認為目前可能實施的可能性非常低，穩定和效率對於他們來說是一切的前提。外圍的一些系統倒是存在著些可能，比如crm、風險監測等。實際實施中也發現客戶具體不了解他們到底需要什麼，往往按照他們模糊的需求開發出系統後，後期往往改動也比較大，這個導致專案的後期收尾非常麻煩。但是敏捷開發具體能否落地就看客戶的高管能否接受了。
5.變種邊做邊改：最大的風險點，網上看了一些資料再結合我實際專案經驗，60%-70%的概率會變種為邊做邊改的模式，那就真是災難了。
還有很多其他的地方沒有思考到，畢竟目前還沒有進行實操。落實敏捷困難很多，但是行業的大方向目前都再往這方面走，如果公司和自己不能在這個方向上有所突破，也許會被時代淘汰吧 。但現實不允許我試錯，所以實際落地只能慢慢摸索吧，看看其中有哪些容易落地的優點先試用起來吧。
遊戲開發中敏捷實施
兩個程式設計師的 msn log a 說 2008 09 17 11 23 20 對了，問個咚咚，你們那邊是用scrum 麼？b 說 2008 09 17 11 23 26 對 a 說 2008 09 17 11 26 36 你們也是每天morning meeting 羅？a 說 2008 09 1...
關於敏捷專案開發
最近深度參與敏捷專案開發，敏捷專案裡的種種玩法逐漸的理解更深入了一些 關於啟動會 啟動會的意義在於團隊建立 目標建立，任務項發布，團隊的風險與應對策略制定，團隊的組織形式約定確立。關於迭代story拆分會議 迭代拆分會議，一方面確定拆分及相關的開發 測試時間，另一方面確定相關的有限及，還有乙個重要方...
敏捷專案開發中的需求分析
敏捷專案沒有需求分析嗎？在很多人的印象中，敏捷軟體開發是種類似黑客行為的過程，是程式設計師最愛的勾當。不寫文件，不作需求分析，沒有專案經理，做什麼東西完全是程式設計師自己的行為。所以他們認為這樣的過程無法滿足真正大型專案和複雜專案的需要，因此在經過考慮後，放棄了敏捷方法。專案經理圈子真的是這樣嗎?敏...