個人閱讀作業 The Last - Cocky－IT工程師數位筆記本

文章出處

對于軟件工程M1/M2的總結：
假象-MO

在團隊開發的前期，我感覺自己其實給了自己很多的期待，因為一直希望著自己可以在團隊中擔任一個角色，用自己的力量為團隊多做事情，也給了其他人一些假象，那就是看起來我是一個做好充分準備有足夠能力去挑戰自己編程能力的一個人。雖然自己現在看當時的自己感覺很好笑，但是也在這樣子的掩護下，我遇到了一群同行人，一群幫助我實現了我想要的假象的人，也找到了很久沒有得到的那種團隊合作經歷。

荒蕪-M1

在第一階段中，我與隊員一起開發了“北航MOOC“的客戶端，在這個客戶端的開發過程中，我深感自己的不足，并且在開發的過程中盡量學習，讓自己得到足夠的能力去開發隊友需要的部分，我們使用的開發環境是Android Studio，開發的是安卓用戶的軟件，Android Studio確實有著很強大的功能，但是對于一個毫無經驗的新手來說，這更像是一本天書，我努力地翻閱這本天書，也在里面學到很多東西，比如在解決課程列表圖片異步加載失敗的問題上，有解決方法： inputstream只能夠讀一次，存為文件之后不能再次讀取為bitmap，所以先存成bitmap，然后將bitmap導出為文件。并且在這基礎上進入了進一步修改，因為大量的bitmap會導致堆內存溢出，所以會選擇壓縮圖片大小的方式來解決最終的一系列問題。

在M1的開發過程中，我是真的挺感謝我的隊友的，因為自己的編程能力確實有些欠缺，但是隊友都有給予一些耐心的輔導，自己負責了測試還有產品需求分析的工作，也盡可能為團隊帶來貢獻，我的隊友都非常努力的投入在軟件工程開發中就比如唐彬會告訴我怎么去配置開發環境，并且在我生病的那個階段也有慰問我，雖然不是一個班的同學，但是我覺得在一個隊伍中一起工作的時候讓我感覺到很開心；比如閆昊和史神，他們兩個在任務分配的時候都主動挑起了負責主要開發的這桿旗幟，并且史神那段時間自己其實也是很繁忙，閆昊也是在前期的開發過程中解決了很多很多的瓶頸，讓開發在中后期有很好的開發條件；金哉仁和余帆，在開發過程中也是做了很多的事情，哉仁負責了界面和測試，余帆也在閆昊同學的指導下，努力幫助閆昊和史神挑起開發軟件主要代碼編寫的這桿旗幟！歪果仁帶你灰這個名字也是顯示了我們隊伍的精氣神吧！大家都很努力的工作，都有在開發的過程中拿出自己最大的努力，都力所能及為團隊分擔任務。

在這個團隊中我感受最多的就是融洽的合作，并且合理的分工，因為團隊中有兩個人之前有過很多的開發經驗，并且也在實驗室進行過工作，在軟件工程這方面有很強的基礎，在我們開第一次meeting的時候，這兩位同學就跟我們說了他們當時開發的經歷和遇到的問題，第一次meeting大多數時間我們都是在吐槽閆昊和唐彬之前的開發經歷，也看的出來，團隊中每個人的角色至關重要，尤其是PM這個角色，在他們的描述中，PM應該是那種手持教鞭，站在你身旁催你寫代碼的人，并且鞭打你也在某種意義上是應該的。在閆昊他們的總結下，我覺得我們在努力地朝著更好的方向發展，制定的合理的分工，安排準確的時間線，每天都會在群里面更新我們目前的狀態，讓每一個同學在結束工作的時候都可以看到我們的任務進度還有接下來將要做的事情。

在M1的過程中收獲大概就是得到了一群努力的隊友，并且學會了開發環境的許多知識，也充分感受到了軟工的樂趣。雖然我在團隊中不能作為領頭羊，也不能夠做一個標桿，但是在這個過程中，通過與隊友的交流讓我懂得，其實人都是在新的環境中，努力去適應并且拼盡全力去找尋一個存活的方式，如果你不能夠適應這個強大的環境，那么大概面臨的就是死亡和滅絕了吧。

消亡-M2

在M1中我用自己的生活方式存活了下來，但是在進入M2之前的那時候，我大病了一場，每天都在跑醫院，然后也被編譯數據庫其他科目作業弄得焦頭爛額，在自己的精力上沒有辦法給出更多的幫助給我的隊友，最后在突如其來的交換隊友中，我被不出意料的交換走了，當然我也沒有說我很難過啦，因為我能明白這個制度是一個互利互益的過程，為一個團隊注入新的血液，融入更多的元素，說不定會讓一個隊伍產生新的動力繼續向前，不過我的M1的隊伍貌似熱情高漲，來什么燒什么的感覺，我拖著我的殘軀來到M2的新隊伍，然后就倒下養病了，給M2隊友帶來了不小的麻煩。

由于身體的緣故，在M1進M2這個階段，我整個人是虛脫沒用的，尤其是在M2時，隊友來找我照相，我都沒能夠下床去配合（那個時候其實正在發高燒），給我的新隊友們一種態度很差的錯覺，不怎么做事連照相都不來的人，要是我，我可能直接fire掉了！不過在M2的團隊中，我努力地去融入新的環境，開meeting，在github上加入團隊項目，也在不停的學習知識去彌補大病一場的那個空缺，也在后來步入正軌，回到一個團隊隊員的工作中去。努力的去學習需要運用的知識，但是由于空缺太大，導致我一直沒能跟上隊員們的腳步，一直處于后面的位置，并且也沒能跟隊員變得熟悉起來，大概之前在M1的感受消亡了，不是因為別人，而是因為自己的原因，現在感受起來真的是一種無可奈何的感受，因為我沒忘記我的初心，也沒忘記我想要做的事情，可是一場大病之后就是什么力氣都沒有，想要往前趕的時候，提不起勁來了。可能是因為，我對于這個新的團隊的歸屬感不足吧，也可能真的是因為那個gap確實有些大，讓我覺得我已經有些沒有力氣去追趕了一樣。

但是在M2這個階段中，我不停的反思，為什么我不能夠把更多的時間貢獻給軟件工程，為什么我生病了之后，起床想要做的第一件事是編譯數據庫，而沒有去選擇估計軟工，或許真的是因為我太忙了？或許是真的因為我生病了，精氣神不足，只能夠選擇做一兩件事，但是不能夠有足夠的時間給軟工？還是說我本身的態度中，就沒有把軟工放在一個特別高的位置呢？我想這些因素都出現過，但是都不是唯一的借口，我想還是我對自己的約束力不足，其實對于我來說軟件工程最后的分數不是我評判的我自己好壞的標準，而是我這個過程中的心態吧，我真的覺得我兩個隊伍的隊長和隊員都很棒，都給了我很多的幫助，讓我在軟件工程這門課中有很大的學習空間，但是作為團隊的一員，我認為應該完成己任，團隊的領導者有義務去安排事情的每個細節，而團隊的成員有義務去完成被分配的任務細節，這才能夠被稱作團隊責任感，我的隊友都是令人喜愛的隊友，我們的領導者都是盡心盡著沒有壓迫隊員的PM，比起很多人，我覺得我是很幸運的那個，盡管這次軟件工程我留下了不少遺憾，也因為身體的情況耽誤很多事情，但是對我來說，我真的學到了東西，受益良多，至于分數我相信不如收獲重要，我也要在這里謝謝M1M2陪伴我的隊友，還有給過我指導和幫助的同學。

之前的問題，如今的理解：
團隊中最重要的角色是什么，他的工作是什么？

在一個團隊中，最重要的毋庸置疑是領導者，在軟件工程這種結構的分配下,PM當然是最重要的人，但是在團隊中，PM其實并不是一個絕對的領導者，因為PM是團隊的粘合劑催化劑，疏通整個團隊的工作和任務，PM將會對每項任務進行很細致的分析，并且都要跟隊員溝通到最好，做到擁有很強的把控能力，并且我跟大多數人的想法可能一樣，在一個團隊中，大家的關系應當都是平行的，在這個團隊中不會存在上下級。

為什么要一直寫daily scrum，daily scrum有什么作用？

其實期初對這個這個產生疑問是因為我覺得這些開會的內容都需要要以博客的形式記錄下來，這是不是代表著我們的工作是透明化的，不知道意義在哪里。不過后來在我閱讀別人的博客時，我發現，其實我們做什么都是從零做起，然后去學習新的東西運用到原先的知識上，以博客的形式記錄下來會讓我們互相促進學習進度，而且如果博客的閱讀數量多，那么自己團隊中的人也會多多少少覺得這是一個小成就，也能促進心態的發展。

為什么產品的任務要分成前后端？

因為在大學三年多來，已經習慣了大作業的形式，僅僅是需要一個程序，能夠給出正確的輸出結果就算是大功告成，那僅僅是一個小的代碼程序，面對龐大的任務量，在有限的時間碼出無限的代碼這種事情肯定讓多個人一起分工要比一個人來的痛快的多，設計到分工那我覺得肯定需要從產品的設計上進行分工，前后端的設計，是程序開發的最優解，也能讓團隊在合作的過程中體現出重要的個人責任感，也讓每個人都能夠專精的進行工作。

敏捷開發模式適合我們學院的學生嘛？

我覺得這種優先開發的模式，應該是屬于那些個人能力比較突出的團隊，因為如果一個團隊中，很多人的程度都較低或者能力不足，那么這種敏捷開發模式只會徒增開發難度和壓力。

在敏捷開發的過程中，每個工程師都會有自己獨立的開發空間，但是這會不會因為每個工程師的思想不一致，導致一些細節問題很難處理呢？

我對于敏捷開發的理解不是很深入，但是我能明白理想的團隊開發就是指團隊聚在一起，集中工作，總是會優先解決出現的問題。敏捷開發更像是把我們從流水線的開發解救出來，讓所有人都能夠擺脫一個人工作之后另一個人才可以行動的枷鎖。

在“需求/設計/實現/測試/發布/維護”階段中的學習與收獲：

需求：我認為需求這個應該算是一個團隊的工作本身的需求，要平衡團隊成員的能力和熟悉語言進行開發軟件的選取。
設計：這個階段尤為重要，因為這個階段主要解決的就是用戶需求的問題，設計出符合產品定位和市場客戶需求的功能，對此需要團隊在市場對產品進行定位，做出符合預想的產品進行推廣。
實現：設計之后需要實現設計好的功能，并且在實現的過程中還要考慮實現難度的問題，也要考慮實現軟件的整個流程和所需要的時間。
測試：測試應當是用戶體驗最重要的第一步，我們的測試人員就是我們的第一個種子用戶，給予軟件重要的意見，以方便我們做出改變和調整。
發布：我們要發布自己的軟件，并且進行一定的推廣，做好活躍設備的統計，因為市場上真正使用我們的用戶，一定是活躍設備的那些人，也是我們所面對的主要用戶。
維護：維護階段我覺得是軟件最需要用心的地方，因為在用戶量的增大情況下，我們需要對系統進行維護，對服務器進行維護，達到我們的軟件可以安心使用的地步，并且也要及時從用戶那邊得到反饋，更好的去實現維護階段。