月份：十月 2017

第二週心得總結

本週主要重複進行 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 掉（因為可能會影響程式的正常邏輯）。