Phương pháp phát triển phần mềm nhanh Agile và phát triển ứng dụng trên smartphone : Luận văn ThS. Công nghệ thông tin: 60 48 01 03

50 Trang 7 DANH MỤC KÍ HIỆU VÀ CHỮ VIẾT TẮT Smartphone Điện thoại thông minh Scrum Không dịch Product Owner PO Chủ sản phẩm Development Team Nhóm Phát Triển Scrum Master Không dịch Dail

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN VĂN DUY

PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM NHANH AGILE VÀ PHÁT TRIỂN ỨNG DỤNG TRÊN

SMARTPHONE

LUẬN VĂN THẠC SĨ NGÀNH CÔNG NGHỆ THÔNG TIN

Hà Nội - 2015

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN VĂN DUY

PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM NHANH AGILE VÀ PHÁT TRIỂN ỨNG DỤNG TRÊN

SMARTPHONE

Ngành: Công nghệ Thông tin

Chuyên ngành: Kỹ Thuật Phần Mềm

Mã số: 60.48.01.03

LUẬN VĂN THẠC SĨ NGÀNH CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS NGUYỄN VIỆT HÀ

Hà Nội - 2015

LỜI CẢM ƠN

Để hoàn thành luận văn Thạc sĩ này tôi xin được gửi lời cảm ơn sâu sắc đến thầy PGS.TS Nguyễn Việt Hà về định hướng khoa học, luôn quan tâm và tạo điều kiện thuận lợi trong suốt quá trình nghiên cứu hoàn thành luận văn này

Tôi xin được gửi lời cảm ơn đến các thầy, cô trong Bộ môn Kỹ thuật Phần Mềm Khoa Công nghệ Thông tin đã truyền đạt cho tôi những kiến thức quý giá

và bổ ích trong quá trình theo học tại trường

Tôi cũng xin chân thành cảm ơn đến gia đình tôi về sự quan tâm, động viên của bố - mẹ và các em đã giúp tôi có thêm nghị lực, cố gắng để hoàn thành luận văn

Cuối cùng, xin gửi lời cảm ơn chân thành nhất đến các bạn cùng học K19, K20 đã giúp đỡ tôi trong suốt 3 năm học tập

Do thời gian và kiến thức có hạn nên luận văn chắc không tránh khỏi những thiếu sót nhất định Tôi rất mong nhận được những sự góp ý quý báu của thầy cô và các bạn

Hà Nội, ngày 28 tháng 12 năm 2015

Nguyễn Văn Duy

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn “Phương pháp phát triển phần mềm nhanh

Agile và phát triển ứng dụng trên Smartphone” là công trình nghiên cứu của

cá nhân tôi dưới sự hướng dẫn của PGS TS Nguyễn Việt Hà, trung thực và

không sao chép của tác giả khác Trong toàn bộ nội dung nghiên cứu của luận

văn, các vấn đề được trình bày đều là những tìm hiểu và nghiên cứu của chính

cá nhân tôi hoặc là được trích dẫn từ các nguồn tài liệu có ghi tham khảo rõ

ràng, hợp pháp

Tôi xin chịu mọi trách nhiệm và mọi hình thức kỷ luật theo quy định cho

lời cam đoan này

Hà Nội, ngày 28 tháng 12 năm 2015

Nguyễn Văn Duy

MỤC LỤC

Mục Lục

Danh mục kí hiệu và chữ viết tắt

Danh mục hình vẽ và đồ thị

Chương 1 : Tổng quan về đề tài 1

1.1 Tổng quan về đề tài 1

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

Chương 2: Tổng quan về Agile 5

2.1 Tìm hiểu chung về Agile 5

2.1.1 Giới thiệu về Agile 5

2.1.2 Vì sao nên sử dụng Agile? 5

2.1.3 Các đặc trưng của Agile 6

2.1.4 Ưu điểm và nhược điểm của phương pháp Agile 7

2.1.5 So sánh mô hình phát triển của Agile với các mô hình phát triển phần mềm truyền thống khác 8

2.1.6 Các quy trình phát triển phần mềm sử dụng phương pháp Agile 9

2.2.1 Tổng quan về Scrum 11

2.2.2 Đặc trưng của Scrum 11

2.2.3 Các thành phần của dự án quản lý bằng scrum 12

Chương 3: Quy trình Agile/Scrum trong dự án SMARTPHONE 27

3.1 Đặc điểm của phát triển ứng dụng trên Smartphone 27

3.1.3 Các thành phần khi phát triển một ứng dụng di động 28

3.1.4 Vòng đời phát triển ứng dụng trên Smartphone 29

3.2 Một số phương pháp phát triển phần mềm cho Smartphone 30

3.2.1 Mobile-D (Abrahamsson et al, 2004) 30

3.2.2 MASAM 32

3.3 Ứng dụng Agile/Scrum và phương pháp Scrum of Scrums trong dự án SmartPhone 34

Chương 4: Ứng dụng Agile/Scrum trong dự án phát triển ứng dụng trên smartphone 36 4.1 Giới thiệu tóm tắt về dự án phần mềm cho điện thoại di động thông minh Social SEF 36

4.2 Một số khó khăn khi đội dự án triển khai 36

4.3 Cách thức đội quản lý dự án theo quy trình Agile/Scrum 38

4.3.1 Thiết lập kế hoạch thực hiện 38

4.3.2 Thành lập đội dự án 39

4.3.3 Xây dựng print backlog cho iOs và Website 39

4.3.4 Quy trình thực hiện 44

4.3.5 Họp scrum hàng ngày 45

4.3.6 Tổng hợp kết quả trên biểu đồ 46

4.4 Đánh giá và nhận xét 47

Kết Luận 49

Tài liệu tham khảo 50

Phụ Lục 51

DANH MỤC KÍ HIỆU VÀ CHỮ VIẾT TẮT

Smartphone Điện thoại thông minh

Product Owner (PO) Chủ sản phẩm Development Team Nhóm Phát Triển Scrum Master (Không dịch) Daily Scrum Meeting Họp Scrum hàng ngày Sprint Planning (Lên) Kế hoạch Sprint Sprint Review Sơ kết Sprint

Sprint Backlog Không dịch Increment Phần tăng trưởng

Phần cải tiến Sprint Event Sự kiện (trong) Sprint

Functionality Chức năng có thể bàn giao

DANH MỤC HÌNH VẼ VÀ ĐỒ THỊ

Hình 1.1 Mô tả quá trình phát triển của Smartphone từ năm 2010-2014 (Nguồn

http://techlomedia.in) 1

Hình 1.2: Danh sách 10 quốc gia sử dụng Smartphone nhiều nhất (Nguồn http://blog.gfk.com) 2

Hình 1.3: Biểu đồ thể hiện sự phát triển ứng dụng từ năm 2009-2013 3

Hình 2.1 So sánh giá thành phát triển sản phẩm của Agile và Thác nước 9

Hình 2.2 Ví dụ về một product backlog sử dụng excel 15

Hình 2 3 Quy trình phát triển Scrum 17

Hình 2.4: Phương pháp phát triển Scum of Scrums 23

Hình 2.5: Mô tả việc chia sub-backlog cho mỗi đội dự án 24

Hình 3.1: Các thành phần phát triển của dự án cho Smartphone 28

Hình 3.2: Quy trình phát triển Agile-Scrum cho ứng dụng di động 29

Hình 3.3: Các giai đoạn phát triển của Mobile-D 31

Hình 3.4: Mô tả Scrum dự án phát triển Smartphone 35

Hình 4.1: Những thay đổi của dự án liệt kê trong Excel 37

Hình 4.2: Những thay đổi yêu cầu của dự án từ khách hàng 38

Hình 4.3: Kế hoạch thực hiện dự án 38

Hình 4.4: Chia công việc cho mỗi Scrum Team 40

Hình 4.5: Luồng thực hiện tác nghiệp 43

Hình 4.6: Liệt kê các công việc trong sprint 1 của dự án trong trello 44

Hình 4.7: Chi tiết của Sprint 1 45

Hình 4.8: Biểu đồ mô tả hoạt động của cả dự án 46

1

Chương 1 : Tổng quan về đề tài

Tóm tắt: Chương này đưa ra lý do thực hiện đề tài và giới thiệu chung về phương

pháp phát triển phần mềm nhanh Agile Thông qua việc tìm hiểu thực tế sự phát triển của Smartphone để đưa ra phương hướng phát triển cho luận văn

1.1 Tổng quan về đề tài

Trong những năm gần đây ngành công nghiệp di động đang chứng kiến sự phát triển nhanh chóng về số lượng thiết bị di động được sử dụng cũng như sự phát triển mạnh mẽ về công nghệ Bảng thống kê bên dưới liệt kê chi tiết tỷ lệ phát triển của thị trường Smartphone từ năm 2010 đến năm 2014

Hình 1.1 Mô tả quá trình phát triển của Smartphone từ năm 2010-2014 (Nguồn

http://techlomedia.in) Cùng với sự phát triển mạnh mẽ của Smartphone ở trên toàn thế giới thì thị trường Smartphone ở Việt Nam cũng đang phát triển Thông qua việc thống kê của tổ chức GFT Forecasts ở năm 2015 thì Việt Nam đang được đứng thứ 9 trên thế giới về

số lượng Smartphone sử dụng

3

Hình 1.3: Biểu đồ thể hiện sự phát triển ứng dụng từ năm 2009-2013

(Nguồn https://research2guidance.com) Chính vì lẽ đó ngành công nghiệp di động có sự cạnh tranh cao và năng động Việc phát triển ứng dụng cho Smartphone đòi hỏi các công ty về phần mềm cho điện thoại di động phải có một quy trình phát triển phần mềm nhanh và thỏa mãn được yêu cầu khách hàng

Agile là một quy trình giúp cho việc phát triển phần mềm được nhanh gọn và linh hoạt hơn Do đó, khi sử dụng phương pháp Agile cho việc phát triển phần mềm làm cho quá trình phát triển phần mềm đủ linh hoạt để thích ứng với các công nghệ nhanh chóng và dễ dàng khi công nghệ thay đổi Trong việc phát triển ứng dụng trên Smartphone, phương pháp này là rất quan trọng vì các ứng dụng được thay đổi và phát triển dựa trên yêu cầu của người dùng là ngay lập tức Đối với các đội tập trung vào yêu cầu của khách hàng thông qua việc phát triển ứng dụng trên một quy trình phát triển sản phẩm thì Agile là phương pháp lý tưởng để làm được điều này

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

- Tìm hiểu phương pháp phát triển phần mềm Agile và so sánh phương pháp phát triển phần mềm Agile với các quy trình phát triển phần mềm truyền thống khác

4

- Tìm hiểu quy trình phát triển phần mềm Agile-Scrum là một quy trình phát triển phần mềm dựa trên các đặc điểm của phương pháp phát triển phần mềm nhanh nhẹn Agile

- Nghiên cứu về các đặc điểm của thiết bị Smartphone và đặc điểm của các dự án Smartphone, qua đó cũng tìm hiểu các quy trình phát triển phần mềm cho Smartphone đã được sử dụng như Mobile D, MASAM, SLeSS

- Nghiên cứu cách thức để thực hiện dự án Smartphone dựa trên mô hình Scrum và áp dụng vào dự án phát triển ứng dụng SEF là một dự án phát triển trên Website và nền tảng iOS để đưa ra các đánh giá và nhận xét chi tiết về phát triển ứng dụng cho Smartphone sử dụng quy trình Agile-Scrum

Agie-5

CHƯƠNG 2: TỔNG QUAN VỀ AGILE

Chương này nhằm giới thiệu tổng quan về Agile Mở đầu bằng lịch sử phát triển của Agile qua từng giai đoạn sau đó đưa ra ưu nhược điểm của Agile trong phát triển phần mềm Giới thiệu đơn giản về một số quy trình phát triển phần mềm sử dụng phương pháp Agile và tập trung về quy trình phát triển phần mềm Scrum

2.1 Tìm hiểu chung về Agile

2.1.1 Giới thiệu về Agile

Phương pháp Agile để phát triển phần mềm đã trở nên lan rộng trong thời gian qua Cụ thể là vào tháng 2 năm 2015 theo khảo sát của tổ chức Scrum Alliance Những ý tưởng của phương pháp này có nguồn gốc từ phương pháp lặp của Lean Manufacturing (1940) và Agile Manufacturing (1990) Trong đó nhấn mạnh khả năng thích nghi của các công ty đến một môi trường năng động Các tính năng độc đáo của phương pháp này được tìm thấy trong “Agile Manifesto” là cá nhân và tương tác quan trọng hơn quy trình nghiệp vụ, sản phẩm tốt hơn tài liệu đầy đủ

Phát triển phần mềm linh hoạt (Agile software development) 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 (iterative) và tăng trưởng (incremental), 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 (adaptive planning), 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ình phát triển

2.1.2 Vì sao nên sử dụng Agile?

- Sản phẩm của một dự án phần mềm là khác nhau nên việc áp dụng một quy trình để phát triển hàng loạt là rất khó khăn

- Ngay từ đầu khách hàng khó có thể hình dung đầy đủ các yêu cầu đặt ra cho sản phẩm mà phải qua quá trình hình thành nên việc ứng phó với những thay đổi yêu cầu sẽ giúp giảm thiểu rủi ro cho dự án

- Đảm bảo sản phẩm đầu ra đúng theo nhu cầu của khách hàng

6

2.1.3 Các đặc trƣng của Agile

Có rất nhiều cách tiếp cận khác nhau với phương pháp Agile Bên cạnh các cách thức tổ chức công việc, thiết lập quy trình, các phương pháp Agile còn nghiên cứu và đưa vào sử dụng các công cụ và kĩ thuật đặc thù như công cụ tích hợp liên tục kiểm thử đơn vị, mẫu thiết kế, tái cấu trúc, phát triển hướng kiểm thử, phát triển hướng hành

vi, hay lập trình theo cặp … để đảm bảo và gia tăng tính linh hoạt

 Tính lặp (Iterative)

Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại Các phân đoạn (được gọi là Sprint) này thường có khung thời gian ngắn (từ một đến bốn tuần) Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử (với các mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm

 Tính tiến hóa (Evolutionary)

Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng Các phần nhỏ này thường là đầy đủ, có khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng ngay Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn

 Tính thích nghi (Adaptive)

Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc lập kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu …) đều có thể được đáp ứng theo cách thích hợp

 Ràng buộc về thời gian (Time - Bound)

Thời gian luôn là vấn đề rất quan trọng trong việc phát triển phần mềm bằng Agile Nó xác định thời gian hoàn thành dự án và mỗi sprint phát triển dự án để bàn giao sản phẩm cho khách hàng kiểm tra xem đúng yêu cầu và chức năng hay không

 Quản lý thực nghiệm (Empirical Process Control)

7

Các nhóm Agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tính toán

lý thuyết hay các giả định Việc phân nhỏ dự án thành các phân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập dữ kiện cho phép điều chỉnh các chiến lược phát triển của mình Theo thời gian, các chiến lược này sẽ tiến gần đến trạng thái tối ưu, nhờ đó nhóm có thể kiểm soát được tiến trình, và nâng cao năng suất lao động

 Dựa trên giá trị (value - based)

Một trong những nguyên tắc cơ bản của Agile là phần mềm chạy tốt chính là thước đo tiến độ Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm

Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm Agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng), cộng tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn cho dự

án Nhờ đó các dự án Agile thường giúp khách hàng tối ưu hóa được giá trị của dự án Chính vì thế, Agile làm gia tăng đáng kể độ hài lòng của khách hàng

2.1.4 Ưu điểm và nhược điểm của phương pháp Agile

- Sẵn sàng thích ứng với những thay đổi thường xuyên xảy ra, kể cả khi đó là sự thay đổi rất muộn

 Nhược điểm

- Khó khăn hơn để xác định một trường hợp kinh doanh cho dự án và để đàm phán các dự án giá cố định

2.1.5 So sánh mô hình phát triển của Agile với các mô hình phát triển phần mềm truyền thống khác

Đượ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

trong quá trình lập kế hoạch

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

trình xây dựng dự án

Ngày hoàn thành sản

phẩm

Được xác định trong quá trình lập 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

Trong kế hoạch ban đầu

Xuyên suốt từ kế hoạch đến xây dựng

và kết thúc

Kinh nghiệm trao đổi Đào tạo trước

cho đến khi bắt tay làm dự án

Đào tạo trước cho đến khi bắt tay làm dự án

Thực hiện trong quá trình làm dự án

Khả năng thành công Thấp Trung bình thấp Cao

9

So sánh về giá thành phát triển phần mềm

Hình 2.1 So sánh giá thành phát triển sản phẩm của Agile và Thác nước Theo “The Money Pit”, tổ chức Standish Group đã nghiên cứu 2 dự án phần mềm lớn giống nhau, thực hiện ở hai công ty có kích thước tương tự nhau Một dự án thực hiện với mô hình Agile, một với Waterfall Các kết quả được mô tả như hình trên, các

dự án Agile rẻ hơn 4 lần so với chi phí của dự án Waterfall

2.1.6 Các quy trình phát triển phần mềm sử dụng phương pháp Agile

Một số quy trình phát triển phầm mềm sử dụng phương pháp phát triển phần mềm nahnh Agile bao gồm phương quy trình Extreme programming (XP), quy trình Scrum, quy trình Ration Unified Process (RUP)

a Quy trình Extreme programming (XP)

XP là một phương pháp linh hoạt dành cho các nhóm phát triển phần mềm nhỏ và trung bình xây dựng các phần mềm có yêu cầu thay đổi một cách nhanh chóng Nó đảm bảo công việc phù hợp cho các nhà phát triển và lợi ích tốt nhất sau thời gian làm việc cho khách hàng và người quản

XP sử dụng các nhóm làm việc kết hợp gồm những người lập trình, khách hàng và các nhà quản trị để phát triển phần mềm có chất lượng cao trong thời gian nhanh chóng Một chương trình chạy được là thước đo đầu tiên của tiến trình theo XP XP có

10

thể phát triển và tồn tại được là do sự hiểu biết ngày một tiến bộ về các vấn đề đang giải quyết và cũng là vì các công cụ sẵn có cho phép ta thay đổi được cái giá của sự thay đổi

b Quy trình phát triển phần mềm thống nhất Rational Unified Process (RUP)

RUP là một nền tảng quy trình thích ứng với sự phát triển các tổ chức và các nhóm

dự án phần mềm dựa trên quy trình vòng lặp phát triển phần mềm RUP hỗ trợ các hoạt động giữa các nhóm, phân chia công việc cho từng thành viên trong nhóm, trong từng giai đoạn khác nhau của quá trình phát triển phần mềm RUP sử dụng hệ thống

ký hiệu trực quan của UML và RUP được phát triển song song với UML

Vòng đời của dự án RUP được chia theo thời gian qua bốn giai đoạn nối tiếp nhau

Bao gồm: Khởi tạo (Inception), Phác thảo (Elaboration), Xây dựng

(Construction), Chuyển giao (Transition) Mỗi giai đoạn có một mốc quan trọng,

mỗi giai đoạn thực chất là khoảng giữa của 2 điểm mốc Cuối mỗi giai đoạn, bộ phận kiểm định sẽ thực hiện thẩm định các đối tượng của giai đoạn này

c Phương pháp Crystal

Crystal là một trong những cách tiếp cận thích ứng nhẹ nhất để phát triển phần mềm Crystal được thực sự bao gồm của một họ của các phương pháp (Crystal Clear, Crystal Yellow, Crystal Orange, …) có đặc điểm độc đáo được thúc đẩy bởi một số yếu tố như kích thước nhóm, hệ thống tính quyết, và các ưu tiên của dự án Gia đình Crystal này nêu lên những nhận thức rằng mỗi dự án có thể yêu cầu một bộ hơi phù hợp của các chính sách và quy trình để đáp ứng đặc điểm độc đáo của dự án

d Phương pháp Feature-Driven Development (FDD)

FDD là một quá trình ngắn lặp đi lặp lại mô hình định hướng Nó bắt đầu với việc thiết lập một hình dạng mô hình tổng thể Sau đó, nó tiếp tục với một loạt hai tuần

"thiết kế bởi tính năng, xây dựng bởi tính năng" lặp đi lặp lại Các tính năng này là nhỏ, "hữu ích trong con mắt của khách hàng" kết quả

FDD bao gồm 5 giai đoạn để cung cấp những phương thức, kỹ thuật và những hướng dẫn mà nhà đầu tư cần đến để chuyển giao hệ thống Phần lặp của quy trình

11

FDD hỗ trợ phát triển linh hoạt với sự thích nghi nhanh chóng với những thay đổi muộn trong yêu cầu của khách hàng

5 Giai đoạn của FDD là:

- Phát triển một mô hình toàn thể (Develop an Overall Model)

- Xây dựng một danh sách các tính năng (Build a Features List)

- Lập kế hoạch nhờ vào tính năng (Plan by Features)

- Thiết kế theo tính năng và xây dựng theo tính năng (Design by Feature and Build by Feature)

Khung làm việc Scrum bao gồm một hay nhiều Nhóm Scrum với các vai trò được phân định rõ ràng, các sự kiện, các tác vụ và các quy tắc Mỗi thành phần trong khung làm việc phục vụ một mục đích rõ ràng và nòng cốt trong việc sử dụng và thành công của Scrum

2.2.2 Đặc trƣng của Scrum

Scrum sử dụng các tiếp cận lặp, tăng dần để tối ưu hóa khả năng dự đoán và kiểm soát rủi ro Ba yếu tố nòng cốt tạo thành một mô hình quản lý tiến trình thực nghiệm gồm: sự minh bạch, thanh tra, và thích nghi

 Minh bạch

Các khía cạnh quan trọng của tiến trình phải được hiển thị rõ ràng cho những người có trách nhiệm với thành quả của tiến trình đó Sự minh bạch yêu cầu các yếu tố này cần được định nghĩa theo một tiêu chuẩn để những người quan sát có thể hiểu những gì họ thấy theo cùng một cách

12

 Thanh tra

Người sử dụng Scrum phải thường xuyên thanh tra các tạo tác và tiến độ để đạt được mục tiêu Sprint và phát hiện điểm bất thường ngoài theo ý muốn Tần suất thanh tra không nên quá dày, không ảnh hưởng đến công việc Công tác thanh tra có ích nhất khi được thực hiện một cách cần mẫn bởi người có kĩ năng thanh tra tại các mốc công việc

 Thích nghi

Nếu một người thanh tra xác định được rằng có vấn đề nào đó vượt quá giới hạn cho phép, và hậu quả của vấn đề đó đối với sản phẩm là không thể chấp nhận được thì quy trình hoặc các tài liệu đang được xử lý phải được điều chỉnh Sự điều chỉnh phải được tiến hành càng sớm càng tốt để giảm thiểu các sai sót khác có thể xảy ra

Scrum yêu cầu bốn sự kiện chính thức cho việc thanh tra và thích nghi như mô

tả trong phần sự kiện Scrum, bao gồm:

- Họp Kế hoạch Sprint (Sprint Planning)

- Họp Scrum hằng ngày (Daily Scrum)

- Họp Sơ kết Sprint (Sprint Review)

- Họp Cải tiến Sprint (Sprint Retrospective)

2.2.3 Các thành phần của dự án quản lý bằng scrum

Để áp dụng quy trình phát triển Scrum cần một số thành phần cơ bản gồm: Tổ chức (Organization), Quy trình (Process), Tài liệu (Atifacts)

a Tổ chức Scrum

 Nhóm Scrum

Nhóm Scrum bao gồm Chủ Sản phẩm, Nhóm phát triển, và Scrum Master Các Nhóm Scrum là các nhóm tự quản và đa chức năng Các nhóm tự quản tự mình chọn cách thức tốt nhất để hoàn thành công việc của họ, chứ không bị chỉ đạo bởi ai đó bên ngoài nhóm Các nhóm liên chức năng có đủ kĩ năng cần thiết để hoàn thành công việc

mà không phụ thuộc vào bất kì người ngoài nào khác Mô hình nhóm trong Scrum được thiết kế để tối ưu hóa sự linh hoạt, sự sáng tạo và năng suất

13

Các Nhóm Scrum chuyển giao sản phẩm theo chu kỳ và mang tính tăng dần, tối

đa hóa cơ hội cho các phản hồi Việc chuyển giao dần dần các phần việc của Sản phẩm

đã hoàn thành đảm bảo một phiên bản có thể sử dụng được của sản phẩm luôn luôn sẵn sàng

 Chủ Sản phẩm

Chủ Sản phẩm chịu trách nhiệm tối đa hóa giá trị của sản phẩm và công việc của Nhóm Phát triển Cách thức để đạt được điều đó có thể rất khác nhau tùy thuộc tổ chức, Nhóm Scrum và cá nhân

Chủ Sản phẩm là một người chủ yếu chịu trách nhiệm chính về việc quản lý Product Backlog Việc quản lý Backlog bao gồm:

- Mô tả rõ ràng các hạng mục Product backlog

- Sắp xếp thứ tự của các hạng mục trong Product Backlog sao cho đạt được mục đích và hoàn thành các nhiệm vụ một cách tốt nhất

- Tối ưu hóa giá trị công việc mà nhóm phát triển thực hiện

- Đảm bảo cho Product Backlog là luôn luôn rõ ràng, minh bạch với tất cả mọi người và chỉ ra những gì mà Nhóm Scrum sẽ làm

- Đảm bảo cho nhóm phát triển hiểu rõ các hạng mục trong Product Backlog cũng như mức độ cần thiết tương ứng

Nhóm Phát triển có các đặc trưng sau:

- Là nhóm tự quản Không ai có quyền yêu cầu Nhóm Phát triển làm thế nào để chuyển Product Backlog thành các sản phẩm có thể chuyển giao được

- Là nhóm liên chức năng, có tất cả các kĩ năng cần thiết để tạo ra sản phẩm

- Nhóm Phát triển không chứa các nhóm con nào khác với các chức năng đặc thù như "nhóm kiểm thử" hay "phân tích nghiệp vụ"

 Scrum Master

Scrum Master chịu trách nhiệm đảm bảo rằng Scrum được hiểu (đúng) và được thực thi Scrum Master thực hiện việc này bằng cách đảm bảo rằng Nhóm Scrum tuân thủ lý thuyết, các kĩ thuật thực hành và các quy tắc của Scrum

Scrum Master hỗ trợ Product Backlog theo nhiều cách, bao gồm:

- Tìm kiếm các kĩ thuật để quản lý hiệu quả Product Backlog

- Giúp Nhóm Scrum hiểu sự cần thiết của hạng mục Product Backlog rõ ràng và súc tích

- Hiểu việc lên kế hoạch cho sản phẩm trong môi trường thực nghiệm

- Đảm bảo rằng Chủ Sản phẩm hiểu cách bố trí Product Backlog sao cho giá trị đạt được lớn nhất

- Hiểu rõ và thực hành sự linh hoạt và tạo điều kiện cho các sự kiện Scrum khi cần hoặc được yêu cầu

Scrum Master hỗ trợ Nhóm Phát triển theo nhiều cách, bao gồm:

- Huấn luyện Nhóm Phát triển cách tự tổ chức và làm việc liên chức năng

- Giúp đỡ Nhóm Phát triển để tạo ra các sản phẩm có giá trị cao

- Loại bỏ các rào cản trong quá trình làm việc của Nhóm Phát triển

15

- Tạo điều kiện cho các sự kiện Scrum theo yêu cầu hoặc khi cần thiết và Huấn luyện Nhóm Phát triển trong trường hợp tổ chức/công ty chưa có hiểu biết và ứng dụng đầy đủ về Scrum

b Các tài liệu trong quy trình Agile – Scrum

 Product Backlog

Product Backlog là một danh sách chức năng cần thiết cho sản phẩm Nó là nguồn yêu cầu duy nhất thể hiện các thay đổi trong sản phẩm Chủ Sản phẩm là người chịu trách nhiệm về Product Backlog, bao gồm nội dung và thứ tự các công việc trong đó

Nó thường xuyên được cập nhập để đáp ứng nhu cầu thay đổi của khách hàng cũng như điều kiện của dự án

Hình 2.2 Ví dụ về một product backlog sử dụng excel Product Backlog là động, nó thay đổi thường xuyên để nhận biết những gì mà sản phẩm cần phải có để trở nên thích hợp, có tính cạnh tranh và hữu ích Chừng nào sản phẩm còn đó, thì Product Backlog của nó còn tồn tại

Product Backlog liệt kê tất cả các đặc tính, chức năng, yêu cầu, cải thiện, bản vá lỗi cần thiết để làm nên sản phẩm trong tương lai Các hạng mục trong Product Backlog được mô tả với các thuộc tính sau: bản mô tả, thứ tự, ước lượng và giá trị

16

Khi sản phẩm được đưa vào sử dụng và bắt đầu mang lại giá trị, có sự phần hồi

từ thị trường, Product Backlog sẽ trở thành một danh sách lớn hơn và toàn diện hơn Nhu cầu thì không ngừng thay đổi, vì thế một Product Backlog là một thực thể sống động Sự thay đổi trong các yêu cầu nghiệp vụ, điều kiện thị trường, hay công nghệ có thể dẫn đến các thay đổi trong Product Backlog

Những hạng mục trong Product Backlog có độ ưu tiên cao thường rõ ràng và chi tiết hơn những hạng mục có độ ưu tiên thấp Việc ước lượng chính xác dựa trên sự rõ ràng hơn và độ chi tiết ngày càng tăng (của các hạng mục trong Product Backlog); ngược lại, với hạng mục có độ ưu tiên thấp hơn, độ chi tiết sẽ thấp hơn Nhóm Phát triển chịu trách nhiệm với mọi việc ước lượng các hạng mục Product Backlog Chủ Sản phẩm tác động lên Nhóm bằng cách giúp họ hiểu và lựa chọn trade-off Tuy nhiên, người trực tiếp làm việc sẽ đưa ra con số ước lượng cuối cùng

 Sprint Backlog

Sprint Backlog là tập hợp các hạng mục Product Backlog được lựa chọn để phát triển trong Sprint Sprint Backlog là một bản dự báo của Nhóm Phát triển về những chức năng sẽ có trong phần Tăng trưởng tiếp theo và công việc cần làm để hoàn thành phần Tăng trưởng đó Sprint Backlog chỉ ra tất cả những việc Nhóm Phát triển cần phải làm để đạt được Mục tiêu Sprint

Sprint Backlog là một kế hoạch với độ chi tiết vừa đủ để những thay đổi về tiến

độ công việc có thể nhìn thấy được trong các cuộc họp Scrum Hằng ngày Nhóm Phát triển chỉnh sửa Sprint Backlog trong suốt Sprint, và Sprint Backlog sẽ được cập nhật trong thời gian đó Việc cập nhật này xảy ra khi Nhóm Phát triển làm việc theo kế hoạch của họ, và hiểu rõ hơn về các công việc cần thiết để đạt được Mục tiêu Sprint Mỗi khi có thêm việc mới Nhóm Phát triển đưa vào Sprint Backlog Khi công việc bắt đầu hay kết thúc, giá trị ước lượng về thời gian còn lại để hoàn tất công việc được cập nhật Khi có phần nào đó của kế hoạch là không cần thiết, chúng sẽ bị bỏ đi Chỉ có Nhóm Phát triển mới có thể thay đổi Sprint Backlog trong Sprint Sprint Backlog là một bức tranh thời gian thực về công việc mà Nhóm Phát triển lên kế hoạch để hoàn thành trong Sprint, và nó chỉ thuộc về Nhóm Phát triển

17

c Quy trình phát triển Scrum

Hình 2 3 Quy trình phát triển Scrum

 Sprint

Trọng tâm của Scrum chính là Sprint, một khung thời gian có độ dài một tháng hoặc ngắn hơn mà trong khoảng thời gian đó, Phần tăng trưởng sản phẩm thỏa mãn điều kiện: "Hoàn thành", sử dụng được và có tiềm năng phát hành Sprint có khoảng thời gian nhất quán trong suốt quá trình phát triển Một Sprint mới bắt đầu ngay khi

Sprint trước kết thúc Sprint bao gồm một cuộc họp kế hoạch Sprint, các cuộc họp

Scrum hằng ngày, một buổi họp sơ kết Sprint, và một buổi họp cải tiến Sprint

Trong một Sprint:

18

- Không cho phép bất kì sự thay đổi nào ảnh hưởng đến Mục tiêu Sprint;

- Mục tiêu chất lượng không được cắt giảm; và,

- Phạm vi có thể được làm rõ và thương lượng lại giữa Chủ Sản phẩm và Nhóm Phát triển

Mỗi Sprint có thể được coi như một dự án nhỏ với độ dài không lớn hơn một tháng Giống như dự án, Sprint được dùng để hoàn thành cái gì đó Mỗi Sprint có một định nghĩa về việc nó phải xây dựng cái gì, với một bản thiết kế và bản kế hoạch linh hoạt sẽ hướng dẫn quá trình xây dựng đó, các công việc cần làm, và sản phẩm của quá trình đó

Sprint được giới hạn trong vòng một tháng (theo lịch) Khi Sprint bị kéo dài quá thì định nghĩa về việc phải xây dựng cái gì có thể bị thay đổi, sự phức tạp sẽ gia tăng

và rủi ro sẽ tăng theo Sprint đảm bảo tính dự đoán bằng sự thẩm tra và thích nghi trong tiến trình tiến tới mục tiêu của mỗi tháng đó Sprint cũng sẽ giới hạn rủi ro trong phạm vi chi phí của một tháng lịch

 Hủy một Sprint

Sprint có thể bị hủy trước khi hết khung thời gian Chỉ có Chủ Sản phẩm mới đủ thẩm quyền dừng Sprint, mặc dù Chủ Sản phẩm có thể chịu ảnh hưởng bởi những bên liên quan khác, bởi Nhóm Phát triển, hoặc bởi Scrum Master

Một Sprint có thể bị hủy nếu như Mục tiêu Sprint có thể trở nên lỗi thời Điều này xảy ra khi công ty chuyển hướng kinh doanh hoặc khi tình thế công nghệ có sự thay đổi Nói chung, Sprint có thể bị hủy nếu nó không mang lại điều gì có ích Thế nhưng, do thời gian trong mỗi Sprint tương đối ngắn, nên việc hủy một Sprint không mấy khi có ảnh hưởng gì

Khi Sprint bị hủy, các phần sản phẩm đã hoàn chỉnh được xem xét lại Nếu phần nào đó của công việc đó là có thể chuyển giao được, thì Chủ Sản phẩm có thể chấp nhận chúng Tất các các hạng mục Product Backlog chưa hoàn tất sẽ được tái ước lượng và đặt ngược trở lại Product Backlog để phát triển tiếp Các phần việc đã thực hiện trên đó sẽ nhanh chóng hết tác dụng và phải thường xuyên được ước lượng lại

19

Việc hủy Sprint sẽ gây lãng phí tài nguyên, do mọi người phải họp lại để lên kế hoạch cho một Sprint mới Việc hủy Sprint thường gây tổn hại nhất định cho Nhóm Phát triển và rất ít khi xảy ra

Việc Lập Kế hoạch Sprint trả lời những câu hỏi sau:

- Nhóm Scrum có thể bàn giao mục tăng trưởng nào trong Sprint sắp tới?

- Làm thế nào để giao nộp được những phần tăng trưởng đó như thế nào?

 Mục tiêu Sprint

Mục tiêu Sprint là một tập các mục tiêu cần đạt trong một Sprint sau khi thực thi một phần của Product Backlog Nó cung cấp các gợi ý để Nhóm Phát triển xây dựng các Phần tăng trưởng Mục tiêu Sprint cho phép Nhóm Phát triển có một số sự linh hoạt nhất định về việc phải thực thi các chức năng như thế nào trong suốt Sprint Các hạng mục Product Backlog được chọn chuyển giao một chức năng kết hợp có thể là một Mục tiêu Sprint Mục tiêu Sprint nên là một bộ các yêu cầu gắn kết khiến Nhóm Phát triển làm việc cùng nhau chứ không phải riêng lẻ cho từng cá thể

Khi Nhóm Phát triển làm việc, họ luôn hình dung Mục tiêu này trong đầu Để thỏa mãn Mục tiêu Sprint, họ sẽ thực thi các chức năng cũng như các kĩ thuật Nếu công việc khác so với dự kiến thì họ có thể cộng tác với Chủ Sản phẩm để thương lượng lại về phạm vi của Sprint Backlog trong Sprint

 Họp Scrum Hằng ngày

Cuộc họp Scrum Hằng ngày diễn ra trong không quá 15 phút với mục đích để Nhóm Phát triển đồng bộ hóa các hoạt động của thành viên và tạo lập kế hoạch cho 24

20

giờ tiếp theo Điều này có được nhờ việc thanh tra các công việc kể từ cuộc họp Scrum Hằng ngày hôm qua và dựa trên dự báo những công việc sẽ được hoàn thành trước buổi họp lần sau Để đơn giản, cuộc họp Scrum Hằng ngày được tổ chức tại cùng một địa điểm, thời gian cố định Trong suốt cuộc họp, mỗi thành viên Nhóm Phát triển giải thích:

- Tôi đã làm những gì kể từ hôm qua để giúp Nhóm Phát triển đạt được Mục tiêu Sprint?

- Tôi sẽ làm những gì hôm nay để giúp Nhóm Phát triển đạt được Mục tiêu Sprint?

- Tôi có thấy vấn đề gì cản trở Nhóm Phát triển đạt được Mục tiêu Sprint?

Nhóm Phát triển sử dụng cuộc họp Scrum Hằng ngày để đánh giá tiến độ công việc đối với Mục tiêu Sprint và đánh giá xu hướng tiến triển của công việc trong Sprint Backlog Cuộc họp Scrum Hằng ngày tối ưu hóa khả năng để Nhóm Phát triển có thể đạt được Mục tiêu Sprint Nhóm Phát triển thường họp mặt ngay sau khi họp xong Scrum Hằng ngày để tái lập kế hoạch cho các công việc còn lại trong Sprint Hằng ngày, Nhóm Phát triển có thể giải thích cho Chủ Sản phẩm và Scrum Master biết họ định làm gì với tư cách là một nhóm tự quản để hoàn thành mục tiêu và tạo ra các phần tăng trưởng cần thiết trong Sprint

Scrum Master đảm bảo cho Nhóm Phát triển tham gia họp, nhưng chính Nhóm Phát triển mới có trách nhiệm chính trong việc tổ chức cuộc họp Scrum Hằng ngày Scrum Master dạy cho Nhóm Phát triển biết cách giữ cuộc họp không vượt quá 15 phút

Scrum Master phải áp đặt quy tắc về việc chỉ có Nhóm Phát triển mới được tham gia cuộc họp Scrum Hằng ngày

Họp Scrum Hằng ngày sẽ cải tiến việc giao tiếp, lược bỏ các buổi họp không cần thiết, nhận biết và loại bỏ các trở ngại trong quá trình phát triển, nhấn mạnh và phát huy việc đưa ra quyết định nhanh, và nâng cao mức độ hiểu biết của Nhóm Phát triển

về dự án Cuộc họp này là chìa khóa của việc thanh tra và thích nghi

 Sơ kết Sprint

21

Buổi Sơ kết Sprint được tổ chức khi Sprint kết thúc để rà soát lại phần tăng trưởng vừa làm ra trong Sprint đó, và để thực hiện các biện pháp thích nghi đối với Product Backlog nếu cần Trong cuộc họp này, Nhóm Scrum và các bên liên quan sẽ trao đổi với nhau về những gì đã hoàn thành trong Sprint vừa rồi Trên cơ sở đó và những sự thay đổi trong Product Backlog trong suốt Sprint, người tham dự cuộc họp sẽ hợp tác để thảo luận về những công việc sắp làm để tối ưu hóa giá trị Đây là cuộc họp không chính thức và việc trình bày về gói tăng trưởng chủ yếu nhằm mục đích cung cấp các phản hồi hữu ích và khích lệ sự cộng tác giữa các bên

Cuộc họp này được đóng khung trong bốn giờ cho các Sprint có độ dài một tháng Sprint ngắn hơn thì thời gian họp rút bớt cho phù hợp Scrum Master đảm bảo các sự kiện được diễn ra và người tham dự hiểu được mục đích của sự kiện Scrum Master cũng hướng dẫn mọi người luôn làm việc trong khuôn khổ thời gian được phép Buổi Sơ kết Sprint có các yếu tố sau:

- Thành phần tham dự bao gồm Nhóm Scrum và những người liên quan chính được Chủ Sản phẩm

- Nhóm Phát triển thảo luận những gì đã làm tốt trong Sprint vừa qua, những khó khăn mà nhóm đã gặp phải và cách giải quyết các vấn đề đó

- Nhóm Phát triển trình diễn các phần việc đã “Hoàn thành” và trả lời các câu hỏi của người tham gia về gói tăng trưởng

- Chủ Sản phẩm trao đổi về Product Backlog Dựa trên tiến độ cho tới thời điểm hiện thời, Chủ Sản phẩm ước lượng ngày hoàn thành (nếu cần)

- Toàn bộ nhóm thảo luận về những gì sẽ làm Để qua đó, buổi Sơ kết Sprint cung cấp các giá trị đầu vào cho buổi Họp Kế hoạch Sprint tiếp theo

- Nhìn lại thị trường hay khả năng áp dụng của sản phẩm có thể bị thay đổi hay không và những gì có giá trị cao nhất sẽ được làm tiếp

- Đánh giá lại thời gian biểu, tài chính, cơ sở vật chất, thị trường cho bản phát hành dự kiến của sản phẩm

Kết quả của cuộc họp Sơ kết Sprint là một bản Product Backlog đã được cập nhật, với các hạng mục dự định sẽ được triển khai trong Sprint tới Product Backlog có thể được điều chỉnh toàn diện để thích ứng với các cơ hội mới