專案開發速度看似遠超出預期，但實際並不。並不是說issues沒有按時完成，而是缺少了應用測試的一步。可以理解為：骨架都有了，但血和肉太少。這一點是我作為pm有所失職的地方，我並沒有正確的估計任務量，或是正確的安排issue。
也正是因為前期專注於搭建骨架，我們低估了新增血和肉的成本。這一點集中體現於「引入真實知識問答資料庫」後，各類文字渲染的問題。同樣，作為pm我應該對此負主要責任，團隊成員之間的交流溝通太少，這一點需要在beta階段加強。pm也需要在beta階段開始前，對專案做更加具體的規劃。
前端作為使用者體驗的最重要保障，在alpha階段的工作並不讓人滿意。主要原因在於，我們並沒有在設計階段對前端進行完整地、細節地設計，而只是想象了乙個大體的框架。這導致，前端似乎可以很快完成框架，但是使用者體驗並不好。我們在beta階段會重視這一點。
我們達到目標了麼（原計畫的功能做到了幾個？ 按照原計畫交付時間交付了麼？ 原計畫達到的使用者數量達到了麼?)
對於後端，原先的問答流程設計是使用者先問問題，然後我們嘗試為他解決，並進行相關引導。但在實現的過程中由於初期後端需要完成較多其他工作，導致這一部分核心功能所分到的時間就比較有限，在比較有限的時間下，對於初期設想的流程，很多地方就沒精力實現，導致最後完成的問答是基於設計好的給定流程進行的，這就導致了問題範圍的縮小以及使用者體驗上的不佳。
利用nlp模型進行對話的功能本來是最重要的功能，但是卻被放進了「緩衝區」裡，作為有餘力再進行的任務，而先實現了詳盡的其餘功能，如精確的資料層報錯、完整分層次的日誌記錄、資料層的高併發控制等等。這樣安排任務順序的時候，考慮的是這一部分功能是前端展示資料所必須的資料來源，盡早實現有助於前端進行開發，但目前看來並沒有達到這樣的效果，但卻導致了alpha階段的產品特色不足，使用者體驗很糟糕；
使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
這一點其實和上一點相關，由於功能實現的差異，所以使用者較低的接受程度也是有所預期的。儘管核心的功能實現上確實有點遺憾，但就目前的狀態來說，後端的其他功能已經實現的差不多了，在之後的過程中我們可以更關注於核心功能的實現。所以總體上還是更接近目標了。
團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
大部分就後端來說，由於兩個人平時住的比較近，所以在設計上如果有任何問題都第一時間進行商量討論出乙個兩個人都能接受的結果。
你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
如果只是看初期規劃的issue，後端同學大致完成了自己分配到的任務。當然，現在看來這個規劃對於機械人問答這一核心功能涉及的很少，這就導致了目前其功能還需在整體上做較大的改進。
是否每一項任務都有清楚定義和衡量的交付件?
由於在初期就對整體專案框架有所設計，所以每一項任務基本對應到了要實現的某乙個功能，也就對應到了框架中要實現的某一**部分。
是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
雖然看起來整個專案都在按著計畫進行，但從最後的結果也可以看出，得到的效果並不是特別好，所以必然是其**現了一些問題。
就後端來說，我認為大致有以下幾點：
將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
關於使用者反饋，我們得到的大多數資訊與使用者體驗有關。團隊將在beta階段著眼於ui設計和使用者體驗上，這一部分的重心將在前端。而對於後端，我們將完善問答社群的功能，提公升整體產品功能豐富度和使用者體驗。將nlp技術引入到問答機械人中，可以讓問答機械人更加高效而準確的查詢資訊，從而反饋更為精確的回答。
我們有足夠的資源來完成各項任務麼?
就後端的普通功能，我們實現起來確實沒什麼困難。但對於關鍵的機械人問答部分，要達到預期的效果的困難程度要比之前想的大的多。
測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
目前來看，在給定的時間內要完成完善的開發與測試確實有點困難了。甚至在後期我們還在糾結於完成測試，現在想來這部分時間不如投入到開發機械人相關的功能上（就我個人來說）。
後端在初期就做了比較詳細的規劃，所以整個開發過程基本上就是按照初期的規劃進行的，即使在開發的過程中遇到了一些困難也基本上能按照進度完成任務。對於beta階段，仍然希望能夠在事先做好詳細規劃的情況下，按照規劃來完成任務。
後端的溝通交流也比較頻繁。由於後端是兩個人共同進行開發，即使每個人都分配到了不同任務，但在任務中也有大量對接，所以經常需要進行溝通交流。經常溝通交流帶來的好處就是每個人都對整個後端目前的情況都有所了解，能為不斷的開發打好基礎，弄清方向。
從目前的結果來看，後端需要調整的地方就是開發的重點，即我們需要專注於機械人問答部分的實現。但這個轉變其實是注定的，因為alpha階段被後端其他功能所拖累，導致在這個功能上的花費的精力就比較小，而經過alpha階段，我們已經把其他大部分功能都實現完了，所以在beta階段可以專注於機械人功能的完善。
與前端人員的溝通。在alpha階段，雖然與前端人員保持了一定程度上的溝通，但基本侷限於介面上的對接，導致我們實際上對於前端的進度並不是特別了解。希望能在beta階段多進行些溝通，推動前端的效果能夠得到完善。
開發順序上，這次選擇了先開發上層模組，同時確定下層模組的介面，然後在根據介面開發下層模組，即先完成呼叫者和被呼叫者的介面，然後完成被呼叫者的實現。這樣導致了乙個問題：在實現被呼叫者的之前，往往無法考慮完全被呼叫者可能需要丟擲怎樣的異常，而實現被呼叫者的時候，才發現有些狀態下無法完成任務，必須通過異常或其它方式來通知上層，尤其是涉及資料庫的時候，這種情況尤甚。但是由上至下的開發順序也帶來了一定好處：由於先確定了呼叫方如何使用這些函式，先確定了這些函式的行為，再進行實現時，一方面不會做無用功，實現一些不會被使用到的功能，一方面也減少了後續再增加介面的情況。因此，我任務由上至下的開發順序值得保留，但是開發被呼叫者的時候，如果新添了可能丟擲的異常，應當記錄下來，以便篩查，而不是直接修改介面類；
單元測試方面，由於測試需要學習建立mock物件的moq庫，由於以前並沒有接觸過mock的概念，而且對於涉及到web的測試並不熟悉，所以並沒有隨著開發進行單元測試，導致開發基本完成的時候，很多webapi前端無法正常呼叫；
整合測試，由於單元測試有一些侷限性，比如單元測試使用的sqlite.inmemory資料庫，無法再插入時自動更新建立時間和修改時間，比如某些配置伺服器的**無法進行單元測試，某些工作於響應的pipline的中介軟體無法進行單元測試；
關於webapi的文件，為了方便檢視其改動，而將其放在單獨的分支來進行，alpha階段評審會議的時候，看到其他組通過wiki功能來方便檢視webapi文件，我認為是一種值得嘗試的方式；
AiApe問答機械人Alpha階段團隊評分結果
盪起雙槳團隊貢獻度評分規則 自評得分細則 團隊成員 貢獻度得分 測試貢獻度得分 專案討論參與度得分 團隊事務管理貢獻度得分 鄧新宇10103 2李明昕66 76董俊傑834 1黃思為81 83黎昊軒147 12楊巨集博 無評分無評分 無評分無評分 互評得分細則 互評成員 評價成員 專案參與度得分 合...
智慧型問答機械人概述
處理邏輯 query 中控邏輯 response 指特定條件下提供資訊或服務的機械人。任務型機械人核心模組主要包括三部分 自然語言理解模組 language understanding 對話管理模組 dialog management 自然語言生成模組 natural language genera...
問答機械人介紹1
知道問答機械人是什麼 知道問答機械人實現的邏輯 在前面的課程中，我們已經對問答機械人介紹過，這裡的問答機械人是我們在分類之後，對特定問題進行回答的一種機械人。至於回答的問題的型別，取決於我們的語料。當前我們需要實現的問答機械人是乙個回答程式語言 比如python是什麼，python難麼等 相關問題的...