顯示具有 scrum 標籤的文章。 顯示所有文章
顯示具有 scrum 標籤的文章。 顯示所有文章

2015年11月27日 星期五

[筆記]Scrum軟體開發速成 THE ELEMENTS OF SCRUM(一)

Product Owner
            1.負責待辦清單
                        1.1  待辦清單來源自,另一份按優先順序排序的清單
      1.2  內容包括 新特性/錯誤修復

   2.Index Card
                        2.1 內容記錄,記錄待辦清單中的特性,一張只記錄一個特性。這些特性稱為 
        User stories。
      2.2 User stories:由團隊成員逐一討論,確認其驗收標準,與故事的完成的模
             樣,團隊成員並討論,要完成這些故事,要做那些工作,有那
             些類型,有多少工作量。若有不清楚的故事,可以排除在當次
             的sprint。

             3.Daily Scrum每日站立會議:團隊成員輪流分享資訊。前一天完成了什麼工作;今天
                                                               打算完成什麼工作;有沒有碰到什麼障礙或問題。

             4.清單整修會議:對產品待辦清單上的故事,進行再次討論並對故事內容有疑慮的地
                                           方再確認。包含故事點的計算及故事的拆解。

Scrum角色:
   1. 產品負責人:唯一有權要求團隊做事及改變待辧清單優先順序的人。
      1.1 掌握產品願景
      1.2    代表業務
      1.3 代表客戶
      1.4 持有產品待辦清單
      1.5 劃定故事優先順序
      1.6 設定故事驗收標準
      1.7 有空回答團隊成員們的問題

   2. scrum master:引領團隊達到更高級的凝聚力,自我組織和表現。團隊的交付物是產
                                        品,而scrum master的交付物是自我組織的團隊。scrum master不是團隊
                                        的老闆僅限於透過影響力所得的領導力。引導scrum會議,幫助團隊理
                                        解和使用scrum的產出物。另一個關鍵作用是替團隊掃除障礙。
      2.1 scrum專家和諌言者。
      2.2 教練
      2.3 障礙移除者
      2.4 引導者


   3.團隊成員:
                        3.1 團隊成員可以全權決定如何完成工作,也可決定要使用的工具和技術。
      3.2 負責估計實現特性需要的工作量。
      3.3 順序由產品負責人決定,完成特性或工作需要多少時間,由團隊成員決
        定。
      3.4 負責交付使用者故事。

Sprint週期
                               
            1.一個Sprint通常為兩週,通常不會超過四週。初期scrum團隊會設成一週,以精練 
     scrum技巧。      
Sprint的各種會議
   2.Sprint規劃會議:Sprint規劃會議代表著Sprint的開始,區分兩部份,第一部份目標
    是,團隊要選擇一組交付物作為目前Sprint的承諾。第二部份,團隊要羅列出交付
    使用者故事(交付物)所需完成的所有工作。
       
                         2.1 第一部份[要做什麼?]:團隊成員與產品責人討論所有的故事(交付物),
        及各故事的驗收標準。團隊成員協商解決各故事依懶性問題,並討論實現
        故事要做那些工作。

      2.2第二部份[要怎麼做?]:團隊把選定的故事(交付物)分解成,所需要執行
        的工作。討論的過程中產品負責人要全程在場,以便回答問題。
   
   3.每日站立會議:開會時間不應該超過15分鐘,快速分享前日已經完成內容,並報告
           預計完成的內容。

   4.故事時間(清單整修會議):也有人稱作[清單稱修]會議,重新檢視清單中,未完
                 成的故事,是否需要在拆解成更小的故事,或故事有
                 不清楚的要重新理解,目的在於,要保持清單中,隨
                 時都要有一小批,已被充份理解的小故事
    
    5.Sprint檢視:也稱作Sprint Demo,目的在於展示,團隊成員的工作成果,可以邀請
         Product Own,也可以邀利害關係人一同參加。會議長度依1週的sprint約
         莫1小時為基礎。Product Own及團隊成員,可以收集會議中的回饋,當作
         之後Sprint的故事。

   6.自省會議:自省會議在每個sprint的最後才召開,目的是為了幫助團隊持續地進行檢
         驗和調整,希望能升提績效幸福感。每個開發週期以1~2小時的比
         例進行安排,最多不要超過3小時。自省議程如下:
        
       6.1 準備階段:這階段重視[建主共同的目標],讓團隊了解開會的目的,
              是為了團隊提升,而不是個人的檢討。

       6.2 收集資料:在sprint中發生了什麼。可以利用開會技巧幫助團隊,以保持
              思路清晰且不偏主題。

       6.3 洞察問題:這階段重視[為什麼],找出問題發生的原因,過程中不聚
              焦在人,而是在問題本身

                            6.4 確定方案:自省會議的問題也許有很多,最好的辦法是,一次自省會議
              ,只決解一個問題。

       6.5 結束:用感謝來當作結束,讓成員說出在sprint中可以感謝的人事物,
            可以讓團隊更加團結。

Sprint 的異常終結:在正常的Sprint中,管理層不會要求,改變需求。異常終止通常發生在外部因素。在終結前若還有可交付部份,則還是可以做Sprint Demo及自省會議,由其自省會議對異常終結Sprint來說尤其重要。


































2013年11月1日 星期五

[Scrum]102.11.1 Scrum vs Saas 課後心得筆記

相片:大受歡迎的Scrum敏捷專家講座【台北場】又將登場,歡迎報名参加!! 點我線上報名:http://tinyurl.com/mna6njh
(因分會人手有限,恕無法接受現場報名參加)

講座Topic:
魚與熊掌不可兼得? – 當Scrum遇上SaaS

講座 Agenda:

1. Why Agile?
►以實際專案開發為例,說明選擇敏捷開發的原因

2. Huston, we have a problem !
在開發過程中,團隊面臨了許多的挑戰與問題:
►如何帶領團隊在短時間內學習敏捷開發模式,以期達成目標?
►在開發過程中,如何保持團隊的機動性與執行力,並且能有效地持續改進缺失?
►如何兼顧開發速度以及產品品質?
►如何轉型從產品開發到SaaS服務提供團隊?

3. Lesson learned
►兩年的專案開發過程中所學習到的經驗分享

Scrum敏捷專家介紹
趨勢科技 資深研發經理
張玉潔  PMP, CSM

時間: 11/01(五) 19:00~21:00
地點: 臺灣金融研訓院(台北市羅斯福路三段62號5樓)
費用: 300元(可申請2PDU)

※
1.本系列活動為限額付費講座,以報名繳費優先順序為主,40席額滿為止。
2.本系列活動前一週將以email寄發行前通知,任何活動注意事項將以email通知信中說明,請務必正確填寫可收件之e-mail地址。
3.本系列活動採自由入座,18:30開放入場,敬請提前或準時報到入場。

※因座位名額僅有40席,報名参加學員請於接獲主辦單位通知報名成功後再行繳費。

*主辦單位保有修改時間地點、活動議程內容、講師異動及報名篩選之權利,最新異動訊息請以台灣分會活動網頁公告為主。

1.Phase包含:
     a.Design (RD/QA)
     b.coding (RD)
     c.Function Test (RD)
     d.Integration Test (QA)


2.實際運作:
  抽1/3的team member(Seal team)做下一個Sprint 的study,如果可行才導入正式的開發流程由army tema接手,1/3的Seal team成員為隨之轉為army team,再從上一個Sprint中army team的成員挑選下一個Sprint的Seal team.

3.Scrum需要的人格特質:
  a.快速學習
        b.主動積極

4.每個Scrum team都有自已的best Practice,別人的best Practice不一定會是自已的best Practice.

5.當不適任的人開始影響其他team member時則要,當機立機斬立決,但砍人之前要給機會,並說明問題,若真的沒有改進才能砍。

6.User Story format
  作為一個 (某個角色) 使用者,我可以做 (某個功能) 事情,如此可以有 (某個商業價值) 的好處。
As a (role of user), I want (some feature) so that (some business value).
  {自動沖水器}:{使用者}離開{感應範圍}後,會{自動沖水}。