這是筆者參加極客時間21天打卡第二週，分享和總結確實是個很好的學習方法，這一週我又對軟件工程多了一些理解，每日總結內容如下：
第八天
今天學習了寶玉老師的《軟件工程之美》中的“07|大廠都在用哪些敏捷方法？（下）”，以下是我的總結：
寶玉老師舉的實施敏捷開發小組的日常的例子跟我們的還不太一樣，人員配置上我們是按職能劃分了客戶端、前端、後臺、運營、產品、設計、測試組，規模會更大一點。分工基本上類似，產品寫完需求設計文檔會拉起相關人員進行宣講，然後我們會進行工作量量評估，後面每天的都是完成日常開發工作，需求和修復bug都是在週期內完成的。我們每個需求都會設置一個Owner，由Owner去負責整個需求的進度根據和推送，關於開發會基於主幹拉起feature分支進行特性開發，開發完成之後合入主幹，發佈之前會拉起release分支進行系統測試，最後纔是發佈上線。說實在我們其實也不是嚴格意義上的敏捷開發，但價值觀和原則是對齊敏捷開發的。我覺得這裏比較好的地方就是培養Owner意識，需要每個人都爲這個需求負責，不好的地方就是週期迭代需要加班，時間點卡的比較死，開發疲於應對需求，少了點時間去做一些技術建設和成長思考。
第九天
今天學習了寶玉老師的《軟件工程之美》中的“08|怎麼平衡軟件質量與時間成本範圍的關係？”，以下是我的總結：
這節課內容對我們日常工作很有啓發作用，質量、成本、範圍作爲軟件工程項目管理的金三角，是我們把項目做成的必然要素，我們都想用儘可能小的成本上去產出高質量的產品，這是個很美好的願景。但在真實的軟件項目開發過程中，只能在這三角中不停做妥協和平衡去尋找最優解。
第十天
今天學習了寶玉老師的《軟件工程之美》中的“一問一答第一期”，以下是我的總結：
基礎理論一共有8講，分別是：
- 01|到底怎麼理解軟件工程？
- 02|工程思維：把每件事都當做一個項目來推進
- 03|瀑布模型：像工廠流水線一樣把軟件開發分層化
- 04|瀑布模型之外，還有哪些開發模型？
- 05|敏捷開發到底是想解決什麼問題？
- 06|大廠都在用哪些敏捷方法？（上）
- 07|大廠都在用哪些敏捷方法？（下）
- 08|怎麼平衡軟件質量與時間成本範圍的關係？
從這8講當中我重新溫習了軟件工程的一些基礎概念和思考了自己實際工作中所實踐的一些開發模型，比如敏捷開發和迭代增量開發，MVP最小可行版本等，以前只是知道我們在用，但沒有深入去理解每個概念的背後到底在解決什麼問題，這個專欄最大的價值在於讓我重新理解了軟件工程這門學科，它能讓程序員更好的去掌控實際的開發工作，而不是被動去接受需求，要從更全局的視野去思考軟件質量和時間成本之間的關係，從中做出最優的決策。專欄裏面有很多人的分享都很有參考意義，着實讓我擴展了視野。
第十一天
今天學習了寶玉老師的《軟件工程之美》中的“09|爲什麼軟件工程項目普遍不重視可行性分析？”，以下是我的總結：
軟件項目不特殊，只要項目具備了可行性研究的條件就需要去做，不然可能會帶來不必要的麻煩，如果不具備可行性，則應該及時調整方案或及時止損。
做出科學的可行性分析，通過合理的方式反饋和建立可行研究的意識來降低項目失敗的概率。
面對創新，可行性研究不是攔路虎，而是能夠做出更準確的判斷過濾掉不靠譜的創新想法。
軟件項目的可行性研究，主要從以下幾個方面入手：
- 經濟可行性（看投入產出比和長期利益）
- 技術可行性（是有有專業的人，技術上解決不了的問題是否存在）
- 社會可行性（法律、道德、社會影響等，比如開源協議）
第十二天
今天學習了寶玉老師的《軟件工程之美》中的10 | 如果你想技術轉管理，先來試試管好一個項目，以下是我的總結：
技術人員轉管理的障礙
過於關注於技術細節，可能會忽視跟其他人的溝通，思考問題不夠有大局觀，不關注項目進展。
如何管理軟件項目？
管好人
人主要是你的客戶和項目成員，比如我們做教育產品的，我們的產品用戶就是我們的客戶，負責這個項目的開發人員、產品、設計、運營、測試等都是項目相關人員。
客戶要管理好預期，我們要按時按質交付高質量的產品和內容，讓客戶對我們的產品產生經濟價值，比如付費行爲。
項目成員需要用流程和規範來完成高效協作，按時完成產品迭代。管好事
軟件項目的事就是完成項目目標，而完成目標是一系列過程，要做好項目管理也就是要做好對軟件開發過程的管理。
- 選擇合適的開發模式，比如迭代模型或者增量模型
合適的開發模式都有配套的流程規範和工具，來保證開發模式正確的被執行- 制定好項目計劃
舉個我們產品的迭代計劃的例子：
需求宣講截止時間11.06
功能開發完成時間11.20
功能測試完成+bugfix完成 11.27
後臺發佈+拉發佈流11.28
系統測試+bugfix完成 12.04
checklist+內部體驗 12.05
灰度一週 12.05-12.11
全量上架12.12
具體節點和截止時間要完成的事情。- 控制和跟蹤計劃，做好風險管理
讓團隊成員正確評估工作量，早點拋出風險點，然後可以通過調整期望值，比如控制範圍和時間來達到目標。
第十三天
今天學習了寶玉老師的《軟件工程之美》中的11 | 代碼未動，計劃先行，以下是我的總結：
軟件項目管理中的計劃是保證項目在執行過程中不會陷入一種無序和混亂中。
對於程序員來說也應關心計劃，這可以讓我們更好的安排實際的工作，比如你需要關心執行過程中是否存在風險，任務之間存在的依賴關係。
制定計劃的步驟一般有以下三個步驟：
- 任務分解
任務分解可以按照WBS（工作分解結構）來拆分，將大階段拆分爲小階段，將小階段再進一步拆分爲具體的任務。- 估算時間
估算時間不能由項目經理來做，因爲可能會存在偏差，開發人員和項目經理需要充分溝通來消除這種偏差，讓開發時間的估算變得更加合理。- 排任務路徑
任務可能不是串行的，排路徑要根據任務之間的關係，資源佔用情況，排出合適的順序。項目計劃制定好之後還沒有完事，還需要進行跟蹤和根據實際情況進行調整，進度跟蹤可以是項目經理定期收集或者項目成員主動彙報。也可以參考敏捷的一些實踐，比如每日站會和看板來跟蹤。
第十四天
今天學習了寶玉老師的《軟件工程之美》中的12 | 流程和規範：紅綠燈不是約束，而是用來提高效率，以下是我的總結：
好的流程規範不是約束，而是用來提升團隊效率的。比如指定代碼規範，讓大家寫出差別不大的代碼，提升了代碼可讀性又增加了可維護性，別人接手起來也不至於太困難。
關於這點我是很認同的，規範能讓團隊中能力不同的人都能夠寫出好的代碼，也能夠讓新人更好的融入團隊。
制定流程規範一般有四個步驟：
第一步：明確要解決的問題
第二步：提出解決方案
第三步：達成共識，推廣執行
第四步：持續優化，不斷改進近段時間我在負責關於熱更新在項目落地的事情，也制定了相應的流程規範，基本是按照這四個步驟在做。
規範是爲了提升效率，如果太過依賴人去執行，反而可能降低了效率，所以應該想辦法通過技術手段來幫助人去執行規範，還是代碼規範的例子，不可能每個人都熟記裏面每一條規則，我們可以藉助IDE或者一些代碼格式檢查工具來輔助開發人員去檢查規範。
最後
第二週的內容正式進入項目規劃篇，這周我學習到了關於可行性分析對軟件項目的重要性，技術轉管理需要跨越的阻礙，怎麼做項目計劃，如何制定流程和規劃，這些內容都是代碼之外的功夫，而這些功夫能讓自己走得更遠，對我來說需求不僅僅只是個需求，項目的成功是有套路的。用更好的方法去指導自己的日常工作，不至於埋頭工作忘了擡頭看天。下週會繼續分享我在學習軟件工程之美學習的內容，謝謝。
歡迎關注公衆號：巫山老妖
