第二週心得總結

本週主要重複進行 PBI 的心得分享與評分,可以感受到大家參與的熱度。

透過這樣的心得分享,可以讓大家得知其他人在做什麼,也順便更新了目前團隊所進行的項目有哪些。另外也強調團隊整體的榮辱與共,每個項目也許不是所有人都投入,但是還是必須要分享給其他人。目前會以兩個方向為主:

  1. 維護的項目:以KANBAN 的方式進行,不區分SRPINT,直接透過 BACKLOG BOARD 區分 APPROVED、COMMITED & DONE。這裡的目的在於將重要的維護項目也納入,如此就可以讓每個人都自行規劃進度,降低PM的工作量。此外一個重點再於維護項目一班都是一個人負責到底,因此TASK的拆分相對而言不是那麼重要(畢竟把事情完成即可);因此直接將PBI指定給成員會是比較簡單的作法。
  2. 專案:此部分就會按照標準的SCRUM進行

上述無論哪一個,都會採用PBI的方式進行。

此外,也介紹的VSTS關於 SCRUM 的整合方式,包含:PBI 建立、TASK建立、CAPACITY、SPRINT 定義。可以看出來大家還是很有興趣的,目前還再請成員各自研究,主要重點放在PM是否熟悉操作方式,此部分單獨指導即可,只要由上而下,自然就惠普及,不用太過於浪費時間全體教育。

下週要安排GIT的操作說明,讓現有維護專案可以直接匯入,整合WORK ITEM,發輝VSTS的效益。目標還是要走向完整的 DEVOPS。

建立一個 SCRUM Team:第二週

一個好的 SCRUM團隊,最基本的任務就是要能夠凝聚對於 PRODUCT BACKLOG 的評分依據,如此才能有後續依據。因此本周持續進行 Story Point Estimation。作法是個別成員報告已經完成的PB,需要描述完成哪些內容,以及評估的分數,然後再用新的要進行的PB進行團體評估。

此外主要重點在於介紹 VSTS,針對上週所提出的PB,填寫 PRODUCT BACKLOG,並且進行工作拆分(TASK),與指派同仁進行。具體介紹的內容如下:

  • 介紹 WORK 的項目與對應的內容:說明如何建立 PRODUCT BACKLOG ITEM 並說明 EFFORT 等同 STORY POINT ESTIMATION。與 PRODUCT BACKLOG 的優先序是由上而下,可藉由拖拉方式說明。
  • 介紹 TASK、ASSIGN & REMAINING WORK(等同工時)的定義
  • 介紹 SRPINT、ITERATION(定義兩週)、CAPACITY 的定義
  • 用測試專案實際操作給同仁參考,與練習

 

本週就會開始使用 VSTS 進行專案管理,因此主要的 PRODUCT OWNER 可個別教學。

第一周心得總結

完成的定義團隊討論的還不錯,每個人都有貢獻自己的意見與心得;最終也彙整出大家接受的目標。接下來就會將之放在 A3 紙上,並且用保力龍掛在辦公室後方,提醒自己,也讓其他單位知道資訊需求有哪些需要處理的項目。

至於 Story Point Estimation,事先準備 3, 5, 8, 13 這四個案例給大家參考,但可以看得出來不是每一個人都瞭解案例內容,因此評估分數比想像中高。不過還是要接受群眾的智慧,不堅持己見、不說服他人我想是推動的基礎。

下週會有兩個方式:

  1. 定義大家每天可以投入的時間
  2. 預估 story point 與時間的關係(可能要拆到 details,但也是依靠眾人力量)
  3. 再加上一個案例分享,這次則是大家評估,並且用來連結時間的關係

建立一個 SCRUM Team:第一週

目標一、定義什麼是完成!

一個SCRUM團隊,必須要有最基本的針對什麼是 PBI (項目:Product Backlog Item) 「完成的定義」

  1. 團隊共識什麼叫做完成
  2. 讓其他人知道完成一個小需求要做的事是很多的,而不是一下就好了
  3. 將完成的目標放入到 Product Backlog
  4. 將他寫在 A3 的紙上,貼在團隊後方,讓每一個來訪的人都可以看到
組織團隊會議,針對問題:『一個需求完成我們必須要做』,提出每個人的意見與整個團隊的共識
  • 開發:
    • 先撰寫單元測試
    • 50% 的程式碼都有單元測試涵蓋
    • 可以正常編譯,並且通過單元測試
    • 程式碼已經被內入到 main master
    • 測試資料庫的 Table Schema 已經被納入到正式資料庫
    • 程式碼有被其他人檢查是否撰寫OK
  • 測試、發佈、運營
    • 有QA測試計畫
    • QA測試計畫被其他人檢視確認正確
    • 在測試環境發佈與測試完成
    • 有撰寫自動UI測試並且通過
    • 少於一到兩個嚴重的BUG
    • 有明確的驗收標準,並且被專案經理審視過
    • 部署計畫有被運營單位確認
    • 正確發佈到正式區

目標二、討論什麼是速度

用 Story Point 分析每個項目的得分,請注意,這裡的分數是代表整個團隊投入需要的工作,並且項目的完成必須要滿足上面的「完成的定義」

作法:將目前手上的項目提出,用之前我們完成項目的經驗,再給定每一個項目分數。每個人可以用以下的分數給分:

接下來,進行討論會議:
1. 提出一個 Story Point = 5 的需求A,描述這個需求A要做哪些工作
2. 在舉範例需求B,描述需求B工作,為什麼比需求A大,再描述需求C與為什麼比需求A小
3. 在拿出目前的工作項目,讓團隊成員每個人決定這個需求分數
4. 請最大跟最小分數的人說明原因
5. 在重複團隊決定分數
直到大家都趨近一個數字即可停止。

解決 EF Core 2.0 當呼叫 Add-Migraion 會出現無法產生的錯誤

EF Core 2.0 執行 Add-Migration 會出現錯誤:

  PM> Add-Migration InitialCreation
Unable to create an object of type 'OrderContext'. Add an implementation of 'IDesignTimeDbContextFactory<OrderContext>' to the project, or see https://go.microsoft.com/fwlink/?linkid=851728 for additional patterns supported at design time.

這是因為 EF Core 2.0 有改變 Tools 的作法,在 Asp.net
core
最佳的解法是:

WebHost.CreateDefaultBuilder(args)

如果是 Console program,可以用 emtpy constructor 的方式:

public class OrderContext : DbContext
{
    public OrderContext() { }
    public OrderContext(DbContextOptions<OrderContext> options) : base(options) { }
    public DbSet<OrderProcess> OrderProcesses { get; set; }
 
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlServer(@"Server=(localdb)\MSSQLLocalDB;Database=Msmtest;Trusted_Connection=True;");
    }
}

重點在於 OnConfiguring 加上指定的 SqlServer connection。一旦產生 Migration 之後,就可以將
empty constructor comment
掉(因為可能會影響程式的正常邏輯)。