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

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

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

“項目”二字，彰顯的是身份，是能力，不說項目多大，不談?chuàng)问裁唇巧?，只要我能參與到這個項目中，我就是厲害！

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

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

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

項目不是一錘子買賣

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

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

梳理項目內(nèi)部是如何協(xié)作的？以及為何這么協(xié)作？

軟件項目中的協(xié)作流程是什么？

各個崗位在流程細節(jié)上又是如何協(xié)作的？

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

項目生命周期

項目的生命周期大致分為5個階段：調(diào)研、設(shè)計、研發(fā)、測試和運營，整個周期呈現(xiàn)環(huán)形，方便后續(xù)進行項目調(diào)整。

調(diào)研：多方位評估現(xiàn)狀，探索發(fā)現(xiàn)最符合公司利益的方案，金點子很重要。

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

研發(fā)：根據(jù)團隊人員數(shù)量和技術(shù)水平，合理拆分任務(wù)，做項目很重要。

測試：對照產(chǎn)品需求文檔、UI設(shè)計等因素下手，找對茬很重要。

運營：把環(huán)境做好，等待符合要求的穩(wěn)定代碼的到來，發(fā)布到生產(chǎn)服務(wù)器中，以技術(shù)的角度，將項目維持好，維穩(wěn)定很重要。

不同階段主導(dǎo)團隊該做什么？

調(diào)研和設(shè)計 ：產(chǎn)品團隊主導(dǎo)，產(chǎn)品原型設(shè)計師、UI設(shè)計師，項目里程根據(jù)其他團隊的能力逐漸梳理出來，不要貪快做不到。

研發(fā)：研發(fā)團隊主導(dǎo)，其他團隊參與。對于設(shè)計階段的內(nèi)容，產(chǎn)品原型由后端研發(fā)人員來完成，UI界面由前端研發(fā)人員來完成，前后端團隊間把控好數(shù)據(jù)接口的標準。

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

運維：運維團隊主導(dǎo)，其他團隊參與。主要做的是環(huán)境標準化、業(yè)務(wù)流程化、操作自動化等。

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

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

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

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

怎么合理的保障流程？

相關(guān)的產(chǎn)品人員，分析現(xiàn)狀問題，發(fā)現(xiàn)梳理需求方案，確定最終方案思路，因為方案太大無法一下子搞定，所以將方案細化成一個個有趣的故事地圖，為各個團隊描述我們?nèi)绾文サ痘艋舻囊徊揭徊綄⒋笙箨P(guān)進冰箱里。

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

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

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

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

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

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

2、沒人敢保證自己研發(fā)的代碼不會出現(xiàn)問題，所以為了保證代碼能夠在生產(chǎn)環(huán)境正常運行，所以將代碼先后拉取到公司開發(fā)環(huán)境、測試環(huán)境、預(yù)發(fā)布環(huán)境，對代碼進行不同級別的測試和驗證，最終保證代碼處于隨時發(fā)布的穩(wěn)定狀態(tài)。

3、運維人員，將經(jīng)過層層測試保證的穩(wěn)定代碼，拉到生產(chǎn)環(huán)境中，部署成功后，開放相關(guān)的權(quán)限，最終用戶可以看到相應(yīng)的效果了。

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

DevOps來了

思路雖好，方案雖好，架不住團隊里面有壞人，總想著有人要害朕。所以一個個部門領(lǐng)導(dǎo)要宣誓主權(quán)，導(dǎo)致部門之間出現(xiàn)各種交流障礙，最終害人害己。

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

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

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

文件產(chǎn)生流程：我們看到的文件，都是怎么產(chǎn)生的，有什么區(qū)別，都是誰做的？

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

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

問題：

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

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

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

我怎么知道可以從后端數(shù)據(jù)庫獲取具體的數(shù)據(jù)？

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

查找主機流程

根據(jù)互聯(lián)網(wǎng)的域名管理系統(tǒng)，解析出來網(wǎng)站的服務(wù)器ip

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

根據(jù)用戶的請求，由反向代理服務(wù)器將請求轉(zhuǎn)交給真實服務(wù)器。

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

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

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

nginx web關(guān)鍵查找url關(guān)鍵字流程

通過server配置段內(nèi)部的listen監(jiān)聽端口接收用戶請求，根據(jù)location匹配的關(guān)鍵字，查找對應(yīng)的資源對象，到root指定的目錄下找index匹配的文件。

Django web程序查找url關(guān)鍵字流程

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

要創(chuàng)建頁面，就要了解頁面的表現(xiàn)樣式，目前互聯(lián)網(wǎng)上的頁面樣式，主要有這么三類：移動端的上中下結(jié)構(gòu)，瀏覽器端的上中下結(jié)構(gòu)，瀏覽器端的左右上下結(jié)構(gòu)。

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

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

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

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

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

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

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

所以基于 減少頁面對象、減少域名解析、使用同構(gòu)網(wǎng)絡(luò)等方式，可以從根本上實現(xiàn)頁面高效訪問的目標。

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

崗位協(xié)作梳理

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

A：研發(fā)出來的產(chǎn)品樣式和流程就是產(chǎn)品人員設(shè)計的，研發(fā)之前產(chǎn)品人員已經(jīng)和研發(fā)團隊徹夜進行心連心的交流了。

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

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

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

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

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

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

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

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

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

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

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

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

A：運維團隊采集數(shù)據(jù)，研發(fā)團隊實現(xiàn)多種靜態(tài)化的方案，最終由運維團隊來落地。

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

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

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

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

編輯：jq