Poemscape|Beta階段過後諸葛亮

設想與目標

咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？
  在Poemscape|Beta整體規劃中定義得很清楚。

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

• 性能：很好的達成目標，項目從Alpha階段的須要一分多鐘才能跑完一首詩，到如今幾十秒就能同步出詩和對聯；
• 功能：實現基礎目標：可以分別爲人像和風景進行鍼對性的創做；
• 美化：稍顯不足，但也較初版有所進步；
    和大成組進行了對比，咱們在目標重視和人員配置上有必定的問題，①咱們以模型速度和質量爲重點，在對用戶體驗方面原本就比較忽視，而後在界面的設計上，又採起了減小用戶點擊次數，讓用戶可以更快的獲得結果爲目標；②表面上咱們前端組有兩我的，但實際可以編碼的人員只有一卓一人（對比大成組Alpha階段就有3-4人負責/參加前端）。這三個思考方式出發點都沒有錯，但拼起來就致使咱們的用戶體驗不佳，這也提醒咱們之後要全局考慮。
  
  

計劃

是否有充足的時間來作計劃?
  Beta初期，因爲你們都是green hand，對任務實際的困難度估算不許確（「PM」仍是一個技術盲==），因此當時咱們認爲，相較於先調研直接定出精準的規劃卻未符合事實，不如根據項目分爲三個階段（試作➕調研階段、完成目標階段、補漏調整階段），同時按照成員興趣進行大體分組管理效率更高。到了中後期後再進行肯定的規劃。前期咱們完成的很是好，燃盡圖一直都有超前完成，可是中後期即便不清楚狀況也應該明確DDL和任務安排，卻沒有實現，這是PM的失職。

團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？
  PM收集整理了全部組員最初的想法都在最初提出，由PM進行整理，最後彙整起來，因爲咱們人數夠多，因此決定將全部任務都列出。而且肯定了任務的基礎性，重要級排序。

你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?
  咱們實現了咱們認爲最重要的工做。固然還有開放的、未完成獲得工做，這部分工做原計劃中就處於bonus狀態，並未計劃是都完成的。

有沒有發現你作了一些過後看來不必或沒多大價值的事?
  從軟件發佈的角度來看，組內安排了大量人手去解決性能方面的問題，其實剩餘的人力資源是不足以在考試/結課月的10天內輔助將人臉識別這個功能很好的Train並投入實際的運行，而這項工做，不只花費組內一位同窗整個Beta階段的大部分精力，前端組也付出了不少的努力。從項目的角度出發，Beta階段重點應放在發佈出去的產品的總體質量上，而不是一味的在功能上提升，固然這是咱們將來成爲成熟的工程師後可以也應該判斷並規避的。
  從PM我的角度出發，做爲非技術口的同窗，天天和你們一塊兒開遠程語音會議的必要性沒有這麼大（因此後期不徹底參加），也花費了很多的時間和精力去消化，反而應該天天經過其餘方式（如私戳你們詢問狀態和進度等等）去和你們交流，以實現對話。

是否每一項任務都有清楚定義和衡量的交付件?
  咱們的架構師對任務有很明確的規劃，並進行了測試，在這點上組內有充分的自信。可是在前端上咱們其實能夠看到效果圖和實際實現的狀態有必定的出入，這點上是美工早早的不熟練，詢問了作網頁設計的前輩，最好的狀況是設計和編碼Html+CSS+JavaScript的是同一我的（至少設計師能作出html+CSS），而負責編碼前端的工程師負責的是先後端的接口等功能的部分。

是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?
  總體而言，項目按照計劃，天天完成和完善前面的issues，並提出新的issues以推進實現項目。但項目仍是有意外——沒考慮到的風險是子項目間的拼接問題花費的時間和精力，致使咱們在拼接功能上花了好幾天時間；緣由是經驗不夠豐富。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?
  齊煒禎 ：beta階段，從PM轉變爲Developer的角色，主要跟隨子博學到了現代軟件的結構，學習了成熟的架構對於整個項目的意義，整個從alpha到beta的過分過程，體會到一個各個功能都有可是走一步掉一個螺絲的機器人和一個功能構建完整功能定位明確，拓展方便的體系之間的區別。若是能重來咱們有什麼改進：在每一個人都有太多本身的事情以外作軟件項目作成如今的程度我已經很知足了。在《人件》中有講到，同時作的事情越多，耗費的無用精力更多；在不一樣的團隊裏，認真負責是互斥的。因此你們在完成好科研工做以外能把項目完成到如今的程度我以爲很好了。若是能重來，我但願能夠全部的developer都是全職員工。
  姚青松 ：確定有銀彈，良好的工具使用，每日例會，合理的分工，正確的衝刺方式，和諧的團隊氛圍必定會讓軟件工程變得容易高效，反過來講若是不懂如何合做開發，很小的問題就會卡死整個項目，和每一個人的實力和問題複雜度無關。若是重來會更加劇視分工交流驗收，即便天天作很小的工做也要確保完成。

  王子博 ：我以爲最大的經驗是，要制定明確、可度量的里程碑，而且將責任分配到人，切實實現之。我在編碼工做基本結束時就宣佈實現了第一個目標，開始計劃額外功能了，這主要是由於更早時我給你們說的估計是四五天能完成第一個目標，到了第四天、第五天時內心有壓力，急於開始安排下一階段的任務。其實這個估計自己沒有什麼問題，正確估計了編碼的時間，但我沒有重視 bug fix 的過程，覺得在前進過程當中上一階段的 bug 能夠零散地被解決。實際上，必須專門爲此分配時間，否則的話人老是更願意編碼新功能，不肯意枯燥地解決 bug 的。咱們遲遲沒有清理乾淨 bug，也就致使遲遲拿不出一個徹底能用的構建。自動構建和部署的系統雖然作了，卻所以沒發揮出足夠的做用，沒有體驗在其上不斷優化、實時觀察進展的過程。

  趙瑞靜 ：總的來講學到了軟件開發的流程和合做溝通的重要性，細節的來講學到了一些淺顯的服務器架構有關知識。 若是歷史再來一遍，相比於添加更多的功能，可能會更加劇視優化已有功能的體驗。

  劉澤 ：軟件工程的時間安排，統籌規劃的重要性。一個好的架構的重要性，怎麼才能提升代碼質量，同時提升本身的工程能力。學習到了一些新的網站搭建知識。重來一遍會作什麼改進：針對功能拼接要花費更多的精力在上面，不然常常出現不如人意的bug.

  張一卓 ：軟件工程的基本開發流程，積累了網頁前端的一點經驗。重來一遍的改進：預先規劃多花一點時間，在開發流程中要可以先完成里程碑，再向前推動。

資源

咱們有足夠的資源來完成各項任務麼?
雖然咱們抱怨過的問題，但咱們有夠用而不充足（adequate but not sufficient）的服務器完成咱們的任務。

各項任務所需的時間和其餘資源是如何估計的，精度如何?
  進行了任務的困難度排序以後，最重要的問題是必定要解決的，因此直接解決，精度分配到我的。

測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度?
  測試的時間有些吃力，服務器資源夠用而不充足，不須要編程的部分，美工難度還好，文案比較匱乏。

變動管理

每一個相關的員工都及時知道了變動的消息?
  和Alpha階段不一樣，此次咱們的daily scrum有在run，確保了消息的及時性。

項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?
  架構師進行了很清晰的定義。

對於可能的變動是否能制定應急計劃?
  咱們相信咱們能夠。

設計/實現

什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?
  齊煒禎：只要有拼接就會有bug。互相交接的工做，責任不明確，會互相推卸責任。

  姚青松：凡是遇到連個功能模塊相接的部分產生的bug最多，engine/api，前端api，由於出現bug沒有落實到人或者兩我的，你們就會一塊兒互相等，致使bug一拖再拖。發佈以後一臺服務器承受不住三個engine，其次沒有考慮到用戶上傳超級大圖片的狀況。開發設計時候低估了用戶量，和用戶上傳內容的不肯定性。

  王子博 ：bug 最多的部分是前端，這也是沒什麼辦法的事情，咱們的前端開發能力確實不太充足，只靠一卓一我的在努力。整體上這是在預料之中的，也沒有對項目進展產生明顯影響。在發佈以後出現過兩次較長 downtime，都是因爲向生產服務器上作了有問題的更新，既沒有事先在開發環境測試，也沒有在生產環境發現後及時回滾以減少損失。我以爲這是由於咱們沒有專門安排生產服務器的維護者，發佈之後你們向服務器推送更新比較隨意，沒有制訂嚴格的服務器操做規範。若是改正的話，規範應該至少包含這樣的要求：生產分支必須經過 pull request 提交，pull request 必須除發起者外獲得一人審查承認，在生產服務器操做時必須事先想好操做內容、操做後的測試方式、測試出問題時的回滾方式。

  趙瑞靜 ：我以爲bug最多出如今兩個功能進行拼接的時候，發佈以後發現沒有不滿意多作幾首的功能。在最初時間規劃不是很好，最後作的不是很完善。

  劉澤 ：功能的拼接，穩定版本的肯定，版本的迭代等。是有想到這些狀況的，只是執行起來比想象中問題大，可能前期不夠重視致使的。

  張一卓 ：全部模塊拼在一塊兒時會出現以前沒有發現的bug，沒有想到的緣由：咱們的項目測試工做作得不夠完善，開發時不能預先測試。

代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
  王子博 ：咱們採納的規範是，每一個倉庫設 dev 和 master 分支，前者用於每日提交，在達到里程碑後向後者發送 pull request，通過至少另外一人評審後簽入並部署。在每日提交後，子博會審覈代碼風格是否符合 PEP8，代碼邏輯是否符合 spec，並以 GitHub comment 的形式給出反饋，你們次日就能及時修正問題，避免開發過程偏離 spec。在實踐中，因爲咱們用了過久纔到達第一個里程碑，部署了無 bug 的網站，達到了簽入 master 分支的標準，因此 master 分支遲遲未被使用，基本上始終在 dev 分支上工做，以致於竟然作出了持續集成 dev 分支這種不合理的事情來（笑），致使很多有 bug 的代碼被持續集成自動部署了。到了後期，項目發佈之後，因爲你們增長功能心切，爲了儘快部署新功能，出現了跨組工做和未經測試和評審就部署代碼的現象，代碼質量便失去了嚴格控制，雖然敏捷，但對服務穩定性形成了必定影響。

團隊的角色，管理，合做

團隊的每一個角色是如何肯定的，是否是人盡其才？
  總體根據你們的興趣和精力進行了任務分配。

團隊成員之間有互相幫助麼？
  有的！

當出現項目管理、合做方面的問題時，團隊成員如何解決問題？
  天天開會溝通+部分狀況微信羣實時溝通

總結

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

對於人的領導和管理，有什麼具體能夠改進的地方？ 請看《構建之法》關於PM、績效考覈的章節，或者《人件》等參考書
  首先，PM的人選有必定的問題，做爲非技術+非本地+還有本身的工做的PM，能力和精力上有些吃力，因此實際上咱們實施的是：經過每日會議你們的互相交流這個基本的"外驅力"進行監督，和你們的自覺做爲「內驅力」進行激勵實現的雙向約束，其本質是全體民主管理，項目計劃的天天調整也是徹底民主的。從項目結果出發的狀況來看，因爲咱們的組員的自我管理約束能力較高，項目產出是不錯的，但從管理模式來看，它的本質是不穩定的，若是這個項目時間更長，仍是容易出現其餘狀況的。

  改進方面，若筆者仍擔PM一職，一定會尋找一個明確的PM助理進行溝通管理，爲更好的分配資源，對天天調整計劃的管理仍是應該有必定的集中度，同時對目標的管理進行嚴格的量化。

貢獻的權重

組別	成員	貢獻權重
引擎	姚青松	21
引擎	齊煒禎	23
架構	王子博	22
API服務器	趙瑞靜	20
API服務器	劉澤	19
前端	張一卓	18