Transcript pps

軟體開發與軟體工程
以 Scrum 為例
陳建村
[email protected]
http://teddy-chen-tw.blogspot.com
April 15 2011
1
我是誰

學歷
 台北科大資工系博士班畢業
(2008/10)
 台北工專電子科五專畢業 (1994)

經歷
 美超微電腦專案經理
(2008/10~今)
 肯心資訊: 技術總監 (2000-2002);
程式設計師 (1996-2000)
2
Outline
 現況
改變
 未來
 結論

3
選擇題：以下何者為對？

行醫需要醫德

從政需要道德

開發軟體需要軟體工程

以上皆非
4
台灣軟體開發的普遍現象

本公司的專案管理，就是凡事都照著 PM 的
時程表走

台灣經濟奇蹟的幕後無名英雄–加班

寫程式有什麼學問，不過就是一堆 printf()
而已
(http://blog.udn.com/chungchia/3388454)
5
對於軟體工程--業界普遍的心聲


你們學校的教授不懂啦，這在業界行不通的
很熟悉的敘述：
 （N
年前）台幣升破35對1美元，台灣的公司會倒
掉一堆
 基本工資若是調漲，企業會倒掉一堆
 若是 xxxxx，企業會倒掉一堆

是無法升級，還是不想升級？
 誰都想當派大星！
6
軟體開發流程
需求
開發
分析
設計
實做
佈署/維護
測試
7
需求：木工，軟工，傻傻分不清楚

(1/2)
XX 總經理：Teddy 啊，我們請木工做一個衣
櫥，木工會幫我們測量衣櫥大小。如果木工
不小心把木版的尺寸裁切錯誤，是要自己吸
收費用的，不可能讓業主來出這一筆錢。你
們做系統經驗不足，都沒有給我們『專業』
的建議，導致需求改來改去的。現在又要我
們全部負擔需求修改的費用，這樣是不是不
合理？
8
需求：木工，軟工，傻傻分不清楚




(2/2)
妳家衣櫃四周的牆壁位置，地板與天花板的
高度，會隨時變來變去的嗎？
衣櫃門板材質選好之後，木版也裁切好了，
妳還可以改變材質嗎？
木工把衣櫃都做好之後，妳可以因為突然發
現『衣服太多放不下』的這個理由，請對方
拆掉重作嗎？
衣櫃作到一半妳可以請木工改成狗屋嗎？
9
實做：硬體代工的思維

老闆：
 我一個工程師
3～4 個月就可以獨立設計一塊電
路板，你們 6~7 個人做個『小』軟體搞了兩年還
做不出來?
 沒有測試人員沒關係，工程師自己測就很好了。
 什麼，要花錢買 software components，15 萬，
這麼貴，自己寫比較省。要導入 Scrum，10 萬，
這麼貴，自己試就好了 。要導入自動化測試，8
萬，這麼貴，人工測一測就好了。要.......『賣夠
共阿啦』，要什麼一律免談。
10
維護：600 多個 bugs 要怎麼修?




做專案不需要自動化測試，做產品才要。
寫程式的時間都沒有了哪有時間寫測試。
解 600 多個 bugs 要靠找『domain knowhow』很強的人來幫忙。
我最多給你三天，在三天之內把這個 bug
給我改好。
11
Outline

現況
 改變
未來
 結論

12
台灣的軟體開發方式與思維
需要改變
13
Software：都是名字惹的禍

事實：
 軟體不軟。實際上，

軟體很硬。
軟體工程的目的：
 讓你有能力可以把軟體做出來。
 讓你的軟體變軟。
 讓你在可接受的成本範圍內達成上述兩件事。
14
什麼是軟體設計

What is Software Design?
 By
Jack W. Reeves, 1992, C++ Journal.
 http://www.developerdotstar.com/mag/articles/reeve
s_design.html.

軟體開發好比：
 Software
development is driving
 Software development is gardening
 All programming is maintenance programming
15
軟體開發教改宣言: Agile Manifesto,




2001
Individuals and interactions over processes
and tools
Working software over comprehensive
documentation
Customer collaboration over contract
negotiation
Responding to change over following a plan
16
敏捷實務作法







Testing early, often, and automated
Incremental design
Daily deployment
Customer involvement
Continuous integration
Short development cycles
Incremental planning
17
Agile methods






eXtreme Programming (XP)
Scrum
Feature Driven Development (FDD)
Dynamic Systems Development Method
(DSDM)
Agile Unified Process (AUP)
…
18
Scrum
Vision
Developers
PO
SM
Stakeholders
Product
Owner
Product
Backlog
Sprint Planning
Meeting
PO
Sprint
Backlog
Developers
SM
Feedbacks
Daily Scrum
Meeting
Developers
PO
1 Day
Developers
PO
PO
SM
Developers
SM
Sprint
Retrospective
Meeting
SM
Sprint Review
Meeting
19
為什麼是 Scrum?

軟體從業人員的直覺: It works!

實施門檻低:只要一個下午的訓練就可以上手

具備無限的擴充性

解決現實世界遭遇到的問題
把計畫變成動詞
營造分工且合作的環境
良好的回饋機制
分階段逐步改善 (不可能一步到位)
 減少浪費
 好玩(有趣)才能持續




20
我們如何導入 Scrum: 事前準備





人 (團隊 + 外部顧問)
觀察 (2-5天) + 面談 (一人/一小時)
一個小時的 Scrum 簡介
一到兩個小時的 sprint planning meeting 演練
Scrum 開發環境






座位調整 (利於溝通) +不受外部干擾的環境 (利於思考)
大桌子
大螢幕 (22”以上，雙螢幕更佳)
高級無線滑鼠，鍵盤
空白牆面或大白板 (taskboard, product backlog)
(專屬)會議室
21
我們如何導入 Scrum: 開始做

熟悉Scrum框架: 2-4 sprints

持續改善
 訂定階段性目標
 決定改善方法
 執行
 檢討改善項目
 重複第一步驟，直到達成目標
22
Scrum Master 的一天

觀察，觀察，觀察
 團隊
 Product
Owner
 其他相關人員

協助專案依循 Scrum (Agile) 精神進行
23
Product Owner 的一天

回答團隊成員的問題

研究競爭者產品

耕耘 Product Backlog

對外代表團隊與客戶，業務，行銷，老闆等相
關人員互動
24
Scrum 帶給我們最大的改善

穩定的產出

較高品質的產出
 每個
sprint 結束都有一個潛在可交付的軟體

依據需求優先順序施工

軟體變軟
25
Scrum 會議改善了我們的合作模式

Sprint Planning Meeting


Daily Scrum Meeting


讓每一天都有明確的工作目標
Sprint Demo (Review) Meeting


還沒動工，就知道要做什麼，有哪些事情要做，做多久
定期驗證系統是否符合顧客所需 (產品改善回饋機制)
Retrospective Meeting

回顧過去 + 展望未來 (流程改善回饋機制)
26
幾個最基本的實務作法






Testing
Continuous Integration
Refactoring
Pair Programming
Shared Code (Collective Ownership)
Test-Driven Development
27
Outline
現況
 改變

 未來

結論
28
Scrum 為什麼很難


任何改變都很難
Scrum 是一種制度


培養敏捷素養





專制 vs 民主
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
持續改善
29
導入 Scrum 不要忽略

軟體設計基本功夫依然重要
 OO
concepts, design patterns, architectures, etc.

軟體工程實務作法依然重要

努力追求成為卓越的專業人員依然重要

人性
30
Scrum roadmap

Type A Scrum: winning teams

Type B Scrum: winning product portfolios

Type C Scrum: winning companies
31
參考書籍
(1/2)
32
參考書籍
(2/2)
33
Is it good to drink?
喝看看(做看看) 就知道
34
結論:

軟體很硬，需要借助軟體工程讓它變軟

實施軟體工程需要方法

Scrum 是一個好方法
Question?
35
Linked slides
36
Product owner
Scrum Master
Team
Role
Sprint planning
meeting (4-8 hrs)
Vision
Story
Product backlog
Sprint backlog
Task
Burndown chart
(task, story, release)
Artifact
Scrum
Activity
Daily Scrum
(15 mins)
Sprint
(2-4 weeks)
Sprint review
meeting
(4 hrs)
Sprint
retrospective
meeting (3 hrs)
37
Agile workspace
38
Visual Studio Team System: Better Software Development for Agile Teams
Sprint Planning Meeting 讓需求與時
程透明化 (1/4)
軟體
分析設
計文件
客戶需
求文件
Customer
SA/SD
Programmers
傳統以文件為主的溝通模式
39
Sprint Planning Meeting 讓需求與時
程透明化 (2/4)
軟體
客戶需
求文件
Customer
分析設
計文件
SA/SD
Programmers
在許多不確定性下開發軟體
40
Sprint Planning Meeting 讓需求與時
程透明化 (3/4)
Vision
Developers
PO
SM
Stakeholders
Product
Owner
Product
Backlog
Sprint Planning
Meeting
PO
Sprint
Backlog
Developers
SM
Feedbacks
Daily Scrum
Meeting
Developers
PO
1 Day
Developers
PO
PO
SM
Developers
SM
Sprint
Retrospective
Meeting
SM
Sprint Review
Meeting
41
Sprint Planning Meeting 讓需求與時
程透明化 (4/4)
會議結束後產生施工所需的 stories 與 tasks
42
Daily Scrum Meeting 讓每個人每天都
有明確的工作目標 (1/2)
不要點到我
每次都在討論
同樣的事?
這個問題不關
我的事
傳統(每週)會議流於進度報告或
成為找「代罪羔羊」的會議
看不出來
我睡著了吧
43
Daily Scrum Meeting讓每個人每天都
有明確的工作目標 (2/2)
http://www.xqa.com.ar/visualmanagement/wp-content/uploads/standup2.jpg
44
Sprint Review Meeting 提供一個定期
產品改善回饋機制 (1/2)
3
軟體
(一年半載之後)
1
客戶需求
2
軟體開發
Customer
5
4
回饋
這不是
我要的
傳統作法:客戶在專案後期才拿到軟體，
回饋週期太長且回饋次數太少
45
Sprint Review Meeting 提供一個定期
產品改善回饋機制 (2/2)
http://www.agilemanagement.net/AMImageArchive/OpsReview4.jpg
Scrum作法:每個 sprint 客戶都看到軟體，
回饋週期短且回饋次數多
46
Retrospective Meeting 提供一個檢視
與改善開發流程的機制 (1/2)
測試都沒做
就要拿給客戶
程式碼亂到
改不下去
完整 build 一次
系統需要3小時
空調太冷，
都快感冒了
傳統作法:影響開發效率的問題要反應給誰?
何時反應? 誰會關心? 誰去追蹤?
47
Retrospective Meeting 提供一個檢視
與改善開發流程的機制 (2/2)
http://pragmaticagile.files.wordpress.com/2008/09/25092008003.jpg
Scrum作法:團隊成員在 sprint
結束前檢視現況並提出改善行動
48
Shared Code

(1/2)
傳統分工模式:
 每個模組有一個負責人

好處:
 個人專長極大化個人效率極大化

問題:
 派工困難
Web UI
Business
Logic
Database
 專業分工形成一堵高牆
 個人成長有限
Driver
 人員流動對專案造成極大影響
49
Shared Code

實施 shared code:


程式碼為所有開發人員共享
好處:





(2/2)
派工比較容易
很多眼睛在看，有效提升程式品質
個人成長性高
人員流動對專案影響較小
挑戰:


Web UI
Database
Business
Logic
Driver
初期成員抗拒
需要長時間經營
50

劉可煒 王瑞材老師訪問矽谷超微電腦公司
51
劉可煒王瑞材老師訪問矽谷超微電腦公司與在美校友合影
52
53
54