• <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>
  • 敏捷軟件開發之Scrum/Sprint

    發表于:2012-11-02來源:SoftwareTeacher作者:鄒欣點擊數: 標簽:敏捷SCRUM軟件開發Sprint
    敏捷軟件開發之Scrum/SprintAdvanced Software Engineering, Development Process, Scrum/Sprint 軟件開發的流程有很多 (看 各種方法論概述), 我也寫過一篇博客 (酒后的敏捷) 談了談最近比較時髦的開發流程。 今天我們不喝酒, 正襟危坐地說說敏捷這一路 Scrum/

      Advanced Software Engineering, Development Process, Scrum/Sprint

      軟件開發的流程有很多 (看 各種方法論概述), 我也寫過一篇博客 (酒后的敏捷) 談了談最近比較時髦的開發流程。 今天我們不喝酒, 正襟危坐地說說敏捷這一路 Scrum/Sprint 開發方法.

      從理論上看, 這個方法真是妙得緊:

    File:Scrum process.svg

      [圖片來源: http://en.wikipedia.org/w/index.php?title=File:Scrum_process.svg&page=1]

      第一步: 找出完成產品需要做的事情 – Product Backlog, Backlog 翻譯成“積壓的工作”, “待解決的問題”, “產品訂單”都可以。

      產品負責人主導大家對于這個Backlog 進行 增/刪/改 的工作。每一項的時間估計的單位為 “天”.

      第二步: 決定當前的沖刺需要解決的事情 – Sprint Backlog.

      任務被進一步細化了,被分解為以小時為單位。如果一個任務的估計時間太長 (例如 超過16個小時),那么它就應該被進一步分解。 沖刺訂單上的任務不會被分派,而是由團隊成員簽名認領他們喜愛的任務。 團隊成員能主導任務的估計和分配, 他們的能動性得到較大的發揮。

      第三步: 沖刺 (Sprint). 在沖刺階段, 外部人士不能直接打擾團隊成員。 一切對交流只能通過SCRUM MASTER 來完成。 這一措施較好地平衡了 “交流”和 “集中注意力”的矛盾。 有任何需求的改變都留待沖刺結束后再討論。

      沖刺期間, 每天要開一個每日例會 (SCRUM Meeting), 團隊成員大多站著開會, 所以又稱每日立會. 大家依次報告:

      我昨天做了啥

      我今天要做啥

      我碰到了哪些問題

      每日立會強迫每個人向同伴報告進度, 迫使大家把問題擺在明面上。同時啟動每日構建, 讓大家每天都能看到一個逐漸完善的版本。

      用簡明的圖表展現整個項目的進度, 這個圖最好放在大家工作的環境中, 或者每天傳達給各個成員:

      圖表可以是燃盡圖 Burn Down Chart (想象我們把一堆 Backlog 的木頭給燒光)。

    image

      也可以是簡單的看板圖 Kanban: (把一堆任務從最初的 “待定”推動到“工作中”等各個狀態, 直至“完成”)

    image

      這里有幾個 現代軟件工程 學生小組的 daily scrum 的過程:

      2010 年學生,2011年學生項目,2012年學生項目

      沖刺階段是時間驅動的 (time-boxed), 時間一到,就結束。這個特點看似不起眼, 其實它有效地給各種延期的想法斷了后路,很高明。

      第四步: 得到軟件的一個增量版本,然后在此基礎上又進一步計劃增量的新功能和改進。

      美妙的理論在實踐中都會碰到這樣那樣的問題, 下面是一些例子:

      第一步:

      各個需求和任務之間是有種種復雜的依賴關系的,除了優先級之外, 我們還要考慮相互的依賴關系。怎樣在計劃中表現依賴關系呢?

      第二步:

      如果團隊成員對某個任務不感興趣, 都不認領這個任務怎么辦?

      有些成員的認領的任務很多, 有些成員認領的任務很少, 忙閑不均, 怎么辦?

      第三步:

      每日例會 (SCRUM Meeting)看起來很爽:

      我昨天做了啥

      我今天要做啥

      我碰到了哪些問題

      爽了之后, 也許會流于形式。 我們想象一幫狗熊開Scrum 會議的時候, 大家的發言是:

      我昨天掰棒子

      我今天繼續掰棒子

      我沒碰到困難

      這樣的會議有用么? 也許昨天掰的棒子沒處理, 今天就掰另一個棒子去了, 明天又來一個新棒子…

      一群狗熊級的程序員會這么說:

      我昨天寫代碼

      我今天繼續寫

      我沒碰到困難

      每天這么寫代碼, 我們離完沖刺的終點線到底是更近了, 還是更遠了? 如果流于形式, 無論多么敏捷的Scrum 每日立會也會被忽悠, 請看學生們的一個忽悠例子.

      一個改進是, 定義好任務究竟是什么? 任務的完成 (done) 到底意味著什么? 每個人的任務必須是明確定義的, 狗熊們不能籠統地說, 我在掰棒子, 而是要說明標號為123 的棒子現在是什么狀態, 你做好之后交給誰了。

      另一個改進是, 要在每一個任務中記載我們完成這個任務還需要多少時間。已經花了多少時間雖然重要, 但是不是關鍵 (那是沉沒成本),關鍵是要看我們離最后目標有多遠。 就像某部門展覽“反腐成果”, 給群眾看 “已經抓出來N 個腐敗分子”固然解恨, 但關鍵還是 ”還剩多少在臺上“,這個問題不說明, 再抓20個, 30個都不解決問題。

      沖刺到一半的時候, 產品負責人突然發現要做馬上重要的改動! 或者某個大佬要看某個不在計劃中的功能的演示, 怎么辦? 這種情況非??简?SCRUM MASTER. 如果一個運動員在跑一百米沖刺, 但是跑到一半的時候,領導突然想看一百一十米欄的比賽, 前面馬上會擺起欄架, 大家要準備8步上欄! 怎么辦?

      一個有正常頭腦的運動員和教練員會說: 去你的, 要改主意, 也要等到老子沖刺完了再說啊!

      關于每日立會 - 如果團隊成員不在同一個地方, 怎么開會呢? 我聽到一些敏捷的專家說, 一個團隊的成員必須面對面開會, 才有效果。

      Ken Schwaber 說: I also recommended eliminating all of the development artifacts – like design documents… Scrum relies on high-bandwidth, face-to-face communication and teamwork; cubicles and unneeded artifacts promote isolation and misunderstandings. [Agile Project Management With Scrum, Page 103]

    原文轉自:http://www.kjueaiud.com

    老湿亚洲永久精品ww47香蕉图片_日韩欧美中文字幕北美法律_国产AV永久无码天堂影院_久久婷婷综合色丁香五月

  • <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>