今天有一個學弟很認真地跟我聊了一些關于軟件工程有關的話題，現在我把我們的聊天記錄貼上來，希望聽聽各位老師的意見。（為保護隱私，文中隱去了直接的學生和團隊的名字）
學弟
乾神，我覺得軟件工程其實和軟件關系不大，目前為止我的感受是它應該叫做工程管理，軟件的部分反而顯得很小。
我
軟件的部分反而顯得很小是指什么？工程管理是必要的，做管理是因為這是一個團隊的項目，項目經理本身就需要做很多管理的工作。不知道你覺得哪里有疑問呢～
學弟
管理本身沒有錯，如果每個人都是全職的軟件工程師，時間充裕的確沒問題。但是現在問題是每人平均每天最多有2小時花在軟工這門課上，其中近1小時用于管理和匯報，但是我們仍要完成足夠影響力的軟件。
這兩者結合的結果是很難同時做到很好，所以我說這門課偏向于管理，因為過程中被檢查的總是博客和會議記錄，這些屬于管理方面。最后也只是看一個大概的結果和數據作為軟件方面的評分，至于代碼是否可維護拓展(與架構相關)，API文檔是否清晰(與傳承相關)等軟件方面的內容反而沒有被太多關注。
我
你說的有些道理，但是我有幾個問題問一下
1.為什么每天匯報工作需要1個小時。Scrum Meeting之所以站立，就是希望將會議的時間在15分鐘左右，讓進度匯報不占那么長時間。至于燃盡圖，寫博客，更新進度這些由項目經理負責，或輪值負責，不會拖整體的時間吧。
2.過程中檢查的不止是會議記錄和博客，我們會看你們簽入的代碼，也會看你們團隊的合作。
學弟
每個人匯報+分配任務，很容易到半小時，多則45分鐘
我
我上次參與過某支隊伍的scrum，他們的會就開得很長，因為會有一些無用信息摻雜進來了。比如上次有一個同學，他提到分詞器，然后把分詞器目前的現狀什么的講了一下，但是這些對其他同學來說重要嗎？這些東西其實是不太重要的，本就不需要讓每個人都知道你做的模塊的原理。不知道你們團隊里是否有這樣的情況？
Scrum Meeting的進度匯報盡可能簡短有力，有一下子解決不了的問題私下單獨交流，減少開會成本。沒問題就安排下一步任務。你可以在今天scrum的時候把握一下時間，如果今天開完scrum以后還覺得scrum非要45分鐘才可以結束的話，那你再來找我，說一說你們scrum時主要內容是什么。
學弟
我覺得軟工這個課最后可能形成的東西是，表面有完整的管理體系，但是軟件本身就像一個大作業，而不是一個項目，管理是成體系了，但是軟件還不是成體系的軟件。
比如舉個例子，乾神你們的物理實驗網站，七八個實驗的前端表格全部寫在了一個頁面里面，2000多行擠在一起，后面的人怎么維護更新…
還有物理腳本完全個人化了，我看得懂，上帝看不懂，這也是所說的軟件不成體系。
我
前端表格這個我沒注意過，這個可能是我們的工程師習慣不好。
但是這些本來就應該是在你們考慮的范圍，之前你們的項目經理說要接手我們項目的時候我就說過，這個東西不是想象的那么簡單，接手一個項目可能要比新建一個項目更困難。
軟件成體系的問題，我在上軟工課之前也沒有受過系統的訓練，我相信我們組其他人也一樣。所以你們在預估接手項目的風險時，就應該考慮到：學長的項目究竟是個燙手山芋，還是一個香餑餑？你們究竟有多少時間用于真正的開發？你們維護的代價會非常大嗎？
我作為項目經理，我們是一個面向用戶的需要快速迭代做出來的產品。我不能要求后端的人寫多么詳細的注釋和清晰無誤的API文檔，前端的人一定要用工程足夠規范的方法，我只能說：規范和文檔是伴隨著工程量或用戶的增加而慢慢進行的，包括模塊化，包括單元測試這些。架構的設計也是一樣，難道我們網站最開始就要設計成可以處理千萬級請求的架構嗎？這不現實。
另外，我不同意每人每天最多只有2個小時用來開發的說法，如果這門課是必修課，或者是很高的學分，大家是不是重視程度就更高一些了？每個人對每件事情都有優先級排序，我能理解。每個人在軟件工程課程花費時間不一，收獲也都不同。
具體的策略取決于你們，具體的實施方案也取決于你們。我承認我們的項目，或者說每一個“上一屆”的項目都不好維護。軟件工程課不會教大家寫代碼的。
學弟
第一，15分鐘的會議，無法對各成員的工作有充分的理解，既然是只是想知道做了什么，也什么要特意開一個會呢？顯然每個人私信一下即可完成。如果說有什么問題再私聊，會議上不多做討論，那這私聊的時間算不算會議的延伸？
第二，如果說軟件工程就是偏管理不教架構設計不講軟件編程規范那我是接受的，但顯然這導致了軟件內在問題很多，這個并不是說這課不好，只是側重點不同，選課之前和之后會有一點愿望的落差而已。但是既然不講怎么寫代碼怎么管理代碼，那最終對軟件的要求終究是有所降低，希望有足夠用戶量，能夠運行下去的愿望都是不堪一擊的，那么最終評分的原則必須對管理方面有所傾斜，不能說沒教的東西評分過重。
第三還是那個說法，我們不是全職，所以做法應該有一定的自由度，不能說全部按照全職的那一套來。比如現在我們上課受到老師的質疑——老師希望我們是按用戶視覺來看問題，增加用戶所希望的新進展，當然成熟的產品自然沒問題，但是考慮到維護性，考慮到非全職，我們在過程中重構了的部分應該也算入工作量里面，甚至我們一半的工作量都在于重構，即便是我功能沒有一點增加，但是我重構了一個很好維護的東西，比之前好，也應該是我們的成績，不能說因為沒有增加特別多的功能，看起來和之前沒有差別就不算我們的工作，另一方面也是因為這既然是偏管理，那在軟件方面就應該降低要求。
我
重構代碼我認為是可以的。我之前跟另外的幾組也說過，只要說清楚你的重構是有意義的就可以，我不反對重構。而且重構的工作當然要算在工作量里。
你們可以從不同的角度來闡釋軟件工程這個詞的含義，不論是面向開發者的，還是面向用戶的。對象不同，工作重心不同。老師認為對的，未必一定是正確的，你們按照自己的理解來，只要你們有收獲，能說明你們的工作是有價值的，那我這邊對你們絕對是肯定的態度。
羅老師質疑你們其實是因為：學霸online的那個網站，四年重構了四次。所以羅老師害怕你們會有這樣的趨勢，才會質疑你們，他怕你們占著已有項目的優勢不做對用戶有價值的工作。你們要抗住老師的壓力，在心里把目標明確就可以。
學弟
的確一百個人有一百種代碼，代碼文檔不全，主管跳槽了后面整個公司都開發受阻也不是不可能。
我
恩，那你們就抓住我們項目存在的缺陷，把它們按你們的理解去彌補、修復，我覺得這也是一個很好的工作啊。
學弟
這是實際問題，根本問題還是大管理套小項目，工程管理和代碼管理分的比較開，我認為羅老師希望學霸online通過每一屆接手最終越做越好在這種情況下是不現實的。
我
我覺得確實有一點不現實。但對大家每個人來說，我們有一個基本期望：希望大家能把軟件工程的基本流程走過一遍，有過這樣的團隊合作的經歷，做過一個能讓自己自豪的項目，那就可以了。
所以我的立足點還是在你們自身的收獲有多大，而不是項目本身有多厲害。
學弟
嗯行。
文章列表
留言列表
