如果沒(méi)有QA，項(xiàng)目的狀況不是對(duì)每個(gè)項(xiàng)目成員透明化，會(huì)出現(xiàn)以上的各種情況；

QA作為協(xié)同式任務(wù)管理工具，通過(guò)對(duì)每個(gè)任務(wù)的記錄和跟蹤，讓項(xiàng)目成員對(duì)整個(gè)項(xiàng)目的情況有直觀的了解，項(xiàng)目經(jīng)理可隨時(shí)監(jiān)控項(xiàng)目推進(jìn)中的風(fēng)險(xiǎn)是否在可控范圍，并提前快速作出調(diào)整。

不管是前期開(kāi)發(fā)的工作包還是后期的測(cè)試bug，均以任務(wù)的形式錄入在QA里，然后對(duì)這個(gè)任務(wù)的一些基本屬性做設(shè)置，如：屬于哪個(gè)milestone、哪個(gè)模塊等，然后由各個(gè)階段的Triage的負(fù)責(zé)人按照需求等級(jí)標(biāo)準(zhǔn)來(lái)對(duì)任務(wù)作分類定級(jí)，并確定是否做，是否現(xiàn)在做；所有的任務(wù)都必須經(jīng)過(guò)Triage并approve通過(guò)，才能開(kāi)始工作。Triage的決策需要多個(gè)層面的知識(shí)（結(jié)合產(chǎn)品、技術(shù)、進(jìn)度等多方因素），特別是在大項(xiàng)目中，Triage往往是一項(xiàng)群體工作，以功能小組（feature team）或產(chǎn)品決策組的方式來(lái)進(jìn)行。在項(xiàng)目的不同階段，可以由不同的角色來(lái)主導(dǎo)Triage流程。

在任務(wù)approve后，各職能方leader將任務(wù)指派給相應(yīng)具體執(zhí)行的人員。執(zhí)行人員，也是任務(wù)的owner，必須設(shè)置任務(wù)的Status date，如：Status任務(wù)狀態(tài)是Working（進(jìn)行中）；Status date即完成日期點(diǎn)，Status date應(yīng)真實(shí)反映實(shí)際工作計(jì)劃，并應(yīng)契合項(xiàng)目時(shí)間表。

在執(zhí)行人員完成任務(wù)時(shí)，QA會(huì)通知各職能方leader去關(guān)閉這個(gè)任務(wù)，關(guān)閉的意義在于通知任務(wù)的相關(guān)跟蹤者，可以著手下一部分的工作，如某功能代碼任務(wù)關(guān)閉，即相關(guān)測(cè)試人員知道可以開(kāi)始這個(gè)功能點(diǎn)的測(cè)試工作；

通過(guò)任務(wù)在QA系統(tǒng)里的記錄和跟蹤，以及任務(wù)狀態(tài)的實(shí)時(shí)更新，終會(huì)匯總生成各種可視化的圖表，項(xiàng)目進(jìn)展直觀，且可度量，能夠很好的把握整個(gè)項(xiàng)目推進(jìn)的節(jié)奏，對(duì)項(xiàng)目中各項(xiàng)問(wèn)題和風(fēng)險(xiǎn)定位更容易，并可在周會(huì)上對(duì)項(xiàng)目的所有成員公開(kāi)進(jìn)度信息，便于協(xié)調(diào)一致；

其中重要的圖表：glide path任務(wù)走勢(shì)圖：

“實(shí)際任務(wù)走勢(shì)”與“計(jì)劃任務(wù)走勢(shì)”的對(duì)比，可以衡量出計(jì)劃與實(shí)際的偏差。

每日構(gòu)建

技術(shù) K：我們只在每個(gè)小milestone才會(huì)打build。

交互 E：希望可以每日bulid，我可以每天拿到新的版本進(jìn)行測(cè)試。

測(cè)試 Q：我建議測(cè)試前期可以每個(gè)milestoen打版本，但是中期開(kāi)始，每日build。

… …

每日構(gòu)建（daily build）是指每天對(duì)整個(gè)項(xiàng)目做一次完整的自動(dòng)構(gòu)建，生成可執(zhí)行文件的過(guò)程，對(duì)Web類產(chǎn)品，每日構(gòu)建通常要伴隨自動(dòng)部署的過(guò)程，將這些可執(zhí)行文件部署至測(cè)試環(huán)境，并按照一定的規(guī)則對(duì)這個(gè)安裝包或測(cè)試環(huán)境做版本編號(hào)，是一種Public build的管理方式。

每日構(gòu)建是編譯管理的一種方式，項(xiàng)目初期，可根據(jù)根據(jù)需要按照一定的頻率打，如：每周、每個(gè)milestone，隨著項(xiàng)目的進(jìn)行頻率逐漸增加build的頻率，如：每天build。

每日構(gòu)建的好處：

每日構(gòu)建讓從產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理、策劃、交互、視覺(jué)等所有的項(xiàng)目人員從第一個(gè)小功能模塊完成開(kāi)始，能夠隨時(shí)測(cè)試新的版本提交bug，并能及時(shí)了解技術(shù)開(kāi)發(fā)的進(jìn)度；
每日構(gòu)建讓測(cè)試人員從第一個(gè)小功能模塊完成開(kāi)始，能夠每天測(cè)試新的版本，提交新bug和復(fù)查部分bug，而不需要等著某個(gè)小milestone或者所有的功能代碼都實(shí)現(xiàn)了，再開(kāi)始測(cè)試，大大增加了測(cè)試和開(kāi)發(fā)的重疊時(shí)間，測(cè)試更充分，測(cè)試和開(kāi)發(fā)的迭代效率更高，產(chǎn)品質(zhì)量控制得更好；而且bug提交到qa上，也會(huì)一并附上build版本號(hào)，方便技術(shù)還原現(xiàn)場(chǎng)，更快地解決bug；
每日構(gòu)建使得技術(shù)必須對(duì)每天自己輸出的代碼負(fù)責(zé)，一旦每日build失敗，必須檢查原因，并糾正不可再犯，以避免再次build失敗，這樣能非常有效地提高所提交代碼的質(zhì)量，減少bug的產(chǎn)生，加快開(kāi)發(fā)效率；
雖然搭建并維護(hù)daily build，需要比較大的工作量，但物有所值。