自工做伊始，就開始實踐敏捷。說實話，那時候若是你問我什麼是敏捷，要怎麼踐行敏捷，我不能給出專業的回答。爲了更好地在工做中貫徹敏捷，我開始深刻去了解敏捷的過去如今和將來，而後我遇到了：Create Your Successful Agile Project前端
敏捷，從一開始就被寄予了太多的指望，也確實能夠有效的幫助項目達成目標，但不少東西不少工具，被強行和敏捷綁定在一塊兒，對敏捷的踐行沒有什麼幫助。這本書，試圖澄清世人（特別是初學者）對敏捷的誤解和誤用，不厭其煩的從項目的各方面闡述如何應用敏捷。c++
敏捷，不是什麼大話題，既不時尚也不神祕，他能夠用來幫助小型團隊構建小型軟件項目，也能夠幫助大型團隊把團隊和項目拆小，再輔以敏捷。敏捷即爲創造和相應變化的能力，是一組章程、實踐和迭代。敏捷關注目標自己，而不拘泥過程；同時也時刻關注項目中的核心驅動力：人的能力狀態，佐以具備彈性的過程控制。docker
《定製化敏捷項目管理》的譯者趙波在 03.22 - 03.28 期間同 開源中國·高手問答 的小夥伴們以」可定製化的敏捷項目管理「」爲切入點「展開討論，本文整理於他和開源中國小夥伴對圖數據庫的討論內容~數據庫
主要分爲如下幾部分：編程
- 項目中如何應用敏捷
- 敏捷項目管理的工具
- 對敏捷應用的誤解
項目中如何應用敏捷：
@O瘋狂O後端
敏捷開發須要注意哪些內容，若是管理過程重要仍是前期準備重要，當前咱們團隊項目比較小而雜，有什麼推薦的管理軟件或者管理方式嗎，如今的感受是用常規管理方式總感受差一點，不能跟蹤所有情況，有時還會丟掉某一些內容？數組
瀑布開發模型在不肯定的需求和不肯定的工程實現手段先後夾擊下連連失利，敏捷軟件開發正是在這個背景下產生的。敏捷，即創造和響應變化的能力。敏捷關注目標自己，而不拘泥於過程；同時也時刻關注項目中的核心驅動力：人的能力狀態，佐以具備彈性的過程控制。項目管理中，無論過程仍是前期準備都是很重要的，任何一個和目標有誤差，均可能引發項目的偏離。 敏捷對於小團隊是一個不錯的選擇，小團隊相對的會要求項目中的人一專多能，那麼如何充分調動項目組成員的積極性，讓他們充分加入到項目中，發揮更多的主觀能動性。這個正是敏捷思惟在項目中的體現。敏捷沒有固定的套路，能夠佐以書中的方式，逐步定製出適合大家團隊的敏捷項目開發流程。編程語言
咱們公司主要是在一些二開系統中，進行業務定製，可是常常遇到客戶定製需求進行修改或者沒法預設目標的狀況，在這些應該如何經過數據化理論的支持，去評定一個任務的工做難度性能
不知道你說的數據化理論是指哪方面？ 從你的描述來看，一個維度是需求的變化程度；另外一維度是需求自己的難度，能夠這麼理解嗎？分別來評估試試。另外，評估這個難度的目的是什麼
一個團隊多少人比較適合敏捷開發啊？
敏捷團隊人數受諸多因素影響，組織環境、項目狀況、團隊狀況等因素都會影響人數，所謂最佳是要根據上述因素斷定的，沒有絕對的標準。網友@源1碼1表示：以往過往小公司的經驗,通常2到4我的整一個模塊比較好, 按模塊拆分。
創業/創新型的產品，方向一直在變，需求各類穿插（優先級被反覆調整），臨時的緊急需求等等，每一個版本又要加上以前版本遺留的需求再一塊兒排期，請問這種狀況如何作敏捷？仍是這種創業/創新型項目天生就不適合用敏捷？
項目開發中會變化的不僅是需求，還有不少其餘諸如人員、開發環境等因素。相對來講，敏捷能夠和不少開發模型結合，發展出適合大多數組織使用的開發流程。 若是需求變化快的話，能夠考慮將需求儘量細分，小步迭代，多輸出以和客戶多溝通，以保證產品能夠和客戶的需求更好的契合。 建議可參考本書，結合大家項目組的狀況，靈活的運用敏捷思惟，在項目開發中實施適合大家的敏捷開發。
@豬娃娃
在一個毫無開發流程規範的團隊裏怎麼去應用敏捷帶動開發流程化呢？
敏捷關注目標自己和達成目標的人的能力狀態。你能夠試着讓團隊裏的人，瞭解流程對開發的幫助。而後結合敏捷思惟，來梳理創建流程。能夠試試本書介紹的一些小方法。好比分解儘量小的中間目標，並在每一個目標以後確認進展，採起可度量的小步前進。
@jasonwu24
咱們是在一個傳統遺留項目中作項目管理，這種工程是公司的核心，改動難度較大，可是卻一直有努力使之更新換代的念頭，也作過敏捷的集體培訓，以 Scrum 爲表明的敏捷項目管理簡化了傳統項目管理的繁瑣流程和文檔，歡迎需求變化，在客戶需求不明確的時候，以在較短的週期內開發出可用的軟件爲目標，來幫助客戶描述本身的需求。迭代過程當中的需求變動會加入到項目繼續迭代需求池，豐富項目的產品功能。但敏捷注重人員的溝通，不是太注重文檔的重要性，但若項目人員流動過太，又給維護帶來很多難度，特別項目存在新手比較多時，老員工比較累，因此文檔化就顯得比較重要。須要項目中存在經驗較強的人，否則大項目中容易遇到瓶頸問題。請問在傳統遺留項目中如何更好地使用敏捷管理的優點助力項目發展呢？
敏捷注重項目中的人，也關注文檔在溝通和項目沉澱中的價值。 遺留項目這一類型，不少是結合現有需求，增量或適配開發。 是否是能夠考慮將維護過程當中的理解和改造落地爲文檔或者測試用例，以即可以更深刻的對項目作分解重構。 另外，項目人員流動過大，就須要找辦法將人員流動帶來的影響用其餘方法儘量降到最低，好比前面提到的涉及的文檔和測試用例；同時儘量謀求人員的相對固定。 但願能幫到你。
@建安七子
APP的開發團隊怎麼來作敏捷比較合適呢？咱們如今是按照迭代來一輪一輪的發版，雖然開發能夠並行着，可是集成測試，迴歸測試只能放到一塊兒，如今想作的更敏捷一些，一個需求就可以直接上線，不比等每個需求都作完再進行。可是測試一直是個問題，特別是迴歸測試，大量的界面測試難以靠自動化徹底替代，迴歸階段須要大量的人力支持，因此只能合併到一塊兒。這塊怎麼可以更敏捷一些。
APP測試按模塊可分爲前端功能、後端接口和性能測試。功能目前多采用手工測試；性能可用工具測試，接口可經過必定量的自動化測試開發完成。 開發和測試能夠並行處理，好比開發下一版本，測試上一版本的，測試的時候白盒黑盒混雜，主要快速的針對改動進行測試。在總體發版前再作全面測試。供參考。
敏捷項目管理的工具
@混世頑童
目前市面上有不少項目管理工具軟件，好比teambition、tower等等，也都宣稱很好的支持敏捷，目前咱們在使用teambition，可是總感受在可視化方面作得不是很到位，請問老師，有哪些工具在可視化方面作得比較好的推薦，或者說哪些工具在你提供的理論支持方面比較好的？
teambition的可視化有什麼問題嗎？沒用過teambition，不太清楚。簡單的看板工具，在項目中就能夠起到很大做用的。固然具體還要看你實際項目的狀況
@源1碼1
Scrum、XP、Lean、kanban、FDD、DSDM、Crystal等多種標準方法 , 請問這幾種方法,哪些適合 作大數據工具平臺的項目? 若是是相似王者榮耀這樣的moba類遊戲開發的項目管理應該怎麼作?
大數據工具平臺的項目是一個大類，其中根據項目目標、客戶需求、項目組狀況等的不一樣，也會有具體不一樣的項目實施方法的。遊戲開發只是大類，遊戲開發的需求變化頻繁，涉及的專業角色較多，很適合用敏捷的方法實施的。你能夠結合本書介紹的方法和項目組成員的狀況，來實施的。
@源1碼1
teambition 和禪道 作項目管理,不知道哪一個工具比較好?小公司想用免費開源的項目管理,應該怎麼思考?
工具只是工具，如何結合工具，或者說脫離工具，在實際項目管理中，運用適合的方法，好比敏捷，多是第一要務要去掌握貫徹的。不要拘泥於工具。工具代有才人出，各領風騷小半邊。
對敏捷應用的誤解
@鬼面書生灬
敏捷開發只適合那些需求不是很明確的項目，沒法預設，只能適應！
項目開發中會變化的不僅是需求。相對來講，敏捷能夠和不少開發模型結合，發展出適合大多數組織使用的開發流程
@賀小皮蛋
項目管理是項目每一個人應該擁有的技能嗎 仍是項目leader擁有就能夠了
項目可大可小，團隊成員可多可少。建議項目管理從管理自身工做開始。至少能夠把歸屬到本身身上的需求和問題，分解成不一樣的步驟，以此反向管理涉及自身的項目。
@SVD
敏捷是否是跟編程範式和編程語言也有關係，好比相似c++這種範式的編程語言的項目團隊，是否不太適合敏捷，由於編譯一個包可能就須要好久。不像容器化類型的項目，使用go等編程語言，基於docker file能夠快速構建編譯。
敏捷只是思想和方法，和編程技術無關。敏捷讓項目組更關注於目標和阻撓項目組達成這個目標的因素。編譯自己，確定有加速的方法的；速度慢，和敏捷也不想背，敏捷的快更多的是指快速的迭代，將目標分拆成一個個小目標.
@FlashCHen
敏捷開發應該是重溝通輕文檔。快速迭代的目的。可是實際上目前人員流動快，隨着項目推動 留下的坑只會愈來愈多，我呆過幾個公司，給個人感受 敏捷開發只是說說口號，在實際的應用上。並無以爲有多少變化。對此你有什麼見解？
敏捷不是忽視文檔，只是提倡輕文檔。所謂輕，是必要，去除沒必要要的文檔，保留對項目持續推動必要的文檔。敏捷強調關注目標自己，朝着目標，小步迭代。從產品開發的角度來講，並無錯。只是不少時候忽視了目標的達成過程，而多強調敏捷。不知是否是能對應到你的狀況。
@degeryang
真正用過敏捷開發的人就會發現它有多垃圾！對開發不友好，對軟件質量很差。只對老闆友好
那可能你所接觸的敏捷，過於強調敏捷，而忽視了目標自己和達成目標的人了。 不論怎樣的敏捷，必需要給開發過程一個迭代週期，在這個週期以內，需求相對穩定，即便需求變化，也是在設計內內能夠接受的變化，而不是想怎麼變就怎麼變。 有了穩定的階段，開發人員纔有相對充裕的時間去開發和構建測試用例，去重構軟件，而這纔是提升開發效率，加快開發進度，達成項目目標的關鍵。
以上爲本次敏捷方法交流的整理，若是你打算在項目中應用敏捷，在項目中應用敏捷過程當中遇到任何問題，歡迎隨時和我交流。
但願你們經過《定製化敏捷項目管理》，能夠消除部分對敏捷的誤解，在項目中更好的應用敏捷，讓項目更好達成客戶滿意的目標。
