中國國有銀行敏捷開發(fā)試點總結(jié)v2

1、敏捷開發(fā)試點工作匯報,試點團隊：電子商務(wù)開發(fā)團隊試點項目小組：善融商務(wù)個人商城手機客戶端小組試 點 牽 頭 人&匯 報 人：Allen Zhang 張 明,中國**銀行股份有限公司,Page ? 2,中國**銀行股份有限公司,Page ? 3,中國**銀行股份有限公司,主站組,營銷平臺組,手機客戶端組,購物中心小組,商戶中心小組,商戶中心小組（7人）,購物中心小組,Page ? 4,中國**銀行股份有限公司,,,,優(yōu)

2、先級、情景化、子任務(wù)化,可視化監(jiān)測開發(fā)進(jìn)展?fàn)顟B(tài)和健康度,溝通、互動、協(xié)作,跨部門、跨職能、提升協(xié)調(diào)力,小步、快跑、不貪多、只求快,盡早發(fā)現(xiàn)小問題、杜絕大問題,注*Scrum：一種敏捷的項目管理方式。敏捷開發(fā)主要有兩個流派，一個是Scrum，一個是XP。Scrum偏重于過程，XP偏重于實踐。Scrum是橄欖球的一個專業(yè)術(shù)語，表示“爭球”的動作，比喻團隊在開發(fā)一個項目時，大家像打橄欖球一樣迅速、富有戰(zhàn)斗激情、人人你爭我搶地完成它。 XP

3、：極限編程(eXtreme Programming)。,Page ? 5,中國**銀行股份有限公司,,,敏捷咨詢顧問（IBM-全職）,注*Scrum Master是負(fù)責(zé)一個team按照Scrum方式運行的角色。職責(zé)包括更新backlog, 主持plan meeting, 主持stand up meeting, 主持retrospective meeting, 提交team velocity, burn up chart, burn do

4、wn chart.,統(tǒng)一團隊,Page ? 6,中國**銀行股份有限公司,,產(chǎn)品需求,細(xì)化（2天以內(nèi)）,,遺留缺陷需求變更,,中國**銀行股份有限公司,Page ? 7,,,選擇能在2~3周之內(nèi)完成的用戶故事量作為本次迭代的目標(biāo)，小步快跑,,充分估計所選用戶故事的需求變更風(fēng)險性和技術(shù)風(fēng)險（歷史經(jīng)驗預(yù)估）,,產(chǎn)品的實施周期以上線周期為準(zhǔn)，平均為一個半月，大步慢跑,,應(yīng)對跨周期或者緊急功能版本時相對被動忙亂，消耗較多人力和精力,,,,可測

5、試功能點在上線前若干天階躍式發(fā)布，開發(fā)測試人員并行性差,,,明確了解該敏捷團隊的消化能力和抗風(fēng)險能力（歷史經(jīng)驗預(yù)估）,,使用看板、子任務(wù)卡片和每日站立會議讓每天的進(jìn)展情況可視化,,每晚檢入代碼，構(gòu)建并在SIT發(fā)布集成了新用戶故事的可測試版本,,每天都保障開發(fā)人員和測試人員的并行流水線式作業(yè)，提高效率,,測試人員進(jìn)行測試和開發(fā)人員修正缺陷的壓力平均分布，不隨上線臨近而階躍上升,測試人員進(jìn)行測試和開發(fā)人員修正缺陷的壓力隨上線臨近而階躍上升,

6、,,小步、快跑、不貪多、只求快,,用功能點來分解需求，不夠情景化,,需求分解的粒度較粗，完成周期較長,,開發(fā)的多個中間過程無法直觀體現(xiàn)和把控,,,將具體的產(chǎn)品需求分解為用戶故事（2天/人的粒度）,,對每一個分解后的需求（用戶故事）進(jìn)行工作量評估,,,明確區(qū)分出技術(shù)性故事和非技術(shù)性故事,,將用戶故事（場景任務(wù)）劃分為若干子任務(wù),Page ? 8,中國**銀行股份有限公司,,,Page ? 9,根據(jù)最佳敏捷實踐Scrum方法論進(jìn)行工作項劃分

7、,中國**銀行股份有限公司,Page ? 10,Scrum工作項展示,中國**銀行股份有限公司,Page ? 11,中國**銀行股份有限公司,Scrum工作項展示,Page ? 12,中國**銀行股份有限公司,Scrum工作項展示,Page ? 13,中國**銀行股份有限公司,Scrum工作項展示,Page ? 14,中國**銀行股份有限公司,,在上線后經(jīng)用戶使用再形成優(yōu)化需求，而非在上線前的會議中提出,,測試完以后直接上線驗證功能，上

8、線之后再總結(jié)本次上線過程，非所有成員參會,,下個周期的開發(fā)內(nèi)容在下個周期開始之后才確定而非當(dāng)前周期結(jié)束時確定,,,回顧總結(jié)本次迭代周期內(nèi)的開發(fā)過程，進(jìn)行反思并改進(jìn),,會議中評審本次迭代出來的產(chǎn)品，形成最終的產(chǎn)品,,,分析本次迭代產(chǎn)品中仍存在的缺陷，并列為下個迭代周期的用戶故事,,在每個迭代周期的最后一天的下午舉行迭代回顧和計劃會議,,由SrcrumMaster主持，敏捷小組所有人員參會,中國**銀行股份有限公司,Page ? 15,,,

9、Page ? 16,IBM敏捷工具RTC功能展示(更加直觀、自動化、協(xié)同化),中國**銀行股份有限公司,中國**銀行股份有限公司,,,用戶故事,,,,,故事點數(shù),工時數(shù),測試用例數(shù),缺陷數(shù),11個,20點,171小時,36個,13個,迭代周期一(2周),,,用戶故事,,,,,故事點數(shù),工時數(shù),測試用例數(shù),缺陷數(shù),20個,85點,290小時,82個,16個,迭代周期二(3周),由 10 點/周 提升到 28.3 點/周,,故事消化能力,故

10、事消化速率,測試通過率,由 64% 提升到了 80%,由 1.82 點/故事 提升到 4.25 點/故事,兩迭代周期對比,提升原因：團隊磨合到位、流程更熟練、抵觸感降低、RTC更上手、協(xié)同參與度增大,中國建設(shè)銀行股份有限公司,,得出最優(yōu)迭代周期長度—3周,二周,三周,亞健康迭代,健康迭代,得出試點敏捷團隊類型—Late-Learner型,,,,,,Early-Learner：開始有一個頂峰，然后是平緩的衰退。團隊認(rèn)識到早期探尋的重要性，

11、然后高效工作以實現(xiàn)目標(biāo)。（理想實踐）,,Fakey-Fakey：表面完美而已。軟件項目過于復(fù)雜以致于難以界定直觀的目標(biāo)。這種燃盡圖來自于充滿了命令與控制的環(huán)境，在這種環(huán)境下，開放的交流變得難以進(jìn)行。（失敗實踐）,,Middle-Learner：要比late-learner更加成熟。燃盡圖中段會有一個頂峰出現(xiàn)。團隊在Sprint的中期會探尋出大多數(shù)的任務(wù)與復(fù)雜性。(良好實踐),,,,Late-Learner：燃盡圖末段會有一個頂峰出現(xiàn)。通

12、常出現(xiàn)在溝通高效且正在學(xué)習(xí)Scrum的團隊中。(普通實踐),,,Page ? 19,中國**銀行股份有限公司,該去向何方？,遇到障礙！,邁出了第一步！,教練很牛很高大上！,怎樣才能擺脫困境？,組員們可以默契高效地合作了！,領(lǐng)導(dǎo)指派的IBM敏捷教練來了！,教練迭代會議耐心講解示范,看不到希望！,手把手教會我使用強大的敏捷工具RTC,幫我們建立合理有效的分工,敏捷小組快速成長！,教練每日嚴(yán)格要求,感謝領(lǐng)導(dǎo)關(guān)懷和教練的指導(dǎo)，我們會繼續(xù)努力在敏