第二次團隊作業——預則立&&他山之石
團隊計劃
| 截至時間 | 任務 | 階段成果展示形式 | 備注 |
|---|---|---|---|
| 2016.10.22 | 團隊計劃書、項目需求說明書、學習掌握地圖api和sdk的使用、最終确定圖檔雲存儲的方案 | 需求初審 | 與真實的潛在使用者進行訪談 |
| 2016.10.29 | 制定編碼規範、統一程式設計環境、接口格式的初步确定、需求說明書的最終版、UI設計、用戶端實作有關地圖的操作、伺服器端實作圖檔的雲存儲 | 編碼架構+需求複審 | 用戶端可先做個demo |
| 2016 10.31 | UI設計改進+架構設計+測試計劃 | 設計評審 | |
| 2016 11.05 | 第一階段沖刺——連續七天的站立式會議。編碼+測試+項目管理同步推進。實作伺服器與用戶端的對接、用戶端實作第一版本的主要功能 | Alpha版本釋出 | 時間較趕Alpha版拟實作主要功能 |
| 2016.11.12 | 項目完善+使用者試用回報+測試計劃改進。完善用戶端第一版本的全部内容 | 改進總結調整 | |
| 2016.11.19 | 第二階段沖刺——連續七天站立式會議+測試+項目管理推進。對用戶端的第一版本進行優化、完善、測試。 | Beta版本釋出 | 拟用一個月的時間完成第一版本全部的功能 |
| 2016.11.26 | 正式版本完善+使用者手冊。完成第二版本的主要功能。 | 着手第二版版本拓展功能的開發 | |
| 2016.12.12 | 完善、優化、測試第二版本。 | 拟用兩個月完成項目的全部開發 | |
| 2016.12.19 | 部署上線 |
采訪回顧
Q1: 如何确定團隊選題？
- 團隊成員是否感興趣最重要，間接影響團隊的積極性；形式上，不要拘泥于選題，可以進行适當的嘗試。
Q2. 在項目開始前，如何評估項目的工作量，以便合理規劃？
- 我們這個選題本身可以做得功能是非常多的，按照我們最初的構想。但是前期确定功能點的時候主要要考慮擁有技術能做多少，或者說再去學習得花多少時間。确定清楚後，就隻選主要功能做就可以了，主要功能實作後基本滿足軟工實踐要求，再說擴充的。這樣工程量也就可控了。
Q3. 當團隊意見不合時，如何協商？
- 講道理，誰的想法更有理，聽誰的。當然團隊中還是話語權重的差别的，有些同學比較有經驗他的話也就權重比較大。
Q4. 請問學長你們是如何根據團隊中成員的編碼能力配置設定工作的？
看會什麼咯，會安卓做安卓，會JAVA做伺服器，會ios做IOS。
學長你們沒有協作開發嗎？比如兩個人開發安卓什麼的？
- 沒有，這種小項目不需要兩個技術領域不同的人結對開發。功能點确定，接口确定就好了。
Q5. 請問學長在開發過程中遇到什麼記憶猶新的困難？是怎麼解決的？
- 困難嘛。。寫項目時還有沒完沒了的作業是我們當時最大的抱怨了，每次寫完彙報後就感覺世界都清淨了。其餘的代碼上的問題，百度谷歌就解決了不是什麼難題。
Q6. 請問學長，你們在伺服器和用戶端的對接上有遇到什麼問題嗎？
接口文檔變動有點頭痛，開發前做得接口預設并不一定符合開發需求。當實作的時候需要加字段時候，資料庫方面也會出現混亂。
那麼針對這個問題，學長有什麼比較好的建議嗎？
- 再三考慮你們的需求文檔，那些什麼背景啦流程啦，進度設定啦都是虛的。功能點界面UI接口要再三論證再下手。
Q7. 在整個開發過程中，學長認為有什麼注意點需要特别注意？并有沒有一些建議？
- 先論證能不能實作再動手，主要難點确定好技術路線。不要提着褲子上路就OK了。
訪談總結
通過這次訪談，我們再一次意識到了軟體工程這門課除編碼外所教授的知識的重要性，編碼前的工作也是十分重要且必須的。其次，通過對學長的采訪，我們意識到一個明确的接口文檔的重要性，了解了如何合理地控制工程量。而對于我們選題和産品原型的設計，我們也會意識到了開發出一款有趣的app或許更加的适合我們，我們會努力做好需求分析，努力把我們的app設計得更為有趣。
權重配置設定
| 姓名 | 比例 | |
|---|---|---|
| 張斯巍 | 問題提綱，采訪 | 16% |
| 賀翎 | 問題提綱 | 15% |
| 林宇晨 | 文稿編輯 | |
| 張建華 | github搭建，問題提綱 | 17% |
| 王淩傑 | 團隊計劃，采訪，問題提綱 | 20% |
| 朱松 | 文稿編輯，問題提綱 |