標籤:strong sp on 問題 代碼 工作 ad 時間 bs
一.Pair work的得與失
合作編程在以前的學習過程中也進行過,基本也就是各人負責一部分最後再將之拼湊起來,而這次作業要求的雙人合作,要求的並不是這樣,而是兩人應該在一起進行工作,這樣的要求理想情況下能在代碼編寫時提供更高的設計品質和代碼品質,也能讓結對人員之間做到相互學習,經驗共用,促進交流,但是在實際情況中,因為結對對象並不是自選,我們之間的共同的空閑時間(因為課程,生活習慣等)不能得到保障,而在另一方面,合作對象之間的相互熟悉也花去了不少的相同的空閑時間,整體效率上也並不見得比分開工作效率高。
而在我理解起來,pair work要想要高效率的運作起來,結對對象的選擇是一個很重要的部分,相比與還需要相互熟悉的之前較少交流的同學,或許室友什麼的溝通起來更為方便,空閑時間也更為統一,而至於老師在課上所說的“pair work中兩人相互督促”,不是在一個寢室的同學的督促無論是次數還是效果肯定是比不上同寢室的室友的。
疑問:pairwork中工作分量不平衡難道不會影響工作配合麼,雖說我們pairwork只合作一次,但是在實際中未必不會出問題嗎?
二. 怎樣通過一個有效辦法確定一個Bug的重要程度?我們知道,修改一個Bug時別的Bug處有可能會產生相應的改變,修改了某個Bug可能有的Bug的出錯原因就發生了改變,也就是說,如果出現了一些Bug,應該先修改那些Bug會比較
有效率?怎樣調整他們的優先順序?
我自己嘗試給出了問題1的答案:盡量縮短需求分析的時間,盡量完成基本核心功能,然後盡量拉長軟體測試的戰線,多測試,少加功能。這樣可以贏得一些比較看重核心用處的高粘性使用者,只要有一些忠誠的使用者,做出來的產品就挺成功的。
三.PM不熟悉現階段項目用到的技術,無法準確控制開發的時間和進度,Dev Leader懂技術懂代碼但是隊員的水平參差不齊,有些事情只有Leader能解決,這時候該怎麼辦?
我認為這時候解決問題的最好方法是Leader在對項目工程進行一些問題修複的時候讓全隊旁觀,相當於每次的工作都是一次教學,畢竟大家的磨合才能使團隊進步。如果水平的不足是既定的事實了,那麼只好尋找方法去彌補。
四.測試與使用者測試
書上也並為給出特殊的測試方法,不過其中一點——單元測試需要也必須由程式開發人員來進行。一方面是有些問題在部分程式碼完成時測試很容易發現,但是在整個工程完成之後卻難以尋找,會極大的降低測試人員的工作效率與工作熱情;另一方面則是態度上的問題——並不是說代碼寫好了,編譯不出錯就算工作完成了,自己的模組要能正確運行才算是完工。比起讓他人來研究開發人員的代碼,要適應不同的編程風格,弄清楚代碼的意思所需要的時間暫且不談,這也難免讓開發人員產生“反正有人來測試”的不負責任的心理。
而使用者測試則要求更高,各種神奇/奇葩的情況下都需要考慮到,而且最重要的一點是這些還未必會在使用者需求中出現,“如果使用者這樣這樣,會出現什麼情況”,如果“使用者輸入那個,又會怎樣”,這固然是要求開發人員在寫代碼的時候就將情況考慮周全,但另一方面來說人本身就難免出現紕漏,因此就有了後續測試的必要。而後續測試中要如何做到周全?就算是做到100%代碼覆蓋,也不能保證100%的正確性,所以才會有各種補丁的不斷出現,所以才會有各種版本的更新…
總而言之,寫代碼和做其他事也沒有什麼區別,負責和擔當總是需要的。
五.團隊開發的若干
規則是死的,人是活的。當然MSF的那一套流程確實是成功經驗的總結,但是在實際中能做到什麼程度又是另一個未知數了。
在按標準流程走不下去的情況下,我們需要考慮哪些呢?Team 專案的最困難的地方就是按時完成任務與隊員間的溝通,其實那一套流程為的也就是保障這兩點,也還好teamwork中各成員也都比較熟悉,估計相互督促溝通也不會太過於困難。
疑問:這隻是針對我們學生的team而言,我們並不是專業Team Dev,我們是否可只借鑒MSF中若干部分/按我們自己覺得方便的方式來開展我們的活動?
Indidual Homework Assignment