Nghiên cứu mô hình kết hợp giữa cmmi level 5 và scrum, ứng dụng vào quy trình phát triển phần mềm tại công ty csc việt nam

1.1 Bối cảnh nghiên cứu Ngày nay lĩnh vực công nghệ thông tin CNTT nói chung ngành công nghệ phần mềm nói riêng đã và đang trở thành xu hướng phát triển của thế giới.[14] Để tồn tại và

ĐẠI HỌC QUỐC GIA TP HCM TRƯỜNG ĐẠI HỌC BÁCH KHOA

-

NGUYỄN THỊ THANH THẢO

NGHIÊN CỨU MÔ HÌNH KẾT HỢP GIỮA CMMI LEVEL 5

VÀ SCRUM ỨNG DỤNG VÀO QUY TRÌNH PHÁT TRIỂN

PHẦN MỀM TẠI CÔNG TY CSC VIỆT NAM

Chuyên ngành: HỆ THỐNG THÔNG TIN QUẢN LÝ

Mã số: 60 34 48

LUẬN VĂN THẠC SĨ

TP HỒ CHÍ MINH, tháng 06 năm 2015

CÔNG TRÌNH ĐƯỢC HOÀN THÀNH TẠI TRƯỜNG ĐẠI HỌC BÁCH KHOA –ĐHQG -HCM

Cán bộ hướng dẫn khoa học:PGS.TS Đặng Trần Khánh

Cán bộ chấm nhận xét 1:

(Ghi rõ họ, tên, học hàm, học vị và chữ ký) Cán bộ chấm nhận xét 2:

(Ghi rõ họ, tên, học hàm, học vị và chữ ký) Luận văn thạc sĩ được bảo vệ tại Trường Đại học Bách Khoa, ĐHQG Tp HCM ngày tháng năm

Thành phần Hội đồng đánh giá luận văn thạc sĩ gồm: (Ghi rõ họ, tên, học hàm, học vị của Hội đồng chấm bảo vệ luận văn thạc sĩ) 1

2

3

4

5

Xác nhận của Chủ tịch Hội đồng đánh giá LV và Trưởng Khoa quản lý chuyên ngành sau khi luận văn đã được sửa chữa (nếu có) CHỦ TỊCH HỘI ĐỒNG TRƯỞNG KHOA…………

ĐẠI HỌC QUỐC GIA TP.HCM CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM TRƯỜNG ĐẠI HỌC BÁCH KHOA Độc lập - Tự do - Hạnh phúc

NHIỆM VỤ LUẬN VĂN THẠC SĨ

Nghiên cứu mô hình kết hợp giữa CMMI Level 5 và Scrum Ứng dụng vào quy trình phát triển phần mềm tại Công ty CSC Việt Nam

- Tìm hiểu lý thuyết về CMMI, AGILE với Scrum framework Phân tích những điểm mạnh cũng như những hạn chế của hai mô hình này

- Tìm hiểu về công ty CSC Việt Nam, thông tin về các dự án, lịch sử ứng dụng các quy trình phát triển phần mềm tại công ty

- Kết hợp những ưu điểm từ hai mô hình CMMI và Scrum để định hướng xây dựng mô hình kết hợp linh hoạt phù hợp với đặc trưng một số dự án của công ty Cụ thể hóa mô hình thành quy trình chi tiết, triển khai áp dụng vào dự án của công ty, đánh giá kết quả đạt

được

III NGÀY GIAO NHIỆM VỤ : 19/01/2015

IV NGÀY HOÀN THÀNH NHIỆM VỤ: 14/06/2015

(Họ tên và chữ ký) (Họ tên và chữ ký) (Họ tên và chữ ký)

LỜI CẢM ƠN

Trước tiên em xin trân trọng cảm ơn quý thầy cô công tác tại trường ĐH Bách Khoa TP HCM đã tận tình hướng dẫn, giảng dạy trong suốt quá trình học tập, và nghiên cứu tại trường

Xin gửi lời cảm ơn chân thành đến thầy PGS.TS.Đặng Trần Khánh đã tận tình hướng dẫn em trong suốt quá trình từ khi xây dựng đề cương và cho đến lúc hoàn tất luận văn

Em xin chân thành cảm ơn các anh chị trong công ty CSC VN, anh Ngọc Đỗ, anh Long Trương, anh Nhân Dương, anh Luật Nguyễn, chị Ánh Trương cùng các đồng nghiệp đã

hỗ trợ em rất nhiều, tạo điều kiện thuận lợi nhất để em có thể vừa học tập và làm việc Đặc biệt đã chia sẽ tài liệu, kinh nghiệm, cùng với những ý kiến đóng góp để giúp em hoàn thành luận văn

Trong quá trình thực hiện mặc dù gặp rất nhiều khó khăn, để có được kết quả luận văn ngày hôm nay bên cạnh sự nổ lực của cá nhân còn là sự động viên, giúp đỡ rất lớn từ bạn bè, người thân

Một lần nữa em xin chân thành cảm ơn thầy cô, anh chị, bạn bè và người thân đã động viên và hỗ trợ em trong suốt thời gian qua

TP Hồ Chí Minh, tháng 06 năm 2015 Nguyễn Thị Thanh Thảo

TÓM TẮT

Luận văn này cung cấp một quy trình phát triển phần mềm mới dựa trên sự kết hợp của hai mô hình có sẵn là CMMI và Scrum Mô hình mới này được thiết kế phù hợp với đặc trưng dự án của công ty CSC VN, giúp các công ty khắc phục được những vấn đề khó khăn mà các dự án trước gặp phải

Kết quả sau khi áp dụng vào hai release của dự án tầm cỡ trung bình của công ty cho thấy cải thiện tốt trong chất lượng công việc, dự án được thực hiện đúng tiến độ và chi phí thực hiện thấp Không có bất kỳ lỗi nghiêm trọng nào phát sinh sau khi chuyển giao, tài liệu và dữ liệu thực hiện dự án được quản lý tốt

Bên cạnh việc sử dụng mô hình mới giúp nâng cao kỹ năng làm việc nhóm Trong quá trình thực hiện dự án, có sự trao đổi trực tiếp với khách hàng, nhận được sự hài lòng và đánh giá cao từ khách hàng

ABSTRACT

This paper provides a new software development process based on the combination between two existing processes: CMMI and Scrum The new process is designed suitably for specific projects of CSC VN Company It supports to resolve the existing issues of previous projects: scope management, requirement changes, risks management, under schedule

After applied on two releases of a medium project, we found that the product quality, productivity are improved Not only is project released on time, but the cost is also reduced significantly There are not any serious errors after delivering to customer Documents and project data are managed and controlled fully and carefully

Besides, employee’s skills have many improvements such as team work, self management, time management, communication skill, and so on

During the developing phase, the communication between project team and customers is frequently It’s a chance to make customers satisfied and get good feedbacks from them

LỜI CAM ĐOAN

Em xin cam đoan kết quả nghiên cứu của đề tài “Nghiên cứu mô hình kết hợp giữa CMMI Level 5 và Scrum Ứng dụng vào quy trình phát triển phần mềm tại công ty CSC Việt Nam” là từ quá trình học tập và nghiên cứu khoa học của bản thân Các dữ liệu, thông tin trong nghiên cứu được tìm hiểu, khảo sát, lựa chọn và thu thập có nguồn gốc khoa học rõ ràng, chính xác và đáng tin cậy

TP Hồ Chí Minh, tháng 06 năm 2015 Nguyễn Thị Thanh Thảo

MỤC LỤC

LỜI CẢM ƠN 1

TÓM TẮT 2

ABSTRACT 3

LỜI CAM ĐOAN 4

MỤC LỤC 5

DANH MỤC CÁC TỪ VIẾT TẮT 8

DANH MỤC HÌNH 14

DANH MỤC BẢNG 16

Chương 1: MỞ ĐẦU 17

1.1 Bối cảnh nghiên cứu 17

1.2 Lý do thực hiện đề tài 18

1.3 Mục tiêu nghiên cứu 18

1.4 Phạm vi nghiên cứu 19

1.4.1 Đối tượng nghiên cứu 19

1.4.2 Thời gian, không gian nghiên cứu 19

1.5 Phương pháp nghiên cứu 19

1.6 Bố cục luận văn 20

1.7 Kết chương 20

Chương 2: CƠ SỞ LÝ THUYẾT 21

2.1 Tổng quan về CMMI 21

2.1.1 CMMI là gì 21

2.1.2 Các loại mô hình CMMI 24

2.1.3 Các thành phần của CMMI 25

2.1.4 Các mức độ trưởng thành của CMMI 26

2.1.5 Ưu điểm, hạn chế của CMMI 30

2.2 Tổng quan về Agile - Scrum 31

2.2.1 Định nghĩa, tuyên ngôn Agile 31

2.2.2 Giới thiệu Scrum framework 33

2.2.4 Ưu điểm và hạn chế của Agile - Scrum 36

2.3 Kết chương 38

Chương 3: GIỚI THIỆU TỔNG QUAN VỀ CSC VN 39

3.1 Giới thiệu về CSC 39

3.1.1 Giới thiệu về công ty CSC Global 39

3.1.2 Tổng quan về CSC VN 41

3.2 Lịch sử nghiên cứu ứng dụng các chuẩn, quy trình vào chuỗi phát triển phần mềm tại CSC VN 47

3.3 Đặc trưng các dự án CSC VN 48

3.4 Kết chương 54

Chương 4: XÂY DỰNG QUY TRÌNH KẾT HỢP 55

4.1 Cơ sở hình thành 55

4.2 Lý thuyết kết hợp CMMI và Agile 57

4.2.1 Quản lý yêu cầu (Requirements Management - REQM) 57

4.2.2 Lập kế hoạch dự án (Project Planning) 61

4.2.3 Giám sát và kiểm soát dự án (Project Monitoring and Control - PMC) 74

4.3 Hướng dẫn quy trình chi tiết cho sự kết hợp CMMI và Scrum 81

4.4 Kết chương 109

Chương 5: ÁP DỤNG QUY TRÌNH VÀO DỰ ÁN FIRSTDOC USER INTERFACE - FDUI 110

5.1 Tổng quan về dự án 110

5.2 Release 1: FDUI 7.1.0000 CONSUMER 117

5.2.1 Mục tiêu release 117

5.2.2 Số lượng Sprint trong FDUI 7.1.0000 Consumer 118

5.2.2 Kết quả và nhận xét 121

5.3 Release 2: FDUI 7.1.0100 REVIEWER/APPROVER 124

5.3.1 Mục tiêu release 124

5.3.2 Kết quả và nhận xét 128

5.4 Những dự án như thế nào sẽ phù hợp với mô hình này 130

5.5 Những thuận lợi và khó khăn khi áp dụng tại CSC VN 133

5.5.1 Thuận lợi 133

5.5.2 Khó khăn 134

Chương 6: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 136

6.1 Kết luận 136

6.2 Hướng phát triển đề tài 137

DANH MỤC CÁC TỪ VIẾT TẮT

A Agile Phát triển phần mềm linh hoạt llinh hoạt

AMS Application Maintenance Support – hỗ trợ

bảo trì ứng dụng ASD Adaptive Software Development - Phát

triển phần mềm thích ứng AMEA Asia, Middle East and Africa – khu vực

châu Á, Trung Đông và châu Phi Admin Admininstration – phòng quản lý

AMI Acute Myocardial Infarction – nhồi máu

cơ tim

B Burndown Chart Biểu đồ hiển thị phần công việc còn lại

tích nghiệp vụ

lý kinh doanh liên tục

CSC VN Computer sciences corporation Viet Nam CIO Chief Information Operator – Nhà quản lý

Chỉ mục Từ viết tắt Ý nghĩa

thông tin CMMI Mô hình năng lực trưởng thành tích hợp CMMI-DEV CMMI for Development – CMMI cho

nhóm lĩnh vực phát triển CMMI-ACQ CMMI for Acquisition - CMMI cho nhóm

lĩnh vực thu mua

CMMI-SVC CMMI for Services - CMMI cho nhóm

lĩnh vực dịch vụ

CSS Cascading Style Sheets – xây dựng giao

diện web

System - hệ thống quản lý tài liệu điện tử

F FCG First Consulting Group – nhóm hỗ trợ đầu

tiên FRS Functional Requirements Specification –

yêu cầu chức năng cụ thể

Chỉ mục Từ viết tắt Ý nghĩa

FDUI FirstDoc User Interface – giao diện người

dùng của hệ thống FirstDoc FDD Feature Driven Development - Phát triển

dựa vào tính năng

thống thông tin địa lý GHPST Global High Performance Sevice team –

nhóm dịch vụ

đánh dấu văn bản

ITIL Information Technology Infrastructure

Library – thư viện cơ sở hạ tầng công nghệ thông tin

IT Information technology – công nghệ thông

tin ISO International Standard Organization – tổ

chức quản lý tiêu chuẩn quốc tế ISMS Information Security Management System

- hệ thống quản lý an toàn thông tin

quản lý mạng

PQP Project Quality Plan – kế hoạch quản lý

chất lượng dự án

PQR Project Quality Requirements - chất

lượng yêu cầu dự án

PP Project Planning – lập kế hoạch dự án PMI Project Management Institute - Viện Quản

lý dự án

PEST Project Estimating and Scheduling Tool

Template – mẫu dự toán và lập kế hoạch

QC Quality Control – kiểm định chất lượng

yêu cầu

SQA Software Quality Assurance – đảm bảo

chất lượng phầm mềm SVN version control system – hệ thống quản lý

phiên bản

Viện Công Nghệ Phần Mềm Mỹ SEPG Software Engineering Process Group –

nhóm quy trình công nghệ phần mềm

Chỉ mục Từ viết tắt Ý nghĩa

SP Specific Practices – các thực hành cụ thể

chuỗi cung ứng SAP Systems, Applications & Products – hệ

thống , ứng dụng và sản phẩm

T TA Technical Architect – kiến rúc sư kỹ thuật

TL Technical leader – trưởng nhóm kỹ thuật

TD Test Director – điều hành nhóm kiểm thử

WBS Work Breakdown Structure - cấu trúc

phân rã công việc

DANH MỤC HÌNH

Hình 2 1: Lịch sử của CMMs 22

Hình 2.2: Ba yếu tố quan trọng trong một tổ chức 23

Hình 2.3: Năm mức độ trưởng thành của CMMI 27

Hình 2.4: Các lợi ích Agile mang lại cho tổ chức 32

Hình 2.5: Tỷ lệ sử dụng các phương pháp trong Agile 33

Hình 3.1: Sơ đồ tổ chức CSC VN 1 42

Hình 3.2: Sơ đồ tổ chức CSC VN_WS 43

Hình 3 3: Sơ đồ tổ chức CSC VN_BCM 43

Hình 3 4: Sơ đồ tổ chức CSC VN_IT 44

Hình 3 5: Sơ đồ tổ chức CSC VN_Finance 45

Hình 3.6: Sơ đồ tổ chức CSC VN_HR 45

Hình 3.7: Sơ đồ tổ chức CSC VN_P&C 46

Hình 3.8: Sơ đồ tổ chức CSC VN_SO 46

Hình 3.9: Lịch sử phát triển và thành tựu cải tiến quy trình tại CSC VN 47

Hình 3.10: Đặc trưng của một số phương pháp, quy trình hiện tại của CSC VN 48

Hình 3 11: Biểu đồ dự án theo độ dài thời gian thống kê từ 2009-2012 49

Hình 3 12: Biểu đồ dự án theo độ lớn thống kê từ 2009-2012 50

Hình 3 13: Biểu đồ dự án theo loại sản phẩm thống kê từ 2009-2012 50

Hình 3.14: Nguyên nhân dẫn đến thất bại của các dự án 52

Hình 4 1: Hướng dẫn CMMI PM từ SP 1.1 đến SP 1.5 57

Hình 4.2: Hướng dẫn CMMI PP từ SP 1.1 đến SP 1.5 62

Hình 4.3: Hướng dẫn CMMI PMC từ SP 1.1 đến SP 2.3 75

Hình 4.4: Giai đoạn 1 của quy trình 81

Hình 4.5: Ví dụ về tài liệu URS của dự án 85

Hình 4.6: Ví dụ minh họa về một số yêu cầu 86

Hình 4.7: Ví dụ về Story và Epic tương ứng trong dự án thực tế 86

Hình 4.8: Cấu trúc phân rã của Story 87

Hình 4.9: Ví dụ về Story và các sub-tasks tương ứng trong dự án thực tế 87

Hình 4.10: Ví dụ về Product Backlog 88

Hình 4.11: Danh sách các thiết kế ban đầu của dự án 89

Hình 4.12: Quy trình xây dựng Test Plan 89

Hình 4.13: Giai đoạn 2 của quy trình 96

Hình 4.14: Vòng đời của một yêu cầu từ lúc bắt đầu đầu đến lúc kết thúc 98

Hình 4.15: Ví dụ về Burndown chart 100

Hình 4.16: Minh họa về Progress Chart 101

Hình 5.1: Kiến trúc hệ thống FirstDoc 111

Hình 5.2: Các yêu cầu kỹ thuật của dự án FUI 112

Hình 5.3: Kiến trúc của dự án FUDI 113

Hình 5 4: Các release dự kiến của dự án 114

Hình 5.5: FDUI 7.1.0000 Consumer_Burndown Chart sprint 4 119

Hình 5.6: FDUI 7.1.0000 Consumer_Burndown Chart sprint 8 119

Hình 5.7: FDUI 7.1.0000 Consumer_Burndown Chart sprint 11 120

Hình 5.8: FDUI 7.1.0100 Reviewer/Approver_Burndown Chart sprint 12-13 125

Hình 5.9: FDUI 7.1.0100 Reviewer/Approver_Burndown Chart sprint 14-15 126

Hình 5.10: FDUI 7.1.0100 Reviewer/Approver_Burndown Chart sprint 16-17 127

DANH MỤC BẢNG

Bảng 2.1: Sự khác nhau giữa Procduct Backlog và Sprint Backlog 36

Bảng 3 1: Thống kê dự án theo độ dài hạn từ 2009 - 2012 49

Bảng 3 2: Thống kê dự án theo độ lớn từ 2009 - 2012 49

Bảng 3 3: Thống kê dự án theo loại sản phẩm từ 2009 – 2012 50

Bảng 4 1 - Sự kết hợp CMMI PM và Agile 61

Bảng 4.2 - Sự kết hợp CMMI PP và Agile 74

Bảng 4 3- Sự kết hợp CMMI PMC và Agile 81

Bảng 4 4 : Đánh giá các công cụ hỗ trợ Agile 83

Bảng 4.5: Danh sách tài liệu được tạo ra sau giai đoạn 1 95

Bảng 4 6: URS Traceability Matrix 105

Bảng 4.7: Danh sách tài liệu được tạo ra sau giai đoạn 2 107

Bảng 4.8: Danh sách tài liệu được tạo ra sau giai đoạn 3 109

Bảng 5 1: Thành viên trong đội dự án 115

Bảng 5.2: Đánh giá công cụ hỗ trợ automation test 116

Bảng 5.3: Quy trình Meeting và Status Reporting 117

Bảng 5.4: Danh sách Sprint của Consumer release 118

Bảng 5.5: Danh sách tài liệu được tạo ra trong Consumer release 122

Bảng 5 6: Danh sách Sprint của Consumer release 124

Bảng 5.7: Danh sách tài liệu được tạo ra trong Consumer release 129

Bảng 5.8: Đặc trưng dự án phù hợp với mô hình 132

Bảng 5.9: Đánh giá kết quả mô hình 133

1.1 Bối cảnh nghiên cứu

Ngày nay lĩnh vực công nghệ thông tin (CNTT) nói chung ngành công nghệ phần mềm nói riêng đã và đang trở thành xu hướng phát triển của thế giới.[14]

Để tồn tại và phát triển các công ty hoạt động trong lĩnh vực CNTT luôn luôn phải đối mặt và đòi hỏi phải vượt qua nhiều thách thức khác nhau như sự thay đổi nhanh chóng của công nghệ, xu hướng dịch vụ hóa trong đó làm hài lòng khách hàng luôn là mục tiêu hàng đầu, là thử thách quan trọng mà các công ty phải vượt qua.[8] Để làm được điều đó đòi hỏi các tổ chức phải xây dựng cho mình một tầm nhìn, và định hướng mục tiêu cụ thể, từng bước từng bước thực hiện nhằm đạt được mục tiêu cụ thể đó Nhà quản lý phải biết phối hợp các nguồn lực hiện có, cùng nhau hợp tác để hướng đến mục tiêu chung Bên cạnh đó, để hạn chế rủi ro cho dự án đòi hỏi nhà quản lý cần phải có năng lực dự đoán trước những vấn đề có thể phát sinh trong quá trình thực hiện dự án

Để làm được những điều trên, việc xây dựng một quy trình (process) phù hợp sẽ là công

cụ hữu ích để các công ty, tổ chức có thể dễ dàng đạt được mục tiêu mà mình đề ra Hiện nay, giống như nhiều công ty khác, CSC VN cũng đã và đang sử dụng CMMI, AGILE như những công cụ hiệu quả cho công việc quản lý các dự án của công ty

Với cá nhân đang là một nhân viên kiểm thử phần mềm (tester) lại CSC VN, được tiếp cận và làm việc với cả 2 quy trình trên, bản thân nhận thấy mỗi quy trình đều có những điểm mạnh và đồng thời cũng có những hạn chế Các dự án sử dụng CMMI hầu hết yêu cầu phải là những dự án có quy mô lớn, có tính chất ổn định, những người tham gia thực hiện CMMI đòi hỏi phải có trải qua quá trình đào tạo bài bản, có kiến thức về CMMI

Đặc biệt, CMMI đặt nặng vấn đề tài liệu, hầu hết tất cả công việc, quy trình, các vấn đề liên quan đều phải được ghi lại, nó làm mất rất nhiều thời gian và công sức cho những người tham gia dự án Bên cạnh đó, Agile với đặc thù là linh hoạt hơn, đáp ứng tức thời

sự thay đổi của môi trường, của khách hàng.[7] Tuy nhiên nó lại có hạn chế là đòi hỏi sự giao tiếp liên tục của con người, do đó các dự án Agile phải là những dự án nhỏ, các thành viên phải ngồi gần nhau Trong quá trình thực hiện dự án, hầu hết không ghi lại thành tài liệu, nếu có sự thay đổi nhân sự trong dự án, người mới sẽ khó lòng bắt kịp vì không hề có tài liệu hướng dẫn nào để lại từ những người làm trước đó Đòi hỏi người tham gia dự án phải có nhiều kinh nghiệm về vấn đề mình đang làm

CMMI đã được CSC sử dụng trong một khoảng thời gian dài, hơn 10 năm, trong khi đó Agile bắt đầu được công ty nghiên cứu và sử dụng từ năm 2013 cho đến nay Đồng thời các dự án của CSC có tính đa dạng: về quy mô, mức ổn định,… Vì vậy nếu chỉ đơn thuần

sử dụng CMMI hoặc Agile sẽ không thể áp dụng trên toàn bộ các dự án, cũng như hiệu quả nó mang lại sẽ không cao

1.2 Lý do thực hiện đề tài

Do đó, với đề tài này, mong muốn có thể thực hiện nghiên cứu một mô hình mới dựa trên

sự kết hợp hai mô hình cơ bản CMMI và Agile (Scrum) Mô hình mới có thể ứng dụng linh hoạt vào nhiều loại dự án của công ty hơn so với hai mô hình trước là CMMI và Scrum Đồng thời mang lại đạt hiệu quả cao hơn cho các dự án như tăng độ hài lòng của khách hàng, giảm độ trễ, giảm chi phí…

1.3 Mục tiêu nghiên cứu

Đề tài thực hiện với mong muốn áp dụng hướng tiếp cận mới vào quy trình phát triển phần mềm của công ty CSC VN, xây dựng một quy trình hoàn chỉnh dựa trên sự kết hợp giữa CMMI và SCRUM được ứng dụng vào một dự án cụ thể của CSC VN Từ đó đánh giá được khả năng ứng dụng vào các dự án cũng như hiệu quả mang lại cho công ty

1.4 Phạm vi nghiên cứu

1.4.1 Đối tượng nghiên cứu

Lý thuyết về CMMI và AGILE – SCRUM

Các dự án của công ty CSC VN

Những người đã hoặc đang tham gia vào các dự án có sử dụng CMMI và SCRUM

1.4.2 Thời gian, không gian nghiên cứu

Đề tài được thực hiện từ tháng 10/2014 – 6/2015 tại công ty CSC VN

1.5 Phương pháp nghiên cứu

Đề tài được thực hiện bằng nghiên cứu định tính, nghiên cứu tài liệu, phỏng vấn trao đổi trực tiếp để lấy thông tin và thu thập ý kiến

Dựa trên kiến thức cơ bản về CMMI, Agile, cũng như nhận biết được những mặt ưu điểm

và hạn chế của từng mô hình, từ đó sẽ đi đến thiết kế và xây dựng bảng câu hỏi Bảng câu hỏi sẽ được xây dựng khác nhau trên từng nhóm đối tượng khác nhau Nhóm đối tượng nghiên cứu sẽ là những người có tham gia vào dự án phát triển phần mềm có sử dụng CMMI hoặc Scrum Tuy nhiên tùy vào mức độ và vai trò mỗi người trong dự án sẽ khác nhau nên yêu cầu bảng câu hỏi phải khác nhau để phù hợp với từng đối tượng

Việc thực hiện khảo sát kết hợp với phỏng vấn này có những thuận lợi: đối tượng tham gia khảo sát làm cùng công ty nên có thể gặp và trao đổi trực tiếp, bằng việc trao đổi mặt đối mặt có thể làm rõ được vấn đề một cách dễ dàng, có thể có thêm nhiều thông tin hữu ích được chia sẻ từ người được phỏng vấn Từ đó độ tin cậy của thông tin cao hơn, giúp hình thành ý tưởng cho mô hình mới nhanh hơn, tính thực tế cao hơn

Tuy nhiên phương pháp khảo sát này cũng có hạn chế: chỉ thực hiện một lúc trên 1 hoặc một nhóm nhỏ người, do đó thời gian thực hiện khảo sát có thể sẽ kéo dài và không liên tục Đặc biệt, đối với đối tượng là những người cấp quản lý (PM – Project Manager), sẽ hơi khó khăn để liên hệ sắp xếp thời gian để thực hiện khảo sát

Chương 5: Ứng dụng vào một số dự án của công ty, kết quả đạt được

Chương 6: Kết luận, hướng phát triển

Tài liệu tham khảo

Phụ lục

1.7 Kết chương

Chương 1 giới thiệu tổng quan về đề tài, giải thích lý do chọn đề tài, mục tiêu nghiên cứu, và phương pháp để thực hiện đề tài

Chương 2: CƠ SỞ LÝ THUYẾT

Tóm tắt chương

 Chương này với mục đích trình bày tổng quan cơ sở lý thuyết về CMMI và Agile – Scrum Tìm hiểu về khái niệm, các thành phần, mô hình của CMMI Các mức độ trưởng thành, ưu điểm và hạn chế khi sử dụng CMMI Tương tự cho Agile, chương này cũng đi tìm hiểu khái niệm Agile, tuyên ngôn Agile Giới thiệu về Scrum framework trong Agile, các thành phần trong Scrum Những ưu điểm và hạn chế của Agile – Scrum framework

2.1 Tổng quan về CMMI

2.1.1 CMMI là gì

Trong giai đoạn công nghệ phát triển như hiện nay, để tồn tại và phát triển đòi hỏi các công ty phải cung cấp các sản phẩm, dịch vụ với chất lượng tốt hơn, thời gian nhanh hơn

và giá cả phải cạnh tranh hơn Chính vì vậy càng về sau này sản phẩm ra đời càng đòi hỏi

độ phức tạp cao hơn, công nghệ hiện đại hơn gấp nhiều lần so với trước đây Bên cạnh đó vấn đề tổ chức, quản lý phải đảm bảo có thể thích nghi và đáp ứng được những yêu cầu cao về công nghệ và tính năng phức tạp của sản phẩm từ phía người dùng

Trong số những mô hình, tiêu chuẩn, phương pháp luận hay các hướng dẫn hiện có mặc

dù có thể giúp cho tổ chức cải thiện được cách làm kinh doanh, nhưng phần lớn nó chỉ tập trung vào hướng làm kinh tế là chủ yếu, mà không đưa ra được hướng tiếp cận một cách hệ thống vào những vấn đề mà hầu hết các tổ chức gặp phải Chính vì chỉ tập trung kinh doanh nên vô tình những mô hình cũ này lại trở thành rào cản mà tổ chức cần phải cải thiện để đảm bảo cho mục tiêu phát triển trong tương lai

CMMI ra đời cung cấp cơ hội để các tổ chức có thể tránh hoặc loại bỏ được những rào cản, hạn chế nói trên

CMM được viết tắt từ Capability Maturity Model – Mô hình năng lực trưởng thành Mô

hình này tập trung mô tả các quy trình, ngữ cảnh, cách tiếp cận tổ chức công việc để đạt

hiệu quả cao CMM được định ra như một phương pháp để đánh giá và đo sự trưởng thành của quá trình phát triển phần mềm của một tổ chức.[2]

Các giai đoạn hình thành và phát triển của CMMI được thể hiện qua hình 2.1 bên đây

Software Engineering Institute (SEI) – Viện công nghệ phần mềm Mỹ

SEI đã nghiên cứu và xác định ra một số yếu tố mà một tổ chức cần tập trung vào để có thể cải thiện được quá trình kinh doanh Trong số đó, có 3 yếu tố quan trọng: con người, thủ tục, và phương pháp Như vậy làm sao để liên kết các yếu tố này lại với nhau?[16] Hình 2.2 dưới đây là minh họa cho mối quan hệ giữa 3 yếu tố này

Hình 2.2: Ba yếu tố quan trọng trong một tổ chức

Qua hình ảnh minh họa trên chúng ta thấy rằng “Process – quy trình” chính là đáp án cho câu hỏi ở trên.[16]

CMMI được coi như một framework hỗ trợ cải tiến quy trình kinh doanh, nói cách khác

nó cũng là một mô hình được các nhà quản lý sử dụng với mục đích xây dựng các hệ thống cải tiến quy trình

CMMI giúp các tổ chức cải thiện hiệu suất công việc và khả năng dự đoán để phân phối sản phẩm, dịch vụ, hàng hóa đến khách hàng một cách tốt nhất, bất cứ khi nào khách hàng có yêu cầu Với mục tiêu này, CMMI đã giúp các công ty cải thiện được hiệu suất hoạt động bằng cách hạ thấp chi phí sản suất, phân phối, cũng như chi phí gia công

2.1.2 Các loại mô hình CMMI

CMMI được chia làm 3 nhóm [1]

 CMMI-DEV (CMMI for Development)

Cung cấp một bộ hướng dẫn được tích hợp đầy đủ cho toàn bộ các tình huống có thể xảy

ra trong quá trình xây dựng và phát triển sản phẩm và dịch vụ

Với mục tiêu: Mô hình CMMI – DEV bao gồm những hướng dẫn thực hành tốt nhất có thể được sử dụng cho cả hai lĩnh vực sản xuất và dịch vụ Những hướng dẫn này kéo dài nguyên cả vòng đời của sản phẩm từ lúc mới hình thành khái niệm, cho đến lúc phân phối cho khách hàng và bảo trì

CMMI – DEV gồm 22 nhóm quy trình, trong số đó có 16 quy trình chính, 1 quy trình chia sẻ dùng chung, 5 nhóm còn lại là 5 quy trình phát triển với quy trình có một đặc thù riêng

Tất cả mô hình thực tế của CMMI-DEV chủ yếu tập trung trên các hoạt động của tổ chức CNTT Năm nhóm quy trình nói trên hướng dẫn thực hiện cho việc phát triển hệ thống một cách cụ thể như: xác định yêu cầu, giải pháp kỹ thuật, tích hợp sản phẩm, kiểm tra, xác nhận

 CMMI-ACQ (CMMI for Acquisition)

Là mô hình cung cấp hướng dẫn cho việc áp dụng CMMI vào các tổ chức thu mua Mô hình đưa ra các bước thực hành cụ thể tập trung vào hoạt động để bắt đầu và quản lý việc mua lại các sản phẩm và dịch vụ để đáp ứng nhu cầu của khách hàng và người dùng cuối Gồm 3 nhóm chính liên quan trực tiếp đến mô hình

CMMI Steering Group (nhóm chỉ đạo CMMI): hướng dẫn và phê duyệt các kế hoạch của Product Team, cung cấp tư vấn quan trọng về các vấn đề liên quan tới CMMI, và đảm bảo sự tham gia từ nhiều người quan tâm Giám sát quá trình thu mua, nhận dạng và đưa

ra những hướng dẫn quan trọng cho nhà thu mua

Product Team (nhóm phát triển sản phẩm): viết, xem xét, sửa đổi, thảo luận và nhất trí về

cơ cấu và nội dung kỹ thuật của CMMI Product Suite (nhóm các sản phẩm CMMI gồm framework, các mô hình, đào tạo, và các tài liệu thẩm định…)

Configuration Control Board (CCB) (ban quản lý cấu hình): là nhóm cơ cấu chính thức

để kiểm soát những thay đổi các mô hình CMMI, tài liệu liên quan thẩm định, và giới thiệu về đào tạo CMMI Đảm bảo tính toàn vẹn trong vòng đời của các bộ sản phẩm bằng cách xem lại tất cả các thay đổi được đề xuất.Chỉ phê duyệt những thay đổi được xác định thỏa đáng và đáp ứng tiêu chuẩn cho việc phát hành sắp tới

 CMMI-SVC (CMMI for Services)

Cung cấp các hướng dẫn thực hành tốt nhất cho việc áp dụng CMMI trong một tổ chức cung cấp dịch vụ Mô hình tập trung vào các hoạt động cung cấp dịch vụ chất lượng cho khách hàng và người dùng cuối CMMI-SVC tích hợp kiến thức một cách có hệ thống cần thiết cho một nhà cung cấp dịch vụ

Gồm 3 nhóm chính đó là CMMI Steering Group, Product Team, và Configuration Control Board (CCB) Vai trò và nhiệm vụ 3 nhóm này cũng tương tự như 3 nhóm trong

CMMI-ACQ đã đề cập bên trên

2.1.3 Các thành phần của CMMI

CMMI bao gồm các thành phần [1]:

 Maturity Levels – cấp độ trưởng thành: Là các lớp cơ cấu tổ chức với điều kiện là

một chuỗi các quy tắc được định ra cần thiết để liên kết trong quy trình phát triển phần mềm Nó rất quan trọng đối với các tổ chức, công ty… cần phát triển năng lực làm việc, khối lượng công việc trong việc rèn luyện, công nghệ hoặc công cụ trong hoạt động Do đó, nó định nghĩa rõ việc làm thế nào để đạt đến các mức chuẩn, từ đó định giá sản phẩm, định giá năng suất làm việc của công ty Nó giúp các dự án, các nhóm, các công ty định hướng được việc trình bày hợp lý trong từng cấp độ lựa chọn

 Key process areas (KPA) – nhóm quy trình chính: Là một nhóm các hoạt động có

quan hệ với nhau khi thực hiện chung để hoàn tất mục tiêu quan trọng

 Goals – Mục tiêu: Mục tiêu của một nhóm quy trình chính (KPA) là tóm tắt tình

trạng , lý do tồn tại của nhóm quy trình thực hiện đầy đủ với kết quả và quá trình thực hiện dài lâu Quy mô của mục tiêu đã hoàn thành cho biết năng lực của tổ chức trong từng cấp độ trưởng thành Mục tiêu biểu hiện phạm vi, ranh giới, và mục đích của mỗi nhóm quy trình chính (KPA)

 Common Features – các tính năng chung: Các tính năng chung bao gồm các

hướng dẫn đã được thực hiện và thể chế hóa một nhóm quy trình Nó bao gồm năm dạng là Commitment to Perform (giao phó đến thực hiện), Ability to Perform (khả năng đến thực hiện), Activities performed (các hoạt động đã thực hiện), Measurement and Analysis (đo lường và phân tích), và Verifying Implementation (thực hiện thẩm tra)

 Key Practices – thực tiễn chính: Mô tả các yếu tố của cơ sở hạ tầng và thực hiện

góp phần tạo những hiệu quả thực sự trong việc thực hiện và thể chế hóa nhóm quy trình chính

2.1.4 Các mức độ trưởng thành của CMMI

Mức độ trưởng thành thể hiện sự cải tiến rõ ràng của việc cải tiến quy trình từ mức độ thấp lên mức độ cao

Có 5 mức độ cơ bản trong mô hình CMMI Mỗi một cấp độ là nền tảng cơ bản cho việc tạo ra cấp độ trên nó, các mức độ sau được xây dựng kế thừa từ cái có trước, đồng thời

bổ sung các yếu tố để hoàn thiện hơn quy trình hiện có Năm cấp độ trường thành trong CMMI [2] được đánh số liên tục từ 1 đến 5 theo như Hình 2.3

Hình 2.3: Năm mức độ trưởng thành của CMMI

 Cấp I – Initial (Khởi đầu)

Quy trình sản xuất phần mềm có đặc điểm tự phát, thành công chỉ dựa vào nỗ lực của cá nhân hoặc tài năng

Ở cấp độ này, quy trình thường là “adhoc” – tự do, không tuân theo một quy trình cụ thể Doanh nghiệp thường không cung cấp môi trường phát triển ổn định Thành công của doanh nghiệp quyết định dựa trên năng lực của cá nhân tài năng trong doanh nghiệp và không thuộc các quy trình đã chứng minh Chính quá trình làm việc tự do, không tuân theo bất kỳ thể thức nào, dẫn đến sự hỗn loạn trong quy trình Do đó ở cấp độ này, doanh nghiệp thường xuyên vượt quá dự thảo ngân sách và kế hoạch làm việc của dự án

Các doanh nghiệp trong cấp độ này được mô tả như đặc trưng của xu hướng hoạt động với quy trình tự do, không lặp lại những quy trình thành công

 Cấp II – Repeatable [Managed] (Lặp)

Ở cấp độ 2 này, công ty về cơ bản đã xác định được các mục tiêu chung và mục tiêu cụ thể Các quy trình quản lý dự án cơ bản được thiết lập để kiểm soát chi phí, kế hoạch và

khối lượng hoàn thành Các nguyên lý về quy trình cơ bản được hình thành nhằm đạt được thành công như những phần mềm tương tự

Trong cấp độ này, những thành công trong quản lý chất lượng sản phẩm được lặp lại Các quy trình có thể không lặp lại toàn bộ trong dự án của công ty Công ty có thể sử dụng một vài chương trình quản lý dự án cơ bản để đưa ra giá thành và kế hoạch dự án

Các quy trình rèn luyện giúp đỡ việc bảo đảm các thực hiện được giữ lại trong suốt thời gian của hoạt động Khi mà thực hiện nằm đúng vị trí, các dự án sẽ được tiến hành và quản lý theo tài liệu kế hoạch

Tiến độ công việc và quá trình phân phối dịch vụ phải đảm bảo thấy được, quản lý được Các quy trình quản lý dự án cơ bản đã thiết lập được giá thành, kế hoạch cũng như chức năng Các quy trình nhỏ nhất cũng được thực hiện lại sớm nếu như thành công trong dự

án với những phần mềm và phạm vi giống nhau Nó vẫn có thể vượt quá sự mạo hiểm và tính toán ước lượng

 Cấp III – Defined (Xác lập)

Quy trình phần mềm cho các hoạt động quản lý cũng như sản xuất được tài liệu hóa, chuẩn hóa và tích hợp vào quy trình phần mềm chuẩn của nhà sản xuất Các dự án sử dụng quy trình phần mềm hiệu chỉnh được phê duyệt dựa trên quy trình chuẩn của nhà sản xuất để phát triển và bảo trì sản phẩm phần mềm

Ở cấp độ 3, một tổ chức phải đạt được các mục tiêu chung và mục tiêu cụ thể đã được xác định ở cấp độ 2 Tại cấp độ này, các quy trình đòi hỏi phải được mô tả thông qua các tiêu chuẩn, thủ tục, công cụ hoặc phương pháp để có thể nắm bắt một cách dễ dàng nhất

Sự khác nhau giữa cấp độ 2 và cấp độ 3 là phạm vi của tiêu chuẩn, sự mô tả quy trình, và các thủ tục Tại cấp độ 2, tiêu chuẩn, miêu tả quy trình và thủ tục có thể khác nhau trong mỗi lần sử dụng quy trình (ví dụ, khác nhau trên mỗi dự án) Tại cấp độ 3, tiêu chuẩn, mô

tả quy trình và thủ tục được đồng bộ từ cấp độ dự án cho đến công ty Các tiêu chuẩn, quy trình trong cấp độ 3 sẽ được mô tả chi tiết cụ thể hơn rất nhiều so với cấp độ 2

 Cấp IV – Quantitatively Managed (Kiểm soát)

Thực hiện đo lường chi tiết quy trình phần mềm và chất lượng sản phẩm Cả quy trình sản xuất và sản phẩm phầm mềm được kiểm soát theo định lượng

Sử dụng đo lường rõ ràng, người quản lý có thể có những quản lý hiệu quả cho sự nỗ lực phát triển phần mềm Trong trường hợp đặc biệt, quản lý có thể nhận dạng cách để điều chỉnh sửa lại quy trình cho phù hợp với các dự án đặc biệt mà không cần đo lường chất lượng hoặc chênh lệch trong đặc tả Tổ chức tại cấp độ này đặt mục tiêu về chất lượng cho cả quy trình phần mềm và bảo trì phần mềm Các quy trình con được lựa chọn phải truyền đạt góp phần tới toàn thể sự thực hiện của quy trình Những quy trình con đã được lựa chọn sẽ quản lý bởi tiêu chuẩn và các định lượng kỹ thuật Sự khác nhau giữa cấp độ

3 và cấp độ 4 khả năng dự đoán hiệu suất của quy trình Tại cấp độ 4, hiệu quả của quy trình có thể kiểm soát bằng các kỹ thuật thống kê và định lượng khác, và có thể dự đoán bằng cách định lượng Tại cấp độ 3, các quy trình chỉ đoán được chất lượng

 Cấp V – Optimizing (Tối ưu)

Quy trình liên tục được cải tiến dựa trên những ý kiến phản hồi từ việc sử dụng quy trình, thí điểm những ý tưởng quản lý và công nghệ mới

Cấp độ 5 tập trung vào việc cải thiện liên tục các thực hiện của quy trình trong suốt quá trình lớn lên và phát triển, đổi mới công nghệ Mục tiêu của quy trình cải tiến chất lượng trong tổ chức được thiết lập, và được sửa đổi liên tục để phản ánh những thay đổi trong mục tiêu kinh doanh, và sử xem như tiêu chí của việc quản lý cải tiến quy trình

Hiệu quả của việc trình bày quy trình phát triển đã nhịp nhàng và đánh giá tương phản với định lượng của quy trình phát triển đối tượng Cả hai định nghĩa quy trình và tiêu chuẩn quy trình của công ty là mục tiêu của hoạt động đo lường phát triển

Tối ưu quy trình là nhanh nhẹn, thích hợp và đổi mới quyết định dựa trên sự tham gia của người thừa hành lực lượng lao động sắp theo giá trị kinh doanh và đối tượng của tổ chức Khả năng nhận thấy của tổ chức nhanh chóng được phản hồi để thay đổi với cơ hội là làm tăng giá bởi việc tìm ra cách tăng nhanh và chia sẻ kinh nghiệm

Sự khác nhau giữa cấp độ 4 và cấp độ 5 là các loại biến được đưa ra trong quy trình Tại cấp độ 4, quy trình chỉ quan tâm đến việc đưa ra các trường hợp đặc biệt gây ra sự biến đổi của quy trình và đưa ra những dự đoán về kết quả Mặc dù có thể dự đoán được kết quả của quy trình, nhưng kết quả này có thể không đủ để hoàn thành hết những mục tiêu

đã được thiết lập Tại cấp độ 5, quy trình còn quan tâm đến các trường hợp thường gây ra

sự biến đổi của quy trình và sự thay đổi đó có thể cải thiện hiệu quả của quy trình để đạt được những mục tiêu về cải tiến chất lượng đã đề ra ban đầu

2.1.5 Ưu điểm, hạn chế của CMMI

 Kết hợp những gì đã có được và cộng thêm vào những thực hành tốt nhất Ví dụ như cách đo lường, quản lý rủi ro, quản lý cung cấp

 Thực hiện thêm đầy đủ và thuần thục với cách thức làm việc

 Thêm vào chức năng nhận phê bình từ sản phẩm và dịch vụ của công ty

 Thêm vào hoàn toàn những điều tuân theo chuẩn ISO

Hạn chế:

 Cần phải xem xét và cân nhắc kỹ về thời gian và nổ lực để thực hiện

 Tốn nhiều kinh phí để triển khai (chi phí nhân lực, tài liệu, đào tạo…)

2.2 Tổng quan về Agile - Scrum

2.2.1 Định nghĩa, tuyên ngôn Agile

Agile Software Development (phương thức phát triển phần mềm linh hoạt), là một nhóm các phương pháp và phương pháp luận phát triển phần mềm dựa trên các nguyên tắc, theo

đó nhu cầu và giải pháp thông qua sự hợp tác giữa các nhóm với nhau.[12]

Theo quan niệm truyền thống, một dự án phần mềm được coi là thành công khi sản phẩm được giao đúng hạn, trong ngân sách cho phép và làm đúng yêu cầu của khách hàng Tuy nhiên, trên thực tế, nhiều dự án thỏa mãn tất cả các tiêu chí này nhưng rút cuộc vẫn bị coi

là thất bại bởi phần mềm làm ra không được người dùng ưa thích, hoặc không mang lại nhiều lợi ích cho các cá nhân, tổ chức sử dụng chúng

Tuyên ngôn của Agile:

 Các cá nhân và sự tương tác quan trọng hơn là quy trình và công cụ

 Phần mềm hoạt động được quan trọng hơn là tài liệu đầy đủ

 Cộng tác của khách hàng quan trọng hơn là việc thương lượng hợp đồng

 Đáp ứng các thay đổi hơn là tuân thủ theo kế hoạch

Theo cuộc khảo sát từ công ty Versionone (http://www.versionone.com/) được thực hiện

từ tháng 7 đến tháng 10 năm 2014, với tổng trên 3.925 người tham gia khảo sát Kết quả cho thấy:

Đánh giá về lợi ích của Agile:

o 87% trong số tất cả những người tham gia trả lời đều đồng ý rằng việc ứng dụng Agile sẽ nâng cao khả năng quản lý sự thay đổi trong tổ chức

o 53% trong số đó cho biết rằng phần lớn các dự án ứng dụng Agile đều thành công Hình 2.4 là kết quả khảo sát về những lợi ích của việc triển khai Agile Trong đó 3 lợi ích được nhiều người nhận định nhất đó là: kiểm soát sự thay đổi, tăng hiệu suất làm việc, có thể nhìn thấy kết quả trong thời gian ngắn

Hình 2.4: Các lợi ích Agile mang lại cho tổ chức

(nguồn http://www.versionone.com/)

2.2.2 Giới thiệu Scrum framework

SCRUM – là một quy trình phát triển phần mềm dựa trên mô hình Agile Là một trong những khung làm việc phổ biến nhất hiện nay.[11]

Từ khảo sát của Versionone về mức độ sử dụng các phương pháp của Agile, kết quả khảo sát được thể hiện qua hình 2.5 cho thấy Scrum chiếm tỷ lệ 56% trong số tất cả các phương pháp hiện có.[3]

Hình 2.5: Tỷ lệ sử dụng các phương pháp trong Agile

(nguồn http://www.versionone.com/) Scrum chia dự án ra thành các vòng lặp phát triển gọi là Sprint, tùy vào mỗi dự án mà quy định thời gian cho 1 Sprint, nhưng thông thường, 1 sprint sẽ kéo dài từ 2 đến 4 tuần

để hoàn thành một số chức năng, mục đích nào đó trong toàn bộ hệ thống Do đó Scrum phù hợp cho những dự án có nhiều sự thay đổi và yêu cầu tốc độ cao.[11]

SCRUM hoạt động dựa trên ba giá trị cốt lõi: Transparency (tính minh bạch), Inspection (sự cam kết), Adaptation (tính thích nghi).[15]

 Transparency (tính minh bạch): Là giá trị cốt lõi cơ bản nhất, các thông tin liên

quan tới quá trình phát triển phải minh bạch và thông suốt Các thông tin có thể là: tầm nhìn về sản phẩm, yêu cầu khách hàng, tiến độ công việc, các khó khăn, rào cản,… Từ đó mọi người ở các vai trò khác nhau cũng đều có đủ thông tin cần thiết

để hoàn thành công việc của mình một cách tốt nhất

 Inspectation (sự cam kết): Việc kiểm tra luôn được thực hiện liên tục trên toàn bộ

các hoạt động trong Scrum, nhằm đảm bảo các vấn đề được phát hiện và xử lý kịp thời

 Adaptation (tính thích nghi): Là một phần của Agile nên Scrum có tính linh hoạt

cao, nhờ vậy mà khả năng thích nghi với thay đổi rất cao Scrum có thể phản hồi lại các thay đổi một cách nhanh chóng và tích cực, từ đó mang lại hiệu quả cao cho công việc dự án

2.2.3 Các thành phần trong Scrum

 Ba vai trò chính

o Product Owner (PO - chủ sản phẩm): là người làm những công việc bắt đầu cho dự án, tạo ra các yêu cầu trong quá trình phát triển dự án Phân tích mục tiêu, đưa các kế hoạch

o Scrum Master (SM): là người hiểu biết sâu sắc về Scrum, có trách nhiệm đảm bảo các Sprint được hoàn thành đúng mục đích, bảo vệ đội làm việc và loại bỏ các trở ngại

o Development team (nhóm phát triển): là một nhóm người thực hiện phát triển các chức năng của sản phẩm, nhóm thường từ 5 - 9 người, tùy theo yêu cầu của từng dự án mà số lượng, kỹ năng các thành viên trong nhóm khác nhau

 Bốn cuộc họp chính trong Scrum

o Sprint planning meeting – cuộc họp lập kế hoạch cho Sprint

Được tiến hành trước khi Sprint bắt đầu Nhóm cùng với Product Owner lên kế hoạch công việc cho Sprint Các công việc đã được sắp xếp theo thứ tự ưu tiên, nhóm phát triển

sẽ cùng kiểm tra, phân tích để làm rõ yêu cầu Đồng thời ước lượng thời gian sẽ hoàn thành công việc Các công việc sau khi ước lượng xong sẽ mang vào Sprint backlog Sau buổi họp này sẽ xác định được tổng thời gian và khối lượng công việc sẽ hoàn tất trong Sprint

o Daily Scrum meeting (Standup meeting) – buổi họp hằng ngày

Trong suốt Sprint, đội dự án sẽ họp hằng ngày trong khoảng 15 phút để cập nhận tình trạng công việc của từng thành viên Đồng thời nhận diện vấn đề phát sinh nếu có

o Sprint review meeting – buổi họp đánh giá Sprint

Sau khi sprint kết thúc, nhóm phát triển sẽ cùng với Product Owner kiểm tra tất cả công việc đã làm được Đề xuất chỉnh sửa hoặc bổ sung sẽ được mang vào sprint kế tiếp để thực hiện

o Sprint Retrospective meeting – buổi họp cải tiến Sprint

Nhận xét đánh giá quá trình thực hiện sprint, những ưu điểm, hạn chế cần khắc phục trong sprint kế tiếp

Là danh sách công việc đã được nhóm phát triển cùng Product Owner kiểm tra, đánh giá

để bỏ vào theo độ ưu tiên Các công việc trong Sprint Backlog cần phải được xử lý hết trong Sprint

Sự khác nhau giữa Product Backlog và Sprint Backlog thể hiện qua bảng 2.1 bên dưới

Đơn vị ước lượng Story Points (đơn vị

ước lượng trong Scrum)

Giờ

Người sở hữu công

việc

Product Owner Nhóm phát triển

Qúa trình thực hiện Xuyên suốt dự án Trong một Sprint

Bảng 2.1: Sự khác nhau giữa Procduct Backlog và Sprint Backlog

 Có thể thấy được kết quả trong thời gian ngắn

 Đáp ứng tối đa sự thay đổi của khách hàng, môi trường

 Tối đa hóa hiệu quả của kỹ năng làm việc nhóm (teamworks) Có thể đánh giá từng cá nhân một cách chính xác nhất

 Tăng năng suất làm việc bằng cách hạn chế các công việc không cần thiết theo các quy trình cũ như đào tạo, làm tài liệu