Đỉnh NGUYỄN

life's a journey not a destination


Leave a comment

Agile – Học những điều cơ bản về Agile/Scrum trong 17 ngày – bookmark


image

Agile #1 – Giới thiệu Agile

Agile #2 – Scrum là gì?

Agile #3 – Scrum Framework

Agile #4 – Các thành phần của Scrum

Agile #5 – Product Owner

Agile #6 – Scrum Master

Agile #7 – Scrum Dev Team

Agile #8 – Định nghĩa "Hoàn thành"

Agile #9 – Artifacts

Agile #10 – Meetings

Agile #11 – Sprint Planning Meeting

Agile #12 – Daily Scrum Meeting

Agile #13 – Spring Review Meeting

Agile #14 – Sprint Retrospective Meeting

Agile #15 – Scrum Process

Agile #16 – User Story

Agile #17 – Burndown Chart

Advertisements


1 Comment

Agile #17 – Burndown Chart


– 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 còn lại để hoàn tất công việc.

– Burndown Chart có thể được dùng để theo dõi tiến độ của Sprint (được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart).

– Biểu đồ burndown không phải là một thành tố tiêu chuẩn của Scrum theo định nghĩa mới, nhưng vẫn được sử dụng rộng rãi do tính hữu ích của nó.

Điều quan trọng là còn bao nhiêu việc phải làm để hoàn tất công việc chứ không phải là đã bỏ ra bao nhiêu công sức trong quá khứ.

image


1 Comment

Agile #16 – User Story


image

Một trong những mục tiêu của Backlog Refinement Meeting là tạo ra các PBIs (User Story) (Product Backlog Items) thoả các điều kiện:

+ Independent: Các User Story dễ làm việc nhất thì phải là các user story độc lập, không chồng lấp và có thể được lên kế hoạch và thực thi theo bất kỳ thứ tự nào.

+ Negotiable: Một story tốt phải có thể thương lượng. Nó không phải là một hợp đồng rõ ràng các tính năng, các chi tiết sẽ được hợp tác tạo ra giữa khách hàng và nhà phát triển

+ Valuable: Một story cần phải có giá trị với khách hàng

+ Estimable: Một story tốt có thể được ước tính. Chúng ta không cần một ước lượng chính xác nhưng phải đủ để giúp cho khách hàng đưa ra đánh giá và sắp xếp các story.

+ Small: Một story tốt có định hướng là càng nhỏ càng tốt (epic thành các user story nhỏ hơn), có khả năng thực thi nhanh chóng và có ước tính chính xác cao.

+ Testable: Có khả năng kiểm thử được. Nếu khách hàng không biết phải kiểm thử story như thế nào chứng tõ rằng story đó chưa rõ ràng hoặc là nó không có giá trị gì cho họ hoặc khách hàng cần sự giúp đỡ trong việc kiểm thử.

image

User Story đảm bảo sự cân bằng giữa các bên tham gia phát triển thể hiện bằng một ngôn ngữ hướng người dùng và các nhà phát triển có thể hiểu được. Ví dụ:… US Phải trả lời được các câu hỏi Who? What? Why?

– Who: As a student

– What: I can see my grades online

– Why: I don’t have to wait until I get to school to know whether I’m passing.

image


1 Comment

Agile #15 – Scrum Process


image

Product Owner tạo ra Product Backlog chứa các yêu cầu của dự án, được sắp theo thứ tự ưu tiên.

Dev Team cùng họp với Product Owner để lập kế hoạch cho từng Sprint. Kết quả của buổI lập kế hoạch (Sprint Planning Meeting) là Sprint Backlog chứa các công việc cần làm trong suốt 1 Sprint.

Trong quá trình phát triển, nhóm sẽ cập nhật Sprint Backlog và họp hàng ngày (Daily Scrum) để chia sẽ tiến độ công việc cũng như các vướng mắt trong quá trình làm việc với nhau.

Nhóm được trao quyền để tự quản lý và tổ chức công việc của mình nhằm hoàn thành trong thời gian 1 Sprint. Khi kết thúc Sprint, dev team phải tạo ra gói phần mềm có chức năng hoàn chỉnh, sẵn sàng chuyển giao cho khách hàng.

Buổi họp sơ kết Sprint (Sprint Review) ở 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 phảI thay đổi hay cải tiến. Sau khi kết thú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 giúp nhóm liên tục học hỏi và trưởng thành qua từng Sprint.

Các Sprint sẽ được lặp đi lặp lại cho đến khi nào các hạng mục trong Product Backlog đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án căn cứ vào tình hình thực tế. Do sử dụng chiến thuật "có giá trị hơn thì làm trước" nên các hạng mục mang nhiều giá trị hơn cho chủ dự án luôn được hoàn thành trước. Do đó Scrum mang lại giá trị cao nhất cho người đầu tư dự án.

Backlog Refinement Meeting (Backlog Grooming)

image

Backlog Refinement Meeting hay còn gọi là Backlog Grooming.

– Thành phần tham dự: Product Owner và scrum dev team

– Khung thời gian: 2 giờ

– Mục tiêu: Giúp Product Owner chọn ra các Product Backlog sẽ được thực hiện trong buổi họp Kế hoạch Sprint tiếp theo (Sprint Planning Meeting)

image

– Xoá bỏ các user story không còn liên quan.

– Tạo mới các user story để phù hợp với nhu cầu mới

– Sắp xếp lại độ ưu tiên của các User Story

– Tính toán, ước lượng độ khó và phân chia Dev cho các User Story mới

– Phân Chia các User Story mà có độ ưu tiên cao nhưng vẫn còn thô(chưa rõ ràng) thành các user story nhỏ hơn.

Ví dụ, một Sprint có thời gian là 2 tuần, đội phát triển nên dành ra khoảng 2 giờ trong khoảng thời gian 2 tuần này cho buổi họp Backlog Refinement.

Các công việc có thể dc làm khi thực hiện Backlog Grooming.

– Xoá bỏ các user story ko còn liên quan.

– Tạo mới các user story để phù hợp với nhu cầu mới

– Sắp xếp lại độ ưu tiên của các User Story

– Tính toán, ước lượng độ khó và phân chia dev cho các user Story mới

– Phân Chia các User story mà có độ ưu tiên cao nhưng vẫn còn thô thành các user story nhỏ hơn.

image

– Không có cam kết nào được tạo ra trong buổi họp Backlog Refinement. Chúng ta sẽ quyết định số lượng công việc phải làm trong 1 Sprint trong buổi họp Sprint Planning Meeting.


1 Comment

Agile #14 – Sprint Retrospective Meeting


image

 

– Dừng và nhìn lại, tìm kiếm các cải tiến và xây dựng tổ chức học tập

– Khung thời gian: 3 giờ

– Thành phần: Scrum Master + Nhóm phát triển

– Product Owner có thể tham dự

– Câu hỏi: Đã làm tốt những gì? Phải cải thiện những gì?

– Scrum Master trợ giúp nhóm tìm hiểu, không đưa ra câu trả lời.


1 Comment

Agile #13 – Sprint Review Meeting


– Nhóm phát triển trình bày những hạng mục đã “hoàn thành” của Product Backlog cho Product Owner và các bên liên quan

– Khung thời gian: 4 giờ

– Thành phần: Nhóm Scrum + các bên liên quan

– Không trình bày những tính năng chưa hoàn thành

– Các phản hồi được đưa ra – Product Backlog có thể được đánh giá lại độ ưu tiên

– Product Owner nên sử dụng kỹ thuật kiểm thử chấp nhận để đánh giá các tính năng

Acceptance Testing: (Kiểm thử chấp nhận)

– Người sử dụng (hoặc khách hàng) chấp nhận kết quả làm việc của Nhóm Phát Triển

– Khách hàng là bên viết các bài test này

– Các test được áp dụng đối với tất cả các logic nghiệp vụ quan trọng

– Có thể tự động hoá được thông qua các hệ thống trợ giúp (Framework for Integrated test, Fitnesse)


1 Comment

Agile #12 – Daily Scrum Meeting


Duy trì mỗi ngày 15p để đồng bộ hóa công việc và lập kế hoạch tức thời.

3 câu hỏi:

-Đã làm được gì kể từ lần họp trước?

-Sẽ làm gì từ giờ cho tới lần họp tiếp theo?

-Có khó khăn gì trong công việc?

Các thành viên trong nhóm sẽ báo cáo cho nhau, KHÔNG báo cáo cho Scrum Master.

Cố định thời gian, địa điểm, nên đứng khi họp.

image

Thanh tra để thích nghi:

-Nhóm có tự quản lý?

-Nhóm có chia sẻ công việc?

-Các báo cáo của nhóm có rõ ràng?

-Các nhiệm vụ quá lớn?

-Nó có lâu quá không?…..Có trở ngại nào ko?

Sau buổi họp Sprint hàng ngày:

-Họp Sprint hàng ngày không giải quyết các vấn đề

-Nó là cơ chế “thanh tra – thích nghi”

+ Phải bám đuổi Scrum hàng ngày để thích nghi

+ Các hành động bám đuổi: họp, huấn luyện, thảo luận, xem xét…

-Scrum Master trợ giúp nhóm tháo gỡ những trở ngại

-Nhóm cập nhật sau họp Scrum hàng ngày:

+ Scrum Backlog với các tác vụ và đánh giá mới

+ Danh mục các vấn đề (Impediment Backlog)

+ Biểu đồ Sprint Burndown


1 Comment

Agile #11 – Sprint Planning Meeting


Nhóm Scrum chọn ra các hạng mục có độ ưu tiên cao nhất từ Product Backlog để làm trong Sprint dựa theo năng lực của nhóm.

image

Sprint Planning Meeting nhằm thiết lập mục tiêu của Sprint. Lựa chọn các việc cho Sprint và làm rõ cách để đạt được chúng.

image


1 Comment

Agile #10 – Meetings


Có 4 loại meetings trong Scrum:

– Sprint Planning Meeting: thiết lập mục tiêu Sprint. Lựa chọn các việc cần làm trong Sprint và làm rõ cách đạt được chúng.

– Daily Scrum Meeting: đồng bộ hóa công việc, cập nhật kế hoạch và công việc.

– Sprint Review Meeting: sớ kết các việc đã hoàn thành trong Sprint. Kiểm tra có đạt được mục tiêu Sprint hay không.

– Sprint Retrospective Meeting: (họp cải tiến Sprint)

image


1 Comment

Agile #9 – Artifacts


Scrum dùng các công cụ đơn giản nhưng hiệu quả để quản lý công việc. Chúng gồm các yêu cầu của Product Owner, được gọi là Product Backlog; bảng kế hoạch của từng Sprint, gọi là Sprint Backlog và biểu đồ Burndown Chart.

image

Product Backlog

Danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án, có thể hiểu như danh sách yêu cầu (requirement) của dự án. Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong Product Backlog dựa trên các giá trị do Product Owner định nghĩa (thường là giá trị thương mạI – business value).

image

Product Backlog có thể không bao giờ hoàn chỉnh, phiên bản sớm của Product Backlog chỉ cho thấy các yêu cầu đã được tìm hiểu rõ ràng từ lúc đầu tiên. Product Backlog sẽ tiến hóa cùng với sản phẩm và môi trường mà nó sẽ được sử dụng. Chừng nào sản phẩm còn đó, thì Product Backlog vẫn hiện diện.

image

Sprint Backlog

Bảng kế hoạch cho 1 Sprint; là kết quả của buổi họp lập kế hoạch (Sprint Planning). Với sự kết hợp của Product Owner, nhóm sẽ 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 (TODO list).

image

Sprint Backlog là các chức năng được chọn từ Product Backlog dựa trên mức độ ưu tiên và khả năng của nhóm phát triển.

Point: dùng đánh giá độ khó, gán điểm cho mỗi user story.

image

Burndown Chart

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 còn lại để hoàn tất công việc. Burndown Chart có thể dùng theo dõI tiến độ của Sprint (gọi là Sprint Burndown Chart) hoặc của cả dự án (Product Burndown Chart). Biểu đồ Burndown không phải là một tiêu chuẩn của Scrum theo định nghĩa mới, nhưng vẫn được dùng rộng rãi do tính hữu ích.