38227,36828

(此版本為搶鮮預覽版)

敏捷開發專案管理與架構設計實務

敏捷開發專案管理與架構設計實務

您的評分:


出版日期:2014-10-26
出版:isdavid(光岩資訊)
作者: 董大偉
語言: 繁體中文(台灣)
檔案格式:PDF
頁數:445
關鍵字:ALM VSTS Agile VS Online 專案管理 敏捷 Scrum
支援閱讀裝置:

零售

零售
)檢舉
免費試閱
嵌入閱讀器至您的網頁

內容簡介

(此版本為搶鮮預覽版,後續會持續更新,但也可能調高價格!(越早買越便宜) 更新後,先前購買的讀者依舊可以免費持續下載最新版本,最近更新日期 2017/03, 約400頁 )

這本手冊是光岩資訊董大偉老師在『敏捷開發專案管理與架構設計實務』課程中的內部訓練教材。董老師以十多年軟體專案與產品開發經驗為基礎,採用Scrum與Visual Studio Team Servic(VSTS)作為專案管理框架的實戰經驗分享,內容相當難得。與坊間的PMP專案管理、CMMI、瀑布式(waterfall)開發有所不同,本書內容為第一手的敏捷開發實戰經驗,不僅如此,這本書也並非傳統照本宣科的Agile/Scrum教材,而是結合了華人特有的專案運作模式與管理制度和文化,所凝結而成的經驗分享。

內容以Scrum為骨架,搭配VSTS為實作工具,從專案的kick-off開始,一路談到專案開發的整個Life-Cycle,內容包含工作項目的管理、Features, Backlogs, Tasks, Bugs的建立、管理、追蹤與維護,包含測試與stakeholders的反饋蒐集,也包括Scrum的周期性工作說明與經驗分享。

在本書中,董老師透過實際專案運用Scrum的經驗,以第一人稱的角度,將運用Scrum和VS Online的第一手經驗真實的呈現給學員,同時也和學員一起探討,面對在華人(特別是台灣)特殊的軟體專案氛圍下,各樣實施Scrum所發生的衝突和解決之道。更豐富的是,書中不僅僅介紹如何採用VSTS進行Scrum團隊開發,更進一步的討論到了如何透過架構與開發框架(Framework)設計,來解決專案經驗不足的團隊,採用Scrum時可能有的水土不服、品質低落的問題。透過開發框架(Framework)設計,簡化開發方法與程序,配合ALM工具和敏捷開發精神,讓您未來面對專案或產品開發更有信心。

不僅如此,這本書也集結了董老師這幾年來,在不同場合分享的Developers生存之道,是一本與資訊技術密切相關,卻又適合技術人員在茶餘飯後細細品味的書籍。

言盡於此,其餘的,就由讀者自行體會了。

章節目錄

● 注意:本手冊為搶鮮版,並不包含標註尚未完成的部分
● 此版本為搶鮮預覽版,後續會持續更新,但也可能調高價格!
● 更新後,先前購買的讀者依舊可以免費持續下載最新版本

----------------------------------------------
目錄 1-9
第1章 先讓我們來聊聊SCRUM 1-1
1-1 對於SCRUM的看法 1-1
打從心底接受規格(需求)變更,而非期待客戶承諾出不可變更的規格。 1-4
著重產出可用的軟體成品,而非美美的文件或是結案報告。 1-6
與客戶的關係是基於合作與信任,而非一紙合約。 1-7
1-2 SCRUM中的精神、角色、與做法 1-8
1-2-1 Scrum到底是什麼? 1-8
1-2-2 Scrum中的活動(Activity) 1-11
1-2-3 Scrum中的角色(Role) 1-12
Product Owner(PO) 1-12
Scrum Master(SM) 1-13
Team Members (專案成員) 1-14
Stakeholders (利益相關者 / 利害關係人) 1-14
1-2-4 一定要這樣區分角色? 1-15
1-2-5 準備開始啟動專案 1-15
第2章 VSTS專案工作的管理與使用 2-22
2-1 從KICK-OFF開始(建立第一個專案) 2-22
Step 1. 添加專案成員 2-24
Step 2. 安排與設定專案的Iterations 2-28
Step 3. 安排與設定專案的Team或Area 2-31
2-2 從蒐集FEATURES開始 2-37
2-2-1 蒐集Features 2-40
2-2-2 建立Features 2-41
2-3 從FEATURES展開BACKLOGS 2-47
2-3-1 Backlogs的細節 2-50
2-3-2 設定Backlogs的階層關係 2-51
2-3-3 Backlogs的狀態與歷史紀錄 2-53
2-3-4 Backlog的異動Alert(Notification)機制 2-54
2-3-5 對應Backlogs與Feature之間的關係 2-58
2-3-6 Backlogs與專案時程推估 2-60
2-3-7 關於Description的撰寫(未完) 2-61
2-3-8 關於Acceptance Criteria(未完) 2-61
2-3-9 關於Effort的估算方式(未完) 2-61
2-4 TASK的建立與撰寫 2-61
2-4-1 建立Task 2-62
2-4-2 剩餘時數 與 燃盡圖 2-64
2-4-3 指派工作負責人員 2-65
2-5 看板(BOARD)的使用與客製化 2-68
2-6 工作完成狀態 與 相關的圖表 2-74
2-6-1 累計流量圖(Cumulative Flow Diagram) 2-74
2-6-2 燃盡圖(BurnDown Chart) 2-76
2-7 控管每一個BUGS 2-77
2-8 數位儀錶板 2-81
第3章 SCRUM專案週期性工作與會議 3-90
3-1 SCRUM中SPRINT的周期性工作 3-90
3-2 PLANNING MEETING 3-92
3-2-1 確定目標Sprint Goal 3-93
3-2-2 決定Sprint Backlogs 3-95
3-2-3 決定該如何完成? 3-99
3-2-4 架構設計的衝突 3-100
3-3 DAILY SCRUM與TEAM ROOM 3-102
3-3-1 關於團隊 3-102
3-3-2 關於溝通 3-104
3-3-3 每天溝通 3-105
3-3-4 線上溝通 3-109
3-4 DEMO MEETING (SPRINT REVIEW) 3-111
3-5 透過REQUEST FEEDBACK取得STAKEHOLDERS的反饋 3-113
3-6 RETROSPECTIVE MEETING 3-128
3-6-1 為何需要Restrospective? 3-128
3-6-2 用感謝做結尾 3-131
3-6-3 只說正面的話 3-132
3-7 BACKLOGS REFINEMENT(尚未完成) 3-133
3-8 CHECK LIST OF ROLE 3-133
3-8-1 PM/PO(Product Owner) 3-133
3-8-2 SM(Scrum Master) 3-134
3-8-3 Team Members (Developers) 3-134
3-9 專案規範 3-135
3-9-1 Weekly report 3-135
3-9-2 Daily report 3-137
第4章 TFS/VSTS程式碼版控(尚未完成) 4-139
4-1 誰需要版控? 4-139
4-1-1 有何好處? 4-140
4-1-2 版本控管的價值 4-141
4-2 TFS/VSTS與原始程式碼版控 4-143
4-2-1 從VSTS開始建立新專案 4-143
4-2-2 將現有程式碼加入版控 4-143
4-2-3 下載部分或全部程式 4-143
4-2-4 關於workspace 4-143
4-3 (待完成)程式碼的簽入與簽出 4-143
4-3-1 簽出修改 4-143
4-3-2 簽入全部或部分簽入 4-143
4-3-3 簽入與work item之間的關係 4-143
4-3-4 Undo changes 4-143
4-3-5 Request code review 4-143
4-3-6 Pending Changes與Shelve 4-143
4-4 (待完成)在VSTS項目中有多個VS方案(SOLUTION) 4-143
4-4-1 簽入另一個Solution(.sln) 4-143
4-4-2 規劃在VSTS項目中的多個方案 4-144
4-5 (待完成)程式碼的版本比較 4-144
4-5-1 程式碼比較 4-144
4-5-2 衝突與解決 4-144
4-5-3 佈署到雲端時的預覽與比較 4-144
4-6 (待完成)進行分支與分支策略 4-144
第5章 建置、測試、持續整合與佈署 5-145
5-1 關於自動化建置 5-145
5-1-1 雲端建置的意義與價值(待完成) 5-145
5-1-2 建立Build 5-146
5-1-3 為何要自動化? 5-146
5-2 關於自動化測試(待完成) 5-146
5-2-1 建立測試 5-146
5-2-2 自動化測試 5-146
5-2-3 Last Minutes Integration Surprises 5-146
5-3 在VISUAL STUDIO中使用CI 5-146
5-3-1 如何設定CI 5-146
5-3-2 透過Check in來觸發Build 5-154
5-3-3 關於Build價格與購買時數 5-156
5-3-4 關於Build Process Template的細項設定(尚未完成) 5-158
5-4 將STYLECOP整合進CHECK-IN POLICY 5-158
5-4-1 關於StyleCop 5-158
5-4-2 將StyleCop設為Check-In Policy 5-163
5-4-3 建立自己的StyleCop Rules 5-168
5-5 將CHECK RULES整合進CI BUILD 5-179
5-5-1 幾個作法 5-179
5-5-2 使用StyleCop.MSBuild 5-180
5-6 配合WINDOWS AZURE WEBAPPS達成CD 5-187
5-6-1 自動部署,這樣穩當嗎? 5-188
5-6-2 建立測試、開發、候選環境 5-191
5-6-3 設定自動發佈 5-193
5-6-4 Azure的Swap 5-198
5-6-5 結語 5-200
第6章 新版TF BUILD(待完成) 6-202
6-1 TF BUILD與XAML BUILD 6-203
6-2 建置第一個TF BUILD 6-203
6-3 帶入UNIT TEST與STYLECOP 6-203
6-4 沒有測試豈不可惜 6-203
6-4-1 在Build中建立Load Test 6-203
6-4-2 加入Performance Test 6-203
6-5 準備邁向CD吧… 6-203
第7章 透過RM進行持續交付 7-204
7-1 為持續交付進行準備 7-205
7-1-1 建置不同的網站 7-205
7-1-2 設計流程 7-205
7-2 環境配置 7-205
7-3 7-205
第8章 VSTS開發人員的密技(尚未完成) 8-206
8-1 (待完成)管理用戶的反饋(FEEDBACK) 8-206
8-1-1 建立VSTS整合 8-206
8-2 (待完成)WORK ITEMS(BACKLOGS)處理進度查詢與報表 8-206
8-3 (待完成)從工時計算專案(或人員)成本 8-206
8-4 (待完成)搜尋TEAM ROOM 8-206
8-5 (待完成)VSTS API的驗證方式 8-206
第9章 透過框架設計提升SCRUM(尚未完成) 9-207
9-1 關於架構、框架、與開發流程 9-208
9-1-1 何謂架構(Architecture)? 9-208
9-1-2 何為開發框架(Framework)? 9-209
9-1-3 先談談我們的開發流程 9-209
9-1-4 為何需要架構設計 9-211
9-1-5 誰該做架構設計?何時該做架構設計? 9-213
9-1-6 關於架構設計的哲學思維 9-215
9-2 可以怎麼做架構設計與開發框架 9-217
9-2-1 應用程式在架構上的分層 9-217
9-2-2 程式碼的分層 9-219
9-2-3 確定你在意的目標 9-220
9-3 我們常用的架構設計與開發框架 9-220
9-3-1 我們所建立的Framework 9-221
9-3-2 開發流程準則 9-224
9-3-3 一般開發規範 9-225
9-3-4 透過Framework簡化開發與流程 9-226
9-3-5 商業邏輯層 – ServerComponent 9-226
9-3-6 展示層開發方式的統一 9-227
9-3-7 Web服務層 9-229
9-3-8 挑戰與改變 9-231
9-3-9 AOP pattern的應用 9-231
9-3-10 透過Nuget套件簡化開發與確保架構 9-233
9-4 (待完成)架構設計與SCRUM 9-235
9-4-1 透過框架設計成就你的Scrum 9-235
9-4-2 我們的架構設計、開發框架、與範本 9-235
9-4-3 建構你自己的架構設計、開發框架、與範本 9-235
9-5 (待完成)導入開發框架的挑戰 9-235
9-5-1 如何讓團隊接受? 9-235
9-5-2 如何捨棄 9-235
9-5-3 要求與承諾 9-235
9-5-4 Code Review與Report 9-235
9-6 堅守架構設計與開發風格 9-236
9-6-1 設計架構不難,難在讓開發人員遵循 9-236
9-6-2 建立Project Template 9-236
9-6-3 建立Private Nuget Server & Package 9-236
9-6-4 建立Code Snippet 9-236
9-6-5 透過StyleCop進行Code Review 9-236
第10章 雲端壓力測試(尚未完成) 10-237
第11章 開發人員私房話 11-238
11-1 專業主義的秘密 - 練習 11-238
11-2 你為了什麼寫CODE呢??? 11-243
11-3 如果人人都能寫程式??? 11-250
11-4 專業的價值 11-256
11-5 命苦是自找的... 11-260
11-6 走進廚房,才知道食材的好壞... 11-264
11-7 關於 如何快速增進程式功力... 11-267
11-8 持續地改變是必然的趨勢... 11-273
11-9 提升你在企業內的價值 11-275
11-10 什麼是專業? 11-281
11-11 誰管你準備好了沒? 11-283
第12章 專案管理私房話 12-285
12-1 PM,你必須真的在乎團隊才行 12-285
12-2 飛機上的27A - 談敏捷開發的成案問題 12-290
12-3 專案中一個幾乎遙不可及的夢 - 專人專用 12-295
12-4 為什麼我要規範所有團隊用同樣的架構開發專案? 12-301
12-5 這些問題都不在SCRUM 12-307
12-6 如何培養你的『溝通力』 12-310
12-7 保持模糊的共識? 12-317
12-8 談需求,不要談功能 12-322
12-9 讓團隊溝通? 比你想像的容易… 12-326
12-10 程式開發是一種難以管理的創意工作? 12-328
第13章 咖啡館呢喃 (尚未完成) 13-332

作者介紹

董大偉老師打從 20 年前 Apple II 時代起即投入程式設計領域,一直對於軟體開發的無限創意深深著迷,在資訊業界各領域均有參與。從2002年開始加入資訊書籍寫作並投身教育訓練與顧問服務的行列,兼具堅強的技術背景和業界經驗為後盾的他在課堂中針對授課的內容與討論的議題均與業界的需求緊密契合,讓學員得以結合實務經驗與電腦操作,在工作中可學以致用。董老師除了在軟體開發領域著有多本暢銷著作,從2006年至今,榮獲多次微軟的最有價值專家(MVP),並多次受邀擔任微軟歷年TechED大型研討會講師,是資訊界裡首屈一指的人才之一。

●光岩資訊技術總監
●美商K2資深顧問
●集英信誠資深顧問
●台灣微軟TechDays/TechEd 2014~2007講師
●China TechEd2013講師
●微軟Virtual TechDays 2009講師
●台灣微軟MSDN講座資深講師
●微軟最有價值專家(MVP)
●Run!PC專欄作者、博碩文化、旗標出版作者
●.NET 書籍暢銷作者
●國內多家企業、機構之軟體技術顧問、教育訓練講師