敏捷開發

敏捷教練(scrum master)

1.敏捷開發概念(對比傳統瀑布式開發)

從需求到設計

設計到編碼

編碼到測試

測試到提交產品

瀑布式缺點: 需求常常改,開發人員作增量交付,迭代式開發,並可以持續發佈

以用戶需求爲核心,進行迭代,按部就班進行軟件開發

敏捷強調適應性而非預見性 

項目需求發生變化, 項目團隊快速響應交付

 

軟件開發初期會切分紅多個子項目,各個子項目的成果都需通過測試,具有可視化,可集成,可發佈

主體軟件隨時可發佈,可交付給用戶

 

2.敏捷開發人員架構劃分

部門->項目組->小團隊

8-10我的的小團隊

小團隊裏有四個角色

PO:product owner 產品或業務負責人(產品經理或項目經理) 肯定產品前景原景 定義產品發佈內容 交付任務的優先級 交付時間

SM:Scrum Master 敏捷專家 (team leader) 熟悉敏捷開發模式和實施流程 

DEV:開發人員

QA:測試人員

 

3.敏捷開發相關的四個會議

　　1.敏捷計劃會 一個月一次月初 一個迭代開一次  任務明確 需求劃分 故事點劃分(小的任務點 1-3天完成的)

　　迭代或衝刺:Sprint 週期 一個月 因此每一年12個迭代

　　2.天天立會 對着任務展板 說 從昨天的立會到如今,我完成了什麼.從如今到明天立會,我計劃完成什麼.有什麼阻礙了個人進度,風險和困難拋出  讓leader進行抉擇

　　我這邊進度正常,沒障礙

　

3.敏捷評審會

　　向客戶和利益關係人展現 團隊在本次迭代中完成的工做並獲取客戶的反饋

　　4.敏捷回顧會 一個月一次月尾 

　　每一個迭代結束時進行,總結工做中的經驗和教訓 30-60分 整個團隊參加

　　　　1.定量分析 

　　　　迭代是否完成目標

　　　　收集評審迭代的度量指標 wiki的工具鏈上作

 

　　2.定性分析

　　　　主觀化的 那些好的保持 很差的中止 改進的,提建議,在下一個迭代改進

4. 平時寫代碼怎麼樣的, 任務如何完成

立會上領取故事點(任務點)

跑測試用例,功能測試徹底經過才能push

ci流程 代碼質量的保證 不經過重複上述流程 跑過了進入team leader那進行代碼評審code review 不經過 在循環改代碼直到經過  入庫 閉環反饋機制操做

 

合代碼宗旨

人與人不影響 最大程度隔離 作任務能全速推動

任務與任務中間不影響

不須要每一個人任務作完,主分支才能交給客戶,隨時隨地交付

 

敏捷是一種科學作事的方式 

從人員劃分 開會 故事點劃分 編碼裏的守護防禦系統 開發和代碼評審的方式

circle ci

 

 

 

 

 

 

 

 

竹薯

目前參與過公司的項目，公司專業從事敏捷開發，也比較成熟，能夠分享下其中的細節。

一、概念，能夠參考敏捷宣言，強調適應變化，四句指導

個體和互動 高於 流程和工具（動員每一個人積極交流，相互之間能夠 battle，頭腦風暴）；
工做的軟件 高於 詳盡的文檔（好的代碼是不須要註釋和文檔的，頂多有一些規範指南一類的在線協做文檔）；
客戶合做 高於 合同談判（真心實意爲客戶創造價值，而不止於眼前的功能交付，這個很難，由此還專門有一個角色去 control 這件事）；
響應變化 高於 遵循計劃（計劃是趕不上變化的，隨時改需求隨時變更迭代計劃，有迭代的概念）；

基於於右邊，而更注重左邊的價值，並非說徹底拋棄傳統的瀑布式開發。

二、人員架構

由於公司沒有所謂的各類領導，這裏就說下交付組裏，我所見的一些角色，也是天天在一塊兒工做的小夥伴：

PM：項目管理者，這裏不是項目經理，負責和客戶籤合同，各類會議的組織者，沒有項目經理那種權利
BA：業務分析師，專門和客戶談需求，超強的交流和控制客戶的能力，幾乎天天都和客戶泡在一塊兒開會過需求，瘋狂開會，驅動客戶（咱們組的BA是御姐型的，氣場極強）
QA：測試人員
DEV：開發人員，其中有掌握技術話語權的 TL

PO：比較特殊，是客戶某的部門領導人，通常和 PM 單獨溝通，幾乎沒出現過，網友同樣的存在

一個團隊通常 1 PM、1 BA、1 QA 、6 DEV (三前三後，至少兩個TL)

這裏沒有 MS，因此每一個人都是 SM，233333

來自安卓客戶端2019-07-06 19:3518回覆

 

竹薯 三、會議

IPM：迭代會議，每一個迭代開始以前開一次，主要是排下個迭代的故事卡，並給每張卡估點，我遇到的是兩週一個迭代（通常會有卡牆，有物理的，也有線上的）
Showcase：開發成果展現，每一個迭代結束開一次，通常是BA或QA給客戶演示上個迭代作的功能，固然也是優化和新改動提得最多的時候
Retro：回顧會議，每一個迭代結束開一次，討論上個迭代團隊作得好和作得很差的事（不是針對和人，不含人身攻擊），並給出改進方案，在下個迭代中執行
Stand Up：天天早上的站會，你們站成一圈，通常由 PM 主持，輪流闡述本身的昨天工做內容和工做進度，和今天要完成的工做，以及遇到的一些問題，及時反饋出來（咱們組有個小龍貓的毛絨玩具，你們挨個傳遞，挨個闡述）

天天還有 Code Review，動態安排時間，咱們團隊一直堅持，剛開始是先後端一塊兒過昨天每一個人寫的代碼，後面時間太長，就先後端分開。你們一塊兒來找茬，你的命名和代碼邏輯劃分，代碼風格，都有個能會被挑刺。在相互找茬的過程當中，堅持下去，對我的的成長有很大很大的幫助。

四、寫代碼

DEV 要作開發，就要先領故事卡，俗稱開卡，本身選好一張故事卡，拉上BA和QA去過其中的細節，理清細節，而後才能上手開發，開發完後再拉上BA和QA去結卡，檢查卡中的功能是否是都完成了，有問題就被打回去改，直到BA和QA以爲完善了，才能關卡。。。

代碼質量要求很嚴格，遵循 TDD，前端有 lint，有單元測試（不能偷懶，並且有覆蓋率要求），有 e2e 測試（必須寫，和QA一塊兒看），當你的代碼走過這三個流程，提交到公共倉庫，CI 自動構建會拉你的代碼，再走一遍測試（掛了就要修代碼），而後自動發佈新版本到 Dev 環境。

你覺得這就完了？還有代碼嗅探器，時刻在掃描代碼倉庫，有兩個重複的函數不行、重複率過高不行、使用了騷代碼去作類型轉換之類的不行、空間內有命名重疊不行。。。。這一套下來，再加上 code review，菜鳥開發天天一半的時間都在改昨天的代碼。

項目還有規定，CI 不能紅過夜，當天的問題當天要修好。。。。

以上這些，小公司就別說什麼沒時間，項目吃緊，而後就沒作，自求多福吧

這些都是我所經歷的，敏捷實踐各不相同，你們看看就好

2019-07-06 19:362回覆

 

竹薯 公司叫 ThoughtWorks，待遇好，想內推的小夥伴能夠聯繫我

2019-07-06 19:371回覆

 

空蝶K 回覆 @竹薯 :怪不得看着感受這麼熟悉，是Martin Fowler的書麼？

2019-07-06 20:361回覆

 

竹薯 回覆 @空蝶K :是的，Martin Fowler是公司創始人之一

2019-07-06 21:33回覆

 

也許我愛的是你愛我 大佬，想問問入職貴公司有什麼要求嗎，我目前是一個小公司的Java程序猿，經驗一年半

2019-07-06 22:40回覆

 

鶯聲繚亂 過於真實公司的開發一直在改，太菜了，我這個測試很是無奈

2019-07-06 22:48回覆

 

空蝶K 回覆 @竹薯 :看前面感受怪怪的，看到ThoughtWorks虎軀一震

2019-07-06 23:18回覆

 

竹薯 回覆 @也許我愛的是你愛我 :SpringBoot、SpringCloud 全家桶要會，會點微服務，基礎的 Java8 知識，熟練使用 stream 編程之類的，目前咱們組的 Java 開發一半時間都是在寫測試用例，要會寫單元測試+集成測試之類的。

2019-07-07 09:291回覆

 

larrytc tw，主要搞java

2019-07-07 14:48回覆

 

AESIRTECH 回覆 @竹薯 :成都嗎？那邊如今有多少人

2019-07-08 21:46回覆

 

竹薯 回覆 @AESIRTECH :三四百吧好像

2019-07-08 23:51回覆

 

做唐逆子 回覆 @竹薯 :久仰久仰

2019-07-15 23:24回覆

 

ahianzhang TW很重視 TDD DDD 不知道能不能交流一下

2019-07-18 09:08回覆

 

竹薯 回覆 @ahianzhang :剛入職的菜雞實習生一枚，在搬磚學習，大佬不嫌棄能夠私聊🌚

2019-07-19 22:40回覆

 

davidzwb 爲何和up主介紹的CI不一樣，up的CI彷佛是不經過不能提交，而這裏介紹的是仍然能夠提交，只不過CI有紅色警告，我感受up主介紹的那種對人的壓力小些。

2019-07-21 05:41回覆

 

竹薯 回覆 @davidzwb :提交的時候，本地git hook會自動跑lint和測試，過了以後代碼就進遠程倉庫了，遠程倉庫會觸發CI，CI會自動把本次提交後的代碼拉給本身，跑測試、構建、代碼質量分析。

因此只要本地測試能過，提交上去後CI會本身跑，這個時候開發一邊寫後面的代碼，一邊能夠觀察上一次提交的狀況，上一次掛了就排查。

你們都是寫一下子，順便看下CI

2019-07-22 19:40回覆

 

竹薯 回覆 @davidzwb :流程沒有絕對的標準，根據組內的人員和項目的狀況選擇適合的就好

2019-07-22 19:43回覆

 

davidzwb 回覆 @竹薯 :原來如此，謝謝

2019-07-23 01:21回覆

 

瘋狂302 哇，這大叔不就是敏捷開發的創始人麼

2019-07-24 11:51回覆

 

 

 

 

先作好運維，再作運維開發。zabbix,elk,ansible，docker,k8s這些工具自帶的功能基本夠一開始用了。業務驅動

 

用了這麼多PM工具，Atlassian JIRA Confluence + 插件是挺好用的，這個平臺就是JAVA開發裏的一個很牛產品

 

ThoughtWorks 瞭解一下