項目流程的制定

       在咱們工做中，創業公司或是須要搶佔市場的項目都採用敏捷開發的方式。最快上線投入市場，但是隨着公司的成長，項目的變大項目流程就顯得愈來愈重要了。因而就會在項目開發的過程當中引入項目流程控制，以保證項目週期和質量。此是多是由公司高層制定，也可能與咱們測試人員商量，對於咱們測試人員，應該如何制定項目流程呢？

一，  國際性工業化流程

      軟件項目工程有標準的流程，也就是國際化標準流程，固然咱們能夠從書上或是網上得到相。以下所示，是我在網上查找到的一個流程：

 

       在實際的公司項目流程中，發現若是徹底按標準的流程來走會有不少問題，關鍵緣由就是這個標準的項目流程是有適應條件的：

（1）項目週期長，有充足的時間；而公司的項目每每週期比較短，一週的項目週期就算長的了，因此根本沒法按正規的週期來執行。

（2）相關標準和文檔比較完善，並且要求高。而如今公司不少開發人員不肯意寫文檔，或是項目歷史包袱較重，沒有辦法整理相關的文檔。

（3）領導重視項目流程，嚴格按標準執行。大型的公司比較重視流程，而如今關注點比較多，如收入，客戶，市場等等，形成流程沒法徹底按標準執行。

二，個性化的項目流程

      針對標準化的流程執行起來比較困難，因此須要根據本身業務和團隊特色來制定個性化的項目流程。簡化標準流程，增強本身須要的部分，下面咱們舉個例子，如下面四個階段作相應的流程控制：

（1）需求階段流程控制

需求是一個項目最先的階段，因此咱們也需求從這個方面開始進行控制。如從如下幾個方面進行控制：

• 項目啓動階段：在需求評審以前，則產品給項目相關人員發送一封項目啓動郵件。簡單描述項目狀況，並安排需求評審的相關事項。
• 測試用例評審：在需求評審完成後，測試人員須要開始設計相關測試用例，併發起測試用例評審。以確認項目相關人等對需求理解一致，防止需求遺漏等現象。若有變更，回覆項目啓動郵件，周知你們。
• 需求同步：在開發過程或是測試過程當中若是需求有任何變更，必須同步相關人員，不能開發和產品一商量就改了需求，測試人員不知道相關狀況。回覆項目啓動郵件，周知你們變更的內容。
• 新增長需求控制：需求要項目啓動的時候，可能沒有想的那麼細，若是在開發或是測試階段，須要增長相應的需求，必須三方人員一塊兒評估新增長內容的工做量。若是不影響項目排期，能夠添加；若是影響了項目排期，就須要評估是延期仍是再新開需求。並回復項目啓動郵件，周知你們評估的結果。

（2）     提測試階段流程控制

      在需求開發階段，若是有必須須要進行設計評審，對設計方案，實現細節進行評審。固然這個評審能夠在開發內部進行，產品和測試參加與否均可以。可是提測試階段也有相應的須要控制的部分：

•  冒煙測試必須經過方可提測試：在測試評審結果後，測試人員會提供冒煙測試用例給開發進行自測；開發人員必須自測冒煙測試，全部冒煙測試用例經過後方可提測試。開發人員在提測時，回覆項目啓動郵件，把冒煙測試的詳情狀況周知你們。
•  自測版本必須是提測版本：開發人員在自測的時候，必須是提測試的最終版本，不可在本地測試，而後打包後發現出了問題，不能夠測試。若有可能，能夠按測試的方法來部署環境，進行自測試。
•  若是冒煙測試經過不過，測試人員有權拒絕測試。根據經驗表示，若是冒煙測試經過不過，或是隻有部分功能實現的狀況下，測試人員的介入是無用的，此時每每浪費不少測試時間。等再次提測試的時候，先前測試過的內容還須要從新測試。爲了保證項目流程，合理利用各方資源，必須有權決定測試介入時間。在測試人員冒煙測試經過後，請產品進行初驗，以保證符合需求內容。冒煙驗收測試不管經過與否，都須要回覆項目啓動郵件周知你們。
•  提測文件必須全面，作到不遺漏。若是開發的文件較多，在提測試的時候必須保證相關的文件都進行的提測試，不能在測試的過程當中才發現文件漏提。若是發現這種狀況，回覆項目啓動郵件，周知你們，督促相關人員提升提測質量。

（3）Bug相關流程控制

    在測試過程當中，會發現很多Bug，固然不一樣的公司都會有不一樣的Bug管理辦法。Bug管理在流程控制中是很是重要的環節，須要從如下幾個方面考慮：

• 全部在測試中發現的Bug必須提到Bug管理平臺中：有些是測試人員的習慣，發現問題直接告訴開發人員進行修改；有些兒是開發人員不喜歡從Bug管理平臺上看本身的問題，這些兒都是很差的習慣，全部的問題必須記錄。不然就會形成問題的遺漏，也不便後期項目總結的時候進行問題分析。
• 開發人員必須按Bug優先級進行處理：有很多程序員喜歡按難易程序進行問題的修復，但是這不利於測試工做的進行。既然測試人員對Bug進行了分級，就必須按優先級來進行處理。
• 開發人員修復Bug須要及時更新狀態，測試人員按Bug狀態進行驗證測試。在測試過程當中，Bug修復狀況以管理平臺中的狀態爲準，沒有更新狀態的Bug按未修復處理，不予進行驗證測試。
• 上線的時候，若是存在Bug沒有修復，須要嚴格處理。若是到了上線日期，仍然有Bug沒有修復完成，必須認真處理。必須處理的Bug沒有修復，則不予上線。延期處理的分給產品請產品註明緣由，並回復項目啓動郵件予以說明。

（4）上線階段流程控制

    項目到了上線階段應該不過有太多的問題了，但是仍是會由於一些兒細節問題會影響上線的。因此在上線階段也不能放鬆：

• 項目負責人制定上線計劃，包括：a,上線須要的前期準備，相關權限，內容的申請；b,上線順序及相關負責人；c,上線後的後續工做。並回復項目啓動郵件，經過相關人等。
• 上線時相關人員必須在場，並肯定擁有相應的權限。通常項目若是到了晚上上線，有些相關人員若是通知不到，會發現上線的時候找不到人。或是上線人員沒有對應的權限，嚴重影響上線流程。
• 項目上線完成後，產品回覆項目啓動郵件，總結上線成果，並關閉項目。固然大的項目還會進行項目總結，進行相關內容的彙總與討論。

風險預警

      風險預警貫穿於整個項目的始終，任何階段若是出現了嚴重影響項目排期的問題，必須進行風險預警。郵件通知全部人員，並組織相關人員進行風險評估，同時同步評估結果，以便相關人員進行工做調整。

    經過上面四個階段作相應的保障，同時在各個階段把控相應的產品，以及嚴格確認可否進行下一個階段，就能基本保障一個項目流程不會出現嚴重的問題。固然還能夠根據本身團隊的特色，強化或是弱化相關的內容。

三，項目流程的保障因素

一個流程或是規章制度不管再完善，仍是須要靠人來執行和保障的，一樣項目流程也須要有相應的保障：

（1）項目負責人重視項目流程

    一個項目須要有相關的負責人，或是項目經理，或是產品，也能夠是開發或是測試。不論是任何人，必須嚴格把控項目流程，注重相應該階段的產出，若是有問題及時找相應的人員來處理。

（2）參與人嚴格遵照

    項目的參與人必須嚴格遵照流程，按規則執行相應的步驟，產出相應的輸入。積極改正之前很差的習慣，如部分測試，不提bug,提測試時不進行冒煙測試等等。

（3）測試嚴格把關並擁有相關權限

測試人員是項目質量的驗收人員，必須在項目流程中進行嚴格的把關。任何階段輸出給測試的產出不符合要求，都要有權進行拒測，或是要求作出明確的說明。若是測試人員沒有任何權限，項目流程在測試環境確定執行很差。

（4）領導的大力支持

     作好整個項目流程的把控，沒有領導的支持是不夠的。

     首先，領導須要承認咱們在項目流程控制中的工做，若是不承認，相關人員就沒有動力。

     其次，支持相關人員作相應的控制，好比說，若是測試說冒煙測試不經過不能測試，產品或開發找到了領導，領導讓聽產品或是開發的，而不是聽測試人員爲何不能測試，那也很差進行流程控制。

     再次，領導不能作打破流程控制的指示，如直接對相關人員下達命令，讓作什麼樣的工做，而這個工做有可能影響整個項目的流程等等。

    整體來講，項目流程控制在前期執行起來至關痛苦，須要改變不少咱們之前的習慣。作至關多的額外工做，大部分人仍是會抵觸的，由於不爽嘛！但是一旦流程化執行起來後，後續工做就會很是容易，項目優化，項目交接，新人介入等等。因此建議先重新項目，週期比較長的項目引入流程化，慢慢改變你們的很差習慣，嚴格按流程進行相應的工做。