理想化 :
上級(PM決策人):交付舊系統程式code+開發文件 並讓我接手修改3個月以上
下級(系統使用人代表):了解新系統與舊系統差異,並願意測試期間參與測試與回饋
實際上 :
上級(PM決策人):
但開發文件與code大不相同,只能自己建立測 試環境修正開發文件,之後再依新[開發文件+系統架構]討論修改時間規劃
下級(系統使用人代表):
新系統(操作UI)需求常改三次,驗收時間增加3倍
新系統(功能)需求常要求更為細膩,系統反應時間要更快,讓程式碼增加3倍
問題 :
系統開發中的程式code人員,程式code的時間規劃要如何做??
我常只能回報交付需求測試第一個版本的時間規劃給PM/主管(依規定要交code/測試文件/測試系統/程式差異比對及差異說明文件/並demo),但需求測試第二個版本+需求測試第三個版本無法知道如何改及時間規劃,只能隨機應變
已邀請的邦友 {{ invite_list.length }}/5
大家都學 敏捷開發觀念?
大家都要 順時鐘 持續改善?
一版一版的更新改善 直到成功? 還是 打掉重練?
我常只能回報交付需求測試第一個版本的時間規劃給PM/主管(依規定要交code/測試文件/測試系統/程式差異比對及差異說明文件/並demo),但需求測試第二個版本+需求測試第三個版本無法知道如何改及時間規劃,只能隨機應變
我覺得你已經知道答案了，就是確定的需求交付時間規劃，變動不確定的版本隨機應變
這兩句話不中聽
建議你最好不要說(隨便你心裡怎麼想)
因為這兩句話不管對錯
都對你現在這個問題沒有幫助
新系統(操作UI)需求常改三次,驗收時間增加3倍
新系統(功能)需求常要求更為細膩,系統反應時間要更快,讓程式碼增加3倍
個人建議:
1.向上反映開發文件與code差異的問題,爭取更多時間
2.和使用者作深度溝通,了解需求並作成文件,讓使用者確認需求,調整時程後向上級說明
3.使用者需求變更時,修改需求文件、調整時程、增加的預算金額,讓使用者及上級知道
iThome鐵人賽
看影片追技術