Tải bản đầy đủ (.pptx) (25 trang)

Mô hình agile scrum

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 (2.65 MB, 25 trang )

Mơ Hình
Agile &
Scrum
Mơn học: Cơng nghệ phần mềm

1


Nội dung trình bày
1

Agile và Scrum là gì ?

2

Đặc trưng của Agile ?

3

Vai trị của Scrum

4

Quy trình vận hành Scrum?

5

Giá trị cốt lõi của Scrum

6


Lợi ích của Scrum mang lại

2


I. Agile là gì?


Agile là một phương pháp phát triển phần mềm linh
hoạt để làm sao đưa sản phẩm đến tay người dùng
càng nhanh càng tốt.

3


II. Scrum là gì?


Srum là một dạng mơ hình của Agile và là Framework phổ
biến khi thực hiện mơ hình Agile.Scum là mơ hình phát triển
phần mềm lặp đi lặp lại.Những khoảng lặp cố định thường
kéo dài 1,2 tuần được gọi là Sprint hoặc Iteration.

4


III. Đặc trưng của Agile ?
2. Tính tiệm
tiến và tiến
hóa


1. Tính lặp
6. Phát triển
dưạ trên giá
trị

5. Tính thích
ứng

Đặc
trưng

3. Tính thích
ứng

4. Giao tiếp
trực diện

5


III. Đặc trưng của Agile ?
3.1 Tính lặp





Dự án đượ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 trên Iteration hoặc Sprint) thường có khung thời gian ngắn từ 1 – 4 tuần.

Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ cơng việc cần thiết
như lập kế hoạch,phân tích, 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.
Các phương pháp Agile thường phân rã mục tiêu thành các thành phần nhỏ với
quá trình lập kế hoạch đơn giản và ngắn gọn nhẹ nhất, có thể và khơng thực
hiện việc lập kế hoạch dài hạn.

6


III. Đặc trưng của Agile ?
3.2 Tính tiệm tiến và tiến hóa



Cuối các phân đoạn , nhóm phát triển thường cho ra các phần nhỏ sản
phẩm cuối cùng.
Các phần nhỏ này thường đầy đủ , có khả năng chạy tốt, được kiểm thử
cẩn thận và có thể sử dụng ngay (gọi là potentially shippable product
increment of functionality).

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 sẽ
được tích lũy,lớn dần lên cho tới khi tồn bộ yêu cầu của khách hàng được
thỏa mãn

7


III. Đặc trưng của Agile ?
3.3 Tính thích ứng.





Do các phân đoạn chỉ kéo dài trong 1 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 có thể được đáp ứng thích hợp.
Theo đó, các quy trình Agile thường thích ứng tốt với các thay đổi.

8


III. Đặc trưng của Agile ?
3.4 Giao tiếp trực diện.


Về u cầu của khách hàng, Agile khuyến khích nhóm phát triển trực
tiếp nói chuyện với khách hàng để hiểu rõ hơn về yêu cầu khách hàng
thực sự cần, thay vì phụ thuộc nhiều vào văn bản.

Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình
viên ( thực hiện việc mã hóa) và một kĩ sư ( thực hiện việc thiết kế) giao tiếp
với nhau thông qua bản thiết kế.

9


III. Đặc trưng của Agile ?
3.5 Quản lý tiến trình thực nghi.





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 tốn lý thuyết hay các tiền giả định.
Nói cách khác, Agile rút gọn vịng đời phản hồi để dễ dàng thích
nghi và gia tăng tính linh hoạt.
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 sốt được tiến trình và nâng cao
năng suất lao động.

10


III. Đặc trưng của Agile ?
3.6 Phát triển dựa trên giá trị






Một trong các 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 loại bỏ đi 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ị sớm nhất có thể 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. Một cách gần như trực tiếp,Agile gia tăng độ đáng kể,
độ hài lòng của khách hàng.

11


IV. Vai trò của Scrum
Trong Srum, đội ngũ tham gia phát triển phần mềm được chia ra 3 vai trò với
trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù như sau:
Product Owner (chủ sản phẩm): là người chịu trách nhiệm về sự thành công của
dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà
phát triển phần mềm.
Scrum Master: là người có hiểu biết sâu sắc về Srum và đảm bảo nhóm có thể
làm việc hiệu quả với Srum.
Development team (đội sản xuất, hay nhóm phát triển): 1 nhóm liên chức năng tự
quản lý để tiến hành chuyển đổi các yêu cầu được tổ chức trong Product Backlog
thành chức năng của hệ thống.

12


V. Quy trình vận hành Scrum





Product Owner tạo ra 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.
Đội sản xuất sẽ thực hiện việc thực hiện hóa dần các yêu cầu của product

owner với sự lặp đi lặp lại các giai đoạn nước rút 1 đến 4 tuần làm việc
( gọi là sprint). Đầu vào là các hạng mục trong product Backlog, đầu ra
gọi là các gói phần mềm hồn chỉnh có thể chuyển giao (potentially
shippable product increment).
Trước khi cả nhóm cùng đua nước rút trong sprint, đội sản xuất với
product Owner để lập kế hoạch cho từng Sprint. Kết quả của buổi kế
hoạch là Sprint Backlog chứa các công việc cần làm trong suốt 1 sprint.

13








V. Quy trình vận hành Scrum
Trong suốt quá trình phát triển, nhóm sẻ phải cập nhật Sprint Backlog và thực
hiện công việc họp hằng ngày,để chia sẽ tiến độ công việc cũng như các
vướng mắc trong quá trình làm việc cùng nhau.Nhóm được trao quyền để tự
quản lí và tổ chức lấy cơng việc của mình để hồn thành cơng việc trong
Sprint.
Khi kết thúc Sprint, nhóm tạo ra các gói phần mềm có chức năng hồn chỉnh,
sẵn sàng chuyển giao (shippable) cho khách hàng.Buổi họp sợ kết (Sprint) ở
cuối Sprint sẽ giúp khách hàng thấy được nhóm đã có thể chuyển giao những
gì, cịn những gì phải làm hoặc cịn gì phải thay đổi hay cải tiến.
Sau khi kết thúc việc đánh giá Sprint,Scrum Master và nhóm cùng tổ chức họp
cải tiến Sprint (Sprint Retrospective) để tìm kiếm các cải tiến trước khi Sprint
tiếp theo bắt đầu, điều này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua

từng Sprint.
14


VI. Giá trị cốt lỗi
Có 3 yếu tố cốt lỗi của Scrum là:





Minh bạch: mọi kế hoạch và công việc của các thành viên tất cả đều phải
biết và công khai.
Thanh tra: phải thường xuyên thanh tra kiểm soát tiến độ cơng việc của
mình xem đã hồn thành đến đâu rồi có gì bất thường khơng để kịp thời
xử lý, đảm bảo tiến độ cơng việc.
Thích nghi: là đảm bảo rằng khi có 1 vấn đề mới hay có sự thay đổi từ
phía khách hàng thì trong team sẽ có thể xử lý và đáp ứng theo cách thích
hợp.Ln phải thích nghi trong mọi hồn cảnh.

15


VII. Lợi ích mà Scrum mang lại
 Cải thiện chất lượng phần mềm,dễ đọc dễ sử dụng
 Rút ngắn thời gian phát triển phần mềm, cho phép
khách hàng sử dụng sản phẩm sớm hơn.
 Nâng cao tinh thần đồng đội, tối ưu hóa hiệu quả và
nỗ lực của đội phát triển.
 Gia tăng tỷ xuất hoàn vốn đầu tư.

 Tăng mức độ hài lịng của khách hàng
 Kiểm sốt dự án tốt, cải tiến liên tục.
 Giảm thiểu rủi ro khi dựng sản phẩm.

16


Ví dụ demo về quy trình Scrum

17


Cơng việc về dự án game theo quy
trình Scrum
Thứ nhất là: Product owner và Scrum master sẽ lên danh sách công việc
cần thực hiện trong Sprint này. Cụ thể trong Sprint, họ lên danh sách cần
hoàn thành các việc sau:
-

Hoàn tất UI/UX cho con game

-

Hồn thành những tính năng của game

12


Thứ hai là : Sau khi Planning, Product Owner và Scrum Master đối chiếu với
Product Backlog, trong Backlog họ thấy có việc của Sprint trước vẫn chưa hồn

thành. Cụ thể trong Backlog, một phần giao diện cũ của home screen trong game cần
phải làm lại và thay đổi cho phù hợp, đồng thời cần kiểm thử lại game và chức năng
ở home screen vì phát hiện lỗi mới, vì vậy nên họ kết hợp giữa Backlog và planning
của Sprint mới.


Thứ ba là: Kết quả cuối cùng của Sprint Backlog kì này sẽ là:
-

Hồn tất UI/UX cho con game.

-

Hồn thành tính năng của con game.

-

Chỉnh sửa giao diện của home screen.

-

Kiểm thử con game và UX home screen.

14


4 cuộc họp quan trọng trong quy trình Scrum


Thứ 4 là : Product owner và Scrum master sau đó sẽ có cuộc họp với team sprint,

trong này, họ sẽ phân chia công việc cho từng team phù hợp, team leader sẽ áng
chừng xem size team có phù hợp với lượng task trong sprint hiện tại hay không để
phân chia, chẳng hạn:
-

Team đồ họa cảm thấy chỉnh sửa giao diện của home game là nhiều quá trong 1
Sprint, sau khi thảo luận, phần game được cập nhật để cho sprint sau, hiện tại chỉ
còn chỉnh sửa giao diện home và game

-

Team dev, Game Design, Tester cảm thấy lượng công việc hiện tại ổn nên bắt đầu
chia việc cho team để tiến hành Sprint


Thứ 5 là : Sau khi Backlog được cập nhật thì bắt đầu Sprint mới.
Thứ 6 là: Trong sprint, mỗi ngày các nhóm sẽ thực hiện daily scrum
meeting để báo cáo tiến độ, chẳng hạn như daily scrum trong team Tester:
-

Ngày hôm trước kiểm tra lỗi xuất hiện ở home screen khi thực hiện
tính năng A, ngày hơm nay tiến hành kiểm thử tính năng B.

15


Thứ 7 là : Khi hết sprint, leader team sẽ họp team sprint một lần nữa, lượng cơng
việc đã hồn thành và chưa hoàn thành sẽ được đưa vào Sprint. Ví dụ:
-


Team đồ họa hồn thành tồn bộ task được giao, chờ đưa ra demo nếu không ổn
sẽ đưa vào backlog sprint tiếp theo chỉnh sửa.

-

Team dev cịn một tính năng của con game chưa kịp hoàn thành, Product owner
sau đó sẽ thảo luận với team leader để sprint sau cắt giảm task cho phù hợp với
team size, đồng thời đưa task chưa hoàn tất vào backlog đợi sprint sau

-

Team Tester hoàn thành task được giao, cũng chờ demo.

Thứ 8 là :Kết quả đầu cuối của quy trình này là tăng trưởng của tiến độ sản phẩm.

8


Nhóm 5
cảm ơn cơ và các bạn
đã chú ý lắng nghe!
CREDITS: This presentation template was
created by Slidesgo, including icons by
Flaticon and infographics & images by Freepik


Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Tải bản đầy đủ ngay
×