從h3c實習開始到現在差不多有六年多，這六年裡，經歷專案越來越多，對與軟體開發流程的思索也越來越多。不同的公司，不同的專案，不同的管理方式，各顯優劣，一時之間也很難去評價。評價雖難，但想法是有的，好吧，我決定將這些想法記錄下來。
想法的開端就是敏捷模式。
第一次聽說敏捷這個詞，感覺就乙個字：快。 快，也一直是我追求的一種工作形態。但僅僅快是不行的，還要好。「快而好」是評判軟體管理模式的硬性指標。但這個「快而好」，是要建立在交付的前提下，同時，優秀的軟體管理模式也要能夠相容團隊人員能力的成長。所以，「面向交付，快而好，能持續增長團隊人員能力」是我對管理模式優秀與否的乙個基本評判。
如果僅從方**的角度考慮，敏捷大體上滿足了我對一種優秀專案管理模式的評判。
敏捷：方**的一種
方**是指以解決問題為目標的體系或系統，通常涉及對問題階段、任務、工具、方法技巧的論述。方**會對一系列具體的方法進行分析研究、系統總結並最終提出較為一般性的原則。敏捷作為一種方**，它的原則在於：個體與互動重於過程和工具，可用的軟體重於完備的文件，客戶協作重於合同談判，響應變化重於遵循計畫。這就是敏捷的四大宣言。
敏捷：方**建模
方**要運用到實踐，建模是必不可少的環節。敏捷建模（am）大體上包括以下幾個環節：
sprint（iteration），sprint plan，sprint review， sprint retrospect，standup meeting，demo，pair programming，refactoring。不同的專案可能會增加或裁減一些環節，但我目前碰到的專案這幾項基本都包含在內。下面是敏捷模式開發的乙個基本流程：
敏捷： 角色
scrum中有3種角色，分別是產品負責人（product owner）、scrum master 和 scrum 團隊，他們各自的職責如下：
產品負責人（product owner）
product owner 需要確定產品的功能和完成時間，並對產品的收益負責，要根據市場需求確定產品功能的優先順序。在每個sprint開始之前，product owner可以修改功能需求和優先順序。而且，product owner 有權決定接受或否決各個sprint的工作成果。
product owner 的角色通常由市場部門的人員或開發部門門內部主要使用該產品的人員來擔任，主要工作是根據市場需求確定產品功能，將其列入product backlog中，並為這些功能確定優先順序。
scrum團隊按照功能的優先順序，將它們從高到低分配到各個sprint中進行開發，這些被分配到乙個sprint中完成的功能就形成了sprint backlog。
在產品的整個開發過程中，product owner對於產品的需求可能會發生改變。他可以修改product backlog，以及增加某些功能需求、刪除某些功能需求、修改優先順序等，但這些行為只能在各個sprint之間進行。
scrum master
scrum master的職責是：負責監督整個scrum專案程序，調整專案計畫；確保開發團隊成員的能力能夠勝任產品的開發；促進團隊中不同角色的成員間充分交流和溝通，並負責為專案的進行掃清障礙；保證開發團隊不受外力的干擾和阻擾；掌握產品開發進度，參與每日scrum會議、sprint計畫會議和 sprint評審會議。
scrum master 通常由傳統開發中的team leader 來擔當。
scrum 團隊
一般由5~10個能全職工作的成員組成較為理想。
團隊成員橫跨各個職能，通常包括開發、測試、文件設計人員等。
敏捷：管理工具
jira：jira是atlassian公司出品的專案與事務跟蹤工具，被廣泛應用於缺陷跟蹤、客戶服務、需求收集、流程審批、任務跟蹤、專案跟蹤和敏捷管理等工作領域。jira中配置靈活、功能全面、部署簡單、擴充套件豐富，其超過150項特性得到了全球115個國家超過19,000家客戶的認可。
kanba：
敏捷：開發過程
如何進行scrum開發？
1）我們首先需要確定乙個product backlog（按優先順序排列的乙個產品需求列表），這個是由product owner 負責的；
2）scrum team根據product backlog列表，做工作量的預估和安排；
3）有了product backlog列表，我們需要通過 sprint planning meeting（sprint計畫會議） 來從中挑選出乙個story作為本次迭代完成的目標，這個目標的時間週期是1~4個星期，然後把這個story進行細化，形成乙個sprint backlog；
4）sprint backlog是由scrum team去完成的，每個成員根據sprint backlog再細化成更小的任務（細到每個任務的工作量在2天內能完成）；
5）在scrum team完成計畫會議上選出的sprint backlog過程中，需要進行 daily scrum meeting（每日站立會議），每次會議控制在15分鐘左右，每個人都必須發言，並且要向所有成員當面匯報你昨天完成了什麼，並且向所有成員承諾你今天要完成什麼，同時遇到不能解決的問題也可以提出，每個人回答完成後，要走到黑板前更新自己的 sprint burn down（sprint燃盡圖）；
6）做到每日整合，也就是每天都要有乙個可以成功編譯、並且可以演示的版本；很多人可能還沒有用過自動化的每日整合，其實tfs就有這個功能，它可以支援每次有成員進行簽入操作的時候，在伺服器上自動獲取最新版本，然後在伺服器中編譯，如果通過則馬上再執行單元測試**，如果也全部通過，則將該版本發布，這時一次正式的簽入操作才儲存到tfs中，中間有任何失敗，都會用郵件通知專案管理人員；
7）當乙個story完成，也就是sprint backlog被完成，也就表示一次sprint完成，這時，我們要進行 srpint review meeting（演示會議），也稱為評審會議，產品負責人和客戶都要參加（最好本公司老闆也參加），每乙個scrum team的成員都要向他們演示自己完成的軟體產品（這個會議非常重要，一定不能取消）；
8）最後就是 sprint retrospective meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結並討論改進的地方，放入下一輪sprint的產品需求中。
談談外包那些事
嗯，剛開始寫部落格，文筆不好，大家多多包涵，技術咱比不了，最近也沒怎麼研究，今天就簡單談談對於入職公司這方面的東西吧。我是今年來到北京，之前也是在地方的小公司做程式設計師，雖說壓力不大，但是技術和未來發展肯定是比不了北京，然後疫情一出，直接涼涼了，想想自己連媳婦都沒有，毅然來到北京尋求發展。說到找工...
談談建構函式的那些事
看過 c efficient 都應該明白以下幾點 1.最好有自己的拷貝建構函式 1.1 在函式引數為物件時，那麼在函式呼叫時，會呼叫拷貝構造生成乙個臨時物件 1.2 在函式返回值為乙個物件時，也會呼叫拷貝建構函式 1.3 拷貝建構函式一定要傳引用，如果穿乙個值，就會調拷貝構造，在乙個函式裡面，自己呼...
談談頁面效能的那些事
前言 一般頁面訪問的 258 原則，在2s內響應，很快，在2 5s內響應，速度還行，5 8s內響應，速度較慢，但還能接受，超過8s，槽糕透了。所以，頁面的效能首先決定了使用者的體驗，只有使用者體驗好才能給 帶來更多的使用者，除此之外，好的前端優化還能降低企業成本，提高公司利益。一 將靜態資源 例如j...