必要的流程
對于流程的認識可能每個項目團隊的理解都有所不同，但無論如何必要的流程對于軟件質量的保證是一種保障。需要設計審查以確保設計質量；需要將單元測試、靜態分析和動態分析作為流程以控制編碼質量；需要代碼版本控制流程來實施并行開發；需要需求管理流程來確保開發部門開發出用戶所需的產品以及保證測試部門沒有遺漏地對產品進行驗證；等等。一個軟件項目是否存在必要的流程是檢驗它是否是“手工作坊”的重要指標，無論項目的規模大小，必要的流程都應當是不可或缺的，否則只能完全靠人的主觀意識去行事，而這不可避免地更容易犯錯。流程的目的在于幫助避免沒有必要的“低級錯誤”，或者說是通過外在的、具體的方法幫助項目團隊維持良好的工作秩序。
當然，流程不是萬能的，千萬不要迷信流程的作用，建立與自己的項目團隊相匹配的流程才有意義，否則會出現團隊為了流程付出很大的努力卻效果不好，進而得出 “流程無用論”。如果發現流程的運用使得團隊沒有時間去做真正有意義的事情，那應當進行流程上的反省，以找到其中沒有價值的內容并改進之。千萬不要為了流程而“流程”，在國內存在大量的采用流程卻不能理解其本意以及不能很好執行的例子。流程的運用不在于只執行流程所規定的動作，而在于明白其背后的思想，以及站在開發團隊的角度去理解每一個動作所帶來的有利于按時交付高質量軟件的益處。
要讓流程在組織中得到真正地被運用需要時間，流程剛部署的開始不可避免的會招到抵觸，這是因為部署流程其實就是改變人的行事習慣，而人一旦涉及自己行為的改變則多少都會有些情緒。要使流程做到深入人心，應當從上層領導開始重視并深刻理解其所給組織帶來的意義，并進而鼓吹“這是我們走向成功的必要保障”。如果上層領導不能深刻理解流程的作用，那可以斷言被部署的流程在組織中極有可能得不到真正有效地運用。
流程最好是與項目的開發環境進行“無縫”整合，并做到對于流程的運用所需的努力盡可能的小，總的來說就是提高其可操作性。另外，流程還應盡可能的工具化或自動化，一個運用起來很復雜的流程注定其將會是另一個擺設。
敏捷軟件開發在最近的十多年來很受歡迎，它的核心思想就是“簡化”，將軟件開發的流程進行簡化。當然，簡化的目的不是為了偷懶，而是為了更加能應對軟件開發過程中的不確定性以盡可能保證項目的成功。筆者認為，運用敏捷思想指導軟件開發需要較高的水平，它的本意是需要使用者先理解軟件行業的特點，再進行簡化�？墒�，有些項目組其實根本沒有什么流程，只是因為沒有才將自己稱之為運用了敏捷的思想，更有甚者將敏捷中的片面內容當做了不做某事的借口。比如，敏捷軟件開發中對于編寫軟件設計文檔的要求就相對低，但有些人卻將其當作借口說“你看，敏捷思想就不提倡寫文檔”。
合適的工具
對于軟件開發的流程靠什么去支撐它呢？那就是工具。對于設計需要UML工具進行支撐；對于代碼的靜態分析和動態分析則需要相應的分析工具進行支撐；對于代碼版本控制需要版本控制工具進行支撐；對于需求管理則需要需求管理工具進行支撐；等等�？梢哉f，軟件的開發離不開合適工具的支撐，否則項目組很有可能是另一種形式的“手工作坊”。
項目組應當樂于去尋找和運用新的工具以簡化流程進而提高開發效率，在開源軟件大行其道的現在，有著大量的開源工具可以幫助提高軟件質量和開發效率。比如，Splint是開源的代碼靜態分析工具，Valgrind是開源的代碼動態分析工具，Gcov是開源的代碼覆蓋工具，Cvs、Subversion和 Git是開源的源代碼管理工具，Bugzilla則是開源的缺陷跟蹤工具，等等。
開發文檔
前面談到軟件高質量還應當包含高效地工作，而文檔在這一點就起著非常重要的作用。文檔可以包括軟件設計文檔、用于指導開發人員進行開發工作的開發指南，以及用于指導測試工作的測試手冊，等等，這些文檔都能幫助團隊提高開發效率。
隨著敏捷軟件開發思想的興起，有些開發團隊將不寫文檔變成了理所當然的事，但作者認為軟件開發不寫文檔等同于慢性自殺。文檔的重點在于闡述設計思想或工作方法，其著力點應當是 “點到為止”地將問題說清道明，而不在于“又長又臭”。寫文檔的目的到底是什么呢？為了夠長才顯得專業？還是為了溝通和提高效率？如果將加強溝通和提高效率當作是寫文檔的目的，或許能讓寫文檔一事變得更簡單一點，進而也會有更多的人愿意去寫。另外，一頁紙能寫完的如果用了兩頁紙，那就會造成閱讀這一文檔的每一個讀者都浪費時間。作者在工作中審查設計文檔時，會通過問“這段話寫在這的目的是什么？會不會有些多余呢？”，或“這里好象缺少一點背景知識？”等問題，來提醒文檔作者是否可以簡化文檔或將其寫得更易懂。
除了設計文檔，開發指南、測試手冊這類文檔也非常的重要。對于大型的項目，其中存在很多的工作流程，包括如何準備開發環境、編譯等等。有了指導性文檔以后，當項目有新人加入時，它們有助于顯著地節約項目組培養新人的時間，否則新人的加入還得讓老員工花不少時間去幫助他，進而加劇了人力資源缺乏這一困境。指導性文檔還有助于幫助項目組沉淀開發活動中的知識，大型項目不可避免地在開發過程中會出現很多非軟件缺陷問題，而在指導性文檔中記錄問題的解決方法有助于加速開發進程。
寫好的文檔不應成為擺設，讓文檔成為真正有用的關鍵是倡導一種習慣于使用文檔的團隊文化，要做到這一點，文檔的作者是關鍵。就作者的觀察，不少人寫了文檔以后，別人向他請教已寫入文檔中的相關內容時，他卻仍樂此不疲地回答，但這不是一種讓大家形成使用文檔習慣的好方法。作者在碰到這種情形時往往會說，“文檔中已經寫了這方面的內容，你可以先看一下，如果有不清楚的地方我再修訂它”，只有通過這種方法大家才會重視使用文檔以及提高文檔的書寫質量。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
