敏捷開發中高效溝通－我們這樣做
b) 白板的右上角是燃盡圖；
c) 白板右下角用在蒐集團隊成員在迭代週期內的所有想法，無論是認為好的實踐，還是認為不好的實踐。這裡有兩個目標：首先在回顧會議中可以很清晰地瞭解團隊在迭代週期內真實的感受，更重要的是我們可以在不好的味道剛剛出現的時侯，第一時間尋找解決方案，而不是等到回顧會議中再去分析、解決。
相關推薦
敏捷開發中高效溝通－我們這樣做
a) 白板中任務標籤包括三種：黃色標籤代表Sprint計劃會議中拆分的任務，紅色標籤代表在迭代週期內新增加的任務，綠色標籤代表測試發現的Bug。每一個標籤都會寫明任務名稱，領取人員以及估算完成時間； b) 白板的右上角是燃盡圖；c) 白板右下角用在蒐集團隊成員在迭代週期內的所有想法，無論是認為好的實踐，還
敏捷開發中需要注意的事情
1.團隊中各個隊員的直接面對面相互溝通勝過任何的工具溝通； 2.可以工作的軟體勝過詳細的文件，程式碼才是最好的文件； 3.良好的客戶關係比死板的合同更具有意義； 4.及時的響應變化勝過時刻遵循計劃； 5.儘早的持續的交付有價值的軟體使客戶滿意； 6.任何時候都積極的擁
產品經理必讀：敏捷開發中的需求管理過程全解
產品的源頭是需求。一切偉大產品的實現都是從需求管理開始的。敏捷開發中的需求管理大致分為三個階段：需求調研，需求分析和需求確認。 需求調研階段 產品立項後，產品經理便開始了和需求打交道的漫長過程。第一步就是需求的調研工作。需求調研的質量，會直接影響到後續產品設計的工作。產品
敏捷開發中QA的職責之敏捷中的QA
QA，通常指的是質量保證(Quality Assurance)工程師，但我更喜歡定義敏捷中的QA為質量分析師(Quality Analyst)，主要基於以下幾個方面的原因： 質量保證更偏向於工業說法，稱參與軟體測試的人員為質量分析師感覺更恰當; 質量保證師更多的還是把測試當作軟體質量的最後把關著、看
敏捷開發中個一些概念及要點
名詞一：backlog 一、什麼是迭代backlog 1、迭代Backlog是團隊在一輪迭代中需要完成的 任務清單，是迭代計劃會議確定的內容； 2、迭代Backlog是團隊在召開迭代計劃會議的時 候從產品Backlog挑選出高優先順序的需求清單； 3、每項任務資訊包含當前剩
敏捷開發中QA如何做質量管理？
敏捷開發中QA如何做質量管理？ 經常有人會問我，敏捷模式下，QA的職責是什麼？QA有什麼價值？我們還需要QA嗎？敏捷轉型中遇到的問題，QA能幫助解決嗎？這些問題以前也思考過，筆者就是QA出
敏捷開發中編寫高質量Java程式碼
敏捷開發的理念已經流行了很長的時間，在敏捷開發中的開發迭代階段中，我們可以通過五個步驟，來有效的提高整個專案的程式碼質量。 Java專案開發過程中，由於開發人員的經驗、Java程式碼編寫習慣，以及缺乏統一的標準和管理流程，往往導致整個專案的程式碼質量較差，難於維 護，需要較
敏捷開發中史詩故事與使用者故事的顆粒度
作者：陳勇出處：blog.csdn.net/cheny_com使用者故事的顆粒度一直是一個談論已久的話題，但參加了很多研討會，搜尋了很多網路資源後發現一直沒有定論，只好在這裡原創一下。前言：為何需要討論使用者故事的顆粒度其實需求顆粒度的問題由來已久，即使是在傳統開發中，也沒有
敏捷開發中使用者故事地圖(User Story Mapping)學習
1.使用者故事地圖 User Story是敏捷開發和管理的核心，User Story是從使用者的角度對系統的某個功能模組所作的簡短描述。一個User Story描述了專案中的一個小功能，以及這個功能完成之後將會產生什麼效果，或者說能為客戶創造什麼價值。
敏捷開發之Scrum掃盲,及敏捷開發中XP與SCRUM的區別
現在敏捷開發是越來越火了，人人都在談敏捷，人人都在學習Scrum和XP... 為了不落後他人，於是我也開始學習Scrum，今天主要是對我最近閱讀的相關資料，根據自己的理解，用自己的話來講述Scrum中的各個環節，主要目的有兩個，一個是進行知識的總結，另外一個是覺得網上很多學習資料的講述方式讓初學者不太容易
敏捷開發中，團隊成員認領的是任務還是使用者故事？
一次敏捷workshop上，有同學問：“敏捷軟體開發中，團隊成員自己主動認領的，是使用者故事還是被分解成的任務？”同學們一時討論熱烈。 稍具敏捷開發實踐經驗的同學都應該知道，答案是——任務（Task
專案經理注意事項（2）——敏捷開發中的頭兒
俗話說兵熊熊一個將熊熊一窩，跟對頭兒絕對是一件振奮人心的事兒。之前寫過一篇關於《專案經理注意事項》（千萬別要點）的部落格，當時所在團隊的開發模式是一般的瀑布模式開發，其實說白了就是類似於作坊式的開發，經理去和客戶談需求（我會告訴你主要是去談錢嗎？）然後拿回來一堆他（她）認為的需求就開始讓我們做了，很多時候無理
敏捷開發中的一些教訓和感悟
工作一年多了，所在的公司採用敏捷開發。作為小團隊裡一名普通的開發者， 既體會到了敏捷的優點，也收穫了很多經驗教訓。在此記錄一下自己地感悟，如果有朝一日自己去領導一個敏捷開發團隊，要儘量想辦法避免和解決這些問題。 背景介紹： 公司的開發進度是大概每5－7周釋出一個小版本，這裡
敏捷開發實踐（3）-我們為什麼需要持續整合？
背景 自從我們使用scrum進行專案開發後，出現了這樣那樣的問題，有些是因為我們對scrum的理解不到位，有些則是客觀因素導致的，針對這些問題，在每次迭代的總結會上，我們進行了反思，並根據具體環境對scrum進行了一一調整，想通過幾篇文章和大家分享一下我的
敏捷開發中的架構設計
敏捷開發對軟體架構設計產生了一定的影響，讓人產生敏捷開發中“輕架構設計”的印象。文章就筆者經驗，和大家一起討論一下敏捷中的架構設計這個話題。 首先，筆者認為敏捷開發是一種軟體過程方法和工具，敏捷開發本身並不能代表架構設計。這就好比建築架構設計和建築工程管理之間的差別
敏捷開發中，Product Backlog 是否足以實現需求管理？
敏捷方法指導團隊將產品需求置於Product Backlog中管理，並按照優先順序對每個產品需求進行必要的排列。在計劃會(Planning Meeting)之前，由Product Owner從Product Backlog中挑選迭代週期準備開發的意向表（W
敏捷開發中，基於Points 的burndown
敏捷開發，很大的成功，來自於將開發的過程簡單化，同時讓整個團隊的工作變得透明。在團隊工作透明化過程中，burndown report 起了很大的作用。 通過檢視整個團隊、某個Story或某個任務的Burndown，能很清晰的瞭解到工作的進展。Burndo
敏捷開發中常犯的10大錯誤
敏捷開發不是信仰，團隊成員並不關心什麼是敏捷，他們只關注把工作搞定，。同樣他們不關心什麼是敏捷，他們僅僅關心那些能幫助他們解決當前問題的事情。 敏捷開發已經成為廣受開發人員關注的軟體工程方法，如何實施有效的敏捷開發，如何有效的在團隊中推行敏捷開發是每個專案管理人員都要關
敏捷開發中的問題
有三種方式去演化我們的系統。1.改變實現或者增加新的實現來替換舊的。2.改變介面。3.增加介面。 一.先說說我對多型的理解： 多型大部分都是執行時多型，也就是說已經形成了.exe檔案或者.jar檔案後，仍然有辦法去影響程式碼的執行！ 但是，這僅僅是開發類庫的人要
敏捷開發中的關鍵字
!. 目標明確 明確的目標，是我們想要實現的願景。 這個願景可以提高客戶的效率，為其創造價值。可以為公司的發展創造價值。為團隊、個人整體能力的提高提供實踐總結的機會。同時也指引著我們工作的方向。 !. 價值 價值體現在客戶、公司、團隊、個人的共同發展。 !. 高效 只有高效、