軟體工程的引入：Scrum開發架構總結

標籤：

俗話說，自己寫的代碼，6個月後也是別人的代碼……複習！複習！複習！涉及的知識點如下：

• 軟體工程概念
• 敏捷開發過程scrum

一、什麼是軟體工程？請用一句話描述。

　　軟體工程是一門研究性的學科：它用工程化的方法（聯絡建築工程……），構建和維護有效、實用的，和高品質的軟體。簡單來說，軟體工程有三要素：過程+方法+工具，而軟體工程是目標，軟體過程是步驟，方法和工具是輔助。

 

二、那麼，軟體過程又是什嗎？

　　軟體過程：首先它是一個架構或者說步驟，它是一個為建造高品質軟體而所需要完成的任務的架構，即形成軟體產品的一系列步驟，包括中間產品、資源、角色及過程中採取的方法、工具等範疇。

 

三、常用的軟體開發過程（開發架構）都有什嗎？選一種做簡單介紹。

　　1、瀑布模型（Waterfall Model）：開發過程是通過設計一系列階段順序展開的，過程如下：先明確要做的是什麼，然後看使用者的需求是什麼，分析需求之後簡單得出一個demo（畫出原型圖，草圖等），然後進行架構分析和設計，總結出設計文檔，之後討論詳細的開發細節，而後實現，最後測試……

 

　　瀑布模型的優點：
　　–為項目提供了按階段劃分的檢查點
　　–當前一階段完成後，您只需要去關注後續階段
　　瀑布模型有以下缺點：

　　–各個階段之間極少有反饋
　　–只有在專案生命週期的後期才能看到結果
　　–通過過多的強制完成日期和裡程碑來跟蹤各個項目階段
　　–不適應使用者需求的變化

　　2、scrum敏捷方法，Scrum是一種迭代式增量軟體開發過程，通常用于敏捷軟體開發。Scrum在英語的意思是橄欖球裡的爭球，Scrum是為管理軟體開發項目而開發的，它同樣可以用於運行軟體維護團隊，或者作為計劃管理方法。

　　3、ICONIX過程，包括願景分析、業務建模、需求分析、健壯性分析、關鍵設計、最終設計、實現……

四、什麼是敏捷開發過程？

　　敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。說白了就是更加靈活！面向人的需求為核心！是一個逐步適應性的過程！敏捷是一種思想！敏捷和瀑布模型比較：

那麼敏捷是不是就是萬能的呢？其他過程都不好？不是的，一定澄清幾個誤區，對敏捷開發的誤解：敏捷固然好，但是其他方法不是都沒用。遵循敏捷過程的常見軟體開發模型有scrum，xp（極限編程）……其中比較流行的是scrum。

 

五、scrum概念

　　Scrum是一個架構，顧名思義scrum是橄欖球運動裡帶球過人，爭球的含義，而帶球過人需要計劃！在球場上，在比賽每段的開始，雙方都要擺開陣勢，教練和隊長都可以參考計劃。而在軟體開發公司。敏捷方法的每個迭代的開始，團隊領導者都應該做好本迭代的計劃，尤其是需求條目的優先順序排序、選擇本迭代的工作、設定必須完成的內容等。且帶球過人需要靈活應變！在球場上，哨聲響起，儘管隊員們努力按照計劃推進，但場上瞬息萬發，隊員不可能即時按照教練指令亦步亦趨地行事，而是靠平時訓練中形成的素養見機行事，達成目標，在軟體開發公司，在每個迭代開始後，團隊領導不可能也不必需要事必躬親，而是應該由具體執行的人選擇如何去做。團隊領導要做好的是協調資源、解決困難、提供指導，以達成目標。

　　1、敏捷開發的角色

　　產品負責人PO，負責產品的需求提煉、條目化，優先順序排序，PO直接和使用者以及其他關係人互動。scrum過程管理者scrum master，負責維護scrum方法的秩序，並協調解決非技術問題。最後是team團隊，自組織的相對扁平化的管理方式進行項目的開發工作。

　　scrum團隊結構：

　　名詞解釋：每個迭代的衝刺周期過程又叫sprint，其中貫穿了很多活動……

　　sprint計劃會議：每次迭代之前召開，時間充足（4-8小時或者……），po，sm，team……都參加po從backlog積壓的產品列表裡找高優先順序任務，並和team商量需要完成多少功能，po把功能分解為小的功能模組，而team要詳細討論如何完成……預估時間。

　　backlog（積壓的待處理事務）：產品的backlog包括了所有需要交付的內容，內容根據業務的需求價值順序排列，更加需求變化動態增長或者減少。既定產品的backlog是一個迭代中的產物，定義了team接受的工作量，整個sprint中不變，sprint backlog涵蓋了最終版本的既定產品backlog的任務，團隊通過它來協調開發進度，障礙backlog列舉了所有團隊內部和相關的和阻礙項目進度的問題，sm需要確保所有的障礙backlog問題都已經分配並且可以得到解決。

　　每日立會：早上開比較好，與會人員站立而開，10幾分鐘足以，任何人都可以參加，sm主持，但只有team能做相關任務的發言，每個team要問三個問題——昨天做了什嗎？今天要做什嗎？遇到了哪些問題？然後更新燃盡圖 (burndown chart)。

　　sprint評審會議：每次sprint結束時召開，時間一般2個小時內控制，team展示本輪迭代完成的任務，不需要ppt，展示demo！此會，客戶，po，管理層……都能參與，目的是讓po去斷定項目開發的進度和迭代目標是否一致。

　　sprint回顧會議：sprint結束之後召開，時間一般1-3個小時左右，po，sm，team都參加，目的是對剛剛接受的sprint進行總結，反思，提高適應能力。需要總結分析成功經驗和解決的困難。

　　2、Scrum主要特徵：快速開發儘快交付，團隊合作適應變化。

　　3、Scrum的適用情境：

•7人，+or-2
•偏小一些會更適合
•最好能坐在一起
•客戶參度不高
•快速移動互連網項目
•自主性研發的產品

六、scrum開發方法的具體流程

1. 項目的提出（項目的背景，項目的主要朋務對象，目標—願景，商業價值，服務物件的細分）以Project Owner為主要提出者，team輔助！

　　項目的背景：“大資料時代已到，資料越來越具有價值，沒有資料寸步難行，有了資料可以在諸多領域幹很多事，比如互連網金融。從互連網上爬來自己想要的資料，是資料的一個重要來源，而且往往是必不可少的來源。所以……要能穩定的、高效的和即時的帶來資料……”。

　　項目的主要服務物件：區分客戶和使用者！客戶是系統的購買者，使用者則是系統的使用者。知乎爬蟲系統服務物件：某論壇-客戶

　　項目的目標（願景）：願景就是嚮往的前景，是人們為止持續奮鬥而希望達到的圖景！比如社會主義接班人要奮鬥終生去努力實現共產主義–沒有階級、沒有壓迫、沒有貧窮、沒有失業、人人幸福的共產主義社會！福特汽車讓每個家庭都有一輛汽車，微軟讓每個案頭都有一台電腦……故可以認為：偉大的願景能成就偉大的事業！具體到軟體的願景，要想找到軟體的願景就要找到項目購買人——老大（專業術語），先找到老大，再得到老大購買該系統的目的，PO去做……我們已經知道軟體項目是為了改善某個組織的某些方面，而購買軟體的人（老大）毫無例外就是這個組織中最有話語權的干係人。比如企業的財務主管需要提高財務工作的效率，某企業的領導需要佔領市場，領先對手，某官員需要彰顯政績……知乎爬蟲系統的願景就是根據論壇主需要，多樣化，精確化豐富論壇內容（這裡學習為主，類比為主，故不考慮著作權，但實際工作必須有著作權意識！），

　　項目的商業價值（難分析，很重要）：先回答什麼是商業價值？通俗地講，商業模式就是項目通過什麼途徑或方式來賺錢。而解決別人願意花錢解決的問題，就是商業價值。po主持挖掘商業價值，如果沒挖掘出來……好吧，放棄該項目！

　　服務物件細分：也就是使用者角色建模，良好的使用者建模，可以保證不同使用者都能方便地訪問其功能 ，使用產品後也更容易獲得其特定的價值，一般由project owner主持，藉助團隊的力量進行頭腦風暴！

• 哪些使用者可能來使用產品(或訪問網站)
• 他們為解決哪些問題而來，or 為達到哪些目的而來

使用者建模的步驟，四步曲

• 儘可能多的列出使用者
• 找出關鍵使用者——購買的決策者，主要的使用者
• 分類，合并次要使用者
• 添加虛擬和極端的使用者，虛擬使用者——假想的使用者角色的代表。比如 “ Mario在SpeedyNetworks的人事部門負責招聘工作，該公司是一個高端網路組件製造商。他已經在該公司工作了6年。Mario有彈性的時間安排，每周周五他在家工作。Mario對電腦相當在行，他覺得對於自己所使用的軟體產品，他幾乎都是超級使用者。Mario的妻子Kim，正在斯坦福大學化學系攻讀博士。由於SpeedyNetworks幾乎一直在擴張，Mario總是在物色優秀工程師。” 極端使用者——很可能讓你編寫出原本可能遺漏的故事。

　　2、產品功能列表的定義，所謂產品功能列表是一個需求、or 特性等組成的列表-產品backlog是Scrum的核心，是一切的起源，按照重要性的層級進行了排序，裡麵包含的是客戶想要的東西，使用使用者客戶的術語加以描述。產品功能列表主要是Product Owner寫，Team也有權利，但最終由PO進行取捨。

　　產品功能列表寫成什麼形式——使用者故事user stroy的形式！因為在產品定義階段我們很難全面描述出來我們項目的需求，我們需要一種方法去探討需求——使用者故事。傳統的需求說明書是這個階段的結果。　　PS：產品功能列表格式

ID（統一標識符）	Name（標題）–簡短的、描述性的故事名	Story（故事）–故事內容描述	Priority（重要性）–產品負責人評出一個數值，指示這個故事有多重要	Initial estimate（初始估計）–團隊的初步估算，表示和其他故事相比，完成該故事所需的工作量	How to demo（如何做示範）–它大略描述了這個故事應該如何在sprint 示範上進行示範	Notes（註解）–相關資訊、解釋說明和對其它資料的引用等等

額外的欄位（非必需）

•Track（類別）–當前故事的大致分類
•Components（組件）–通常在Excel文檔中用“複選框”實現
•Requestor（要求者）–這項需求的提出者
•Bug tracking ID（Bug跟蹤ID）–故事與bug間的直接聯絡

　　那麼使用者故事又是什麼鬼？
　　使用者故事是一種敏捷的需求挖掘方式，其側重點不是將需求書寫出來，而是將需求討論出來。基本的敘述格式為：“作為一個……，可以……，以便……” 的樣式和思路寫成的使用者需求，就是使用者故事。作為一個網站站長，我希望能通過xx爬蟲系統抓取xx資料，以便於我的網站使用者能方便的得到某些資訊、作為一個網上商城的買家，我希望通過QQ號可以登入商城，以便於買東西……

　　使用者故事三要素：角色、功能、客戶價值，角色來源於使用者角色建模的結果！功能使用主語-謂語敘述原則，動賓片語原則.比如針對顯示xx資料：作為一個系統管理員，我希望可以顯示xxx資料，以便vip使用者……注意：角色和功能之間是主語-謂語關係；功能本身是動賓片語。我們一般把使用者故事的標題寫為功能的形式。關於客戶價值，看似簡單，其實很難寫，我們先體驗一下；“作為一個網友，我希望能夠有個快速通知可以提醒我有新的新聞更新，以便於節省我瀏覽網站尋找新聞的時間，從而有更多時間做其他的事情。”、“作為一個站長，我希望爬蟲系統能有效，快速的抓取xxx資料，並進行一些列分析……以便於我得到xxx資訊。”

　　使用者故事也是用來被賣掉的東西，看不到價值的故事不是使用者故事。

     讓故事停留在業務層面，避免技術性故事，Eg:給xxxx表添加索引，它的真正目標是什嗎？當然是為了提高在後台系統中搜尋事件表單的響應速度，最開始的技術描述只會作為一個註解存在（“為事件表添加索引可能會解決這個問題”）

　　好故事的準則

　　•獨立的（Independ）避免故事間的相互依賴性。

–使用者可以用Visa信用卡儲值。
–使用者可以用萬事達信用卡儲值。
–使用者可以用美國運通卡儲值。
　　思考：如何消除依賴？

合并故事——使用者可以用信用卡儲值。

通過不同的維度分割故事！——使用者可以用一種信用卡儲值，使用者可以用另外兩種信用卡儲值。

　　•可討論的（Negotiable）不要包含過多的細節

　　•對使用者or客戶有價值的（Valuable）
　　•可估計的（Estimatable）一般有以下3個原因會導致故事不可估計

–開發人員缺少領域知識。
–開發人員缺少技術知識。
–故事太大了。
　　解決方案
–PO講解/和客戶討論。
–分解為更小的故事

　　•小的（Small）剛剛好的，比如：使用者可以完成一次購物——大故事不好！

　　•可測試的（Testable）故事必須是可測試的。成功通過測試可以證明開發人員正確地實現了故事。通常，不可測試的故事發生在一些非功能性的需求上，這些需求和軟體有關，但不直接和功能有關。

–使用者必須覺得軟體很好用。
–使用者絕不需要花很長時間等待視窗出現。在95%的情況下，新視窗會在2秒內開啟

　　使用者故事的好處
　　•使用者故事強調對話交流而不是書面溝通。
　　•使用者故事可以同時被po和開發人員理解。
　　•使用者故事的大小適合做計劃。
　　•使用者故事適用反覆式開發法。

　　3、產品發布和迭代周期：常見兩種方式

　　每次迭代發布，移動互連網項目，自主性研發產品……

　　多次迭代發布，傳統項目、大型項目

　　前面說了，迭代之前要開sprint計劃會議，但是在衝刺計劃會議之前要：

• 確保產品 backlog 的井然有序，產品 backlog必須存在，只能有一個產品 backlog和一個產品負責人，重要的 backlog 條目都已經根據重要性被評過分，PO應當理解每個故事的含義！

• 確定Sprint 計劃會議議程
  -13:00 – 17:00 （每小時休息 10分鐘）
  -13:00 – 13:30。產品負責人對 sprint 目標進行總體介紹，概括產品 backlog。定下示範的時間地點
  -13:30 – 15:00。團隊估算時間，在必要的情況下拆分 backlog條目。產品負責人在必要時修改重要性評分。
  -15:00 – 16:00。團隊選擇要放入 sprint 中的故事
  -16:00 – 17:00。為每日 scrum會議安排固定的時間地點

• 會議由Product Owner、Scrum Master、Scrum Team參加，產品負責人必須參加

• 確保品質不能讓步：外部品質是系統使用者可以感知的。運行緩慢、讓人迷糊的使用者介面就屬於外部品質低劣，內部品質一般指使用者看不到的要素，它們對系統的可維護性有深進影響。可維護性包括系統設計的一致性、測試覆蓋率、代碼可讀性和重構等等。

　　在衝刺計劃會議中

　　

 

• 確定Sprint目標及長度，半死不活的目標也比啥都沒有強。
• 講解Story：講解故事就是要明確故事內容，決定spring包含的故事，使用故事索引卡，哪些故事需要從產品 backlog 拷貝到sprint backlog 中，在sprint中包含多少故事由團隊決定 ，而不是產品負責人or其他人
• 估算時間；估算時間就是對故事的估算，估算的單位——故事點（理想化的人-天），可以使用計劃牌

　　我們在這裡使用以下幾種技術：
　　–本能反應
　　–昨日天氣，昨日天氣（yesterday’s weather）——查看團隊的曆史

　　–生產率計算：用生產率計算來估算，這項技術包括步驟如下：

–參考實際生產率
–得出投入程度
–得出估算生產率
–計算在不超出估算生產率的情況下可以加入多少故事。

　　實際生產率：把上一個 sprint 中完成的所有故事的原始估算加起來，得到的和就是實際生產率

 

　　　　“投入程度（focus factor）”，以上一個例子為基礎，團隊的投入程度為：

18/50=36%

　　　　估算生產率:Eg：假設下個Sprint我們有30個人天，則生產率=30×36%=10個故事點

　　　　一些其他問題：如果沒有曆史資料怎麼辦？在新團隊中使用的“預設”投入程度通常是 70%。

　　　　　　　　　　　實際過程中我們用的是哪種估算技術？一般我們都是結合起來用

　　　　　　　　　　　　–審視上個sprint的投入程度和實際生產率
　　　　　　　　　　　　–估算一個投入程度
　　　　　　　　　　　　–再進行“直覺反應”的檢查

　　　　　　　　　　　產品負責人如何對 sprint 放哪些故事產生影響？
　　　　　　　　　　　　　調整優先順序

 

　　　　　　　　　　　　　縮小範圍

• 任務分解；“任務”和“故事”的區別是什麼呢？——故事是可以交付的東西，任務是不可以交付的東西

　　spring計劃會議中：定下每日例會的時間地點，一般是9:00，9:30 or 10:00，必須是每個人都能完全接受的時間。定義“完成”，產品負責人和團隊需要對“完成”有一致的定義，

　　Sprint計劃會議之後:Sprint 計劃會議會產生一些實實在在的成果

　　　　–sprint目標
　　　　–團隊成員名單（以及他們的投入程度，如果不是 100%的話）
　　　　–sprint backlog（即 sprint 中包括的故事列表）
　　　　–確定好 sprint 示範日期
　　　　–確定好時間地點，供丼行每日 scrum會議

　　　　 讓別人瞭解我們的Sprint
　　　　•sprint資訊頁；sprint 目標和示範日期

　　　　•經過團隊認可、要添加到這個 sprint 中的故事列表
　　　　•Sprint 中每個故事的估算值
　　　　•明確每日例會固定丼行的時間地點
　　　　•把故事拆分成任務

 

 

　　4、scrum每次sprint設計的過程

　　不好的,引發風險,產品不能滿足客戶需求變化，bug率標高，代碼品質堪憂

　　好的：

1. 先介面原型設計，PO主持，那什麼是介面原型？

　　介面原型指使用工具根據客戶需求及軟體分析人員的理解，將頭腦中的介面快速的反映到介質上。將需求轉化為可視畫面以及人與系統的互動！

　　介面原型的好處：Prototype不僅僅可確定需求，它更可贏得順客的心—阿倫 M.戴維斯 和 迪安 A. 萊芬韋爾，《用需求管理快速交付高品質的軟體》的作者（Rational軟體公司/IBM）

　　介面原型的目的:
　　　　•儘早驗證需求
　　　　•儘早明確不確定性因素
　　　　•方便便溝通交流
　　　　•為後續介面設計提供基礎

　　　　　　介面原型的目的是需求驗證，不必太糾結細節。

　　如果原型設計都沒通過，就沒有必要進行下去，

 

　　畫介面原型的工具;白紙、鉛筆、橡皮、橡皮+鉛筆+白紙、Axure、MS OFFICE、PS、Viso……工具只是工具，任何一種方法or工具都是為我們開發、生產過程服務的，我們不能成為工具的奴隸。根據實際以及環境選擇合適的工具繪製。

　　2、資料庫設計。這裡主要講解範式——”資料庫的三範式

　　　　•第一範式
　　　　　　–關係R中的屬性都是不可分割的項.
　　　　•第二範式
　　　　　　–在1N的基礎上,每個非主屬性完全函數依賴碼.
　　　　•第三範式
　　　　　　–在2N的基礎上,每一個非主屬性既不部分依賴碼也不傳遞依賴碼.

　　從1範式到2範式
　　•1N | 消除非主屬性對碼的部分氹數依賴 2N
　　•假定選課關係表為
　　　　–SelectCourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分)
　　　　–存在如下決定關係： (學號, 課程名稱) → (姓名, 年齡, 成績, 學分)
　　　　–正常化 學生：Student(學號, 姓名, 年齡)； 課程：Course(課程名稱, 學分)； 選課關係：SelectCourse(學號, 課程名稱, 成績)。

 　　從2範式到3範式

　　•2N | 消除非主屬性對碼的傳遞氹數依賴 3N
　　•假定學生表為
　　　　–Student(學號, 姓名, 年齡, 所在學院, 學院地點, 學院電話)
　　　　–正常化 學生：(學號, 姓名, 年齡, 所在學院)； 學院：(學院, 地點, 電話)。

　　對於三範式的理解
　　　　–每一列只有一個值
　　　　–每一行都能區分。
　　　　–每一個表都不包含其他表已經包含的非主關鍵字資訊

　　3、系統設計

 

　　5、產品實施（監控過程），管理sprint backlog最有效形式—掛在牆上的任務板！在每日例會的時候（or 會議開始前）更新任務板

　　　　在首次每日例會以後，任務板可能會變成這樣

　　　　幾天以後，任務板可能會變成這樣

 

　　還有使用燃盡圖 (burndown chart)（burn down chart）：是在項目完成之前，對需要完成的工作的一種可視化表示。Sprint燃盡圖 (burndown chart)和迭代燃盡圖 (burndown chart)，Sprint燃盡圖 (burndown chart)展示了以故事點表示的在本輪迭代中剩餘的工作量;

-y:預估剩下的故事點
–x:日期（非工作日除外）
–y/x=生產率

 　　計劃速率和實際速率:監測實際速率和計劃速率的偏差

　　還有累計故事點圖：表明了在每輪迭代結束時總共完成的故事點數。

　　每日燃盡圖 (burndown chart)顯示了團隊在某輪迭代中的進度，你可以用這個資訊判斷計劃的工作能否在迭代結束時都能完成。

 

軟體工程的引入：Scrum開發架構總結