目錄
產(chǎn)品研發(fā)過程常見問題1：缺乏統(tǒng)一的管理平臺(tái)
產(chǎn)品研發(fā)過程常見問題2：難以量化的需求開發(fā)與管理
產(chǎn)品研發(fā)過程常見問題3：跨部門協(xié)作困難
產(chǎn)品研發(fā)過程常見問題4：多項(xiàng)目管理挑戰(zhàn)多
產(chǎn)品研發(fā)過程常見問題1：缺乏統(tǒng)一的管理平臺(tái)
隨著軟件開發(fā)實(shí)踐的不斷深入，應(yīng)用生命周期管理越來越被業(yè)界接受為一種經(jīng)過實(shí)踐檢驗(yàn)的，可以創(chuàng)造高品質(zhì)的應(yīng)用程序的，可靠的軟件開發(fā)模式。但是，要實(shí)施整個(gè)應(yīng)用程序生命周期管理是非常復(fù)雜的，我們必須借助一些工具來幫助我們完成整個(gè)生命周期的管理。
讓我們先來回顧一下絕大多數(shù)軟件研發(fā)團(tuán)隊(duì)的典型工作情景：
【場(chǎng)景1】：工具滿天飛
很多研發(fā)企業(yè)的管理平臺(tái)非常分散，不同團(tuán)隊(duì)和個(gè)人使用工具不同，我們常常可以看到，產(chǎn)品部門收集需求使用Word、Excel，項(xiàng)目經(jīng)理制定項(xiàng)目計(jì)劃、進(jìn)行任務(wù)劃分和分配使用Project，開發(fā)部門管理任務(wù)和缺陷使用Jira、URTracker，測(cè)試部門管理測(cè)試任務(wù)使用TestDirector、TestLink，配置管理使用VSS、SVN、CVS、CC等等，這些平臺(tái)相互是獨(dú)立的，不僅不可以信息共享，部門之間還產(chǎn)生了有明顯的信息壁壘，完全靠手工操作實(shí)現(xiàn)信息傳遞。
【場(chǎng)景2】：研發(fā)過程銜接不暢
公司的需求管理、計(jì)劃管理、缺陷跟蹤、測(cè)試管理等等各種研發(fā)活動(dòng)，使用不同公司開發(fā)的無法整合的工具，這些不同來源的工具，既無法共享項(xiàng)目信息，給使用上帶來很多不便，又無法在各種不同類型的數(shù)據(jù)之間建立關(guān)聯(lián)，導(dǎo)致一些高級(jí)管理功能無法實(shí)現(xiàn)，比如要實(shí)現(xiàn)需求跟蹤，需要整合需求管理、任務(wù)管理、測(cè)試管理三個(gè)系統(tǒng)。
【場(chǎng)景3】：一個(gè)BUG引發(fā)的血案？！
軟件開發(fā)人員1： 通過代碼走查發(fā)現(xiàn)一個(gè)BUG，需要將這個(gè)BUG記入缺陷跟蹤系統(tǒng)；
軟件開發(fā)人員2（代碼的作者）：需要根據(jù)這個(gè)缺陷判斷需要如何修改，并評(píng)估修改的工作量。如果是普通的BUG，只需要開發(fā)人員進(jìn)行修改即可；一旦發(fā)現(xiàn)是深層次的BUG，涉及到數(shù)據(jù)結(jié)構(gòu)的調(diào)整、界面的調(diào)整甚至軟件架構(gòu)的調(diào)整，這將牽動(dòng)研發(fā)團(tuán)隊(duì)的項(xiàng)目經(jīng)理、系統(tǒng)架構(gòu)師、數(shù)據(jù)庫管理員、界面設(shè)計(jì)人員、產(chǎn)品經(jīng)理；
項(xiàng)目經(jīng)理：收到開發(fā)人員的匯報(bào)，很不幸的發(fā)現(xiàn)這個(gè)問題需要在缺陷跟蹤系統(tǒng)中將相關(guān)的人員統(tǒng)統(tǒng)拉到一起才可以解決問題；
產(chǎn)品經(jīng)理：需要根據(jù)缺陷評(píng)估即將投入的人力成本和由此引發(fā)的后果；
系統(tǒng)架構(gòu)師：評(píng)估架構(gòu)調(diào)整的成本并拿出可行性方案；
數(shù)據(jù)庫管理員：調(diào)整數(shù)據(jù)結(jié)構(gòu)，并為由此帶來的數(shù)據(jù)結(jié)構(gòu)升級(jí)準(zhǔn)備方案；
界面設(shè)計(jì)人員：重新調(diào)整界面，并為原來統(tǒng)一的風(fēng)格如何調(diào)整傷透腦經(jīng)；
軟件開發(fā)人員3（終確定FIX BUG的人員）：根據(jù)終收到的修改方案，制定修改計(jì)劃并進(jìn)行BUG的修改，而且該軟件開發(fā)人員制訂的開發(fā)計(jì)劃需要讓相關(guān)人員能準(zhǔn)確的掌握BUG修改的進(jìn)度，因?yàn)樗挠?jì)劃制約了后續(xù)的每一步工作；
版本經(jīng)理：根據(jù)修改結(jié)果發(fā)布一個(gè)測(cè)試版本，并知道版本中已包含了此次修改；
測(cè)試人員：在拿到該版本后需要對(duì)這個(gè)BUG導(dǎo)致的代碼修改設(shè)計(jì)針對(duì)性的測(cè)試用例，這個(gè)測(cè)試用例可能是自動(dòng)測(cè)試用例，也可能是人工測(cè)試用例，總之測(cè)試人員需要在測(cè)試管理系統(tǒng)來記錄這個(gè)BUG修改的驗(yàn)證過程；
版本經(jīng)理（又出現(xiàn)了! ）：一切緒后，向客戶發(fā)布版本時(shí)還需要提供release notes以指明該版本中的這個(gè)改動(dòng)（假設(shè)該BUG對(duì)用戶可見）；
技術(shù)支持：收到版本經(jīng)理發(fā)布的版本、操作手冊(cè)以及相關(guān)的FAQ，做好給客戶提供支持的準(zhǔn)備；
QA：仔細(xì)分析代碼走查發(fā)現(xiàn)的所有BUG原因，如果是典型問題，還需要將該問題寫入開發(fā)經(jīng)驗(yàn)庫，并通過知識(shí)共享的形式分享給所有團(tuán)隊(duì)成員；
項(xiàng)目經(jīng)理（?�。阂磺袇s還沒有結(jié)束！項(xiàng)目經(jīng)理的職責(zé)還需要從組織級(jí)的角度把控項(xiàng)目過程和研發(fā)全進(jìn)程。一個(gè)開發(fā)人員的代碼如果被統(tǒng)計(jì)出問題較多，應(yīng)該對(duì)該開發(fā)人員開發(fā)的代碼采取補(bǔ)救和預(yù)防措施，要么加強(qiáng)測(cè)試，要么給他一些培訓(xùn)，要么他根本不適合這個(gè)職位應(yīng)該走人；對(duì)于這個(gè)開發(fā)人員的上司，他應(yīng)該如何評(píng)價(jià)這個(gè)犯錯(cuò)的下屬，因?yàn)閹讉�(gè)BUG認(rèn)為他的工作不稱職顯然是不正確的，還有他如何衡量這個(gè)開發(fā)人員的工作量，是否是該員工工作量太多導(dǎo)致了該員工的代碼質(zhì)量不高？他還想知道該員工在引入這個(gè)BUG時(shí)當(dāng)時(shí)的工作任務(wù)是否過于緊迫？當(dāng)然，他也可能想分析一下這個(gè)典型的BUG引入會(huì)導(dǎo)致多少額外的工作量產(chǎn)生？
…………………….
這，也太麻煩了吧！
一切只是因?yàn)橐粋�(gè)開發(fā)人員的某行代碼的BUG引發(fā)的血案？！
拜托！這是研發(fā)工作的特點(diǎn)！好嗎？!
理由很簡(jiǎn)單：沒有一個(gè)集中管理、統(tǒng)一、高度整合的管理平臺(tái)！
