對聯組項目管理 - 過後諸葛亮會議

項目網址：https://poempicture.azurewebsites.net/index
demo錄屏：錄屏網址
成員得分：

設想和目標

咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？

解決的問題和定義請查看本網址當時對於典型場景、用戶定位和需求都有比較清晰的認識，所制定的基礎功能和殺手功能到如今來看都是比較準確的。

咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)

alpha階段的話還算是基本完成目標了。本來制定的功能完成了對聯和古詩創做兩個核心功能，對人臉做詩也基本走完了流程，可是服務器上只整合了對聯和古詩的功能，並且根據負責server的同窗報告，由於azure的限制和比較差的硬件，咱們一次只能開一個模型，對聯或者古詩。按照原計劃時間交付了。如今除了咱們組和另外一個對聯組同窗的使用，尚未其餘使用用戶。

和上一個階段相比，團隊軟件工程的質量提升了麼？ 在什麼地方有提升，具體提升了多少，如何衡量的？

這是第一個版本。略過

用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?

就如今的運行速度來講，沒人可以接受。離目標最少還差一個架構師。其次還差能大改模型的人。

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

單就此部分，設想和目標來講的話，仍是比較成功的，基礎功能和以後的殺手功能或者拓展輔助功能的設定仍是比較有指導意義的，用戶定位如今看起來也還算合理。教訓也有一個致命的，就是功能太多，就咱們能租的起的服務器來講，根本不可能完成徹底，就算能跑在服務器上，也徹底不可能支持大規模訪問，不過做爲設想，是指導咱們的，真正完成哪些功能，是根據實際狀況來完成設想的指導的；所以設想目標還算成功。

計劃

是否有充足的時間來作計劃?

有不少時間能夠用來作計劃，可是因爲咱們都沒有太小組的項目經歷，所以實際上作起來以前，很難說在項目開始以前就準確地知道具體的任務該作什麼和任務量。因此咱們把alpha又分爲了前半階段和後半階段。前半階段仍是摸石頭過河，所以是兩人一個小組，每一個小組一個任務主題，邊探索邊肯定任務量，在初期就有一個用於參考的ddl，可是很靈活，根據每小組真實的進度來更改。請參考alpha第一階段計劃。而到了真正作起來，小組步入正軌以後，PM對於項目的理解、進度的把控到了一個熟悉的階段以後，則能夠制定到每一個人天天該作什麼的詳細計劃，而不是粗糙的參考ddl。請參考alpha後五天計劃

團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？

第一階段摸石頭過河，PM根據每一個人的興趣肯定的小組和小組任務，並分配了小組參考ddl階段的任務目標，每一個小組的目標、任務量都是由小組進行起來以後自行確認而且和PM溝通的；即PM定大方向，小組組員確認詳細計劃。第二階段則是由PM制定到每一個人，並在任務開始前詢問組員對於計劃的意見進行修改，而且在進行起來以後確認了組員的真實進度後進行調整。

你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

基本作完。基本作完和徹底作完之間的gap：好比人臉做詩，服務器上已經不容許咱們跑更多的模型了；生成詩和對聯的質量都不理想；tag到詞典的處理不理想；server的代碼質量和處理方法不理想等等。直接緣由在於PM不敢佔用你們太多時間，做太push的要求；PM管理經驗不足，沒有能夠合理管理進度（確保組員接受到任務、確保組員完成任務）的方法；須要有一個備忘錄好比GitHub issue，每人天天都查看；根本緣由在於，一，你們太忙了，抽不出足夠的時間在這個工做上，所以好比模型太差（包含生成效果差和模型太大跑得慢），不會有從新推翻找新的模型的動力；二，咱們組組員的coding能力都比較差，項目經驗幾乎沒有，因此分工了以後每一個模塊的解決手段比較簡單粗暴，代碼水平也比較低，不過這一點在PM看來不是什麼大問題，原本也是來學習軟件工程的，有什麼水平寫什麼代碼，徹底能夠接受。

有沒有發現你作了一些過後看來不必或沒多大價值的事?

沒有

是否每一項任務都有清楚定義和衡量的交付件?

如今看起來這是PM作的比較差可是很開就意識到開始解決的一個問題。在摸石頭過河階段，沒法定義清楚很是清楚的定義和衡量的交付件是能夠理解的。在alpha第二階段，已經安排到我的任務和具體的工做任務，可是因爲沒有「清楚的定義」和「衡量的交付件」，PM遇到了不少問題。好比需求是訓練一個模型，可能真的會訓完就職務結束了，dev不會自覺地 去嘗試跑一下各個輸入有沒有合適的輸出，等PM意識到須要額外指派任務纔會有人作這個事的時候，發現了問題須要解決就已經嚴重拖累進度了。因此第二階段第三天起就開始把任務定義成「作完並交接給xxx而且跑通才算完成」、「訓練完使用一下觀察tag生成文本的結果沒有嚴重問題纔算完成」等等

是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?

有很多意外。意外大大小小的都有。小意外好比，須要某同窗完成某功能，並與下一個同窗交接，該同窗則完成了該代碼就丟在一遍或者push到repo上就無論了，而PM詢問工做進度時該同窗會彙報已作完。可是PM讓負責server整合的同窗做demo的時候卻發現整合同窗根本沒有接到過這份代碼，致使拖累項目進度的意外。這個狀況不止出現過在一我的身上，也不止一次。所以從該階段第兩三天開始，PM開始陪着每一個同窗寫代碼而且督促交接，今後開始任務才得以解決。再好比，有的同窗沒有該任務的經驗，完成不了任務卻不告訴PM，有的同窗任務沒有完成或者還存在問題就告訴PM已經完成了當天進度，出現了大問題卻瞞着不告訴PM，等到PM發現某進度嚴重出現問題時纔開始解決，最終拖累了項目進度。不過好的是晚些你們仍然是比較坦誠的，忽然發現了error可能會遲一些，可是必定會彙報error，而後一塊兒解決。大的意外好比上週出現的開除組員狀況，由於上週上課已經詳細討論過了，略過不提。

在計劃中有沒有留下緩衝區，緩衝區有做用麼?

有留緩衝區。緩衝區很是重要。能夠保證進度的連續性，不會由於不少風險的產生就最終使項目失敗

未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

詳細到定義好每一個人的天天的Input，output，作到哪一步，能跑成什麼樣算完成。緩衝期設計到20%。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

千萬不能設計定性的任務和模糊的任務，要精確到每個可執行的步驟。結束後必定要查驗到能夠跑通的代碼纔算結束，而不是問了獲得確定的答覆就算結束。

資源

咱們有足夠的資源來完成各項任務麼?

沒有。

各項任務所需的時間和其餘資源是如何估計的，精度如何?

對於資源的估計比較失敗，跑神經網絡別說gpu了……連好點的cpu都沒有。因此一開始設計的功能也設計多了，因此後續beta的重點在於優化模型、優化界面、優化體驗、加速、設計小程序和人性化的分享功能，而不是添加功能了。

測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度?

感受美工過重要了。一萬個感謝早早設計的效果圖。

你有沒有感到你作的事情可讓別人來作（更有效率）?

除了寫各個文檔的本職工做外，PM確實作了不少其餘不應本身作的任務。好比由於有組員不工做，PM要去寫網頁。交接任務，都不會主動去交接，須要PM去跟着把兩邊人喊在一塊兒陪同交接。組員能夠完成「訓練模型」一類的任務，而沒法完成「觀察xxx，找到最好的xxx，並解決xxx到xxx的gap」一類定性沒法定量的任務 。須要把任務精確到「PM整理好交給你的這份數據訓練多少輪，換成哪些數據，而後……，跑完輸入tag觀察一下結果沒有致命的問題纔算完成」等等才能夠進行，感受雖然明確的能夠馬上上手作的任務安排是PM須要作的，可是太細的任務描述讓本身感到吃力，甚至有時候心情很差的時候想讓組員不要作了本身作還能快一點。

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

對於dev來講，每一個人的能力不止在於coding的能力，也在於對於任務是什麼，該怎麼作，什麼樣算作完，怎麼樣算作好的辨別能力，以及分析問題的能力。好比我覺得你們都知道咱們的cpu能力有限，有啓動時長限制，加載一個模型的啓動時間已經很吃力了的狀況下佈置的新任務，解決「現代詞彙tag到詞表詞彙」的問題，確定是找一個api或者輕量的運算方法，而不是load一個巨大的模型進來致使更加跑不動須要版本閹割掉功能等等。組員做爲focus在本身項目上的開發者，對問題的思考和對全局的觀念可能和PM不同，極可能會忽略一些問題，涉及到全局的任務，應該是PM定義清楚的。其次是組員對於本身focus上的項目，也可能會由於分析問題不徹底致使不少問題，好比任務是」修改古詩模型，訓練上對聯的數據而且觀察結果能夠有正常的創做結果「，組員可能會忽略掉如今語料的對聯數據集，就不須要過一遍詩學含英古詞彙詞典的filter了，不然訓練結果會一團糟。應該讓每一個人作本身擅長的工做。不過好在組員都很是坦誠，最後發現了問題也不會瞞着不報，因此問題最終仍是能夠經過臨時加班解決的。

變動管理

每一個相關的員工都及時知道了變動的消息?

這點PM作的缺陷比較大。PM覺得在微信羣通知一遍、在博客園寫一遍、在github上提一遍issue員工就知道了。實際上員工可能會忙忘掉。因此PM後期會再通知一遍獲得我的的回覆。可是由於你們都很忙貌似根本沒時間看issue，因此最後issue也都是由PM關掉的（宇飛除外），因此確認工做進度的效率低下，須要PM再次確認進度沒有翻車。beta階段須要確保這些工具可以真的使用起來。這個問題還體如今，有的時候某個組員給某個組員提了需求，只是去他工位上告訴他或者微信羣裏說，致使忙着忙着就忘了；在beta階段須要養成每一個組員開issue關issue，把issue當成備忘錄的習慣。

咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

由PM判斷。由於你們都很忙，員工提出任務遇到困難且溝通後肯定不會嚴重影響項目的就能推遲則推遲，很是影響產品品質的則必須實現。

項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?

第一階段（前五天）沒有，完成框架功能就算作好了，第二階段（後五天）開始逐漸有清晰定義，好比「交接給server端，運行成功纔算結束」，可是員工仍然有可能寫了代碼丟一邊就無論了，PM當天詢問進度時候才發現沒有拼接，只好在進度博客中謊報該員工完成了任務，可是三四天後他才拼接並且發生嚴重問題致使功能只能被丟棄的問題發生。

對於可能的變動是否能制定應急計劃?

能夠。加班。

員工是否可以有效地處理意料以外的工做請求？

有的能夠，好比宇飛，基本上有額外的意外PM都會去拉着宇飛一塊兒解決，所以宇飛是整個項目裏貢獻最大的人。好比在圖片字行數不正確等問題，以及從項目開始初期就反覆確認了不少遍的給tag2couplet的接口所須要的形式以後，pre的前一天晚上員工忽然告訴PM那邊的模型須要中文逗號隔開的輸入才能正確識別，PM又拉着宇飛改代碼改到了十一點多

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

如實彙報進度

設計/實現

設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

進度設計上面已經提過了，咱們把alpha又分爲了前半階段和後半階段。前半階段仍是摸石頭過河，所以是兩人一個小組，每一個小組一個任務主題，邊探索邊肯定任務量，在初期就有一個用於參考的ddl，可是很靈活，根據每小組真實的進度來更改。請參考alpha第一階段計劃。而到了真正作起來，小組步入正軌以後，PM對於項目的理解、進度的把控到了一個熟悉的階段以後，則能夠制定到每一個人天天該作什麼的詳細計劃，而不是粗糙的參考ddl。請參考alpha後五天計劃
。UI設計是在alpha的第一階段和第二階段中間由擅長美工的早早完成的，是合適的時間合適的人完成的。

設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？

我以爲上面這一問已經把如今這一問回答清楚了。

團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？ 比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

沒有作。時間太緊張，核心功能尚未作完。

什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?

古詩模型的全部操做基本都bug重重。由於組員對代碼理解的很不到位，就開始工做，工做後缺乏必要的檢查就交付，致使後期修改的任務量比較重。

代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

沒有進行很好的代碼複審也是項目出現問題和緊急狀況的緣由。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

測試/發佈

團隊是否有一個測試計劃？爲何沒有？

沒有。都是跑起來看結果有沒有問題。由於核心功能還沒開發完，甚至還在砍。只能說解決明顯的bug

是否進行了正式的驗收測試？

無

團隊是否有測試工具來幫助測試？

無

團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？

無

在發佈的過程當中發現了哪些意外問題？

生成圖片的詩顯示不全，檢查代碼找不到問題，本地測試也沒有發現問題，最後發現由於前端使用的時候每行詩之間爲了顯示美觀多輸出了一個空行，而本地文件中的處理是split計算行數留出空白的。
臨pre前一天晚上組員發現出了bug，致使臨時加班

咱們學到了什麼? 若是重來一遍, 咱們會作什麼改進?

團隊的角色，管理，合做

每一個成員明確公開地表示對成員幫助的感謝 （而且寫在各自的博客裏）：

我感謝  _______徐宇飛____對個人幫助，  由於某個具體的事情: __屢次一塊兒改bug解決緊急狀況___。

總結:

你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?

勉強能夠到第二級，管理級。能夠分工到權責到人，再有一樣的項目任務，大機率能夠完成。

你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?

規範階段。

你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?

這是第一個里程碑

你以爲目前最須要改進的一個方面是什麼?

PM對於合理佈置準確量化的任務和驗收的能力；組員對於「思考一個問題」的流程的能力。

對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。

儘早並持續地交付有價值的軟件。衝刺前就找好了代碼庫和api接口。
業務人員和開發人員應當天天共同工做。後期作到了

正如咱們前面提到的， 軟件的質量 = 程序的質量 + 軟件工程的質量，那團隊在下一階段應該如何提升軟件工程的質量呢？

嚴格遵照進度檢查和天天的博客書寫，要求每一個組員必須本身去管理github上的issue，確保天天PM驗收代碼經過後纔算完成任務

代碼管理的質量具體應該如何提升？ 代碼複審和代碼規範的質量應該如何提升？

代碼的管理須要從新更改，能夠參考最後一天報告中子博的建議。代碼複查和代碼質量爲了控制工做量仍然是自審，可是應該列在任務裏量化掉，纔會有人去作。

整個程序的架構如何具體提升？ 如何經過重構等方法提升質量，如何衡量質量的提升？

很差意思我不知道

其它軟件工具的應用，應該如何提升？

工具已經足夠用了，須要提升的點在於督促組員去使用，主動地報告問題和進度。

項目管理有哪些具體的提升？

任務量化，細化，具體到能夠馬上實現；須要有驗收和整合的步驟。

項目跟蹤用戶數據方面，計劃要提升什麼地方？例如大家是如何知道每日/周活躍用戶等數據的？

沒有除測試同窗外的使用用戶。

項目文檔的質量如何提升？

文檔的目的是輔助項目的發展，有效的記錄、指導、督促纔是重要的。

對於人的領導和管理， 有什麼具體能夠改進的地方？ 請看《構建之法》關於PM、績效考覈的章節， 或者 《人件》等參考書

首先是整個事情的大背景和條件，存在有老師的指望和同窗的指望之間的矛盾。老師很是認真負責，對於項目的要求比較高；同窗們大四對於成績的要求很是低，組裏的科研任務很是重，並且你們的coding水平良莠不齊，你們對於項目的指望水平也不一樣。並且和真正的項目相比，並不存在真正的管理被管理之間的約束，分數對於你們的影響也很是小，所以致使了每一個人幹活 意願相差不少的狀況。爲了很好的管理團隊，須要有必定的制約力。我認爲，由於是臨時湊成的小組，能力不一樣，作出來的成果水平不一樣是不要緊的，可是若是有能力卻不工做，並且態度不好的話，是我不能接受的。在」開除組員「前，組裏有兩個同窗幾乎歷來不回覆消息，由於知道他們忙，因此任務量佈置得很是少，可是把關照會當成直接忽視，開會等等很難聯繫到，可是「開除組員」後，你們明顯回覆消息積極了不少，項目的推展也順利了不少。其次是像老師中途評論到的，必定要把各個任務能夠量化到，你們才能很好的完成，這點在真實工做中，真的是必須的。

對於軟件工程的理論，規律有什麼心得體會或不一樣意見？ 請看閱讀做業。 (這個做業的期中閱讀)