现代软件工程系列 学生的精彩文章 (6) 项目总结
學做一個PM By Cheng Lu
對于我們的SmartMe，我是真正傾注了感情的。看到今天SmartMe走出了堅實的第一步，心中首先是感謝，感謝LunaR團隊四個好兄弟為咱們的軟件付出的心血；然后是欣慰，我們幾個月5個人的共同奮斗沒有白費；最后更是展望，我們希望我們的SmartMe不因課程結束而銷聲匿跡，我們希望我們的SmartMe能真正成為一個成熟的軟件產品。
?
在SmartMe中，我專注的只有一件事情：學做一個PM。
我是在軟工課上第一次接觸PM這一概念的。雖然一開始被指派有些鬼使神差，但是現在自己還是感覺很慶幸能得到這方面的鍛煉。程序能力的提高固然是軟件工程課程必不可少的要素之一，但是在工程的整個運行和管理方面能力的提高，以及一個商業視角的培養，我想才是軟件工程這門課區別于其他程序設計課程最顯著的地方。
雖然以前在別的組織中做過一些項目的負責人，在一個技術團隊中做管理者自己還是頭一回。開始我并不知道該怎么做。自己一直堅信代碼是一個軟件的靈魂，而PM是要負責除代碼以外的任何事情，這讓我更加迷茫，不知所措。好在我有4個最靠得住的兄弟和我并肩作戰，他們對我犯的錯誤的容忍和他們的幫助，讓我慢慢上路，謝謝你們。
我覺得PM最重要的事情是要團結整個團隊，讓每一個成員有一種歸屬感，他們能夠在團隊奮斗中感受到快樂。我努力讓每一個人做的事情對于整個項目來說都是實實在在的貢獻，并且盡量保證合理的分工，讓每個人的工作量相差不多。一方面實實在在的貢獻會產生成就感，這是快樂的重要源泉，另一方面平均的工作量又不會使任務重壓力大的組員心生怨怒。福利政策自不可少，我們每周在翅香園或考研院開組會，作為PM，多花點錢也是義不容辭的。
PM另外一個重要的責任就是要保證項目能夠按照計劃前進。這個我走了一些彎路。一開始我嘗試完全脫離我們的代碼來進行項目管理，但是很快我便發現在技術項目中這么做是舉步維艱的。因為如果不了解每個人實實在在的工作，那么我很難判斷他們是否完成了這一階段的任務，并且和他們一同討論下一步的方向。感謝吳昊和蔣葉，讓我迅速了解了咱們整個程序的具體框架，之后項目的統籌規劃自己才感覺更游刃有余。這是一個很有意思的事情，我需要了解具體的程序以制定項目的前進方向和我們要實現的功能，但是我又沒有必要精通每一個細節，因為那樣我就越權了。如何保持這么一個平衡是對技術類PM的一個挑戰。：）
在項目的關鍵時候，在團隊中出現爭論的時候，仲裁和做出最后的決策是我的責任。這方面我有功有過。在Alpha版出來前，決定我們完善UI而暫時放棄歷史記錄的設計，我覺得是我做得好的。在歷史記錄基本完成后，看到林添UI部分的壓力太大，進度跟不上時，決定之后的工作重點在于推進UI，放棄設計更多Feature，并且在最后關頭組織大家一起突擊攻關，我覺得是SmartMe得以最后發布最關鍵的幾個時間點。但是這些決策我做得還是不夠及時和果斷。如果我們能夠更早地意識到UI的巨大工作量并且平攤，如果我們能夠更早地在一起協同攻關，那么我們的SmarMe肯定會更早地發布。
我必須要對SmartMe用心，團隊中的其他人才會對SmartMe用心。我向整個團隊道歉，在項目的前期，因為自己的事情，拖累了團隊和項目的進度。之后的日子，我一直在努力用行動彌補我的過失，維護好咱們的Blog，做好項目進度管理，了解每個人的工作量， 督促大家同步前進，最后一起突擊攻關。這些其實還不夠，Beta之后的日子我還會盡好我的職責，因為這樣我覺得才對得起大家共同的努力。
我是幸運的，能和4位如此踏實靠譜的兄弟一同工作。謝謝林添，你的投入讓我牢牢記著自己身上的責任，鞭策我用心努力工作。你對整個軟件理念、對軟件框架和UI設計的貢獻不可磨滅。謝謝吳昊和蔣葉，你們腳踏實地的工作是我們最后能夠成功發布的根本保障。謝謝馬成龍，你最后階段的付出讓SmartMe錦上添花。
11:52 PM?| Add a comment?| Permalink?| Blog it?| Software Engineering我的軟工總結 By Chenglong Ma
軟件工程是一門我很期待的課程 因為這門課可以使我了解寫代碼這種事是怎么可以成為一種工業的 也能讓我親身經歷軟件開發的流程寫代碼使我很喜歡做的一件事 上了3年的大學 學了不少代碼的知識 但真正做出來的產品大多是面向老師的產品 能夠面向用戶的卻很少 這不能不說是一個遺憾 軟件工程這門課就實現了我的夢想 讓我真正體驗了做用戶喜歡的軟件的感覺
由于種種原因 軟工的理論課我上的比較少 但是上過的課我都會認真的去聽去想去躬行 在做Individual Project的時候那個題目讓我百思不得其解 后來得到了一篇論文 根據文中的算法我才順利的解決那個題目 這啟示了我一定要把學習和研究的重心放到算法的設計上算法是代碼的靈魂 在做第一個Pair Project時 我和朱晨光同學合作了一個web平臺3D中國象棋的項目我學習了這個項目所涉及的一些新知識 并將其運用到項目中 這個項目做得還算成功 算是我參與制作的第一個比較像樣的游戲了同時我也第一次了解了合作開發的理念 第二個Pair Project我沒有參與開發 確實很對不起譚宸浩同學
真正讓我體會到作為工程的軟件開發是Team Project 在Team Project中 我參與了前期的策劃設計 中期少量的coding 和末期的rush test debug的工作 雖然時間不長 但我很積極很拼命 臨近發布的時候工作到早上四五點鐘 雖然我沒用過C# WPF這些新生事物 但我也盡量去了解她們最終我們的項目 SmartMe取得了前所未有的成功 這讓我們很欣慰 多月來的工作終于有了結果 而這一切都歸功于大家的合作其中包括呂誠PM的調度指揮 林添 吳昊 蔣葉的拼命coding 以及我對這個團隊默默的支持 由于鄒欣老師傳授給我們軟件工程中先進的理念和方法也由于我們將所學到的知識在項目中認真的貫徹執行 我們的開發得以有條不紊的進行 基本按期實現了每一個環節 也趕在課程結束前發布了我們的軟件經過這次合作開發 我深刻的意識到扎實的業務基礎 積極的態度 高效的溝通是一個團隊成功的三要素
感謝鄒老師的辛勤付出 貝助教的認真負責 同學們的團結合作 讓這門軟件工程不僅僅是一門課 也是我們揮灑青春的舞臺 更是我們IT生涯新的起跑點 10:00 PM?| Add a comment?| Permalink?| Blog it?| Software Engineering
軟件工程感想 By Tian Lin
軟件工程這門課，對于我來說是一次軟件開發，發布，團隊協作的一次實戰。尤其是在Team Project中，跟大家一起努力，實現我們的夢想！SmartMe對于我來說，有一種特殊的感情。它起源于我之前的一個想法，用技術最大化信息獲取的渠道，讓用戶享受信息盡在指尖的體驗。
在理念的提出階段，或許SmartMe是最受爭議的一個項目。它本身是新穎的，在市場上并沒有一款現成的產品可以作為模板，大家都看不到vision。所以在最初的時候，我們經歷了很多次討論以達成。為了便于宣傳和理解，我們以最快的速度完成了Technical Preview。
或許提到SmartMe，每一個團隊成員和用戶看到最多的是技術。而我覺得從項目本身來看，我最大的收獲就是學會了如何事實說話。我們的每一個feature都是從survey開始的，都是投入和成本的權衡。當在技術上證明其可行性之后，我們首先檢驗是否符合我們的vision。這讓我們能夠很好的走下去。在發布之后，我們收到了很多用戶的反饋，而大多數反饋的內容，都是跟我們的計劃相match的。
另外一個感受用一句話概括就是，The only limit is your imagination。相信很多的人都會有這種體會。即便是在搜索這個相對成熟的領域，仍然有可以做的空間。無論是最初的輸入伴侶或是現在的搜索資源管理器，SmartMe于我來說都是實現著一個相同的理念。這也是對我個人來說最為鼓舞的一件事情。
而最為感動的是能夠加入有這么一個優秀的團隊：我們的PM呂誠，團結起整個團隊的感情，讓大家充滿斗志，為軟件的推廣做出了不可磨滅的貢獻；吳昊，實現了非常穩定的kernel，給軟件的集成打下堅實的基礎；蔣葉，勤勤懇懇地付出，實現了我們一個又一個實用的功能；馬龍，給我們提出了很多寶貴的建議，為軟件穩定提供了保證。 9:58 PM?| Add a comment?| Permalink?| Blog it?| Software Engineering
軟工感想收獲 By Ye Jiang
??? IProject比較扯吧，先是從wiki上知道這個問題被人做出來了，然后花了三天時間才找到論文（《穩操勝券》這本書真NB），又花了一個小時寫代碼。聽吳昊說他用程序生成了8000+行的代碼，orz......我覺得這個作業的題目不好，不應該選這種已經有結論的題目。??? PProject I，唐神花了不到五分鐘的時間搭好了一個框架，讓我大開眼界。
??? PProject II，只是簡單的用了貪心，沒想到效果還不錯。另外多虧老朱的最后的測試數據比較溫和，不然我的程序的bug就會被發現了。另外楊松寫的描述太贊了！
??? TProject，SmartMe最初的定位并不太明確，中間在理念上和技術上也經過了一些轉變。不過幸好我做的最主要部分——從網絡抓取結果——基本沒有怎么變化。比較遺憾的就是，沒有從一開始就用后來林添提出的基于javascript的方法，而是用了一個類似SAX那樣的解析器，導致后來吃了不少苦頭，而且功能上不夠靈活，擴展性不足。而詞典部分選用了 Dictcn這個網站也不太靠譜，在我們快發布時居然大改版，而且還掛掉了一段時間，訪問速度也不快。當初選擇它主要是覺得它頁面結構最為合理，處理起來也最方便，現在看來似乎有點得不償失了。后來做了一點點的UI，感覺做UI還是挺麻煩的，林添真是辛苦啦。另外就是，每次開會的時候林添，吳昊和馬成龍總會爭論，然后呂誠就會仲裁，從中我也學到了不少social skills。 9:57 PM?| Add a comment?| Permalink?| Blog it?| Software Engineering
軟件的藝術
-- Created by Hao Wu ?軟件工程課明天就要完結了，盡管我們還計劃了后續的工作，但是對于此課程應該沒有什么影響了。對于這門本科階段最“工程”的一門課程，我總覺得還是應該留下點什么的。也許將來我不會以做軟件謀生，但是對這門課程，乃至整個軟件工程的體會予以總結，也許在若干年后回來看的時候，會有什么深刻的感想也說不定。為了給將來留念，特此寫下此文。閑話休提，言歸正傳，就以軟件工程課最后的團隊項目——SmartMe的感想來收束我的軟件工程課吧。
最新的技術不一定是最好的，因為用戶很可能有一臺不能使用這種技術的計算機。盡管.NET確實是非常好的技術，而且我們5組當中有4組使用了此技術，但是我們的目標用戶群當中，有不少使用的是Windows XP的機器，并且沒有裝.NET Framework，這使得一些人未能選擇試用我們的軟件。但我覺得此犧牲是必要的，因為對于我們來說，三要素（時間、資源、質量）中其實最缺乏的是時間——質量好固然好，資源也可以想辦法獲得，但是時間是定死的——無論如何一定要在1月4日交付，而且越早交付越好，獲得的好處甚至可能超過質量。因此，為了節省Dev的編程時間和測試及調試的時間（如果用C++&MFC實現，肯定將要多花很多時間，這是看iHunter的Blog總結出來的），做這一點犧牲應該是必要的。
模塊化編程，但是盡早綜合到一起。我們從一開始就把所有代碼綜合在一個Solution當中，盡管不同的Dev編寫不同的模塊，但是模塊之間從一開始就是能放在一起工作的，避免了某些小組出現的一開始各寫各的模塊，最后發現無法綜合到一起的問題。不過這種方法也有缺點，就是大家發現不能運行的時候，有可能會選擇改動別人寫的代碼的Bug，而不是交由編寫該模塊的人去Debug。事實上最后我基本上所有文件都修改過，其他Dev也差不多。
盡早開始測試工作。我們啟動測試有點晚了，結果1月4日才能將所有問題Fix，比預定晚了1天發布。關于測試還有一個問題，就是是不是即便有已知Bug的軟件也要發布？鄒欣老師雖然舉了一個例子（Excel的紀年，將1900年記做閏年），但這是一種特殊的情況。我最初一直覺得最好不要發布，但在1月4日之后我發現這是不對的，因為我在書上看到這樣的話（忘記那本書誰說的了），“推遲半個月發布或許是個好主意，但是只有在競爭對手不會在這半個月發布的時候”。有的時候，發布早也是優勢，甚至是一個很大的優勢。即使早一小時發布，也是能有很大很大的收益的。
要使用管理工具，比如Google Code。如果不使用的話，我難以想象那些Bug是怎么Fix的，不同人寫的代碼是怎么同步的，怎樣避免沖突代碼帶來的問題。Google Code確實是很好用的平臺。它最大的好處是，所有源代碼、剩余bug/issue，軟件文檔等等，都記錄了下來，而且只要Google Code本身不出問題，這些東西都能輕易轉移到以后想接續開發的人手里！使用TFS管理或許方便很多，但是如果那臺服務器Down掉的話，數據可能就丟失了。而且將來的接續開發者很可能不能再訪問這臺服務器，這樣他們獲得源代碼和文檔等就比較麻煩了。
一定要進行代碼復查。事實證明，出錯的代碼基本上都是沒有被復查過的，被復查過的代碼錯誤只占很小的比例。而且，代碼復查的最好時機，就是代碼剛寫出來的時候。因為首先，代碼剛寫出來的時候，寫代碼的程序員對這段代碼最清楚。然后，代碼剛寫出來的時候，其他程序員對它的關注也是最高的，這是由于人們對新鮮事物總是比較關注的，也比較能認真審核它們。如果等待一段時間之后，在管理機制不完善的情況下，可能就忘記代碼復查了；即便仍然記得或者通過管理工具提醒，由于其關注度沒有之前高，也就沒有之前那么用心的檢查了。
要寫單元測試。這個對復查代碼是必要的，而且也能檢驗局部代碼（例如，一個類）是否正確，避免到綜合起來之后才發現問題。而且，當代碼修改或者重構之后，通過這些單元測試，可以驗證修改后的代碼沒有破壞原有的邏輯，方便了測試工作；而且在寫代碼出錯的時候可以用來快速區分是破壞原有代碼還是新出現的問題，這也方便調試。
最后，這些方法，不是做好軟件的全部，甚至不是最重要的部分。我看了《走出軟件作坊》這本書，這本書的主要宗旨是如何做好一家小型的軟件公司，也許跟我們的項目關系不大。但是，這本書講述了一些很基本的道理，這些不僅僅是在軟件工程上，而是在其他工業活動當中也是有借鑒意義的。例如，做一款軟件，或者說，做一個項目或產品，真正的目的是什么？對于一個小公司的老板來說，目的可能是為了賺錢；對于一個開源項目的管理者來說，目的可能是為了擴大自己的影響等。而對于我們來說，目的究竟是什么？我曾經認為我們的目的很清楚，是要做一款足夠優秀的軟件。但是，在讀過《夢斷代碼》之后，我發現這一目的，正是Chandler項目走向困境的主要原因，因為事實上這根本不能稱為是目的。或許我們的目的是“無論如何，一定要在1月3日或之前發布我們的軟件，并且以任意方法宣傳以盡量增加我們軟件的下載量”？這似乎是說，我們寫軟件的目的就是為了分數（但說不定這才是我們寫此軟件的真正目的吧）。跟這種迷惘相比，用不用什么管理工具，方法好不好之類的問題都是小Case了。我們究竟如何處理做軟件和課程管理之間的矛盾？這也許才是做SmartMe過程中最大的問題吧。
?
???????? 謹以此文，獻給陪伴一個學期的軟件工程課，鄒欣老師，貝小輝助教，LunaR全體成員(呂誠同學，林添同學，蔣葉同學，馬成龍同學)，尹杰同學，印奇同學，以及一起參加軟件工程課的其他同學們！
?
總結
以上是生活随笔為你收集整理的现代软件工程系列 学生的精彩文章 (6) 项目总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java 中violate_Java中的
- 下一篇： 复数卷积 tensorflow_PyTo