在實踐過程中,我最終發現寫成文件類的溝通是比較有效的.比如說,我和前端的負責人談論她所需要的介面,如果少的話,在企鵝上一句兩句就可以解釋明白,但如果需求多的話,可能就要寫乙份需求的說明,我會按照前端的要求,乙個乙個的完成任務,同時把對應的解釋寫在原來說明對應的位置,內容會寫比如返回給前端什麼樣的資料,格式這些等等,把這些東西回傳給他,這樣挺有效率,出現問題也很有針對性.
進度這個東西真的很難去說什麼,在和隊友的合作中,在分工明確了之後,大家基本能成功完成自己的部分.
還是那個任務分配的地方,怎麼分配任務既能發揮各人所長,有使工作量合理.
再版本不斷地更迭中,有些介面 函式之類的講被新的代替,或者被擱置一旁不再用了,這些**是否應該留給後來的維護者(我在看學長**時候就發現了很多無用**,甚至是假實現),該怎麼處理這類東西.
需求:nabcd需求分析.
設計:估算工程量
實現:敏捷開發 結對程式設計
測試: 單元測試
發布:尋求使用者反饋
維護:通過實際的反饋進行修改
個人閱讀作業
問題 1.對於高健壯性的 應該先斷言再進行錯誤處理 大全 p193。為什麼不直接用錯誤處理呢？先斷言再進行錯誤處理和直接進行錯誤處理的效果不是一樣的麼？2.完全填充分配到的所有記憶體，這樣可以讓你檢查到記憶體分配錯誤。完全填充已分配到的所有檔案和流，這樣可以讓你排查出檔案格式錯誤。大全 p206 什...
個人閱讀作業
移山之道 這本書，光聽書名就有一種霸氣在裡面，自古以來，道 這種看不見摸不著東西，一直是人類的探索求知慾的終極目標所在，道即是道理，是規律，是方法，作者將程式設計的道理與規律比作 移山之道 這本書光從書名就已經吸引了我。這是一本很有誠意的書，鄒欣老師並不故作高深，語言非常平易近人，你可以輕易的分辨這...
個人閱讀作業2016 1 10
快速閱讀 1.什麼樣的團隊才能夠算作乙個好團隊。團隊配置合理，有專門的pm，開發人員，測試人員，ui設計師，團隊中的各個人都有能力承擔相關工作。此外團隊在開發過程中，各個成員應該配合pm，按時完成自己的任務。2.怎樣調解團隊成員之間可能產生的糾紛。首先確認糾紛產生的原因以及糾紛的焦點在 依據不同的情...