【解決方案推薦】
工欲善其身,必先利其器。軟件企業(yè)也是如此,要做到高效的軟件開發(fā)和過程管理,必須選擇運用靈活高效、統(tǒng)一整合的開發(fā)管理工具。
TechExcel DevSuite 是一款高度集成、靈活可擴展的研發(fā)管理平臺,實現(xiàn)了在同一平臺下從產(chǎn)品的概念形成、需求分析、項目規(guī)劃、任務(wù)跟蹤到開發(fā)測試等全生命周期的管理。有效且協(xié)同地控制需求、資源、工期和質(zhì)量,幫助研發(fā)團隊快速改進軟件開發(fā)過程,提高產(chǎn)品質(zhì)量和工作效率。
一個平臺即解決所有工具問題!
DevSuite平臺不但包含了項目人員、架構(gòu)師、開發(fā)人員和測試人員等所有人員對應(yīng)的支持功能,增強了軟件開發(fā)團隊中的溝通與協(xié)作。舉個例子,項目經(jīng)理在定制項目計劃時可以直接使用需求內(nèi)容,在做計劃的同時又可以給研發(fā)人員分配任務(wù),研發(fā)人員在接到任務(wù)時可以直接查看相關(guān)聯(lián)的客戶需求,而測試人員在遇到缺陷時可以自動提交Bug,并且能實時查看Bug的修復(fù)進度。統(tǒng)一的平臺既節(jié)省了所有員工的工作量,也保證了信息的一致性,同時也使得項目研發(fā)的所有歷史都可追蹤到。
也是說,研發(fā)過程的每一個階段輕而易舉的實現(xiàn)業(yè)務(wù)關(guān)聯(lián),如用戶需求與產(chǎn)品功能、定制項目可關(guān)聯(lián);產(chǎn)品功能與項目規(guī)劃、開發(fā)任務(wù)、測試用例、測試任務(wù)可關(guān)聯(lián);測試任務(wù)與BUG可關(guān)聯(lián);開發(fā)任務(wù)與源代碼可關(guān)聯(lián);知識條目與需求、功能、任務(wù)均可關(guān)聯(lián)等等!
當(dāng)然必須地要提一下,DevSuite平臺還適用于跨地域、跨時區(qū)協(xié)同開發(fā),支持分布式研發(fā)團隊,實現(xiàn)高效率的溝通與協(xié)作。
產(chǎn)品研發(fā)過程常見問題2:難以量化的需求開發(fā)與管理
在軟件項目的開發(fā)過程中,需求管理貫穿了軟件項目的整個生命周期,在軟件項目管理中需求工程是軟件開發(fā)的第一步,是關(guān)鍵的一步,也是難把握的一步。需求管理做得好壞直接影響到軟件的質(zhì)量,甚至軟件項目的成敗。從軟件的項目立項、研發(fā)、維護,用戶的經(jīng)驗在增加,對使用軟件的感受有變化,以及整個行業(yè)的新動態(tài),都為軟件帶來不斷完善功能、優(yōu)化性能、提高用戶友好性的要求。
在項目管理過程中,項目經(jīng)理經(jīng)常面對用戶的需求變更,如果不能有效處理這些需求變更,項目計劃會一再調(diào)整,軟件交付日期一再拖延,項目研發(fā)人員的士氣將越來越低落,將直接導(dǎo)致項目成本增加、質(zhì)量下降及項目交付日期推后。這決定了項目組必須擁有需求管理策略和有效的落地。
讓我們一起來回顧一下實際研發(fā)過程中,通常會面臨到的需求管理挑戰(zhàn):
1. 缺乏需求的集中管理
按照需求工程的說法,在進入開發(fā)環(huán)節(jié)之前,開發(fā)團隊和客戶之間需要形成一份完整的需求規(guī)格說明書,詳細地說明目標軟件的各種需求,這其中包括功能性需求、非功能性需求和其他各種約束。在典型的瀑布模型中,需求規(guī)格說明書是在需求分析階段完成的。然而,由于軟件外部環(huán)境的變化,很少有哪個項目在需求分析階段能將所有可能的需求準確無誤地包含進來,并且在開發(fā)階段不需要修改,一句話,需求的變更是不可避免的。需求的變更也需要及時地反應(yīng)到需求管理中。
除此之外,在實際的敏捷軟件開發(fā)中,對開發(fā)而言,需求的來源不一定像瀑布模型那樣完善的需求規(guī)格說明書,而通常有以下幾種:
1)客戶初始的業(yè)務(wù)需求:很多客戶可能只會告訴我們,它想做一個系統(tǒng)或者工具平臺,大致是什么樣子,應(yīng)該具備哪些功能,但這種需求往往比較抽象,缺乏細致的分析。這種需求可能源自于一次交談,或者一封Email,形式上并不正式。
2)客戶對項目快速原型的反饋意見:對于需求,在實際項目開發(fā)中,客戶關(guān)注的業(yè)務(wù)功能,項目經(jīng)理關(guān)注的是抽象設(shè)計,而開發(fā)人員關(guān)注的卻是具體實現(xiàn)。在項目初期,客戶往往也不是很清楚他們要什么,或者理想中的產(chǎn)品到底后會是什么樣的,界面布局,操作流程等等。這一點,在新產(chǎn)品的開發(fā)中尤為明顯。
這時候,需要開發(fā)團隊能夠按照現(xiàn)有的理解快速地開發(fā)一個原型,作為開發(fā)團隊和客戶討論和分析需求的共同基礎(chǔ),原型能夠幫助用戶更好地發(fā)掘和定義需求?蛻魧τ谠偷恼撟C作為反饋意見也可以使開發(fā)團隊更加直觀和感性地認識客戶的需求。
3)客戶對每個迭代周期發(fā)布的版本的修改建議
如果該企業(yè)采用的是敏捷開發(fā),每個迭代周期都要發(fā)布一個可用的版本給客戶,該版本盡可能多地實現(xiàn)了當(dāng)前迭代周期內(nèi)的需求以及之前迭代周期內(nèi)遺留下來的需求?蛻粢炞C需求的實現(xiàn)是否符合他們的要求,并提出修改意見和建議。
4)客戶在研發(fā)周期中的需求變更
需求來源的特殊性決定了軟件開發(fā)過程中需求管理的特殊性,尤其是對于一個同時承擔(dān)數(shù)個小項目的開發(fā)團隊而言,不同的項目需求是由不同的開發(fā)人員或QA分別進行管理和跟蹤的,缺乏集中的管理,對于需求的跟蹤也比較原始。往往是手工整理需求郵件和需求列表,然后形成簡單的需求文檔,在需求查詢和狀態(tài)維護方面存在明顯不足。