Alpha階段事後總結
總體
項目開發速度看似遠超出預期，但實際并不。并不是說issues沒有按時完成，而是缺少了應用測試的一步。可以了解為：骨架都有了，但血和肉太少。這一點是我作為PM有所失職的地方，我并沒有正确的估計任務量，或是正确的安排issue。
也正是因為前期專注于搭建骨架，我們低估了添加血和肉的成本。這一點集中展現于“引入真實知識問答資料庫”後，各類文本渲染的問題。同樣，作為PM我應該對此負主要責任，團隊成員之間的交流溝通太少，這一點需要在Beta階段加強。PM也需要在Beta階段開始前，對項目做更加具體的規劃。
前端作為使用者體驗的最重要保障，在Alpha階段的工作并不讓人滿意。主要原因在于，我們并沒有在設計階段對前端進行完整地、細節地設計，而隻是想象了一個大體的架構。這導緻，前端似乎可以很快完成架構，但是使用者體驗并不好。我們在Beta階段會重視這一點。
設想和目标
我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)
對于後端，原先的問答流程設計是使用者先問問題，然後我們嘗試為他解決，并進行相關引導。但在實作的過程中由于初期後端需要完成較多其他工作，導緻這一部分核心功能所分到的時間就比較有限，在比較有限的時間下，對于初期設想的流程，很多地方就沒精力實作，導緻最後完成的問答是基于設計好的給定流程進行的，這就導緻了問題範圍的縮小以及使用者體驗上的不佳。
利用NLP模型進行對話
的功能本來是最重要的功能，但是卻被放進了“緩沖區”裡，作為有餘力再進行的任務，而先實作了詳盡的其餘功能，如精确的資料層報錯、完整分層次的日志記錄、資料層的高并發控制等等。這樣安排任務順序的時候，考慮的是這一部分功能是前端展示資料所必須的資料源，盡早實作有助于前端進行開發，但目前看來并沒有達到這樣的效果，但卻導緻了Alpha階段的産品特色不足，使用者體驗很糟糕；
使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
這一點其實和上一點相關，由于功能實作的差異，是以使用者較低的接受程度也是有所預期的。盡管核心的功能實作上确實有點遺憾，但就目前的狀态來說，後端的其他功能已經實作的差不多了，在之後的過程中我們可以更關注于核心功能的實作。是以總體上還是更接近目标了。
計劃
團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
大部分
就後端來說，由于兩個人平時住的比較近，是以在設計上如果有任何問題都第一時間進行商量讨論出一個兩個人都能接受的結果。
你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
如果隻是看初期規劃的issue，後端同學大緻完成了自己配置設定到的任務。當然，現在看來這個規劃對于機器人問答這一核心功能涉及的很少，這就導緻了目前其功能還需在整體上做較大的改進。
是否每一項任務都有清楚定義和衡量的傳遞件?
由于在初期就對整體項目架構有所設計，是以每一項任務基本對應到了要實作的某一個功能，也就對應到了架構中要實作的某一代碼部分。
是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
雖然看起來整個項目都在按着計劃進行，但從最後的結果也可以看出，得到的效果并不是特别好，是以必然是其中出現了一些問題。
就後端來說，我認為大緻有以下幾點：
- alpha階段受後端精力有限、任務較多的影響，再加上我們對任務的重要性估計有誤，導緻了真正關鍵的功能沒有得到很完善的實作。
- 後端與前端的交流不夠充分。一開始我們是認為隻要前後端對接的接口實作好了，就可以各自幹各自的活，但就目前的情況來說，前端實作的内容與設想有所出入，說明确實需要更深入的進行交流。
将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
關于使用者回報，我們得到的大多數資訊與使用者體驗有關。團隊将在Beta階段着眼于UI設計和使用者體驗上，這一部分的重心将在前端。而對于後端，我們将完善問答社群的功能，提升整體産品功能豐富度和使用者體驗。将NLP技術引入到問答機器人中，可以讓問答機器人更加高效而準确的查找資訊，進而回報更為精确的回答。
資源
我們有足夠的資源來完成各項任務麼?
就後端的普通功能，我們實作起來确實沒什麼困難。但對于關鍵的機器人問答部分，要達到預期的效果的困難程度要比之前想的大的多。
測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
目前來看，在給定的時間内要完成完善的開發與測試确實有點困難了。甚至在後期我們還在糾結于完成測試，現在想來這部分時間不如投入到開發機器人相關的功能上（就我個人來說）。
做的還行的地方
- 後端在初期就做了比較詳細的規劃，是以整個開發過程基本上就是按照初期的規劃進行的，即使在開發的過程中遇到了一些困難也基本上能按照進度完成任務。對于Beta階段，仍然希望能夠在事先做好詳細規劃的情況下，按照規劃來完成任務。
- 後端的溝通交流也比較頻繁。由于後端是兩個人共同進行開發，即使每個人都配置設定到了不同任務，但在任務中也有大量對接，是以經常需要進行溝通交流。經常溝通交流帶來的好處就是每個人都對整個後端目前的情況都有所了解，能為不斷的開發打好基礎，弄清方向。
需要改進的地方
- 從目前的結果來看，後端需要調整的地方就是開發的重點，即我們需要專注于機器人問答部分的實作。但這個轉變其實是注定的，因為alpha階段被後端其他功能所拖累，導緻在這個功能上的花費的精力就比較小，而經過alpha階段，我們已經把其他大部分功能都實作完了，是以在beta階段可以專注于機器人功能的完善。
- 與前端人員的溝通。在alpha階段，雖然與前端人員保持了一定程度上的溝通，但基本局限于接口上的對接，導緻我們實際上對于前端的進度并不是特别了解。希望能在beta階段多進行些溝通，推動前端的效果能夠得到完善。
- 開發順序上，這次選擇了先開發上層子產品，同時确定下層子產品的接口，然後在根據接口開發下層子產品，即先完成調用者和被調用者的接口，然後完成被調用者的實作。這樣導緻了一個問題：在實作被調用者的之前，往往無法考慮完全被調用者可能需要抛出怎樣的異常，而實作被調用者的時候，才發現有些狀态下無法完成任務，必須通過異常或其它方式來通知上層，尤其是涉及資料庫的時候，這種情況尤甚。但是由上至下的開發順序也帶來了一定好處：由于先确定了調用方如何使用這些函數，先确定了這些函數的行為，再進行實作時，一方面不會做無用功，實作一些不會被使用到的功能，一方面也減少了後續再增加接口的情況。是以，我任務由上至下的開發順序值得保留，但是開發被調用者的時候，如果新添了可能抛出的異常，應當記錄下來，以便篩查，而不是直接修改接口類；
- 單元測試方面，由于測試需要學習建立Mock對象的
Moq
- 內建測試，由于單元測試有一些局限性，比如單元測試使用的
SQLite.InMemory
- 關于WebAPI的文檔，為了友善檢視其改動，而将其放在單獨的分支來進行，Alpha階段評審會議的時候，看到其他組通過Wiki功能來友善檢視WebAPI文檔，我認為是一種值得嘗試的方式；