敏捷開發系列文章目錄
敏捷開發在國內是不是只是一個理想化的工作環境？
經常有人問，你們搞敏捷開發工作量是由開發人員自己估的，而不是由經驗豐富的技術主管估的，他們自己肯定會把工作量估得非常大，那什麽時候項目才做得完？你們每天開那麽多會，怎麽不把時間放在好好寫代碼上面？一個叠代這麽短的時間既要做設計、又要編碼、還要測試，這麽急著做出的東西質量肯定不高。系統設計肯定得經驗豐富的老手做更靠譜。每當我聽到有人說這些問題，我就知道他肯定沒有真正的認識敏捷開發，如果真的有實踐過，自然就會發現這些問題根本就不是問題，只是杞人憂天而已。
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）