成年人之間的客套，不能信，尤其是IT行業。

最近在忙啥？一起吃個飯？

不了不了，手里還有幾個項目呢，下次吧

“項目”二字，彰顯的是身份，是能力，不說項目多大，不談擔任什么角色，只要我能參與到這個項目中，我就是厲害！

項目組的人表面上光鮮亮麗，背地里絞盡腦汁，進入項目組中，就會發現，在軟件項目從0-1中，時間是按照“月”來計算的，幾個月甚至幾年，才能完成一個項目。

如果交給你一個軟件項目，你會怎么做？

今天就帶大家從0-1了解軟件項目的那些事兒，初學者可以了解在軟件項目工程中，主要涉及到哪些崗位以及他們的工作職責；經驗者可以了解軟件項目工程中，不同的崗位工作對于項目的定位是什么，如果要團隊內部協作的話，有什么思路來提高認識。

項目不是一錘子買賣

項目不是一錘子買賣，所有崗位人員并行多任務操作，期間的崗位人員需要的不僅是各司其職，還需要相互和諧。

在項目開始前，首先要這明白幾個問題：

梳理項目內部是如何協作的？以及為何這么協作？

軟件項目中的協作流程是什么？

各個崗位在流程細節上又是如何協作的？

軟件項目在產生時，經歷的各個階段，都由不同崗位人員參與，他們的定位更加明確，只有在進行項目協作時，考慮項目的生命周期、項目的迭代流程、項目的協作流程和高效協作方式，再體會不同崗位是如何項目協作的，才能營造良好的協作氛圍。

項目生命周期

項目的生命周期大致分為5個階段：調研、設計、研發、測試和運營，整個周期呈現環形，方便后續進行項目調整。

調研：多方位評估現狀，探索發現最符合公司利益的方案，金點子很重要。

設計：從產品的原型、UI界面和項目里程三個方面考慮，畫大餅很重要。

研發：根據團隊人員數量和技術水平，合理拆分任務，做項目很重要。

測試：對照產品需求文檔、UI設計等因素下手，找對茬很重要。

運營：把環境做好，等待符合要求的穩定代碼的到來，發布到生產服務器中，以技術的角度，將項目維持好，維穩定很重要。

不同階段主導團隊該做什么？

調研和設計 ：產品團隊主導，產品原型設計師、UI設計師，項目里程根據其他團隊的能力逐漸梳理出來，不要貪快做不到。

研發：研發團隊主導，其他團隊參與。對于設計階段的內容，產品原型由后端研發人員來完成，UI界面由前端研發人員來完成，前后端團隊間把控好數據接口的標準。

測試：測試團隊主導，其他團隊參與。根據實際情況，依據產品原型的功能和UI界面的效果，進行各種功能性測試和非功能性測試以及其他測試，最終保證過我收的東西是合格的。

運維：運維團隊主導，其他團隊參與。主要做的是環境標準化、業務流程化、操作自動化等。

就以單一的基礎的項目任務來說，運維人員工作的時長，要遠遠的超出其他人員對于項目的付出， 能力有多大，責任就有多大。

公司組建一個團隊不容易，不可能一個人干活，其他人就靜靜地看著，為了讓大家創造出來價值，實現個人的能力升華，也為了讓公司更大程度的開發員工的價值，讓員工高效的工作，是我們最終的目標。

對于項目來說，一個無限循環的∞，而對于團隊個人來說，進入到了一個，剛做完A就開始B，剛做完B就開始C的無限循環中，最終一個團隊的所有人都在緊張而忙碌的并行工作，為了讓公司開發最大的價值而努力奮斗。

前半個循環參與的部門多，所以需要一個協作機制 AGILE，保證信息的交流是精確的，后半個循環是一個部分自己內部消化的，所以無需其他的協作機制。

怎么合理的保障流程？

相關的產品人員，分析現狀問題，發現梳理需求方案，確定最終方案思路，因為方案太大無法一下子搞定，所以將方案細化成一個個有趣的故事地圖，為各個團隊描述我們如何磨刀霍霍的一步一步將大象關進冰箱里。

拆分完成的故事地圖任務很多，為了保證產品能夠如期的完成，有我們的協調人員組織大家開一個計劃會，群策群力，都說說自己怎么辦，怎么干，需要花費多少時間，最終根據時間節點，將任務按照優先級進行排列，田忌賽馬的方式，優先完成核心功能，輔助的功能隨后以迭代或者其他方式來完成。

產品人員根據梳理出來的實施內容，準確的向實施團隊（開發、測試、運維）描述主旨，保證實施方向不偏，然后實施團隊開始著手，圓環套圓環的方式將所有的任務列表中的內容完成，并逐步發布到生產服務器，最終完成交付產品的目的。執行過程中，每日的站會可以讓大家互相周知我們彼此在干什么，協作起來有了知根知底的前提。

產品發布前，通過回顧評審會，向產品人員演示我們的產品成果，評審成功，產品最終發布，然后進行反思大會， 積極的開展我黨的批評與自我批評大會，讓整個團隊氣質高昂起來，優點發揚，劣勢規避，積極的為下一個版本的產品做好處。

這個流程簡單來說，可以理解為敏捷研發的scrum：三角色：PO、SM、DevTeam三工件：產品地圖、任務列表、完成報告五事件：用戶故事地圖梳理、工作計劃會、每日站會、回顧評審、反思會等。

協作流程中，開發、測試、發布緊密的結合在一起，這部分的工作是否高效，直接決定了整個項目協作流程是否能夠通順的走下去。而這部分的工作就是平常所說的持續集成和持續交付的主要核心 操作對象：永遠存在代碼倉庫里面的“代碼”

1、研發人員在自己的本地環境開發代碼，開發完畢后，將代碼推送到代碼倉庫。

2、沒人敢保證自己研發的代碼不會出現問題，所以為了保證代碼能夠在生產環境正常運行，所以將代碼先后拉取到公司開發環境、測試環境、預發布環境，對代碼進行不同級別的測試和驗證，最終保證代碼處于隨時發布的穩定狀態。

3、運維人員，將經過層層測試保證的穩定代碼，拉到生產環境中，部署成功后，開放相關的權限，最終用戶可以看到相應的效果了。

4、整個流程，純手工來做的話，眼就瞎了，所以為了省事的同時也提高工作效率，做了如下兩個動作：將所有的代碼獲取流程、代碼的部署運行流程自動化 -- jenkins之類的持續交付工具。將所有的環境標準化、流程化、實現基礎環境的快速呈現 -- Ansible、Saltstack 實現配置的統一標準化管理，Docker、Kubernetes實現業務應用環境的快速標準化。

DevOps來了

思路雖好，方案雖好，架不住團隊里面有壞人，總想著有人要害朕。所以一個個部門領導要宣誓主權，導致部門之間出現各種交流障礙，最終害人害己。

因此需要一種軟性的交流思路，能夠打破不同部門的協作思路，推己及人，互相理解，于是DevOps來了。

用戶訪問流程：用大家最常見的場景作為入口，理解團隊協作的時候，都干了什么。

文件查找流程：我看到的文件，是怎么找到的？他保存在哪里？

文件產生流程：我們看到的文件，都是怎么產生的，有什么區別，都是誰做的？

加速訪問流程：頁面效果好不好，誰說的算？ 客戶。那么客戶對什么感興趣？時間。

基本訪問流程：用戶在瀏覽器輸入域名，通過互聯網找到對應的主機，主機上的應用程序找到到處是空白窟窿的文件，通過程序機制到后端數據庫獲取數據，然后再空白窟窿的文件里面填充，形成完整的頁面，最終返回一個完整頁面數據，完整的頁面數據，在用戶瀏覽器渲染成一個完美的頁面。

問題：

我怎么知道要找的主機在這里？

我怎么知道要找的文件在哪里？

我怎么知道頁面到處都是窟窿？

我怎么知道可以從后端數據庫獲取具體的數據？

我怎么知道獲取到的數據，可以填補空白頁面中隨處可見的窟窿？

查找主機流程

根據互聯網的域名管理系統，解析出來網站的服務器ip

因為群眾里面有壞人，所以為了安全，不讓所有人看到真實的服務器

根據用戶的請求，由反向代理服務器將請求轉交給真實服務器。

全球的根DNS實例1381個（截止到今天），由12個根dns運營商來管理，每個DNS實例的服務器數量未知，我們國家有37個根DNS實例（圖中數據沒有問題，因為它把越南的3個算到了香港的那個區域中）。

用戶在瀏覽器輸入的地址主要有三部分組成：

域名 - 解析為ip地址，目的是找互聯網上的主機地址端口 - 請求的服務在服務器上以端口的樣式作為唯一入口。url關鍵字 - 請求的資源到底是什么，根據這個關鍵字有程序來識別。

nginx web關鍵查找url關鍵字流程

通過server配置段內部的listen監聽端口接收用戶請求，根據location匹配的關鍵字，查找對應的資源對象，到root指定的目錄下找index匹配的文件。

Django web程序查找url關鍵字流程

nginx反向代理請求給Djangoweb應用程序，應用程序的路由系統匹配路由關鍵字，交給后端的view視圖系統，views視圖系統根據request對象識別相關參數，按照內部的函數邏輯對數據進行整體處理，借助于后端的數據庫引擎基于模型類從后端數據庫中獲取數據，根據render函數找到到處是窟窿的模板文件，然后基于context的屬性將數據和模板整合為一個完整的頁面。然后原路返回給nginx程序，經Nginx軟件，將數據返回給用戶瀏覽器端。

要創建頁面，就要了解頁面的表現樣式，目前互聯網上的頁面樣式，主要有這么三類：移動端的上中下結構，瀏覽器端的上中下結構，瀏覽器端的左右上下結構。

樣式雖多，但是生產的方式主要有兩種：干脆利索：直接在后端生產完整的頁面，最后統一返回給用戶方便快捷：先返回頁面框架，根據實際的情況，通過大量的局部請求，逐漸獲取頁面中的部分數據

整合樣式1：web程序端的項目代碼邏輯，先獲取模板文件，經由ORM工具從后端數據獲取數據，通過render函數將數據和模板整合為一個完整的頁面，返回給用戶，在用戶端進行正常的渲染。

整合樣式2：將之前后端程序一個人做的事情，拆分為兩個地方來做，前端程序和后端程序，前端程序通過axios等方式，根據情況在用戶發起局部請求的時候，從后端獲取針對性的數據，然后再瀏覽器端逐一的加載到一起，最終形成一個完整的頁面。

所謂的用戶體驗，就一句話，用戶訪問的時候，越快越好，享受山大留學生的皇帝后宮式體驗。網絡上的用戶體驗策略多種多樣，我們直接從頁面本質上入手。

如果一個頁面中的子文件對象少一點，頁面加載的速度就會快很多，因為沒有資源獲取的等待+阻塞時間了。

每個頁面都有自己的域名地址，如果大部分的文件都在同一個域名下，后面的資源就無需重復的域名解析，使用dns緩存記錄，可以大大提高文件的獲取效率。

頁面中的子文件對象存放在不同的主機中，如果一個在河南，一個在荷蘭，那么獲取的方式就很慢。但是如果所有的文件都在同一個局域網中，那么所有的文件獲取的速度就會非?？臁?/p>

所以基于 減少頁面對象、減少域名解析、使用同構網絡等方式，可以從根本上實現頁面高效訪問的目標。

雖然頁面的優化策略非常多，但是我們主要是從頁面訪問流程來描述不同崗位的協助思路，所以其他的優化策略，不再我們的思考范圍中。

崗位協作梳理

Q：為什么這個項目的訪問流程中，沒有過多的描述產品崗位和測試崗位？

A：研發出來的產品樣式和流程就是產品人員設計的，研發之前產品人員已經和研發團隊徹夜進行心連心的交流了。

只有研發出來的代碼，才會進行代碼質量測試，只要能夠給用戶看到的，都必須經過測試人員的火眼金睛的找茬能力校驗。

因為這兩個崗位的職責清晰，所以我們沒有過多的描述，主要集中的體現在了研發和運維的角度。

Q：用戶訪問流程有什么重要的？

A：就是很重要，這個流程都不理解，我們怎么互相達成一個普遍的認知，而且這件事情就是我們做事情的根本。

Q：用戶訪問流程有什么重要的？

A：就是很重要，這個流程都不理解，我們怎么互相達成一個普遍的認知，而且這件事情就是我們做事情的根本。

Q：頁面的查找流程，研發人員和運維人員的定位是什么？

A：主機的查找流程，涉及到 DNS的解析、TCP/IP的三握手四斷開，nginxweb軟件的配置、反向代理的配置、真實web服務器的部署和管理，這些都是運維人員的 核心競爭能力。

頁面的查找流程，涉及到web軟件的配置、反向代理的配置，這些是運維人員的崗位需求。后端django程序的頁面查找是研發人員的主要崗位要求，內部代碼的邏輯不通，何以通全程？

Q：頁面的加速流程，不同崗位人員的定位是什么？

A：頁面加速流程是一個綜合性的項目維護過程，涉及到哪些頁面應用需要進行加速、用戶對哪些應用頁面感興趣，運維團隊采集數據，產品團隊進行功能梳理或者版本功能計劃。

Q：怎么進行頁面加速策略實施？

A：運維團隊采集數據，研發團隊實現多種靜態化的方案，最終由運維團隊來落地。

Q：為什么對頁面本身的業務邏輯對象來進行加速訪問策略？

A：這些東西對于研發人員或者運維人員來說，都比較好入手，好處理。

Q：還有沒有其他的策略可以讓我們更好的完成頁面的加速流程？

A：有，不同的崗位都會有自己的思路來完成這個任務，但是很多人不愿意干，因為沒有動作，就沒有傷害。

編輯：jq