敏捷開發系列文章目錄
敏捷開發在國內是不是只是一個理想化的工作環境?
經常有人問,你們搞敏捷開發工作量是由開發人員自己估的,而不是由經驗豐富的技術主管估的,他們自己肯定會把工作量估得非常大,那什麽時候項目才做得完?你們每天開那麽多會,怎麽不把時間放在好好寫代碼上面?一個叠代這麽短的時間既要做設計、又要編碼、還要測試,這麽急著做出的東西質量肯定不高。系統設計肯定得經驗豐富的老手做更靠譜。每當我聽到有人說這些問題,我就知道他肯定沒有真正的認識敏捷開發,如果真的有實踐過,自然就會發現這些問題根本就不是問題,只是杞人憂天而已。
1.序言,敏捷不一樣的開發團隊管理方法
2.叠代開發的過程是怎麽樣的
3.PO如何給開發團隊講好故事
4.糾結的估點
5.為什麽要做設計評審和測試用例評審
6.為什麽要做代碼評審
7.開發故事完成給測試做ShowCase
8.故事燃盡圖和任務燃盡圖
9.每日站會的正確姿勢
10.叠代計劃會與回顧會
11.如何正確對待團隊速率
12.利用jenkins搭建.Net持續集成環境
敏捷開發系列文章目錄
相關推薦
敏捷開發系列文章目錄
環境 回顧 集成 每日 序言 開發人員 叠代開發 font 計劃 敏捷開發在國內是不是只是一個理想化的工作環境? 經常有人問,你們搞敏捷開發工作量是由開發人員自己估的,而不是由經驗豐富的技術主管估的,他們自己肯定會把工作量估得非常大,那什麽時候項目才做得完?你們每
C#.NET微信公眾賬號接口開發系列文章整理--微信接口開發目錄
開發 接口開發 基礎 公眾賬號 https 文章 cat 平臺 微信公眾賬號 基礎開發 1.C#/ASP.NET MVC微信公眾號接口開發之從零開發(一) 接入微信公眾平臺 2.C#/ASP.NET MVC微信公眾號接口開發之從零開發(二) 接收微信消息並且解析XML(
【DevOps】團隊敏捷開發系列--開山篇
jmeter junit ger 優秀 資料 開發 load 分析 針對 隨著軟件發布叠代的頻率越來越高,傳統的「瀑布型」(開發—測試—發布)模式已經不能滿足快速交付的需求。2009 年左右 DevOps 應運而生,開發運維一體化,通過自動化工具與流程讓整個軟件開發構建、
Azure Redis Cache (5) Redis Cache Cluster叢集模式 Windows Azure Platform 系列文章目錄
《Windows Azure Platform 系列文章目錄》 Redis Cluster 3.0之後的版本,已經支援Redis Cluster叢集模式,Redis Cluster採用無中心架構,每個節點儲存資料和整個叢集狀態,每個節點都和其他所有節點連線。其redis-cluster架構圖
Azure VMSS (3) 修改VM Template並建立VMSS Windows Azure Platform 系列文章目錄
《Windows Azure Platform 系列文章目錄》 在開始本章內容之前,我們需要準備好Azure VM的映象,具體可以參考:Azure VMSS (2) 對VM執行Generalize操作 1.我們先檢視到之前建立的映象(Image)的資源ID。我們首先點選All
Android 自定義View 系列文章目錄 Canvas篇
一、基礎 Android 畫筆 Paint 基本操作API:https://blog.csdn.net/huangliniqng/article/details/82588824 Android 畫布 Canvas 基本操作API:https://blog.csdn.net/
android 敏捷開發系列(一)——《啥是敏捷開發》
說起敏捷開發,大家或多或少會有些印象。而在android上的敏捷開發可能還並未普及。 博主將與大家共同討論一起交流android上的敏捷開發、框架搭建等知識。 本博將通過 講解敏捷開發概念->敏捷開發架構思想->開發環境搭建->專案原始碼敏捷開發構建、
敏捷開發系列之旅 第三站(認識FDD特徵驅動開發)
上篇文章中,我們探討了什麼是XP極限程式設計,以及極限程式設計的管理思想、核心價值觀等等。在敏捷開發之旅的第三站,我想要和大家一起分享FDD特徵驅動開發方法。 特徵驅動開發——Feature Driven Development 還是老規矩,討論之前,我們先了解一下什麼
敏捷開發系列之旅 第二站(走近XP極限程式設計)
這是最重要的核心價值。因為XP強調要“擁抱變化”,因此對於使用者的反饋,提倡積極面對現實和修改問題的勇氣,如放棄已有程式碼,改進系統設計等;勇敢的重構;所有人擁有程式碼;敢於極限(把好的方法做到極致)。XP認為,軟體開發中,人是最重要的一個方面。在一個軟體產品的開發中,人的參與貫穿其整個生命週期,是
敏捷開發系列學習總結(10)——到底什麼是敏捷開發?
1,提要 軟體開發是一個系統工程,包括最初的可行性分析、再到設計、開發、測試、維護等整個生命週期。在這個過程中某些階段的失誤或說是變化,都可能增加整個軟體專案的風險。 如何在保證效率的基礎上還能安計劃
敏捷開發系列學習總結(11)——Scrum敏捷開發流程的三個角色、四個會議和三個物件
Scrum敏捷開發流程主要包擴三個角色、四個會議和個三物件。 三個角色 Scrum團隊中包括三個角色,他們分別是產品負責人、開發團隊和 專案的直接管理者(Scrum Master)。 Scrum 團隊是自組織、跨職能的完整團隊。自組織團隊決定如何最好地完成他們的工作
敏捷開發系列學習總結(2)——Bug修改流程
原則,力求各司其職,簡單明瞭。 1. 測試人員提交bug ⑴ 標題: [ 模組名稱 ] 問題描述 ⑵ 內容: 問題重現步驟的描述,最好貼上圖片。 因為一圖勝萬言。 ⑶ 指定責任人: 根據bug指定責任人。如果不能確定責任人,就指定給專案負責人。 2. 責任人檢
敏捷開發系列之旅 第四站(透明的Crystal水晶方法)
上一站,我們簡單的談了談FDD,瞭解了什麼是特徵驅動開發,以及它核心的整體模型,在我看來,它是一種有效但有一些複雜的敏捷開發方法,對於小團隊來說,實施起來有些困難。然而,今天我們要認識的是一種新的開發過程——Crystal,透明水晶方法。 概述 水晶方法,Crystal
android 敏捷開發系列(三)——《環境部署》
書接上文,上次我們瞭解了敏捷開發的架構,但是利用我們普通的開發工具Eclipse的Ant構建是無法完成專案依賴等工作的,所以在開發之前我們需要準備好以下開發環境 maven + nexus + hudson + git 注:本文基本環境 服務端系統為ubuntu13.0
敏捷開發系列終極之旅 第六站(像橄欖球運動一樣富有激情的SCRUM)
適用的專案 剛剛瞭解Scrum的朋友,經常會有這樣的疑問:到底什麼樣的專案適合使用Scrum呢?我們也一直在探討。首先,我們來看一下關於過程的定義。過程控制通常有兩種形式,一種是預定義過程,另一種則是經驗性過程。 預定義過程 每一項工作都可以被完全理解給予合理的輸入定義,每次便可以得到相同的輸出過
敏捷開發系列(1)-為什麼需要敏捷?
這篇文章,我將會去簡單探討為什麼需要敏捷? 先貼出連結,如果你有時間的話,可以考慮仔細看看:The New Methodology (Martin Fowler's description of the background to agile methods)1
敏捷開發系列學習總結(6)——你用什麼工具管理專案
在開發專案時,哪些東西需要被管理?1,當然是需求、設計說明。2,介面原型。3,專案進度。4,bug。我團隊目前就是這些資料需要被管理。讀者們有其他的好東東,就在評論裡分享吧。這些資料跟git上儲存的程式碼不同,大多是文件式的。專案進度和bug的管理,這些就屬於開發流程管理
敏捷開發系列學習總結(8)——創業公司研發團隊建設
小編從小就是個喜歡挑戰、喜歡折騰的人。我一直認為,寧做餓死創業狼,不做養肥打工狗。小編國內某著名重點高校計算機小碩,畢業後在世界著名500強做碼農。碼了幾年後,蘊藏於小編心底的創業激情就按捺不住了,於是小編裸辭,單槍匹馬出來闖江湖。 創業,真心是不容易的。媒體上天天看到
敏捷開發系列之旅 第五站(不一樣的RUP統一軟體開發過程)
迭代式開發在軟體開發的早期階段就想完全、準確的捕獲使用者的需求幾乎是不可能的。實際上,我們經常遇到的問題是需求在整個軟體開發工程中經常會改變。傳統的開發方式對於這種需求的變更是很難應對的。 迭代式開發允許在每次迭代過程中需求可能有變化,通過不斷細化來加深對問題的理解。迭代式開發不僅可以降低專案的風險,而且
【微信小程式開發•系列文章四】模組化
微信小程式的MINA框架,其實是許多前端開發技術的組合。這篇文章中,我們來簡單地討論一下模組化。 1、模組化標準 玩前端的同學大部分都知道模組化的幾個標準,CommonJs / AMD / CMD。這裡花費一些篇幅簡單的介紹一下,比較熟悉的同學可以跳過這一部分的介紹。(1)