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庫，由於以前並沒有接觸過mock的概念，而且對於涉及到Web的測試並不熟悉，所以並沒有隨着開發進行單元測試，導致開發基本完成的時候，很多WebAPI前端無法正常調用； - 集成測試，由於單元測試有一些局限性，比如單元測試使用的
SQLite.InMemory數據庫，無法再插入時自動更新創建時間和修改時間，比如某些配置服務器的代碼無法進行單元測試，某些工作於響應的pipline的中間件無法進行單元測試； - 關於WebAPI的文檔，為了方便查看其改動，而將其放在單獨的分支來進行，Alpha階段評審會議的時候，看到其他組通過Wiki功能來方便查看WebAPI文檔，我認為是一種值得嘗試的方式；