• 總結部落格

第一部分

提問部落格

曾經提出問題的新解答

Question1-Chapter3軟體工程師的成長

我閱讀了第三章關於初級軟體工程師成長的5個小點（P49），對於其中的積累問題領域的知識和經驗和提升職業技能這兩點感觸頗深，
但對於同樣成長的初級工程師如何去量化這兩個方面的提升呢（作為學生）？還是說這樣的積累是在工作崗位中不斷累積
最終形成職業的晉升呢？這兩個點的掌握程度上級可以通過面試評估出來但作為學生的我們又需要如何去提升它們

呢？

NewAnswer:在經歷了這學期的軟工實踐後我逐漸發現有開發經驗的同學和沒有開發經驗的同學在面對困難時的解決辦法是不一致的。
掌握開發能力必然伴隨著開發專案經驗的提升。提升開發能力必定伴隨開發專案的進展。在學習生活中我們所掌握的開發能力諸如Java云云，大概率是會在後續工作中運用上的。
但是掌握開發相關技能並不代表擁有專案開發經驗，能夠面對程式碼出錯解決bug的能力才是未來所必需的能力。
其實作為學生，只要能夠真正著手進行專案開發就能夠提升能力。只是只有極少部分人能做到。

Question2-Chapter3軟體工程師的成長

我閱讀了第三章練習與討論中第四個問題。（如下圖）我認為這是在程式開發過程中難以避免的問題，然而我們該 如何降低這種問題發生的頻率

呢？（個人認為前期的面向物件分析與設計是很重要，可是沒有投入到實際實踐中空於理論一定是會產生偏差的。即使是我在完成學生成績系統時，寫到後面也會發現冗餘的可能影響篇幅巨大的需要修改的地方。）

NewAnswer:在實際程式開發過程中，團隊開發必定是先進行一系列的計劃與設計，同時應當評估風險做好預案。
一開始我認為的在實際開發中不可避免其實是錯誤的，因為作為團隊既然選擇了這一方法，那就應當做好後續的設計與風險評估。
也應當有風險預案。如果沒有這一系列的措施只能說明這個團隊並不成熟。

Question3-Chapter5

我閱讀了第五章對於團隊模式的集中分類後，認為功能團隊模式是最符合成熟的軟體開發流程的，然而究竟是是團隊創造專案

還是專案主導團隊，我依舊對此感到難以權衡。

NewAnswer:在經過這學期的學習之後，我有了新的理解。我認為是團隊創造專案。因為一個功能團隊模式已經有了成熟的軟體開發流程了。
而對於他們而言，組內的人的想法經過共識之後就會形成團隊共識，轉變為專案雛形。在我們軟工課程中的立題也是如此，有了想題目的人，團隊才會創造新的產品出現。
事實上一個團隊開發什麼專案在軟工課程中或者是在創業過程中，我們都是擁有有想法的人之後才組成這樣的團隊。

Question4-Chapter8需求分析

我閱讀了第八章需求分析，在其中筆者提及調差問卷式的提問具有兩個關鍵疏漏：實際答案並非我們所希望得到的答案（例：選擇最喜歡的搜尋引擎，使用者給的回答可能是使用最頻繁的）以及容易帶有引導性。於是筆者引導我們去正確的設定調差問卷評估使用者需求。然而個人以為，不論是一個新產品的問世還是一個新需求的呈現，無非都是具有極其強烈引導性的，因為我們要抓住使用者的痛點，擴大化其痛點。與其不停的讓痛點使用者模糊的表述需求，似乎選擇先行製造介面再引導使用者修改效率更高？誠然，這樣做會使得軟體可能需要進行大規模修改，然後選擇題和主觀題是不是選擇題更容易作答些。但換句話來說這兩種方式皆有利有弊，個人偏向於先做demo再詢問，私以為效率更高些。

NewAnswer:在進行軟體開發模型的學習時發現確實存在這種開發方式，即先製作出原型再進行開發。但這一種開發模式的弊端在於後期進行製作時
可能需要刪減部分功能還需要和使用者進行對接。

Question5-Chapter8需求分析

我閱讀了第八章需求分析中的功能分析四象限，對於其中的殺手功能有一些疑惑。我曾經想要開發一個類似於收集衣服搭配的軟體，然而在我的不斷設想中（當時還沒有接觸產品學習）我所謂的功能在不斷的增加，新的功能（虛擬試衣）會覆蓋之前的功能成為“殺手功能”，可慢慢的我發現這一新出功能慢慢的成為了這個軟體中篇幅最大的內容，或者說他的內容超過了原先我認為的使用者痛點（也就是搭配模組）。如果出現這種情況我們又該如何應對呢？就像我們常說根據使用者需求或是軟體發展新增新功能後，慢慢地隱蔽了原先的亮點。一個軟體功能的擴充是必不可少的，可如果失去了主次會不會就像沒有初心的人逐漸喪失競爭力一般。

NewAnswer:在這學期的軟工實踐中我進行了這個設想的重新規劃。我發現需求設計還需要考慮到實際開發的可實現性以及明確我的使用者痛點。
系統性的軟體不一定是最優解，但是專且精這一方向是沒有問題的。

Question6-Chapter9專案經理

在小組開會的過程中，我們總是會抓住很小的但是重要的點討論非常久的時間，但整個主流框架都沒有討論清楚，花大量的時間在重要的末流過多的浪費了開會的時間，作為專案經理該如何去規避這個問題發生的頻率呢？

NewAnswer:彷彿是命中註定一般，在這次開發過程中我充分意識到我“跑題”的問題。事實上到最後每次開會前期我都先行列舉好會議大綱，
進行會議流程的安排。由於一開始選題過於天馬行空導致我們小組成員對於我開會都有些抗拒。事實上一個成熟的專案經理在熟悉團隊成員後，
分工應當是明確且適當的。但由於我和我的成員有一定的溝通成本，故前期花費了些許精力。

Question7-Chapter4兩人合作

在第四章中看到這句話結對程式設計中駕駛員和領航員的角色要經常互換，避免長時間緊張工作而導致觀察力和判斷力下降？
在這句話中我聯想到前後端的合作，是否前後端也需要適當的角色互換才能夠更理解互相交流時的需求呢？在實際生活中似乎少見這種互換的發生。

NewAnswer:（我簡直太會提問了）在這次實踐中，我重新審視了這個問題，發現我一開始對問題的理解是有誤的，其實應當是開發和產品互換才能夠互相體諒。
經歷過角色互換之後，才能更理解如何將需求轉換為開發，如何規劃開發時間點，減少爭執。

請問你在專案的需求/設計/實現/測試/釋出階段（一共5個階段）中，每個階段收穫最大的知識或能力是什麼？

• 需求

  • 溝通能力:由於我不著重點的聯想導致了團隊開會時間很長，反饋之後每次開會進行了會議大綱的設定。
  • 視角轉換能力:站在使用者的角度思考是否有實際痛點，設計的功能是否能夠明確實現痛點，而不是為了新意追求新意，為了技術追求技術。
  • 熬夜加班能力:不多贅述了
  • 在需求設計階段中，我和我的組員由於我溝通能力的問題（和大家不熟悉、標準不一致、開會沒重點等）加重了溝通成本，組內氛圍並不是很融洽，
    當時我們小組由於只有我一位女生，普遍認為Outfits沒有市場前景，但我將團隊提及的每一個備案都進行了NABCD分析，通過理性的資料和分析
    說服了他們（可能是因為死纏爛打），當然後來在答辯時大家也意識到了這個產品的市場前景。這件事情讓我印象深刻是因為我意識到當無法互相說服的時候
    需要一些資料來客觀評估。誠然，遺留的溝通問題也成為後續組內的較大問題。

• 設計

  • 需求轉換能力:將使用者需求轉換至實際功能點。
  • 標準統一的評價:應當團隊建立統一的標準去進行材料任務的評估，而不是用個人的標準規定整組人。
  • 抗壓能力:這個時候和組員的部分溝通不是很融洽，由於標準不一致的原因，導致我重新修改審閱材料。
  • 熬夜加班能力
  • 在這一階段由於標準不一致的問題並沒有解決，導致我和部分同學進行了反覆的材料修改。在原型答辯之後我開了一個全體大會，設定了責任小組，
    也進行了標準統一的設立。經由小組長設定標準，我直線對接負責人。在這次制度的修改後，我充分的下放了權利。雖然後期有發生小組長不太負責的情況發生，
    但也算是使得我們組內的責任明確化了。
  • 同樣，在這次開會後我充分意識到組內的成員們對於課程的目標是不一致的。我的目標是培養的我專案開發的產品經驗。很大部分的同學僅僅是為了完成
    課程要求，因為他們已經具備了充分的開發能力與經驗，並不一定只有這門課程能夠給他們帶來教學。當我意識到這個問題時，我發現我並不能改變每個人的想法，
    無法中和，只能勉強讓大家完成任務。所以我提議在課程初期進行分組的時候就可以合理規劃大家對實踐課程的目標分數是多少以此來分小組，或許是個不錯的想法。

• 實現

  • 規劃能力:專案的初期就要按照每日進度表規劃一樣去執行，否則後期會非常疲勞。
  • 溝通能力:出現部分斷聯現象，但由於前期“負債累累”所以只能自嘗惡果。
  • 學習能力:學習了安卓開發，但效果並不顯著。
  • 抗壓能力:每天不是在催材料就是在催材料的路上，收集不到每日進度，很多時候表格就只能置空。
  • 在這一階段，我後期大部分就是隻負責部落格撰寫和答辯相關事宜。這個時候團隊部分成員出現了懈怠的情況，可以理解也無法改變，
    畢竟大家對於軟工實踐的課程要求並不一致。但這就導致文稿不及時，後期ddl瘋狂補救的情況發生。

• 測試

  • 風險評估能力
  • 學習能力:短時間尋找測試工具學習。
  • 程式碼規範很重要。

• 釋出

  • 調查問卷應當面向物件調查。
  • 及時反饋能力

結合自己在個人專案/結對程式設計/團隊專案的經歷，談談自己的理解或心得。

• 作為一個輔修工商管理並且意向做產品經理的人而言，這門課應當是非常鍛鍊我的能力的，也確實真真切切地讓我感受到鍛鍊，雖然非常的痛苦。在這裡也要謝謝汪璟玢老師、傅明建老師、張璟璇助教、林新宇助教、楊心逸助教、孫首男助教和徐明盛助教給我的幫助和教誨。
• 在個人專案中，我設立了短期內的發展方向與規劃考量，雖然後期被我咕咕咕了，但是嘗試去探索自己的發展路徑和摸索這個行業的前景，是一項非常需要學習的能力。我學習了檢索資訊的能力，但在區分有效和無效的資訊中還是有些迷茫。就如同摸索發展方向一般，但後續的軟工實踐就像引路燈一般帶我親身經歷一番實際開發過程，或許他在真正的職場中還漏了部分環節，但總算是體驗了一番產品的感覺。同樣地，在進行程式碼編寫的時候，0分的執行分讓我充分意識到程式執行是非黑即白的，努力與實現它並沒有聯絡。很多時候，只看目標不看過程才是常態。讓自己達到滿分的結果才是基礎。（當然管理不能這麼想）
• 在結對程式設計中，我充分意識到掌握一門技術的重要性。在軟工之前，我學習了python-flask這門開發技術，這使得我在結對程式設計中少了許多學習的成本能夠直接上手開發。但是學習是無處不在的，在結對程式設計中我第一次嘗試爬蟲程式的編寫。但其實在很早之前，我就有機會去學習爬蟲了。由於我的懶惰，導致了我在這個階段還需要繼續學習。這同樣也讓我意識到很早之前看到的一句話。15歲時覺得游泳難，放棄游泳，18歲時遇到一個你喜歡的人約你去游泳，你只好說我不會呀。18歲時覺得英語難，放棄英語，28歲時出現一個很棒但要會英語的工作，你只好說我不會呀。雖然很不形象，但是很貼切。所有我逃避的最終都會回到我身上。結對程式設計的隊友是我的舍友，我們之前並沒有溝通成本，大家都追求能夠有效認真的完成，於是我們相處的非常融洽。
• 在團隊專案中，我真真切切的意識到自己的不足，學習到非常非常多。在我修習的輔修管理課程中，大多都是面向職場，我錯誤意識了學校中組長組員的關係與真正職場的不同，這就導致一開始我的“專斷”。加之每個人針對這門課程的目標不同，我逐漸意識到無法讓所有人都跟隨我的標準，於是我開了一次會，下設了負責人，經由負責人統一標準，將小組制度化來改善這一情況。（如果這個問題能在組隊時被發現就好了。）幾乎是不可避免的產生了組內的矛盾衝突。後期聯絡不到組員，也就相當於自食惡果。我和部分組員只能在每次答辯之前瘋狂趕工。這並不是良好的氛圍，我理解，但是我造成了這個局面。真的心力交瘁。這門課極大程度的鍛鍊了我的抗壓能力；意識到自己的管理能力有問題；意識到自己溝通能力有問題。
• 寫總結部落格的時候發現自己提的問題真的都是自己在實際發生的問題，淚目了。
• 發現了很多錯誤 ，也正在嘗試改正，就是有那麼一點點辛苦。
• 其實在這門課的過程中有無數次想說的話，但到了最後只想說“終於結束了”。

第二部分

技術部落格