敏捷開發 Practices of an Agile Developer (source:wiki)

價值觀 

雪鳥會議共同起草了敏捷軟體開發宣言。其中最重要的部分就是對一些與會者一致同意的軟體開發價值觀的表述：

藉著親自並協助他人進行軟體開發，我們正致力於發掘更優良的軟體開發方法。透過這樣的努力，我們已建立以下價值觀:

• 個人與互動 重於 流程與工具
• 可用的軟體 重於 詳盡的文件
• 與客戶合作 重於 合約協商
• 回應變化 重於 遵循計劃

也就是說，雖然右側項目有其價值， 但我們更重視左側項目。

原則 [編輯]

宣言中還包括以下原則：^[3] [4]

• 我們最優先的任務，是透過及早並持續地交付有價值的軟體來滿足客戶需求。
• 竭誠歡迎改變需求，甚至已處開發後期亦然。敏捷流程掌控變更，以維護客戶的競爭優勢。
• 經常交付可用的軟體，頻率可以從數週到數個月，以較短時間間隔為佳。
• 業務人員與開發者必須在專案全程中天天一起工作。
• 以積極的個人來建構專案，給予他們所需的環境與支援，並信任他們可以完成工作。
• 面對面的溝通是傳遞資訊給開發團隊及團隊成員之間效率最高且效果最佳的方法。
• 可用的軟體是最主要的進度量測方法。
• 敏捷程序提倡可持續的開發。贊助者、開發者及使用者應當能不斷地維持穩定的步調。
• 持續追求優越的技術與優良的設計，以強化敏捷性。
• 精簡──或最大化未完成工作量之技藝──是不可或缺的。
• 最佳的架構、需求與設計皆來自於能自我組織的團隊。
• 團隊定期自省如何更有效率，並據之適當地調整與修正自己的行為。

對比其他的方法 [編輯]

敏捷方法有時候被誤認為是無計劃性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性。

適應性的方法集中在快速適應現實的變化。當項目的需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述未來將會如何變化.

對比迭代方法 [編輯]

相比迭代式開發兩者都強調在較短的開發周期提交軟體，敏捷方法的周期可能更短，並且更加強調隊伍中的高度協作。

對比瀑布式開發 [編輯]

兩者沒有很多的共同點，瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文檔，測試計劃和代碼審閱等等。

瀑布式的主要的問題是它的嚴格分級導致的自由度降低，項目早期即作出承諾導致對後期需求的變化難以調整，代價高昂。瀑布式方法在需求不明並且在項目進行過程中可能變化的情況下基本是不可行的。

相對來講，敏捷方法則在幾周或者幾個月的時間內完成相對較小的功能，強調的是能將儘早將盡量小的可用的功能交付使用，並在整個項目周期中持續改善和增強。

有人可能在這樣小規模的範圍內的每次迭代中使用瀑布式方法，另外的人可能將選擇各種工作並行進行，例如極限編程。

敏捷方法的適用性 [編輯]

在敏捷方法其獨特之處以外，他和其他的方法也有很多共同之處，比如迭代開發，關注互動溝通，減少中介過程的無謂資源消耗。通常可以在以下方面衡量敏捷方法的適用性：從產品角度看，敏捷方法適用於需求萌動並且快速改變的情況，如系統有比較高的關鍵性、可靠性、安全性方面的要求，則可能不完全適合；從組織結構的角度看，組織結構的文化、人員、溝通則決定了敏捷方法是否適用。跟這些相關聯的關鍵成功因素有：

• 組織文化必須支持談判
• 人員彼此信任
• 人少但是精幹
• 開發人員所作決定得到認可
• 環境設施滿足成員間快速溝通之需要

最重要的因素恐怕是項目的規模。規模增長，面對面的溝通就愈加困難，因此敏捷方法更適用於較小的隊伍，40、30、20、10人或者更少。大規模的敏捷軟體開發尚處於積極研究的領域。

另外的問題是項目初期的大量假定或者快速收集需求可能導致項目走入誤區，特別是客戶對其自身需要毫無概念的情況下。與之類似，人之天性很容易造成某個人成為主導並將項目目標和設計引入錯誤方向的境況。開發者經常能把不恰當的方案授予客戶，並且直到最後發現問題前都能獲得客戶認同。雖然理論上快速交互的過程可以限制這些錯誤的發生，但前提是有效的負反饋，否則錯誤會迅速膨脹。

用於敏捷開發團隊的專案管理工具 [編輯]

已經有一些專案管理工具用於敏捷開發，可以用它們來幫助規劃，跟蹤，分析和整合工作。 這些工具在敏捷開發中扮演的重要的角色，也是知識管理的一種方法。

通常包括：版本控制整合，進度跟蹤，工作分配，集成發布和迭代規劃，論壇和軟體缺陷的報告和跟蹤。

方法列表 [編輯]

目前列入敏捷方法的有：

• 軟體開發之韻，Software Development Rhythms
• 敏捷數據庫技術，AD/Agile Database Techniques
• 敏捷建模，AM/Agile Modeling
• 自適應軟體開發，ASD/Adaptive Software Development
• 水晶方法，Crystal
• 特性驅動開發，FDD/Feature Driven Development
• 動態系統開發方法，DSDM/Dynamic Systems Development Method
• 精益軟體開發，Lean Software Development
• AUP（Agile Unified Process）
• Scrum
• XBreed
• 極限編程，XP Extreme Programming
• 探索性測試

ASP 與雲端服務 SaaS, PaaS, IaaS比較

1.ASP應用服務提供者(Application Service Provide, ASP), 如主機代管, 網站建置, email, 使用者依使用量或定期租用

2.雲端服務主要有三種類型：

1)「軟體即服務」（Software as a Service, SaaS），提供使用者網路的軟體應用，例如Yahoo電子信箱、Google地圖、Youtube、Facebook…等，甚至是趨勢科技的雲端防毒，都是我們最常見到的雲端服務類型。

2)「平台即服務」（Platform as a Service, PaaS），指的就是提供了平台來提供運算或解決方案，並提供了整合的API(應用程式介面)，可以讓客戶的應用程式放在該平台代管，佈署更簡便，而且節省成本。例如微軟的Windows Azure、Google的 App Engine、Yahoo的 Application Platform、Salesforce的AppExchange平台…等就是PaaS。

3)「基礎設施即服務」」（Infrastructure as a Service, IaaS），直接提供硬體的環境及網路頻寬給企業用戶使用，例如中華電信的HiCloud、IBM的Blue Cloud、HP的Flexible Computing Services及亞馬遜的EC2…等。

2010 OWASP Top 10 網站潛在漏洞摘要

1. Injection: 攻擊者利用 GET / POST 在參數裡塞入部份程式, 取得不被允許的資料。如常見的 SQL Injection。解法就是別相信使用者傳進來的東西, 限制傳入東西的型別和可能的文字模式。
2. XSS: 誤執行攻擊者傳來的程式。比方說 textarea 就容易混入這類程式。別傻傻的直接引入使用者傳上來的 html, 最好只充許純文字, 或限制 html tag 的功能。
3. Broken authentication and session management: 如網站傻傻的將 session id 放到 URL 上, 讓使用者有機會不小心外洩 session id。
4. Insecure direct object reference: 沒有在存取資料時再多做權限檢查。攻擊者在登入後, 可以傳特定參數取得他不能取得的資料。比方說 alice 登入後在需要傳 user id 的地方改傳 bob 卻能取得 bob 的資料。
5. CSRF: B 網站偷塞會連向 A 網站更新資料的操作 (如塞在 img src 裡), 若使用者登入 A 網站後沒登出, 接著連到 B 網站就中招了。解法是 A 網站要確保任何會更新資料的操作, 在產生輸入的頁面時先塞一段密文, 在更新資料時檢查是否有這段密文, 確保使用者真的從 A 網站送出請求。
6. Security misconfiguration: 網站留一堆後門給攻擊者用, 像是可以由外連上管理者介面 (如 phpMyAdmin), 或是可以瀏覽網站目錄, 下載 source code 之類的。還有用別人的 framework / lib, 明明說有 security patch 卻不更新。
7. Insecure cryptographic storage: 加密的 key 和加密的資料存在一起, 有防和沒防一樣。password 檔沒加 salt (之前寫過的文章: 為啥要用 salt)。
8. Failure to restrict URL access: 沒有在載入頁面時檢查權限。比方說只有查使用者是否有登入, 並隱藏使用者沒權限執行的頁面。一但攻擊者知道那些 URL, 就能登入後直接連上去使用。
9. Insufficient Transport Layer Protection: 輸入密碼或重要資料 (如卡號) 時沒透過加密連線, 攻擊者可透過監聽網路封包的方式取得這些資料。或是一般使用的情況取得 session id。另外有用 SSL 但沒設好 certificate, 造成惡意攻擊網站有機會偽裝成自家網站, 騙取輸入資料。
10. Unvalidated Redirects and Forwards: 隨便在參數提供 redirect 不小心被當作攻擊的打手, 使用者沒注意看就點了別人貼 A 站的網址, 卻被 redirect 到 B 站去。或是自己的站被用來導到其它頁面, 卻沒有在進入頁面時檢查權限, 於是 redirect 被當作任意門使用, 能進入不被允許的頁面。