推 nvidia:約耳 09/18 09:53
提供一些想法供原PO參考吧
我工作也4年了，在開始工作時就遇到軟體開發上的相關問題，所以就一邊
工作，一邊學著解決這些工作上遇到的問題，那本人月神話我前公司有有買
一本放在書架上呢。
----------------------------------------------------------
最近我也是在專案實際開發1個多月後
(前期和客戶談spec、需求分析、範籌界定…等等都不算喔，就以寫code開始)
公司才找到部份人力進來(也就是公司還在找，但不順利)
那差不多再過1個多月，系統也得上線了
而且這人力也是part time的，
意思就是要支援其它的專案，
通常我們的人員會分配2、3個專案同時在進行
首先我想應該會有許多無意義的會議，可能只是去湊人數或是被主管罵一罵。
此時這20個人之一的任一人都可以派上用場。那原本的團隊中的某人就有
更多的時間開發。
再來就是如何把專案的工作再做更細部的分工，我想原本這專案，應該還有許多的
工作是屬於重覆性高、單調的簡單工作，例如撰寫Test Case，原PO寫一次，
其他人就可以依樣畫葫蘆此時這20個人力也可以派上用場，
我想教會這些工作應該不會花上個半天吧。
此時也可以試著採用 XP 的 Pair Programming，讓這些多出來的人一起看code或
提供想法，說不定可以提早發現問題。(目的就是避免重工)
或是可以讓這些人採用一些其它的軟體開發方法做實驗，找出一些更有效的方法
出來。
另外也可以請這20個人的某些人記錄原本開發團體在工作上所花的時間，
這是為了讓大家知道時間都花在那裡了，許多人常說時間不夠用什麼的，
但什麼時間做了什麼事卻沒有記錄，就不知道時間浪費在那裡。
總之這麼做也是為了提高生產力。
總之就是這20個人雖然未必要實際寫code，但仍然可以提高團隊的生產力，產生
更高品質的軟體。
市面上的中文書也不是只有人月神話這本談軟體開發的經典書籍喔，
經濟新潮社近年來引進了許多談軟體開發的書籍，
其它出版社也有出版些不錯的專案管理書籍，或談一些生產力、問題解決的書籍
這些都具有很好的參考價值，原PO去書店走走翻翻這些書，說不定可以得到許多
靈感之類的。
※ 引述《jexcel (excel)》之銘言：
: 我們是一個約10人的團隊
: 每個人的資歷都在3年以上 相當熟悉各自分配的部份
: 但有新的案子要在1個半月後結案 跟主管反應有進度的困難
: 於是主管一口氣增加了20個人 給我們的案子使用
: 但這20個人的能力高低有差 也不熟悉我們的domain know how.
: 也不懂我們的開發平台語言
: 看起來一切很美好 都可以克服 但主管表示這20個人只能支援我們一個月
: 一個月後 這20個人就要支援其它專案
: 一個月的時間 根本最多把這些人教懂 還寫不出夠品質的code.
: 訓練到一定水準就要離開了
: 但主管表示他也知道 這種做法有一定風險 但希望我們突破嘗試@@
: 如果是您遇到這種情況 您覺得該怎麼做才能突破現狀?
: 目前我們是規劃讓每個支援人員 知道自己一個月內的任務 就是完成一支夠品質的程式
: 先進行一週的教育訓練 然後老人帶支援人員 分組的方式進行 每日review code寫法
: 確保品質 雖然主管大家都讀過人月神話 都知道案子在趕 增加人力是很沒效率的方法
: 更何況是只能支援"一個月"的人力 可是主管鐵了心腸要這樣進行 大家覺得該怎麼做呢?
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.216.231.197