Nghiên cứu tiến trình linh hoạt và ứng dụng scrum framework để xây dựng quy trình phát triển phần mềm cho công ty tnhh phần mềm hoàn cầu

Đưa ra những đặc thù dự án của Công Ty, sau đó phân tích những hạn chế hiện tai của Công Ty, kết hợp với những ưu điểm của tiến trình linh hoạt, mà trong đó là Scrum Framework để định hư

Trang 1

-

HUỲNH THỊ TÚ UYÊN

NGHIÊN CỨU TIẾN TRÌNH LINH HOẠT VÀ ỨNG DỤNG SCRUM FRAMEWORK ĐỂ XÂY DỰNG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM CHO CÔNG TY TNHH PHẦN MỀM

Trang 2

CÔNG TRÌNH ĐƢỢC HOÀN THÀNH TẠI

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ĩ)

Trang 3

ĐẠI HỌC QUỐC GIA TP.HCM

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

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

Họ tên học viên: Huỳnh Thị Tú Uyên MSHV: 10320989 Ngày, tháng, năm sinh: 05/07/1984 Nơi sinh: Quảng Ngãi Chuyên ngành: Hệ Thống Thông Tin Quản Lý Mã số: 60 34 48

I TÊN ĐỀ TÀI:

Nghiên cứu tiến trình linh hoạt và ứng dụng Scrum Framework để xây dựng quy trình phát triển phần mềm cho Công Ty TNHH Phần Mềm Hoàn Cầu

II NHIỆM VỤ VÀ NỘI DUNG:

Nghiên cứu lý thuyết về các thành tố tạo thành và nguyên lý hoạt động của tiến trình linh hoạt, mà trong đó là Scrum Framework Tìm hiểu về thông tin Công Ty, thông tin dự án cũng như quy trình phát triển của Công Ty TNHH Phần Mềm Hoàn Cầu Đưa ra những đặc thù dự án của Công Ty, sau đó phân tích những hạn chế hiện tai của Công Ty, kết hợp với những ưu điểm của tiến trình linh hoạt, mà trong

đó là Scrum Framework để định hướng cho việc xây dựng quy trình phát triển phần mềm cho Công Ty TNHH Phần Mềm Hoàn Cầu Xây dựng chi tiết quy trình phát triển phần mềm phù hợp cho Công Ty TNHH Phần Mềm Hoàn Cầu Triển khai, áp dụng quy trình vào các dự án tại Công Ty và đánh giá kết quả

III NGÀY GIAO NHIỆM VỤ: 14/01/2013

IV NGÀY HOÀN THÀNH NHIỆM VỤ: 22/11/2013

Trang 4

LỜI CẢM ƠN

Trước tiên xin trân trọng cảm ơn quý Thầy Cô công tác và giảng dạy ở trường Đại học Bách khoa TP Hồ Chí Minh đã tận tình giúp đỡ, hướng dẫn và truyền đạt kiến thức từ khi Em là học viên cao học ngành Hệ thống thông tin quản lý

Trong quá trình thực hiện luận văn đã gặp không ít khó khăn Để có được kết quả này, ngoài nổ lực của bản thân còn có sự đóng góp rất lớn từ người thân, thầy cô

và bạn bè Em xin ghi vào đây những lời tri ân đầy trân trọng

Xin được gởi lời cảm ơn chân thành nhất đến Thầy PGS TS Đặng Trần Khánh đã tận tình giúp đỡ, định hướng và hướng dẫn trong suốt quá trình thực hiện luận văn

để Em có thể hoàn thành nghiên cứu này

Xin được cảm ơn Anh Phan Trung Hiếu, giám đốc Công Ty TNHH Phần Mềm Hoàn Cầu, đã cho phép và tạo điều kiện cho Em thực hiện luận văn tại Công Ty TNHH Phần Mềm Hoàn Cầu

Sau cùng, Em xin cảm ơn những người bạn đã động viên và hỗ trợ trong suốt thời gian qua

TP Hồ Chí Minh, tháng 11 năm 2013

Huỳnh Thị Tú Uyên

Trang 5

TÓM TẮT

Luận văn này cung cấp quy trình phát triển phần mềm cho Công Ty TNHH Phần Mềm Hoàn nói riêng và cho những Công Ty phần mềm có quy mô và đặc trưng về Công Ty cũng như về các dự án phần mềm nói chung, dựa trên việc nghiên cứu và

áp dụng các ưu điểm nổi bật phù hợp của tiến trình linh hoạt mà cụ thể là Scrum Framework

Kết quả của việc áp dụng quy trình này tại Công Ty TNHH Phần Mềm Hoàn Cầu cho kết quả tốt trong việc cải thiện thời gian thực hiện, chất lượng của dự án, đồng thời giảm rủi ro sản xuất, chi phí thấp Khả năng trao đổi giữa khách hàng và nhà phát triển, giữa những thành viên trong đội được đặt lên mức cao Bên cạnh đó việc phát hiện lỗi, các vấn đế sớm và chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển dự án và đặc biệt phát triển những chức năng khách hàng thực sự cần để mang lại giá trị cho khách hàng, làm gia tăng độ hài lòng của khách hàng

Trang 6

This paper provides a software development process specifically for the GSOFT Company (and other software companies of similar size and function) as well as software projects in general based on research and application of strengths relative

to the Agile development process with focus on scrum framework

The result of applying this process to the GSOFT Company brings out the best results in improvement of execution time and project quality while also reducing production risks and lowering costs Communication between the Client and development team are paramount In regards to early bug and issue detection, managing change requirements, and even accepting late development features requested by the Client for vital software, customer satisfaction is our number one priority

Trang 7

LỜI CAM ĐOAN

Em xin cam đoan kết quả nghiên cứu của đề tài “Nghiên cứu tiến trình linh hoạt và ứng dụng Scrum framework để xây dựng quy trình phát triển phần mềm cho Công

Ty TNHH Phần Mềm Hoàn Cầu” 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 11 năm 2013

Huỳnh Thị Tú Uyên

Trang 8

MỤC LỤC

MỤC LỤC 7

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

DANH MỤC HÌNH 14

DANH MỤC BẢNG 15

CHƯƠNG 1: MỞ ĐẦU 16

1.1 Xây dựng vấn đề nghiên cứu 16

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

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

1.3.1 Mục tiêu đề tài 19

1.3.2 Câu hỏi nghiên cứu 19

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

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

1.4.2 Không gian và thời gian 20

1.5 Ý nghĩa nghiên cứu 20

1.6 Kết cấu của luận văn 20

1.7 Kết chương 21

CHƯƠNG 2: CƠ SỞ LÝ THUYẾT 22

2.1 Tổng quan về phát triển phần mềm linh hoạt Agile 22

2.1.1 Định nghĩa về phát triển phần mềm linh hoạt Agile 22

2.1.2 Mức độ phổ biến Agile theo thống kê của Forrester 22

2.1.3 Tỷ lệ thành công của các dự án sử dụng Agile thường gấp 3 lần so với CMMi 23

2.1.4 Các nguyên tắc và giá trị cốt lõi trong Agile 24

2.2 Tuyên ngôn Phát triển Phần mềm Linh hoạt 25

2.1.1 Cá nhân và Sự tương tác 25

2.1.2 Phần mềm Chạy tốt hơn Tài liệu Đầy đủ 27

2.1.3 Cộng tác với khách hàng hơn là Thương thảo Hợp đồng 28

2.1.4 Phản hồi với Thay đổi hơn là Bám sát Kế hoạch 29

2.3 Mô tả cụ thể về Scrum Framework 30

2.3.1 Định nghĩa về Scrum 30

2.3.2 Các thành tố cấu thành Scrum [6] 31

2.3.2.1 Ba giá trị cốt lõi 31

Trang 9

2.3.2.2 Ba vai trò 31

2.3.2.3 Bốn cuộc họp 32

2.3.2.4 Ba công cụ 33

2.3.3 Nguyên lý hoạt động của Scrum 33

2.3.4 So sánh Scrum với các quy trình phần mềm truyền thống 34

2.3.4.1 Các quy trình truyền thống: 34

2.3.4.2 Đối với quy trình Scrum 35

CHƯƠNG 3: GIỚI THIỆU VÀ ĐẶC TRƯNG CÁC DỰ ÁN CỦA GSOFT 38

3.1 Giới thiệu về GSOFT 38

3.1.1 Giới thiệu chung 38

3.1.2 Sơ đồ tổ chức 41

3.2 Quy trình phát triển phần mềm GSOFT đã sử dụng trước đó là mô hình thác nước 46

3.3 Đặc trưng các dự án của GSOFT 49

3.3.1 Nguyên nhân từ khách hàng: 51

3.3.2 Nguyên nhân từ nội bộ dự án: 51

3.3.3 Nguyên nhân khách quan: 52

CHƯƠNG 4: XÂY DỰNG CHI TIẾT QUY TRÌNH CHO GSOFT 56

4.1 Xây dựng chi tiết quy trình linh hoạt cho GSOFT 56

4.1.1 Giai đoạn 1: Chuẩn bị, lập kế hoạch và thiết kế ở mức cao [11] : 57

4.1.2 Giai đoạn 2 : Thực thi để hoàn thiện sản phẩm [15] 61

4.1.3 Giai đoạn 3: Kết thúc 77

4.2 Chọn công cụ để hiện thực quy trình linh hoạt cho GSOFT 79

4.3 Đào tạo khung làm việc và công cụ triển khai Scrum cho nhân viên trong GSOFT 82

CHƯƠNG 5: ÁP DỤNG THỬ NGHIỆM QUY TRÌNH SCRUM TẠI GSOFT VÀ ĐÁNH GIÁ KẾT QUẢ 84

5.1 Dự án số 1: FOLUP 84

5.1.1 Tầm nhìn của sản phẩm 85

5.1.2 Số Sprint trong dự án FOLUP 85

5.1.3 Tốc độ đốt cháy của Sprint 01 86

Trang 10

5.1.7 Nguyên nhân dẫn đến thành công của dự án FOLUP 90

5.2 Dự án số 2: LPCH (Lucile Packard Children’s Hospital) 90

5.2.1 Tầm nhìn của sản phẩm (Product Vision) 90

5.2.2 Số Sprint trong dự án LPCH 91

5.2.6 Nguyên nhân dẫn đến thành công của dự án LPCH 93

5.3 Dự án số 3: FRED 94

5.3.1 Tầm nhìn của sản phẩm 94

5.3.2 Tổng cộng dự án có 3 Sprint như bên dưới 95

5.3.6 Nguyên nhân dẫn đến thất bại của dự án khi sử dụng mô hình Scrum: 98

5.4 Đánh giá kết quả 98

5.4.1 Đánh giá kết quả dự án FOLUP 101

5.4.2 Đánh giá kết quả dự án LPCH 102

5.4.3 Đánh giá kết quả dự án FRED 103

5.5 Đặc trưng dự án nào thì sử dụng mô hình linh hoạt phù hợp .105

5.6 Những thuận lợi và khó khăn khi triển khai Scrum tại GSOFT 109

5.6.1 Thuận lợi khi triển khai Scrum tại GSOFT 109

5.6.2 Khó khăn khi triển khai Scrum tại GSOFT 110

CHƯƠNG 6: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 112

6.1 Kết luận 112

6.2 Hướng phát triển 113

TÀI LIỆU THAM KHẢO 115

PHỤ LỤC 117

Trang 11

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

Chỉ

mục

Từ viết tắt Thuật ngữ Ý nghĩa

Chart

việc còn lại

truyền thông CMMi Capability Maturity Model

DDD Detail Design Document Tài liệu thiết kế chi tiết hệ

Trang 12

EVM Earned Value Management Quản lý giá trị thu được

F FPT-IS FPT Information Systems Công ty hệ thống thông tin

FPT

cộng đồng FDD Feature Driven Development Phát triển dựa vào tính năng

Company

Công ty trách nhiệm hữu hạn phần mềm hoàn cầu

Ideal Time Là thời gian thực để hoàn

thành một công việc nào đó

cần chuỗi từ một điểm sản xuất

Trang 13

L Learn Learn Software

Development

Quy trình sản xuất tinh gọn

LPCH Lucile Packard Children‟s

Hospital

Bệnh viện trẻ em Lucile Packard

Specification

Tài liệu đặc tả hệ thống theo hướng lập trình

Trang 14

Stakehoder Người liên quan

Châu Âu Stoty

Công ty tin học Tường Minh

gia công phần mềm và đầu tư hàng đầu của Mỹ

Trang 15

DANH MỤC HÌNH

Hình 2.1: Nguyên lý hoạt động của Scrum [7] 33

Hình 3.1: Sơ đồ tổ chức 1 41

Hình 3.6: Vòng đời phát triển phần mềm tại GSOFT 46

Hình 3.7: Bức tranh tổng thể vòng đời phát triển với quy trình của GSOFT 47

Hình 4.1: Các giai đoạn của quy trình Scrum tại GSOFT 56

Hình 4.2: Chi tiết về quy trình Scrum tai GSOFT 57

Hình 4.3: Product Backlog trong dự án thực tế 59

Hình 4.4: Xác định thành viên trong dự án 60

Hình 4.5: Thiết kế kiến trúc của hệ thống 61

Hình 4.6: Kịch bản trong dự án thực tế 63

Hình 4.7: Cách thức để tập hợp kịch bản dự án 64

Hình 4.8: Ví dụ về kich bản đăng ký vào hệ thống 65

Hình 4.9: Cách xác định độ phức tạp của kịch bản cho việc ước lượng dự án 68

Hình 4.10: Bảng ước lượng theo tam giác 69

Hình 4.11: : Bảng so sánh của Ideal days và Story points [18] 71

Hình 4.12: Danh sách kiểm tra để làm DoD 72

Hình 4.13: 7 giai đoạn mang lại giá trị trong tiến trình linh hoạt 78

Hình 4.14: Bảng so sánh để chọn công nghệ áp dụng tại GSOFT [22] 80

Hình 5.1: FOLUP_Burn down chart của Sprint 01 86

Hình 5.4FOLUP_Burn down chart của Sprint 04 89

Hình 5.5: LPCH_burn down chart của Sprint 01 91

Hình 5.8: FRED_burn down chart của Sprint 01 95

Trang 16

DANH MỤC BẢNG

Bảng 1.1: Doanh thu Công nghệ thông tin 16

Bảng 1.2: Bảng xếp hạng thành phố phát triển trong việc gia công phần mềm 17

Bảng 2.1: Mức độ phổ biến Agie theo thống kê của Forrester năm 2010 23

Bảng 2.2: Tỷ lệ dự án thành công nhờ sử dụng Agile 24

Bảng 2.3:Bảng so sánh các quy trình phần mềm [8] 36

Bảng 3.1: Biểu đồ về độ lớn (size) dự án 49

Bảng 3.2: Biểu đồ về phân khúc thị trường 50

Bảng 3.3:Biểu đồ về tính đúng hạn trong việc phát triền dự án 50

Bảng 3.4: Mô tả đặc trưng dự án tại GSOFT 54

Bảng 5.1: Bảng đo lường tại GSOFT 99

Bảng 5.2: Bảng công thức đo lường tại GSOFT 100

Bảng 5.3: Bảng đánh giá kết quả của dự án FOLUP 101

Bảng 5.4: Bảng đánh giá kết quả của dự án LPCH 102

Bảng 5.5: Bảng đánh giá kết quả của dự án FRED 103

Bảng 5.6: Bảng đặc trưng dự án nào thì sử dụng mô hình linh hoạt phù hợp 108

Bảng 5.7: Bảng danh sách kiểm tra Scrum 109

Trang 17

Chương 1: MỞ ĐẦU

Tóm tắt chương:

 Nội dung của chương này trình bày tổng quan về tình hình phát triển của nền công nghiệp phần mềm ở Việt Nam, đồng thời đưa ra những khó khăn trong việc phát triển phần mềm và xu hướng để giải quyết khó khăn đó là áp dụng tiến trình linh hoạt Chương này cũng trình bày lý do thực hiện đề tài, mục tiêu của đề tài và nội dung, bố cục của đề tài

1.1 Xây dựng vấn đề nghiên cứu

Trong những năm gần đây, do sự khủng hoảng kinh tế toàn cầu, doanh thu của ngành công nghiệp công nghệ thông tin chủ yếu là do sự tăng trưởng cao của lĩnh vực công nghiệp phần cứng, điện tử với doanh thu chiếm 82% [1] Công nghiệp phần mềm và công nghiệp nội dung số cũng tăng trưởng nhưng tốc độ chậm lại Năm

2011, doanh thu công nghiệp phần mềm chỉ đạt 1,17 tỷ USD tăng trưởng khiêm tốn 10% [1]

Bảng 1.1: Doanh thu Công nghệ thông tin

Nguồn : Sách trắng về CNTT-TT Việt Nam 2012

2011 Việt Nam được xếp hạng thứ 8 trong tổng số 50 nước hấp dẫn nhất về gia công phần mềm, tăng 2 bậc so với 2009 và 11 bậc so với 2007, vượt lên trên Philipine và tiến sát Thái Lan [1] Báo cáo căn cứ vào các chỉ số tài chính (giá) với

Trang 18

40%, kỹ năng và sự sẵn sàng của nguồn nhân lực (30%) và môi trường kinh doanh (30%) Việt Nam được đánh giá đứng đầu về chỉ số tài chính [1]

Việt Nam vẫn nằm trong danh sách top 30 nước dẫn đầu thế giới về gia công dịch

vụ và top 10 châu Á - Thái Bình Dương [1]

Theo Báo cáo về 100 thành phố hấp dẫn nhất thế giới về gia công phần mềm được

Công ty tư vấn Tholons công bố tháng 6/2012, TP.Hồ Chí Minh đang đứng ở vị trí

16 ( lên 1 bậc) còn Hà Nội ở vị trí 21 (giữ nguyên) [1]

Bảng 1.2: Bảng xếp hạng thành phố phát triển trong việc gia công phần mềm

Nguồn: Sách trắng về CNTT-TT Việt Nam 2012

Số lượng doanh nghiệp phần mềm, dịch vụ CNTT tăng nhanh, tính đến năm 2012,

cả nước có khoảng trên 1.000 doanh nghiệp, tăng gấp 2,5 lần so với năm 2005, trong đó chủ yếu tập trung tại tỉnh, thành phố lớn, với nhân lực trên 70.000 người [1] Năng suất lao động bình quân toàn ngành phần mềm và dịch vụ đạt trên 14.800 USD/lao động, nhưng với các doanh nghiệp có thâm niên cung cấp dịch vụ cho nước ngoài thì mức doanh thu đạt trên 20.000USD/người/năm, đặc biệt đối với lĩnh vực tích hợp hệ thống doanh thu đạt trên 30.000USD/người/năm [1]

Việt Nam hiện đã có nhiều doanh nghiệp phần mềm có quy mô trên 1.000 người như FPT-IS, TMA Solutions , đặc biệt FSoft đã có trên 3500 lao động [1] Cả nước

Trang 19

đã có 03 doanh nghiệp đạt chứng chỉ quản lý chất lượng quốc tế CMMi cấp độ 5, và hàng chục công ty có chứng chỉ CMMi cấp độ 4, CMMi cấp độ 3 hoặc ISO-9001 [1].Hiện tại có 7 khu phần mềm tập trung đang hoạt động, trong đó có một số khu khá thành công, được nhiều người biết đến như Công viên phần mềm Quang Trung, Công viên phần mềm Đà Nẵng, Khu công nghệ phần mềm Đại học quốc gia TP Hồ Chí Minh v.v

Với tiềm năng phát triển vô cùng to lớn của ngành công nghiệp phần mềm ở Việt Nam, để đảm bảo chất lượng và hạn chế rủi ro trong việc phát triển các dự án phần mềm, các công ty có vốn nước ngoài có quy mô lớn như CSC, Havernash, Pyramid

và một số Công ty phần mềm có vốn trong nước như FSoft, FPT-IS, TMA Solutions, áp dụng theo các quy trình chuẩn quốc tế, quy trình linh hoạt như CMMi, Agile, Scrum Framework, Learn, Kanban…còn các công ty có quy mô nhỏ vừa và nhỏ ở Việt Nam thì việc nghiên cứu và áp dụng các quy trình phần mềm tiên tiến này còn gặp nhiều hạn chế như thiếu thông tin, không có đội ngũ chuyên gia…dẫn đến tính cạnh tranh của các Công ty phần mềm vừa và nhỏ ở Việt Nam không cao, chất lượng dự án không cao, làm tác động không tốt đến sự phát triển của công nghiệp phần mềm ở Việt Nam [2]

Bên cạnh đó dữ liệu ngành công nghiệp cho thấy hơn 60% các yêu cầu về sản phẩm hay dự án bị thay đổi suốt quá trình phát triển phần mềm [3] Ngay cả khi các dự án truyền thống kết thúc đúng thời gian, đúng kinh phí, với tất cả các tính năng theo kế hoạch, nhưng khách hàng thường không hài lòng vì những gì họ thấy không thật sự đúng như những gì họ muốn vì khi đội dự án chuyển giao cho khách hàng thì có đến 64% các tính năng của sản phẩm mà khách hàng hiếm khi sử dụng hoặc không bao giờ sử dụng [4]

Do đó tiến trình phát triển phần mềm linh hoạt ra đời nhằm khắc phục các vấn đề ở trên nhằm khuyến khích đội dự án chủ động lấy công việc từ danh sách đã được sắp xếp, tự quản công việc, tập trung vào việc cải thiện cách thức làm việc bằng sự cam

Trang 20

kết của chính các thành viên trong đội dự án làm tăng tốc độ hoàn thành dự án và giảm thiếu 40% sai sót [3]

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

Nghiên cứu tiến trình linh hoạt và đặc biệt Scrum Famework để xây dựng một quy trình phát triển phần mềm cho các Công Ty phần mềm vừa và nhỏ ở Việt Nam và

áp dụng triển khai thực tế vào GSOFT

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

1.3.1 Mục tiêu đề tài

Xây dựng hoàn chỉnh quy trình phát triển phần mềm cho GSOFT dựa trên những đặc trưng về quy mô và dự án của GSOFT Áp dụng triển khai thử nghiệm ít nhất trên ba dự án tiêu biểu của GSOFT để đánh giá kết quả để áp dụng rộng rãi cho GSOFT nói riêng và các Công Ty phần mềm có đặc trưng về Công Ty, dự án tương

tự nói chung

1.3.2 Câu hỏi nghiên cứu

Hiện tại GSOFT đang áp dụng quy trình quản lý phần mềm nào?

Quy trình đó có đảm bảo các dự án bàn giao đúng tiến độ hay không? Có phát sinh thêm thời gian hay không?

Hiện tại trong một dự án phần mềm có những vai trò nào?

Tỷ lệ lỗi trước và sau khi bàn giao cho khách hàng?

Hiện tại trên thế giới có những quy trình quản lý dự án phần mềm nào tiên tiến? Quy trình đó có áp dụng phù hợp vào trong GSOFT hay không?

Trang 21

1.4 Phạm vi nghiên cứu

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

Đối tượng của nghiên cứu này là tiến trình linh hoạt, đặc biệt là Scrum Framework, đặc thù của GSOFT, các dự án cũng như quy trình phát triển phần mềm hiện tại của GSOFT

1.4.2 Không gian và thời gian

Không gian: nghiên cứu được thực hiện trên phạm vi các dự án phần mềm triển khai ở Việt Nam và gia công cho các khách hàng ngoài phạm vi lãnh thổ Việt Nam tại GSOFT

Thời gian: từ ngày 14/01/2013 đến ngày 22/11/2013

1.5 Ý nghĩa nghiên cứu

Xây dựng hoàn chỉnh quy trình phát triển phần mềm cho GSOFT Kết quả của việc

áp dụng quy trình này tại GSOFT cho kết quả tốt trong việc cải thiện thời gian thực hiện, chất lượng của dự án, đồng thời giảm rủi ro sản xuất, chi phí thấp Khả năng trao đổi giữa khách hàng và nhà phát triển, giữa những thành viên trong đội được đặt lên mức cao Bên cạnh đó việc phát hiện lỗi, các vấn đế sớm và chào đón việc thay đổi yêu cầu , thậm chí rất muộn trong quá trình phát triển dự án và đặc biệt phát triển những chức năng khách hàng thực sự cần để mang lại giá trị cho khách hàng, làm gia tăng độ hài lòng của khách hàng

1.6 Kết cấu của luận văn

Luận văn bao gồm 5 chương:

 Chương 1: Mở đầu

 Chương 2: Cơ sở lý thuyết

 Chương 3: Giới thiệu về GSOFT và đặc trưng dự án của Công Ty

 Chương 4: Xây dựng quy trình phát triển phần mềm cho GSOFT

Trang 22

 Chương 5: Áp dụng thử nghiệm quy trình phát triển phần mềm Scrum Framework tại GSOFT và đánh giá kết quả

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

1.7 Kết chương

Trong chương này xác định rõ lý do chọn đề tài, mục tiêu nghiên cứu và những câu hỏi nghiên cứu Đối tượng nghiên cứu và phạm vi nghiên cứu cũng được xác định

Trang 23

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

 Nội dung của chương này trình bày tổng quát cơ sở lý thuyết về tiến trình linh hoạt, mức độ phổ biến sử dụng Agile trong phát triển dự án phần mềm, tỷ lệ thành công của dự án sử dụng Agile so với sử dụng mô hình CMMi, các nguyên tắc và giá trị cốt lõi trong Agile Sau đó sẽ trình bày cụ thể về tiến trình linh hoạt được dùng

để áp dụng cho GSOFT, đó là Scrum Framework: các thành tố cấu thành Scrum, nguyên tắc hoạt động của Scrum, so sánh Scrum Framework với các mô hình truyền thống khác

2.1 Tổng quan về phát triển phần mềm linh hoạt Agile

2.1.1 Định nghĩa về phát triển phần mềm linh hoạt Agile

Phát triển phần mềm linh hoạt (Agile Software Development – gọi tắt là Agile) là một triết lý cùng với 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 phát triển phân đoạn lặp và tăng trưởng, theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng Agile thường sử dụng cách lập kế hoạch thích ứng, việc phát triển và chuyển giao theo hướng tiến hóa, sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trìh phát triển Ngày nay, triết lý Agile đã vượt xa khỏi khu vực truyền thống của mình là phát triển phần mềm để đóng góp sự thay đổi trong cách thức làm việc, quản lý, sản xuất ở các ngành khác như sản xuất, dịch vụ, kinh doanh, tiếp thị, giáo dục v.v

2.1.2 Mức độ phổ biến Agile theo thống kê của Forrester

Thuật ngữ Agile chính thức được sử dụng rộng rãi theo cách thống nhất kể từ khi

“Tuyên ngôn Agile” được giới thiệu ra công chúng năm 2001 Nhờ tính linh hoạt,

đa dạng và hiệu quả cao, các phương pháp Agile ngày càng trở thành sự lựa chọn hàng đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm

Theo khảo sát của hãng nghiên cứu thị trường Forrester (Bảng 2.1), mức độ phổ

Trang 24

biến của Agile hiện đang ở mức cao nhất, và gấp nhiều lần so với các phương pháp truyền thống như thác nước hay CMMi

Bảng 2.1: Mức độ phổ biến Agie theo thống kê của Forrester năm 2010

Nguồn từ Forrester Research

2.1.3 Tỷ lệ thành công của các dự án sử dụng Agile thường gấp 3 lần

so với CMMi

Các dự án Agile có tỷ lệ thành công gấp 3 lần so với những dự án không dùng Agile Báo cáo đó cho thấy rằng, “Quy trình linh hoạt là phương thuốc phổ dụng dành cho các dự án phát triển phần mềm thất bại Các ứng dụng phần mềm được phát triển bởi các quy trình linh hoạt có tỷ lệ thành công gấp 3 lần so với phương pháp thác nước truyền thống và có tỷ lệ phần trăm thấp hơn nhiều về thời gian và chi phí phát sinh.” Standish Group đánh giá dự án thành công dựa trên thời gian, ngân sách, và tất cả các tính năng được lên kế hoạch.Họ không báo cáo về việc có bao nhiêu dự án trong cơ sở dữ liệu của mình nhưng họ cho biết kết quả này được thực hiện trên các dự án từ năm 2002 đến 2010 Biểu đồ sau sẽ cho thấy các số liệu

cụ thể trong báo cáo của họ (Bảng 2.2)

0.0% 5.0% 10.0% 15.0% 20.0% 25.0% 30.0% 35.0% 40.0%

Agile (Phát triển phần mềm linh hoạt)

Không sử dụng một quy trình chính thức

Iterative development (Phát triển phân đoạn lặp)

Rational Unified Process (Quy trình phát triển phần …

Spiral (Quy trình xoắn ốc) Waterfall (Quy trình thác nước) Capability Maturity Model Integration (Mô hình trưởng …

ISO 9000 (Cơ Quan Thiết Lập Tiêu Chuẩn Hóa Quốc Tế)

Trang 25

Bảng 2.2: Tỷ lệ dự án thành công nhờ sử dụng Agile Nguồn từ “CHAO Manifesto” năm 2011 của Standish Group

2.1.4 Các nguyên tắc và giá trị cốt lõi trong Agile

Phát triển phần mềm linh hoạt Agile làm một thuật ngữ có nguồn gốc từ Tuyên Ngôn Phát triển Phần mềm Linh hoạt, tuyên ngôn này được soạn thảo năm 2001 bởi một nhóm gồm 17 nhà khoa học (các nhà sáng tạo Scrum, XP, DSDM và Crystal, đại diện của phát triển hướng tính năng và một vài nhà lãnh đạo khác trong lĩnh vực công nghiệp phần mềm) [5] Tuyên ngôn Agile đã tổng kết ra một số giá trị và nguyên tắc chung, phổ quát cho tất cả các phương pháp luận về linh hoạt đang tồn tại độc lập tại thời điểm đó Văn bản này đưa ra bốn giá trị cốt lõi cho phép các nhóm đạt được hiệu suất cao

Các giá trị cốt lõi này còn được hỗ trợ bởi 12 nguyên tắc [5]

 Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các phần mềm có giá trị

 Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng

 Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn

 Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt

Trang 26

 Xây dựng các dự án xung quanh những cá nhân có động lực Cung cấp cho họ môi trường, sự hỗ trợ cần thiết và tin tưởng họ để hoàn thành công việc

 Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp

 Phần mềm chạy tốt là thước đo chính của tiến độ

 Các quy trình linh hoạt thúc đẩy phát triển bền vững Các nhà tài trợ, nhà phát triển và người dùng có thể duy trì một nhịp độ liên tục không giới hạn

 Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt

 Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản

 Các kiến trúc tốt nhất, yêu cầu tốt nhất và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức

 Nhóm phát triển sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp

2.2 Tuyên ngôn Phát triển Phần mềm Linh hoạt

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

Phần mềm chạy tốt hơn là tài liệu đầy đủ

Cộng tác với khách hàng hơn là đàm phán hợp đồng

Phản hồi với các thay đổi hơn là bám sát kế hoạch

Mặc dù các điều bên phải vẫn còn giá trị, nhưng chúng tôi đánh giá cao hơn các mục ở bên trái [5]

2.1.1 Cá nhân và Sự tương tác

Cá nhân và sự tương tác giữa họ là cốt yếu để nhóm đạt được hiệu suất cao Các nghiên cứu về “bão hòa truyền thông” trong một dự án cho thấy rằng, khi không có vấn đề trong truyền thông, nhóm có thể thực hiện công việc tốt hơn 50 lần so với mức trung bình trong lĩnh vực của mình [3] Để tạo điều kiện cho truyền thông, các phương pháp linh hoạt thường xuyên sử dụng chu trình thanh tra và thích nghi Chu

Trang 27

trình này có thể diễn ra hằng phút với lập trình cặp, hằng giờ với tích hợp liên tục, hằng ngày với đứng họp, hằng phân đoạn với các buổi họp sơ kết và cải tiến

Tuy nhiên, chỉ tăng tần suất phản hồi và giao tiếp là không đủ để loại bỏ các vấn đề

về truyền thông Chu kỳ thanh tra và thích nghi làm việc tốt chỉ khi các thành viên trong nhóm thể hiện những hành vi quan trọng sau:

 Tôn trọng giá trị của mỗi cá nhân

 Trung thực trong truyền thông

 Minh bạch về dữ liệu, hoạt động, và quyết định

 Tin tưởng vào sự hỗ trợ của mỗi cá nhân với nhóm

 Cam kết với nhóm và các mục tiêu của nhóm

Để thúc đẩy các hành vi này, nhà quản lý linh hoạt phải cung cấp một môi trường

hỗ trợ, các nhà huấn luyện phải tạo điều kiện thuận lợi, và các thành viên của nhóm phải thể hiện chúng Chỉ khi đó nhóm mới có thể phát huy được hết tiềm năng của mình

Đạt tới các hành vi đó khó khăn hơn rất nhiều so với việc hình thành chúng Hầu hết các nhóm tránh lé sự thật, sự minh bạch, và tin tưởng vào các chuẩn mực văn hóa hoặc có những kinh nghiệm tiêu cực từ các xung đột xuất phát từ truyền thông trung thực trước đây Để chống lại những khuynh hướng này, ban lãnh đạo và thành viên nhóm phải tạo điều kiện cho những xung đột tích cực Làm như vậy không chỉ giúp tạo ra hành vi sinh lợi mà còn đem lại các lợi ích khác:

Cải tiến quy trình phụ thuộc vào nhóm trong việc tạo ra danh sách các trở ngại hoặc vấn đề trong tổ chức, đối mặt với chúng một cách trung thực, và sau đó loại bỏ chúng một cách có hệ thống tùy theo độ ưu tiên

Đổi mới chỉ xảy ra với việc tự do trao đổi các ý tưởng mâu thuẫn lẫn nhau, một hiện tượng được nghiên cứu và viết thành tài liệu bởi Takeuchi và Nonaka, những người cha đỡ đầu của Scrum

Trang 28

Việc hướng các nhóm tới mục tiêu chung đòi hỏi nhóm phải đối mặt và giải quyết các vấn đề về xung đột

Cam kết làm việc cùng nhau sẽ xảy ra chỉ khi mọi người đồng ý với mục tiêu chung và sau đó đấu tranh cho sự tiến bộ của bản thân cũng như nhóm

Ý cuối cùng ở trên nói về cam kết là đặc biệt quan trọng Đó là khi mà các cá nhân

và các nhóm được cam kết mà họ cảm thấy có trách nhiệm với việc cung cấp các giá trị cao, đó là điểm mấu chốt đối với các nhóm phát triển phần mềm Các phương pháp linh hoạt tạo điều kiện cho việc cam kết bằng cách khuyến khích các nhóm đưa ra một danh sách các công việc được ưu tiên hóa, để họ tự quản lý công việc của mình và tập trung vào cải tiến về cách thực hiện các công việc đó Thực hành là nền tảng của tự tổ chức, đó là động lực để đạt được kết quả trong một nhóm Agile

Để tạo ra các nhóm có hiệu suất cao, các phương pháp linh hoạt coi trọng cá nhân

và sự tương tác hơn là quy trình và công cụ Thực tế cho thấy rằng, tất cả các phương pháp linh hoạt tìm kiếm sự gia tăng trong truyền thông và cộng tác thông qua việc kiểm tra thường xuyên các chu trình thanh tra và thích nghi Tuy nhiên, các chu trình đó chỉ thực sự làm việc tốt khi mà các nhà lãnh đạo Agile khuyến khích các cuộc xung đột tích cực, thứ cần thiết để xây dựng một nền tảng vững chắc cho sự trung thực, tính minh bạch, lòng tin, sự tôn trọng, và cam kết từ các nhóm Agile của họ

2.1.2 Phần mềm Chạy tốt hơn Tài liệu Đầy đủ

Phần mềm chạy tốt là một trong những khác biệt lớn mà phát triển linh hoạt mang lại Tất cả các phương pháp linh hoạt thể hiện Tuyên ngôn Agile bằng cách nhấn mạnh việc cung cấp một phần nhỏ của phần mềm chạy tốt tới khách hàng sau một khoảng thời gian nhất định

Tất cả các nhóm Agile phải xác lập những gì họ muốn nói là “phần mềm chạy tốt”, cái thường được biết như là định nghĩa hoàn thành Ở mức độ cao, một phần của

Trang 29

chức năng hoàn thành chỉ khi các tính năng của chúng vượt qua tất cả các kiểm thử

và có thể được vận hành bởi người dùng cuối Ở mức thấp nhất, các nhóm phải vượt qua được kiểm thử đơn vị và kiểm thử hệ thống Các nhóm tốt nhất còn bao gồm việc kiểm thử tích hợp, kiểm thử hiệu năng, và kiểm thử chấp nhận của khách hàng trong định nghĩa hoàn thành đối với một phần chức năng Thông qua nguồn dữ liệu phong phú từ các dự án, một công ty CMMI Cấp độ 5 cho thấy việc xác định kiểm thử chấp nhận cùng với các tính năng, triển khai một loạt các tính năng và theo độ

ưu tiên, ngay lập tức chạy các kiểm thử chấp nhận với mỗi tính năng, và sửa bất cứ một lỗi nào có độ ưu tiên cao nhất sẽ tăng gấp đôi tốc độ sản xuất và giảm các sai sót đến 40% Điều này có được từ một công ty có tỷ lệ sai sót thấp nhất thế giới [3]

Tuyên ngôn Agile khuyến nghị các nhóm cung cấp phần mềm chạy tốt sau một khoảng thời gian nhất định Đồng thuận với định nghĩa hoàn thành là một trong những cách thực tế để nhóm Agile mang lại hiệu suất và chất lượng cao, cái cần thiết để hoàn thành mục tiêu này

2.1.3 Cộng tác với khách hàng hơn là Thương thảo Hợp đồng

Trong hai thập kỷ qua, tỉ lệ thành công của các dự án tăng hơn hai lần trên toàn thế giới Điều này được cho là vì các dự án nhỏ hơn và mức độ chuyển giao thường xuyên đã cho phép khách hàng cung cấp các thông tin phản hồi về phần mềm hoạt động một cách đều đặn hơn Các tác giả của bản Tuyên ngôn đã làm sáng tỏ điều này khi họ nhấn mạnh rằng việc để khách hàng tham gia vào quá trình phát triển phần mềm là hết sức cần thiết để dẫn tới thành công

Các phương pháp phát triển linh hoạt đã thúc đẩy giá trị này bằng cách đưa vào một đồng minh tích cực của khách hàng làm việc sát cánh với đội phát triển Lấy một ví

dụ, một nhóm Scrum đầu tiên có hàng ngàn khách hàng Sẽ là không khả thi nếu cho phép tất cả khách hàng tham gia vào quá trình phát triển sản phẩm, vì vậy họ chọn ra một vị đại sứ của khách hàng, được gọi là PO, để đại diện cho không chỉ tất

cả khách hàng trong trường hợp này mà còn bao gồm cả quản lý, dịch vụ khách

Trang 30

hàng, và các bên liên quan khác PO có trách nhiệm cập nhật danh sách yêu cầu về sản phẩm sau mỗi bốn tuần thời điểm mà nhóm Scrum phát hành phiên bản sản phẩm chạy tốt, có tính đến yếu tố thực tế cùng phản hồi của khách hàng và các bên liên quan Điều này cho phép khách hàng có thể giúp định hình sản phẩm phần mềm đang được tạo ra

Một nhóm XP đầu tiên đã bắt đầu với một dự án CNTT nội bộ Họ có thể có sẵn người sử dụng đầu cuối của công ty trong nhóm làm việc với họ hàng ngày Khoảng 10% thời gian, các tư vấn viên và nhóm nội bộ có thể tìm được một người dùng cuối có thể làm việc với nhóm từng ngày 90% thời gian còn lại, họ phải cử ra người đại diện cho khách hàng Người này, được nhóm XP gọi là Customer, làm việc trực tiếp với người dùng cuối để cung cấp một danh sách các tính năng rõ ràng cùng độ ưu tiên cho phép đội phát triển có thể thực hiện [3]

Cộng tác với khách hàng (hoặc đại diện của khách hàng) trên cơ sở hàng ngày là một trong những lý do lý giải tại sao các dữ liệu trong ngành công nghiệp cho thấy rằng các dự án linh hoạt có tỉ lệ thành công cao hơn gấp đôi so với các dự án truyền thống tính trung bình trên toàn thế giới Các phương pháp phát triển linh hoạt đã nhận ra điều đó, và do vậy, chúng đã tạo ra một vị trí đặc biệt trong đội hình phát triển để dành riêng cho vị khách hàng đại diện này

2.1.4 Phản hồi với Thay đổi hơn là Bám sát Kế hoạch

Phản hồi với thay đổi là điều cần thiết cho việc tạo ra một sản phẩm làm hài lòng khách hàng cũng như mang lại những giá trị kinh doanh Dữ liệu ngành công nghiệp cho thấy hơn 60% các yêu cầu về sản phẩm hay dự án bị thay đổi suốt quá trình phát triển phần mềm [3] Ngay cả khi các dự án truyền thống kết thúc đúng thời gian, đúng kinh phí, với tất cả các tính năng theo kế hoạch, nhưng khách hàng thường không hài lòng vì những gì họ thấy không thật sự đúng như những gì họ muốn Luật Humphrey nói rằng khách hàng không bao giờ biết những gì họ muốn cho đến khi họ thấy phần mềm hoạt động Nếu khách hàng không nhìn thấy phần

Trang 31

mềm hoạt động cho đến khi kết thúc dự án, sẽ là quá muộn cho việc kết hợp các thông tin phản hồi của họ ở thời điểm này Các phương pháp phát triển linh hoạt tìm kiếm sự phản hồi của khách hàng trong suốt dự án để có thể kết hợp thông tin phản hồi và thông tin mới ngay khi sản phẩm đang được phát triển

Tất cả các phương pháp phát triển linh hoạt đều được tích hợp sẵn những tiến trình thay đổi các kế hoạch trong một khoảng thời gian đều đặn dựa trên những thông tin phản hồi từ phía khách hàng cũng như bên đại diện của khách hàng Các kế hoạch được thiết kế để sao cho luôn cung cấp giá trị kinh doanh cao nhất trước hết Bởi vì 80% giá trị nằm trong 20% các tính năng, một dự án phát triển linh hoạt chạy tốt có

xu hướng kết thúc sớm, trong khi hầu hết các dự án truyền thống thường kết thúc trễ Kết quả là, khách hàng thì vui vẻ hơn, và các nhà phát triển thì thích thú với công việc của họ hơn Các phương pháp phát triển linh hoạt dựa trên những hiểu biết đó, để thành công hơn chúng phải có kế hoạch để thay đổi Đó là lý do tại sao chúng thiết lập các quy trình, chẳng hạn như Sơ kết và Cải tiến, được thiết kế đặc biệt để thay đổi các ưu tiên thường xuyên dựa trên thông tin phản hồi của khách hàng và giá trị kinh doanh [3]

2.3 Mô tả cụ thể về Scrum Framework

2.3.1 Định nghĩa về Scrum

Scrum là một trong các khung làm việc linh hoạt phổ biến nhất hiện nay Scrum được dùng để quản lý các dự án phát triển phần mềm, nhưng cũng được dùng trong các công việc khác với độ phức tạp và tính sáng tạo rất đa dạng [6]

Dựa trên lý thuyết quản lý thực nghiệm: Scrum sử dụng kỹ năng lặp và tăng dần để tối ưu hóa sự hiệu quả và kiểm soát rủi ro Scrum rất đơn giản, dễ đọc và khả năng ứng dụng lớn Vì vậy, để dùng Scrum chúng ta cần nghiên cứu các thanh phần sau đây

Trang 32

 Thanh tra

Công tác thanh tra liên tục các hoạt động trong Scrum bảo đảm cho việc phát hiện các vấn để cũng như giải pháp để thông tin đa dạng và hữu ích đến được với các bên tham gia dự án Với việc truy xét kỹ càng và liên tục là cơ chế khởi đầu cho việc thích nghi và cải tiến liên tục trong Scrum

Trang 33

 Nhóm phát triển

Là một nhóm liên chức năng có nhiệm vụ giải quyết các yêu cầu từ PO để tạo ra các gói sản phẩm tốt nhất

2.3.2.3 Bốn cuộc họp

 Lập kế hoạch cho Sprint

Nhóm phát triển sẽ gặp gỡ với PO để lên kế hoạch làm việc cho một Sprint Các công việc như là: chọn lựa các yêu cầu cần phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất các công việc Scrum sử dụng phương thức lập kế hoạch từng phần và tăng dần theo thời gian Theo đó, việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của

dự án mà được lặp đi lặp lại, có sự thích nghi với tình hình thực tiễn trong tiến trình

đi đến sản phẩm

 Buổi họp hằng ngày

SM cùng với Nhóm phát triển tổ chức họp hằng ngày để Nhóm chia sẽ tiến độ công việc cũng như các khó khăn gặp phải trong quá trình phát triển phần mềm suốt một Sprint

 Buổi họp đánh giá

Cuối Sprint, Nhóm phát triển cùng với PO sẽ rà soát lại các công việc đã hoàn thành trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm

 Buổi họp cải tiến

Dưới sự chỉ đạo của SM, Nhóm phát triển sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản phẩm

Trang 34

2.3.2.4 Ba công cụ

 Product Backlog

Có thể hiểu như là danh sách các yêu cầu của dự án PO chịu trách nhiệm sắp xếp

độ ưu tiên cho từng hạng mục trong Product Backlog dựa trên các giá trị do PO định nghĩa

 Sprint backlog

Là kết quả của buổi họp lập kế hoạch cho một Sprint với sự kết hợp giữa PO và Nhóm phát triển Họ sẽ cùng nhau phân tích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng danh sách công việc

 Burndown Chart

Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết để hoàn tất công việc Burndown Chart còn được dung để theo dõi tiến độ của một Sprint hoặc của cả dự án

2.3.3 Nguyên lý hoạt động của Scrum

Hình 2.1: Nguyên lý hoạt động của Scrum [7]

Nguồn từ scrum.org

Trang 35

Với mỗi dự án thì nhiệm vụ của PO là tạo ra các Product Backlog chứa các yêu cầu của dự án với các hạng mục được sắp xếp theo thứ tự ưu tiên Nhóm phát triển sẽ có nhiệm vụ hiện thực hóa các hạng mục do PO yêu cầu với sự lặp đi lặp lại các giai đoạn nước rút trong vòng 2 đến 4 tuần, với đầu vào là các Product Backlog và đầu

ra là các gói sản phẩm có thể chuyển giao được Trong lúc cùng nhau đua nước rút thì Nhóm phát triển cùng họp với PO để lên kế hoạch cho từng Sprint Kết quả của mỗi buổi họp là các Sprint Backlog Trong quá trình phát triển Nhóm phát triển sẽ thường xuyên cập nhật Sprint Backlog và thực hiện công việc này hằng ngày để cùng nhau chia sẽ tiến độ công việc cũng như các khó khăn trong quá trình làm việc Mỗi sprint kết thúc là lúc nhóm tạo ra các gói phần mềm có thể chuyển giao được Cuối mỗi Sprint, Nhóm phát triển cùng họp đánh giá với PO để thấy được Nhóm phát triển đã chuyển giao được những gì, còn những gì phải làm hoặc phải thay đổi, cải tiến Sau khi cuộc họp đánh giá kết thúc, SM và Nhóm phát triển sẽ phải tổ chức họp cải tiến để tìm ra các cải tiến mới trước khi Sprint tiếp theo bắt đầu

Các Sprint sẽ được lặp đi lặp lại cho tới khi các hạng mục trong Product Backlog được hoàn tất hoặc khi PO quyết định dừng dự án căn cứ vào tình hình thực tế Với chiến thuật “quan trọng làm trước”nên các hạng mục mang lại giá trị lớn cho dự án

Do đó, Scrum luôn mang lại giá trị tốt nhất cho người đầu tư cho dự án Quy trình luôn được cải tiến nên nhóm Scrum thường có năng suất hoạt động cao và đây là lợi ích mà Scrum mang lại cho các tổ chức

2.3.4 So sánh Scrum với các quy trình phần mềm truyền thống

2.3.4.1 Các quy trình truyền thống:

 Quy trình thác nước

Chia dự án phần mềm gồm các giai đoạn: đặt tả yêu cầu, thiết kế hệ thống, cài đặt, kiểm thử và bảo trì Quy trình này dễ quản lý nhưng kém linh hoạt và không hiệu quả bởi có sự thay đổi trong giai đoạn sau sẽ có ảnh hưởng lớn đến các giai đoạn trước Tất cả các yêu cầu công việc được xác định trong quá trình lập kế hoạch gồm

Trang 36

những việc cơ bản như: xác định các yêu cầu sản phẩm, chi phí sản phẩm, ngày hoàn thành…Dẫn đến khả năng thành công thấp nếu có những yêu cầu mới hoặc chỉnh sửa sản phẩm sẽ có sự ảnh hưởng rất lớn đến các giai đoạn trước

 Quy trình xoắn ốc

Chia dự án thành các giai đoạn như: lập kế hoạch, phân tích rủi ro, giao tiếp khách hang, đánh giá lại, sản xuất và phân phối Nhưng chưa được sử dụng rộng rãi

2.3.4.2 Đối với quy trình Scrum

Điểm mạnh nhất đó là việc linh hoạt, dự án không được cố định từ đầu về thời gian hoàn thành hay những yêu cầu mà nó sẽ được xác định khi phát triển thực tế

Phân phối sản phẩm mềm dẻo: nội dung sản phẩm chuyển giao được xác định linh hoạt theo môi trường sử dụng thực tế

Thời gian biểu linh hoạt: có thể muộn hoặc sớm hon so với kế hoạch ban đầu

Chất lượng sản phẩm tốt và giảm rủi ro sản xuất, chi phí thấp Khả năng trao đổi giữa khách hàng và nhà phát triển, giữa những thành viên trong đội được đặt lên mức cao

Tốc độ phát triển nhanh, tiết kiệm thời gian Việc chuẩn bị hành động cho những thay đổi trong quá trình phát triển tốt hơn vì hầu như hàng ngày luôn có những buổi họp đánh giá lại ở những vòng lặp phát triển

Các lỗi và các vấn đề được phát hiện sớm hơn rất nhiều so với các phương pháp truyền thống bởi vì khách hàng được tham gia đánh giá rất nhiều và đầu ra của sản phẩm rất nhanh Và khi đi sai hướng, có thể hủy ngay Sprint đó để quay lại với bản

kế hoạch

Trang 37

Đặc điểm Thác nước Xoắn ốc SCRUM

Xác định các giai

đoạn phát triển

lập kế hoạch và kết thúc

Sản phẩm cuối

cùng

Được xác định trong quá trình lập

kế hoạch

Xác định trong quá trình xây dựng dự

án Chi phí sản phẩm Được xác định

sản phẩm

kế hoạch

Thay đổi cục bộ Xác định trong quá

trình xây dựng dự

án Đáp ứng với môi

trường sử dụng

Trong kế hoạch ban đầu

Xuyên suốt từ kế hoạch đến xây dựng và kết thúc Khả năng sáng tạo,

linh hoạt của nhóm

Hạn chế khả năng tiếp cận, linh hoạt của nhóm

Không Hạn chế khả năng tiếp cận, linh hoạt của nhóm Kinh nghiệm trao

đổi Đào tạo trước cho đến khi bắt tay làm

Bên cạnh đó dựa trên thông kê của một tập đoàn đáng tin cậy là CHAO Manifesto

năm 2011 của Standish Group về tính thiết thực và hiệu quả mang lại cho khách

hàng so với các mô hình trước đây

Trang 38

Qua những phân tích này, rút ra được vấn đề liên quan trong việc sử dụng tiến trình linh hoạt mà đặc biệt là Scrum Framework trong việc phát triển các dự án phần mềm.

Trang 39

Chương 3: GIỚI THIỆU VÀ ĐẶC TRƯNG CÁC DỰ ÁN

CỦA GSOFT

 Nội dung của chương này giới thiệu Công Ty TNHH Phần Mềm Hoàn Cầu (GSOFT) về tổ chức, loại hình kinh doanh, đối tượng khách hàng, phạm vi hoạt động và đặc trưng dự án Bên cạnh đó đưa ra các nguyên nhân dẫn đến sự trể tiến

độ trong dự án và quy trình phát triển hiện tại mà GSOFT đã và đang sử dụng trước đó

3.1 Giới thiệu về GSOFT

Công Ty TNHH Phần Mềm Hoàn Cầu được thành lập theo giấy phép số:

4102048910 do Sở Kế Hoạch Đầu Tư TP.Hồ Chí Minh cấp ngày 06/04/2007 với số lượng nhân viên hiện tại là 47 thành viên

Tên giao dịch viết tắt: GSOFT [9]

Tên đầy đủ bằng tiếng Việt: Công Ty Trách Nhiệm Hữu Hạn Phần Mềm Hoàn

Cầu

Tên viết tắt bằng tiếng Việt: Công Ty TNHH Phần Mềm Hoàn Cầu

Tên đầy đủ bằng tiếng Anh: Global Software Limitted Company

Trụ sở chính: 239 Âu Cơ, Phường 5, Quận 11, Tp.HCM

Website: www.gsoft.com.vn[9]

3.1.1 Giới thiệu chung

GSOFT là một công ty phần mềm hướng công nghệ, được sáng lập bởi những người có tâm huyết, có năng lực và kinh nghiệm chuyên môn cao với mong muốn hình thành và phát triển một công ty phần mềm hàng đầu tại Việt Nam và vươn tầm

ra thế giới

GSOFT cung cấp các giải pháp kết nối cộng đồng dựa trên nền tảng công nghệ Internet, xây dựng website, các giải pháp thương mại điện tử và các giải pháp phần

Trang 40

mềm quản lý từ xa GSOFT luôn đáp ứng được những yêu cầu công nghệ, kỹ thuật mới nhất, làm thỏa mãn những nhu cầu khó tính nhất của khách hàng GSOFT định hướng nghiên cứu và ứng dụng công nghệ phần mềm vào thực tiễn đời sống nhằm nâng cao chất lượng sống cộng đồng thỏa “khát khao nâng tầm cuộc sống” đã in sâu trong tâm tưởng từng con người GSOFT

Dù sản phẩm có giá trị lớn hay nhỏ, sự uy tín và tính chuyên nghiệp với khách hàng đều được GSOFT đặt lên hàng đầu Mọi sản phẩm đều được sự bảo trì, hỗ trợ tối đa

từ phía GSOFT để đảm bảo công việc kinh doanh của khách hàng không bị gián đoạn

Với phương châm UY TÍN, CHẤT LƢỢNG VÀ CHUYÊN NGHIỆP, GSOFT

mong muốn đem đến cho quý khách hàng những sản phẩm phần mềm chất lượng nhất!

TẦM NHÌN

GSOFT định hướng xây dựng và phát triển thành một mái nhà chung cho những người có khả năng và đam mê sáng tạo trong lĩnh vực công nghệ phần mềm nói riêng và lĩnh vực công nghệ thông tin nói chung, hoạt động và mở rộng phát triển sâu rộng trong cả nước, vươn ra khu vực và toàn cầu bằng những giải pháp và sản phẩm công nghệ trí tuệ, độc đáo giúp nâng cao chất lượng cuộc sống

SỨ MỆNH

 Đối với khách hàng: Bằng cách khai thác, ứng dụng những thành tựu khoa

học công nghệ mới nhất, GSOFT mang lại những giải pháp, sản phẩm dịch

vụ giúp khách hàng gia tăng hiệu quả công việc, tăng doanh thu và giá trị thương hiệu của khách hàng, đồng thời giúp khách hàng giảm thiểu chi phí quản lý, chi phí quảng bá, truyền thông, tiếp thị, bán hàng

 Đối với đồng nghiệp: GSOFT luôn tạo ra một môi trường năng động, kích

thích sự sáng tạo và phát triển toàn diện, vượt trội cho từng thành viên

Định dạng
Số trang	156
Dung lượng	3,01 MB