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
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.2 MB, 62 trang )
ĐẠ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.1Tổng quan về đề tài ..............................................
1.2Phương pháp nghiên cứu .....................................
Chương 2: Tổng quan về Agile .......................................................................................
2.1Tìm hiểu chung về Agile ......................................
2.1.1 Giới thiệu v
2.1.2 Vì sao nên s
2.1.3 Các đặc trưn
2.1.4 Ưu điểm và
2.1.5 So sánh mô
mềm truyền thống khác ...........................................................................................
2.1.6 Các quy trìn
2.2.1 Tổng quan v
2.2.2 Đặc trưng củ
2.2.3 Các thành p
Chương 3: Quy trình Agile/Scrum trong dự án SMARTPHONE ................................
3.1Đặc điểm của phát triển ứng dụng trên Smartpho
3.1.3 Các thành p
3.1.4 Vòng đời ph
3.2Một số phương pháp phát triển phần mềm cho S
3.2.1 Mobile-D (A
3.2.2 MASAM ...
3.3Ứng dụng Agile/Scrum và phương pháp Scrum o
SmartPhone. ..............................................................................................................
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ô
Social SEF .................................................................................................................
4.2
Một số khó khăn khi đội dự án triển khai ....................................
4.3
Cách thức đội quản lý dự án theo quy trình Agile/Scrum ............
4.3.1Thiết lập kế hoạch thực hiện .
4.3.2Thành lập đội dự án ..............
4.3.3Xây dựng print backlog cho iO
4.3.4Quy trình thực hiện ...............
4.3.5Họp scrum hàng ngày ...........
4.3.6Tổng hợp kết quả trên biểu đồ
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
Scrum
Product Owner (PO)
Development Team
Scrum Master
Daily Scrum Meeting
Sprint Planning
Sprint Review
Sprint Backlog
Increment
Sprint Event
Inspection
Adaption
Framework
Functionality
Chat
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
) ............................................................................................
Hình 1.2: Danh sách 10 quốc gia sử dụng Smartphone nhiều nhất (Nguồn
) ...............................................................................................
Hình
1.3: Biểu đồ thể hiện sự phát triển ứng dụng từ nă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 ...........
Hình 2.2 Ví dụ về một product backlog sử dụng excel......................................
Hình
2. 3
Quy trình phát tr
Hình 2.4:
Phương pháp ph
Hình 2.5:
Mô tả việc chia s
Hình 3.1:
Các thành phần p
Hình
3.2:
Quy trình phát tr
Hình
3.3:
Các giai đoạn ph
Hình 3.4:
Hình
Mô tả Scrum dự
4.1:
Những thay đổi c
Hình 4.2:
Những thay đổi y
Hình 4.3:
Kế hoạch thực h
Hình 4.4:
Chia công việc c
Hình
4.5:
Luồng thực hiện
Hình
4.6:
Liệt kê các công
Hình
4.7:
Chi tiết của Sprin
Hình 4.8:
Biểu đồ mô tả ho
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
)
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.
1
Hình 1.2: Danh sách 10 quốc gia sử dụng Smartphone nhiều nhất (Nguồn
)
Cùng với sự phát triển về số lượng cũng như về công nghệ của Smartphone các
ứng dụng cho Smartphone cũng phát triển không ngừng. Cụ thể sự phát triển các ứng
dụng cho Smartphone được nhìn thấy rõ rệt trong biểu đồ bên dưới.
2
Hình 1.3: Biểu đồ thể hiện sự phát triển ứng dụng từ năm 2009-2013 (Nguồn
)
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.
3
-
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 AgieScrum 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.
4
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.
5
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)
6
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
Ƣu điểm
Có một số lý do khiến Agile được sử dụng rộng rãi và bàn giao được một sản
phẩm hoàn thiện theo đúng yêu cầu của khách hàng.
-
Ưu điểm đầu tiên có thể nói đến ở đây đó là sự hài lòng của khách hàng về việc
liên tục có những bản release được gửi và sớm có sản phẩm có giá trị để có thể
sử dụng thử.
-
Sự tương tác giữa con người với con người được chú trọng hơn là việc thực
hiện theo quy trình và các công cụ. Điều này được thể hiện bằng quá trình liên
tục trao đổi giữa development và tester, giữa development và tech leader, giữa
team phát triển và khách hàng qua mail, skype liên tục trong suốt dự án.
-
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.
7
-
Đôi khi sự tương tác giữa con người quá nhiều dẫn đến việc thiếu tập trung vào
thiết kế và các tài liệu cần thiết.
-
Cần có đội ngũ phát triển có năng lực cao, kinh nghiệm, có sự năng động và
linh hoạt để có khả năng đưa ra các quyết định cần thiết trong quá trình phát
triển phần mềm khi gặp phải những khó khăn trở ngại.
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 điểm
Xác định các giai đoạn
phát triển
Sản phẩm cuối cùng
Chi phí sản phẩm
Ngày
hoàn
th
ứng
v
phẩm
Đáp
trường sử dụng
Kinh nghiệm trao đổi
Khả năng thành công
8
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ó
9
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
10
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).
2.2 Tổng quan về Agile-Scrum
2.2.1 Tổng quan về Scrum
Scrum là gì ?
Scrum là khung làm việc đã được sử dụng để quản lý quy trình phát triển sản
phẩm phức tạp từ đầu những năm 1990. Scrum là một khung làm việc trong đó con
người có thể xác định các vấn đề thích nghi phức tạp, trong khi vẫn đảm bảo được
năng suất và sự sáng tạo để chuyển giao sản phẩm có giá trị cao nhất.
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.
11
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.
12
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
Nhóm Phát triển là những người trực tiếp sản xuất ra sản phẩm để phát hành
được cuối mỗi Sprint. Nhóm Phát triển được tổ chức và trao quyền bởi tổ chức/công ty
để quản lý công việc của họ. Sự hợp lực sẽ giúp tối ưu tổng thể hiệu suất và hiệu quả
làm việc của Nhóm Phát triển.
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ụ".
13
-
Một cá nhân trong Nhóm phát triển có thể có một số khả năng hoặc sự tập trung
đặc biệt nhưng trách nhiệm vẫn thuộc về cả nhóm phát triển.
Độ lớn tối ưu của Nhóm Phát triển là đủ nhỏ để linh hoạt và đủ lớn để hoàn thành
công việc. Nhóm ít hơn ba người sẽ có ít sự tương trợ lẫn nhau dẫn đến năng suất thấp.
Nhóm Phát triển ít người hơn có thể phải đối mặt với các ràng buộc (thiếu) kĩ năng
trong suốt Sprint và kết quả là Nhóm Phát triển khó có thể chuyển giao gói tăng trưởng
phát hành. Nhóm nhiều hơn 9 người cần điều phối nhiều hơn. Nhóm Phát triển lớn hơn
nữa trở nên phức tạp và khó quản lý để vượt qua quy trình thực nghiệm. Chủ Sản
phẩm và Scrum Master không được tính vào Nhóm Phát triển, trừ khi họ kiêm nhiệm
vai trò Thành viên của Nhóm Phát triển.
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.
14
-
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ị.
15
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.
16
