Get Started. It's Free
or sign up with your email address
Rocket clouds
Scrum by Mind Map: Scrum

1. Tổ chức nhóm làm việc

1.1. Các vai trò trong Scrum

1.1.1. Product Owner tối ưu hóa gúa trị của sản phẩm

1.1.1.1. Quản lý Product Backlog, sắp xếp chúng sao cho hợp lý

1.1.1.2. chịu trách nhiệm định hướng sản phẩm

1.1.1.3. Chi tiêt

1.1.1.3.1. Product Owner là ai?

1.1.1.3.2. Product Owner làm gì?

1.1.1.3.3. làm sao để trở thành một Product Owner giỏi?

1.1.2. Nhóm phát triển có nhiệm vụ làm việc và chuyển giao hạng mục trong Product Backlog thành các phần tăng trưởng ở cuối mỗi sprint

1.1.2.1. vai trò của Nhóm Phát triển

1.1.2.1.1. bao gồm các chuyên gia thực hiện nhiệm nhiệm vụ chuyển giao các hạng mục ở cuối mỗi Sprint

1.1.2.1.2. đây là lực lượng duy nhất trực tiếp tham gia tạo ra các phần tăng trưởng này

1.1.2.2. tính tự tổ chức

1.1.2.2.1. nhóm có khả năng và thẩm quyền

1.1.2.2.2. nhóm có toàn quyền lựa chọn

1.1.2.2.3. trong quá trình sản xuất nhóm tự tiến hành

1.1.2.2.4. khi bắt đầu mối Sprint, nhóm tự lựa chọn các hạng mục được sắp xếp ở danh sách Product Backlog sao cho phù hợp khả năng sản xuất của mình

1.1.2.2.5. tự ước lượng các hạng mục của công việc

1.1.2.2.6. tiến độ công việc cũng được nhóm theo dõi

1.1.2.2.7. để xây dựng được 1 nhóm tự quản cần sự tham gia của 3 vài trò

1.1.2.3. tính liên chức năng

1.1.2.3.1. nhóm được trang bị đầy đủ các kĩ năng cần thiết đề hoàn thành công việc ở cuối mỗi sprint mà không cần đến sự hỗ trợ từ bên ngoài

1.1.2.3.2. điều này là quan trọng giúp nhóm có thể hoạt động độc lập, trở thành một đơn vị sản xuất hoàn chỉnh tổ chức vận hành và chuyển giao sản phẩm có chất lượng

1.1.2.3.3. nó giúp nhóm đưa ra các quyết định nhanh chóng, kịp thời mà không phụ thuộc và chờ đợi từ các đơn vị khác từ bên ngoài

1.1.2.3.4. tổ chức liên chức năng là khác biết với tổ chức theo phòng ban

1.1.2.4. độ lớn của nhóm phát triển

1.1.2.4.1. nhóm phát triển được khuyến cáo là có từ 3-9 thành viên

1.1.2.4.2. nhóm có quá nhiều thành viên sẽ làm tăng tính phức tạp trong quản lý, gây khó khăn trong tương tác, giao tiếp, đảm bảo tính minh bạch và làm giảm tính minh bạch của nhóm

1.1.2.5. tính ổn định của nhóm

1.1.2.5.1. nhóm phát triển đòi hỏi tính ổn định cao để đạt được năng suất và chất lượng cao nhất trong sản xuất

1.1.2.5.2. tuy nhiên nhóm phát triển vẫn chấp nhận thay đổi thành viên với hiểu biết rằng nó sẽ ảnh hưởng đến năng suất của nhóm trong ngắn hạn

1.1.2.6. đóng góp của nhóm phát triển trong việc định hình sản phẩm

1.1.2.6.1. sự am hiểu của nhóm phát triển về sản phẩm là cực kỳ quan trọng để đi đến thành công

1.1.3. Scrum Master đảm bảo Scrum hoạt động tốt thông qua việc tuân thủ các nguyên lý, kỹ thuật, quy tắc của Scrum

1.1.3.1. Giúp nhóm giải quyết khó khăn trong quá trình sản xuất, tạo điều kiện cho nhóm làm việc tốt

1.1.3.2. không phải là quản lý của nhóm

1.1.3.3. là một lãnh đạo theo phong cách phục vụ (servant leader). Các đối tượng phục vụ của ScrumMaster gồm

1.1.3.3.1. Product Owner

1.1.3.3.2. Nhóm Phát triển

1.1.3.3.3. Tổ chức

1.1.3.4. Làm thế nào để trở thành một ScrumMaster tốt

1.1.3.4.1. nên làm việc toàn thời gian để tập trung vào

1.1.3.4.2. cần am hiểu sâu sắc về Scrum

1.1.3.4.3. cần có kĩ năng giao tiếp tốt

1.1.3.4.4. ScrumMaster có thể có nền tảng kỹ thuật hoặc không nhưng nếu 1 SM có nền tảng kỹ thuật tốt sẽ có nhiều thuận lợi hơn trong công việc

1.1.3.4.5. nên là người có ảnh hưởng và thuộc cấp quản lý của tổ chức

1.2. Các đặc điểm của nhóm Scrum

1.2.1. cần được trao quyền dưới hình thức tự tổ chức, có toàn quyền lựa chọn và quyết định những gì mình cần làm để đạt kết quả cao nhất mà không phải dựa vào sự chỉ đạo của bất cứ ai bên ngoài nhóm

1.2.2. tính tự tổ chức

1.2.2.1. nhóm Scrum lựa chọn và cam kết phần sản phẩm họ sẽ sản xuất và chuyển giao ở cuối mối sprint

1.2.2.2. từ cam kết đó nhóm sẽ tự phân tích và lên kế hoạch cho chính mình

1.2.2.3. nhóm cũng có quyền quyết định trật tự các hạng mục công việc mà mình sẽ thực hiện

1.2.3. liên chức năng

1.2.3.1. nhóm có đầy đủ các chức năng cần thiết để hoàn thành và chuyển giao các hạng mục mà không cần đến sự trợ giúp từ bên ngoài

1.2.3.2. không phân biệt dựa theo chuyên môn của mình như kiểm thử viên, nhà thiết kế, nhà kiến trúc mà được gọi chung là thành viên nhóm scrum

1.2.3.2.1. trách nhiệm tập thể

2. Tạo sản phẩm chất lượng

2.1. Product Backlog

2.1.1. Product Backlog là gì

2.1.1.1. là nơi lưu trữ các tính năng mong muốn của sản phẩm

2.1.1.1.1. danh sách này được sắp xếp dựa trên độ ưu tiên của từng hạng mục

2.1.1.2. là 1 phần rất quan trọng trong Scrum

2.1.2. Ai quản lý Product Backlog

2.1.2.1. PO là người chịu trách nhiệm quán lý và bảo trì Product Backlog

2.1.2.1.1. Xác định nội dung

2.1.2.1.2. Đánh giá độ ưu tiên

2.1.2.1.3. Sắp xếp các hạng mục

2.1.2.1.4. Làm mịn các hạng mục

2.1.2.1.5. Làm rõ các hạng mục

2.1.2.1.6. Giữ cho các hạng mục luôn được minh bạch

2.1.3. Các hạng mục Product Backlog

2.1.3.1. Chứa

2.1.3.1.1. Các tính năng của sản phẩm

2.1.3.1.2. Lỗi

2.1.3.1.3. Công việc liên quan đến kỹ thuật

2.1.3.1.4. Công việc nghiên cứu

2.1.3.2. Thể hiện hạng mục Product Backlog - User Story

2.1.3.2.1. là tính năng mong muốn đứng ở góc độ của người dùng

2.1.3.2.2. định dạng của user story

2.1.3.3. được sắp xếp dựa theo độ ưu tiên

2.1.3.3.1. do đó nhiệm vụ của PO là đánh giá độ ưu tiên của từng hạng mục

2.1.3.3.2. PO cần xem xét các yêu tố khác nhau để đánh giá độ ưu tiên này

2.1.3.3.3. độ ưu tiên được cập nhật liên tục khi PO có những thông tin mới, hiểu biết nhiều hơn về sản phẩm và có thể có những điều chỉnh về lộ trình của sản phẩm

2.1.3.3.4. PO phân loại thành các hạng mục cần thiết bao gồm

2.1.3.4. mỗi hạng mục Product Backlog cần được ước tính kích thước - lượng nỗ lực cần để triển khai nó

2.1.3.4.1. được thực hiện bởi nhóm phát triển

2.1.3.4.2. các hạng mục Product Backlog có kích thước/mức độ chi tiết khác nhau, chúng cần được làm mịn để đưa vào sản xuất

2.1.4. tiêu chuẩn DEEP cho Project Backlog - tiêu chuẩn để xây dựng 1 Project Backlog tốt

2.1.4.1. Detail Appropriately

2.1.4.1.1. đủ chi tiết hợp lý

2.1.4.1.2. một Product Backlog được coi là đủ chi tiết khi

2.1.4.2. Estimated

2.1.4.2.1. được ước tính

2.1.4.3. Emergent

2.1.4.3.1. tiến hóa

2.1.4.4. Prioritized

2.1.4.4.1. sắp xếp theo độ ưu tiên

2.1.4.4.2. nhằm tối ưu hóa giá trị của công việc phát triển

2.1.5. sự tiến hóa của Project Backlog

2.1.5.1. ban đầu

2.1.5.1.1. Product Backlog còn ở dạng tương đối tổng quát, các hạng mục tương đối lớn, vẫn còn ở dạng thô

2.1.5.2. được làm mịn

2.1.5.2.1. sau đó PB đc làm mịn để bắt đầu phát triển

2.1.5.2.2. việc làm mịn này tập trung vào phía trên của PB vì đây là vùng sẽ được đưa vào phát triển sớm nhất, những phần dự đoán phát triển cũng được làm mịn hơn so với những phần còn lại

2.1.5.3. sẵn sàng

2.1.5.3.1. ở Sprint đầu tiên, các hạng mục của PB ở trạng thái sẵn sàng - tức là các hạng mục trên cùng đã được xác định và làm mịn để sẵn sàng bắt tay vào sản xuất

2.1.5.4. kết thúc Sprint 1

2.1.5.4.1. khi Sprint 1 kết thúc thì PB cũng đc làm mịn để chuẩn bị cho Sprint thứ 2

2.1.5.5. việc cập nhật và làm mịn này được diễn ra liên tục để đảm bảo PB luôn ở trạng thái sẵn sàng, giúp cho hoạt động sản xuất được thông suốt

2.2. Sprint Backlog

2.2.1. Sprint Backlog là gì

2.2.1.1. là bảng công việc được Nhóm Phát triển sử dụng để quản lý quá trình sản xuất trong 1 Sprint

2.2.1.2. nội dung cơ bản của 1 Sprint Backlog bao gồm

2.2.1.2.1. danh sách các hạng mục đã được Product Backlog đã được lựa chọn cho Sprint hiện tại

2.2.1.2.2. danh sách các công việc cần thực hiện trong Sprint để hoàn thành các hạng mục của Product Backlog đó

2.2.2. Ai quản lý Sprint Backlog

2.2.2.1. Sprint Backlog là do Nhóm Phát triển sở hữu và vận hàng

2.2.2.1.1. bởi vì quá trình làm việc trong 1 Sprint cũng do Nhóm Phát triển tự quản lý

2.2.2.1.2. Nhóm Phát triển tạo ra Sprint Backlog trong buổi lập kế hoạch Sprint

2.2.3. Cấu trúc cơ bản của Sprint Backlog

2.2.3.1. các trình bày dưới dạng 1 bảng truyền thống - có thể sử dụng bảng tính truyền thống

2.2.3.1.1. cột 1 - Hạng mục Product Backlog

2.2.3.1.2. cột 2 - Công việc

2.2.3.1.3. cột 3 - Người thực hiện

2.2.3.1.4. cột 4 - Tổng khối công việc để hoàn thành hạng mục

2.2.3.1.5. các cột tiếp theo đánh số điểm hoàn thành của hạng mục

2.2.3.2. bảng Kanban được sử dụng nhiều vì tính đơn giản và hiệu quả

2.2.3.2.1. cột 1 - chứa các hạng mục Product Backlog

2.2.3.2.2. cột 2 - chứa các công việc tương ứng với từng hạng mục của Product Backlog

2.2.3.2.3. cột 3 - chứa các công việc đang được triển khai

2.2.3.2.4. cột 4 - chứa các công việc đã hoàn thành

2.2.4. Công cụ quản lý Backlog

2.2.4.1. đối với nhóm làm cùng nhau thì nên sử dụng bảng vật lý

2.2.4.1.1. tăng tính trực quan

2.2.4.1.2. sẵn sàng cho tất cả các thành viên cập nhật bất cứ lúc nào

2.2.4.2. nhóm có thể sử dụng các công cụ trực tuyến khác như

2.2.4.2.1. JIRA

2.2.4.2.2. ASSEMBLA

2.2.4.2.3. PIVOTAL TRACKER

2.2.4.2.4. BACKLOG

2.3. Khái niệm phần tăng trưởng của sản phẩm

2.3.1. Phần tăng trưởng là gì?

2.3.1.1. là tên gọi ngắn của phần tăng trưởng có khả năng chuyển giao được

2.3.1.2. là phần sản phẩm Nhà Phát triển tạo ra cuối mỗi Sprint

2.3.1.3. đây là 1 định nghĩa khiến cho Agile khác hoàn toàn so với quy trình phát triển phần mềm truyền thống

2.3.1.3.1. phát triển truyền thống

2.3.1.3.2. phần tăng trưởng sau mỗi Sprint trong Scrum

2.3.2. Các đặc điểm của Phần tăng trưởng

2.3.2.1. sử dụng được

2.3.2.1.1. ví dụ

2.3.2.2. có khả năng chuyển giao được

2.3.2.2.1. tức là đạt tới trạng thái sẵn sàng để chuyển giao

2.3.2.2.2. vì trong thực tế việc chuyên giao ngay ko phải lúc nào cũng thực hiện được

2.3.2.2.3. quyết định phát hành sản phẩm quyết định dựa vào nhiều yếu tố khác

2.3.2.3. phần tăng trưởng phải tuân theo định nghĩa hoàn thành đã được Nhóm phát triển và PO thống nhất trước đó

2.3.2.3.1. ví dụ

2.3.3. Tại sao bạn cần phần tăng trưởng

2.3.3.1. SỚm có được phản hồi từ người dùng/khách hàng

2.3.3.1.1. các phản hồi sẽ được ghi nhận, điều chỉnh lại sản phẩm nếu cần thiết

2.3.3.2. sớm thu được giá trị từ sản phẩm

2.3.3.3. gia tăng tính minh bạch trong quá trình sản xuất

2.3.3.3.1. sau 1 khoảng thời gian sản xuất chúng ta đã tạo ra 1 sản phẩm thực chứ không phải là các bản mẫu, báo cáo, thiết kế tiềm ẩn nhiều rủi ro

2.3.3.4. giúp giảm thiểu rủi ro

2.3.3.4.1. kinh doanh

2.3.3.4.2. kỹ thuật

2.3.4. Làm sao để có được phần tăng trưởng

2.3.4.1. nhóm phát triển có đảm bảo tính liên chức năng để hoàn thành các công việc theo định nghĩa hoàn thành hay không

2.3.4.1.1. ví dụ

2.3.4.2. Product backlog có được xây dựng hợp lý để hỗ trợ việc phát triển tăng dần hay không

2.3.4.2.1. đây là thách thức của PO và nhóm Phát triển trong việc...

2.3.4.3. Nhóm phát triển cần biết cách lập kế hoạch Sprint tốt nhằm thuận lợi trong việc tạo ra phần tăng trưởng

2.3.4.3.1. đây là nhiệm vụ quan trọng của Nhóm Phát triển vì chỉ có họ mới là người phụ hợp để lựa chọn các hạng mục trong Product Backlog đưa vào trong Sprint

2.3.4.3.2. số lượng hạng mục được lựa chọn cần phù hợp với khả năng của nhóm để nhóm có thể hoàn thành hết mọi công việc trong Sprint

2.3.4.3.3. các hạng mục được lựa chọn trong Sprint cần có sự độc lập tương đối với các hạng mục khác

2.3.4.4. Nhóm phát triển có vận hành tốt để đạt được mục tiêu chung hay không?

2.3.4.4.1. bao gồm

2.3.4.5. công cụ hỗ trợ có tốt không

2.3.4.5.1. quản lý mã nguồn

2.3.4.5.2. kiểm thử tự động

2.3.4.5.3. tích hợp liên tục

2.3.4.6. khung thời gian của Sprint có đủ dài không?

2.3.4.6.1. đối với nhóm lập trình mới chưa có kinh nghiệm

2.3.4.6.2. nhóm đã đạt được trạng thái vận hàng hiệu quả

2.4. Định nghĩa hoàn thành

2.4.1. định nghĩa hoàn thành là gì

2.4.1.1. là một danh sách quy định những công việc thực hiện xong trước khi một hạng mục được công nhận là đạt trạng thái có khả năng chuyển giao được

2.4.1.1.1. ví dụ

2.4.2. tại sao chúng ta cần định nghĩa hoàn thành

2.4.2.1. đảm bảo một cách hiểu chung, gia tăng tính minh bạch trong phát triển

2.4.2.1.1. ví dụ

2.4.2.2. ngăn ngừa 1 số mâu thuẫn xảy ra trong giao tiếp khi đề cập đến trạng thái hoàn thành của các hạng mục

2.4.2.3. nâng cao chất lượng sản phẩm

2.4.3. xậy dựng định nghĩa hoàn thành phụ thuộc vào

2.4.3.1. đặc điểm của sản phẩm

2.4.3.1.1. ví dụ

2.4.3.2. công nghệ và kỹ thuật đang được sử dụng

2.4.3.2.1. nếu là ứng dụng web thì sẽ có các quy định liên quan về việc hỗ trợ tốt với các trình duyệt khác nhau

2.4.3.3. các quy định của tổ chức

2.4.3.4. trình độ Nhóm phát triển

2.4.3.4.1. trình độ cao

2.4.4. định nghĩa hoàn thành cho những cấp độ khác nhau

2.4.4.1. cơ bản

2.4.4.1.1. mã nguồn đã được kiểm tra chéo

2.4.4.1.2. đã có kiểm thử đơn vị

2.4.4.1.3. có chú thích đầy đủ

2.4.4.1.4. không có lỗi được phát hiện

2.4.4.1.5. mã nguồn đã được đẩy lên hệ thống lưu trữ

2.4.4.2. nâng cao

2.4.4.2.1. đã có kiểm thử tích hợp

2.4.4.2.2. đã có kiểm thử chấp nhận

2.4.4.2.3. mã nguồn đã được tái cấu trúc

2.4.4.2.4. mã nguồn đã được kiểm tra chéo

2.4.4.2.5. đã có kiểm tra đơn vị với độ phủ 100%

2.4.4.2.6. có chú thích đầy đủ tuân theo quy ước của công ty

2.4.4.2.7. không có lỗi được phát hiện

2.4.4.2.8. mã nguồn đã được đẩy lên hệ thống lưu trữ

2.4.4.2.9. đã có tài liệu sử dụng

2.4.4.2.10. đã đẩy lên máy chủ thử nghiệm

2.4.4.3. user story - định nghĩa sẵn sàng

2.4.4.3.1. User story đã được ước tính

2.4.4.3.2. có danh sách tiêu chí chấp nhận

2.4.4.3.3. user story là duy nhất

2.4.4.3.4. có đính kèm tài liệu phù hợp

2.4.4.3.5. giá trị ước tính ban đầu không nhiều hơn 5 điểm

2.4.4.4. công việc trong Sprint

2.4.4.4.1. mã nguồn đã được kiểm tra chéo

2.4.4.4.2. mã nguồn đã có đầy đủ chú thích

2.4.4.4.3. mã nguồn đã được đưa lên hệ thống lưu trữ

2.4.4.4.4. đã cập nhật thời gian của công việc trên Sprint Backlog về 0

2.4.4.5. phiên bản phát hành

2.4.4.5.1. tất cả mã nguồn đều đã được triển khai trên máy chủ thực tế

2.4.4.5.2. sản phẩm được dùng thử bởi 10 người ngoài Nhóm phát triển trong 5 ngày

2.4.4.5.3. không có lỗi được phát hiện

2.4.4.5.4. nhóm chăm sóc khách hàng đã được huấn luyện về các tính năng mới

2.4.5. định nghĩa hoàn thành và tiêu chí chấp nhận

2.4.5.1. định nghĩa hoàn thành

2.4.5.1.1. được áp dụng cho tất cả user story

2.4.5.2. tiêu chí chấp nhận

2.4.5.2.1. được áp dụng cho 1 hoặc 1 vài user story nhất định

2.4.5.3. một hạng mục chỉ được công nhận là hoàn thành khi nó đáp ứng các định nghĩa hoàn thành chung và tiêu chí chấp nhận riêng cho từng hạng mục đó

2.4.5.4. ví dụ

2.4.5.4.1. là khách hàng tôi muốn thanh toán bằng thẻ tín dụng

3. Vận hành quy trình hoạt động hiệu quả và chất lượng

3.1. Lập kế hoạch Sprint

3.1.1. Các sự kiện trong Scrum

3.1.1.1. Toàn bộ khoảng thời gian của Scrum sẽ diễn ra trong 1 Sprint, mỗi Sprint này sẽ diễn ra trong 1 tháng hoặc ít hơn, một Sprint mới bắt đầu ngay sau khi 1 Sprint trước khép lại

3.1.1.2. Mỗi Sprint có thể coi là 1 tiểu dự án trong đó diễn ra các hoạt động như

3.1.1.2.1. các hoạt động gồm

3.1.1.2.2. sản phẩm của tiểu dự án là 1 phần tăng trưởng bàn giao được của sản phẩm

3.1.2. Lập kế hoạch Sprint

3.1.2.1. Xác định mục tiêu Sprint

3.1.2.2. Lên kế hoạch cần thực hiện trong Sprint

3.1.2.2.1. gồm 2 phần

3.1.2.3. trả lời các câu hỏi

3.1.2.3.1. mục tiêu của Sprint này là gì

3.1.2.3.2. Sprint này phải chuyển giao cái gì

3.1.2.3.3. làm sao để đạt được điều đó

3.1.2.4. độ dài của buổi lập Sprint

3.1.2.4.1. kéo dài 8h đối với Sprint 1 tháng

3.1.2.4.2. 4h đối với Sprint kéo dài 2 tuần

3.1.2.4.3. thời gian dành cho 2 phần này kéo dài bằng nhau

3.1.3. Phần 1: Chúng ta sẽ làm gì trong Sprint này?

3.1.3.1. toàn bộ thành viên Scrum phải tham gia phần đầu của sự kiện

3.1.3.2. kết quả của phần này là mục tiêu Sprint với các hạng mục trong Product Backlog để phát triển trong Sprint

3.1.3.3. quá trình

3.1.3.3.1. PO trình bày mục tiêu mong muốn đạt được trong Sprint này

3.1.3.3.2. PO làm rõ thêm các hạng mục ở phần trên của Product Backlog, đã được sắp xếp để cả nhóm có thể kiểu rõ hơn về các hạng mục này

3.1.3.3.3. sau đó cả nhóm sẽ hợp tác để tìm hiểu công việc phải làm trong Sprint

3.1.3.3.4. Nhóm phát triển lựa chọn hạng mục họ tin là có thể hoàn thành trong Sprint này, bắt đầu từ những hạng mục đứng đầu trong Product Backlog

3.1.3.3.5. Kết thúc phần này Nhóm phát triển và PO thống nhất lại mục tiêu Sprint và danh sách các hạng mục sẽ được chuyển giao trong Sprint

3.1.4. Phần 2: Chúng ta sẽ làm như thế nào?

3.1.4.1. PO có thể vắng mặt nhưng phải luôn sẵn sàng hỗ trợ nhóm phát triển để làm rõ các hạng mục khi cần thiết

3.1.4.2. kết quả của phần này là Sprint Backlog - tức là bảng công việc được Nhóm phát triển sử dụng trong suốt Sprint

3.1.4.2.1. các hạng mục Product Backlog đã được lựa chọn

3.1.4.2.2. nhóm phát triển bắt đầu thiết kế hệ thống và lên danh sách các công việc cần làm

3.1.4.2.3. đối với mỗi hạng mục trong danh sách lựa chọn nhóm sẽ tách thành các công việc cụ thể

3.1.4.3. nhóm phát triển ước tính nỗ lực cho từng công việc một

3.1.4.3.1. việc tính nỗ lực là cần thiết để nhóm biết được tổng nỗ lực cần làm trong Sprint

3.1.4.3.2. đồng thời nhóm sẽ sử dụng ước tính này để theo dõi tiến độ Sprint

3.1.4.3.3. nếu 1 công việc được ước tính là hơn 1 ngày thì cần tách ra thành công việc nhỏ hơn

3.1.4.3.4. cách ước tính

3.1.4.4. nếu nhóm phát triển thấy lượng công việc quá nhiều hoặc quá ít có thể thương lượng với PO để thêm hoặc bớt công việc

3.1.4.5. Nhóm phát triển cũng có thể nhờ thêm trợ giúp kĩ thuật từ ngoài để phục vụ cho việc sản xuất

3.1.5. Bắt đầu sản xuất

3.1.5.1. diễn ra với hình thức tự tổ chức

3.1.5.1.1. các thành viên tự trao đổi với nhau để lựa chọn công việc mà mình sẽ thực hiện

3.1.5.1.2. mỗi người không nên lựa chọn trước nhiều công việc mà mình sẽ thực hiện trước mà chỉ lựa chọn 1 công việc

3.1.5.1.3. trong suốt Sprint, Scrum không cho phép sự thay đổi nào ảnh hưởng tới Sprint, nhóm phát triển sẽ không chấp nhận làm thêm các công việc nào khác ngoại trừ các công việc đã lựa chọn khi lập các kế hoạch Sprint kể cả các công việc đó xuất phát từ lãnh đạo

3.2. Ước tính

3.2.1. Ước tính là gì

3.2.1.1. là việc dự đoán độ lớn của 1 hạng mục sẽ được phát triển

3.2.2. Tại sao cần phải ước tính

3.2.2.1. để lập kế hoạch sản xuất một cách hiệu quả

3.2.2.2. trả lời cho câu hỏi

3.2.2.2.1. thời gian?

3.2.2.2.2. người?

3.2.2.2.3. tính năng?

3.2.2.2.4. hiệu quả?

3.2.2.2.5. quản lý

3.2.3. Ai thực hiện việc ước tính

3.2.3.1. được ước tính bởi nhóm phát triển

3.2.3.2. tăng tính chính xác của ước tính

3.2.3.2.1. dữ liệu từ quá khứ

3.2.3.2.2. hiểu biết hiện tại về tình hình sản xuất

3.2.3.2.3. một số giả định

3.2.3.2.4. các rủi ro có thể tính được

3.2.3.3. một vài cách thức ước tính

3.2.3.3.1. dựa vào ý kiến của chuyên gia

3.2.3.3.2. dựa vào mối tương quan giữa các hạng mục - so sánh các hạng mục đã được ước tính

3.2.3.3.3. phân tách các hạng mục thành hạng mục nhỏ hơn để gia tăng tính chính xác

3.2.4. Các đơn vị được sử dụng trong ước tính

3.2.4.1. số lượng dòng mã

3.2.4.2. số điểm chức năng

3.2.4.3. số điểm tương đối

3.2.4.3.1. thường được gọi là point, nhằm để định lượng độ lớn tương đối giữa các hạng mục

3.2.4.3.2. dễ dàng đo đạc

3.2.4.3.3. cần tìm được điểm cơ sở, lấy đó làm quy chuẩn để từ sau đó tiến hành đo đạc

3.2.4.4. thời gian lý tưởng

3.2.4.4.1. lấy thời gian cần thiết để triển khai hạng mục đó

3.2.4.4.2. là thời gian lý tưởng để triển khai, trên thực tế thì chúng ta thường không đạt được

3.2.5. Ước tính các hạng mục Product Backlog

3.2.5.1. thời điểm

3.2.5.1.1. thời điểm ban đầu khi phát triển sản phâm

3.2.5.1.2. thời gian tiếp theo khi triển khai sản phẩm, một số sản phẩm được thay đổi, làm mịn, bỏ đi

3.2.5.2. ước tính lại

3.2.5.2.1. khi Nhóm phát triển nhận thấy ước tính của 1 hạng mục không còn được phù hợp, họ có thể ước tính lại

3.2.6. Ước tính các hạng mục công việc trong Sprint

3.2.6.1. có thể kết hợp ước tính bằng điểm tương đối và thời gian lý tưởng

3.3. Planning Poker

3.3.1. Planning Poker là gì

3.3.1.1. là một kỹ thuật hiệu quả và phổ biến, được sử dụng để ước tính

3.3.1.2. dựa trên cả 3 cách

3.3.1.2.1. dựa trên ý kiến chuyên gia

3.3.1.2.2. so sánh các hạng mục

3.3.1.2.3. phân tách các hạng mục

3.3.1.3. việc sử dụng Planning Poker khá nhanh chóng và đem lại kết quả khá tin cậy

3.3.2. Cách tiến hành Planning Poker

3.3.2.1. chuẩn bị các bộ bài Planning Poker dành cho các thành viên

3.3.2.2. tất cả các thành viên đều tham gia buổi ước tính sử Planning Poker, các thành viên có các kỹ năng khác nhau

3.3.2.3. PO tham gia phiên ước tính nhằm làm rõ các hạng mục chứ không trực tiếp tham gia vào việc ước tính

3.3.2.4. Ước tính

3.3.2.4.1. các thành viên ước tính các hạng mục từ trên xuống

3.3.2.4.2. nêu đây là lần đầu tiên ước tính, nhóm cần chọn 1 hạng mục làm cơ sở - hạng mục nhỏ nhất, gán cho nó là 1 và sau đó dùng nó để so sánh với các hạng mục khác

3.3.2.4.3. các thành viên cùng lựa chọn 1 quân bài chứa con số

3.3.2.4.4. mỗi hạng mục nên giới hạn thời gian ví dụ là 3 phút

3.3.3. Chia thành nhiều nhóm ước tính

3.3.3.1. khi có quá nhiều hạng mục cần ước tính thì nên chia nhóm thành các nhóm nhỏ để cùng ước tính

3.3.3.2. số lượng của mỗi nhóm nhỏ là phải có từ 3 thành viên trở lên

3.3.3.3. ban đầu các nhóm nhỏ cần ước tính cùng với nhau để hiểu được độ lớn của Point cơ sở

3.3.3.4. các điểm số ở các team có giá trị như nhau

3.3.4. Planning Poker cho nhóm phân tán

3.3.4.1. sử dụng 1 công cụ Planning Poker trực tuyến để sử dụng

3.4. Scrum hằng ngày

3.4.1. Mục đích của Scrum hằng ngày

3.4.1.1. đây là buổi trao đổi ngắn ko quá 15 phút

3.4.1.2. mục đích giúp nhóm phát triển

3.4.1.2.1. đồng bộ công việc

3.4.1.2.2. tái lập kế hoạch

3.4.1.3. để tránh cho việc phức tạp cần diễn ra tại 1 địa điểm cùng 1 khung thời gian

3.4.1.3.1. đầu giờ buổi sáng

3.4.1.3.2. đầu giờ buổi chiều

3.4.2. Những ai tham gia?

3.4.2.1. danh cho nhóm phát triển

3.4.2.2. SM tham dự chỉ để đảm bảo nhóm thực hiện đúng công việc này

3.4.2.3. PO và lãnh đạo có thể tham dự nhưng chỉ được lắng và không đóng bất cứ vai trò nào

3.4.3. 3 câu hỏi cần trả lời

3.4.3.1. tôi đã làm được gì

3.4.3.2. tôi sẽ làm gì

3.4.3.3. tôi gặp khó khăn gì

3.4.4. những vấn đề cần tránh

3.4.4.1. tránh lan man

3.4.4.1.1. không thảo luận sâu

3.4.4.2. scrum hằng ngày thành buổi báo cáo lãnh đạo

3.4.4.2.1. scrum cần thể hiện vai trò bảo vệ nhóm của mình bằng cách ko cho phép lãnh đạo hay PO tham gia vào scrum hằng ngày để các thành viên nhóm phát triển cảm thấy tự do hơn, không bị áp lực công việc

3.4.4.3. scrum hằng ngày thành buổi báo cáo với Scrum Master

3.4.4.3.1. Scrum Master không nên nhìn trực tiếp vào mắt người báo cáo, người báo cáo nên nhìn các thành viên khác của nhóm

3.4.4.4. Scrum hằng ngày trở thành 1 phiên thảo luận để giải quyết các vấn đề

3.4.4.4.1. thường đi vào chi tiết các vấn đề kĩ thuật dẫn tới thiếu thời gian

3.4.4.4.2. SM cần dừng cuộc thảo luận lại để các thành viên khác tiếp tục cuộc họp và chuyển cuộc thảo luận vào ngay sau đó

3.4.4.5. Scrum hằng ngày diễn ra quá xa nơi làm việc điều này khiến mất thời gian và gây khó khăn cho việc tổ chức Scrum hằng ngày

3.4.4.5.1. Scrum Master nên sắp xếp hỗ trợ team có không gian họp Scrum hằng ngày ngay tại vị trí làm việc của nhóm tốt nhất là nên ở cạnh bảng công việc của nhóm để tiện cho việc cập nhật tiến độ công việc

3.4.4.6. Nhóm phát triển không thấy giá trị của Scrum hằng ngày

3.4.4.6.1. sau Scrum hằng ngày các thành viên không nắm được thêm thông tin về công việc của các thành viên khác cũng như nhắc nhở

3.4.4.7. các thành viên thường báo cáo là không gặp vấn đề gì kể cả có các dấu hiếu không ổn trong sản xuất

3.4.4.7.1. đây có thể là do các thành viên chưa biết cách nhận diện khó khăn cốt lõi của chúng

3.4.4.7.2. SM có thể dạy cho nhóm cách xác định vấn đề và truy tìm nguồn gốc của chúng

3.4.5. hoạt động scrum hằng ngày để

3.4.5.1. cập nhật tiến độ

3.4.5.2. thanh tra

3.4.5.3. thích nghi

3.4.6. nhiệm vụ của SM trong Scrum hằng ngày

3.4.6.1. đảm bảo thuận lợi nhất cho nhóm tiến hành sự kiện

3.4.6.1.1. địa điểm

3.4.6.1.2. thời gian cố định

3.4.6.1.3. ghi nhận trở ngại

3.4.6.1.4. đảm bảo các thành viên tập trung vào công việc thay vì sa đà vào các vấn đề khác

3.5. Sơ kết Sprint

3.5.1. Mục đích

3.5.1.1. đây là 1 hoạt động thanh tra và thích nghi sản phẩm

3.5.1.2. kết thúc buổi sơ kết Sprint thì lộ trình Product Backlog có thể được điều chỉnh để phù hợp hơn với tình hình phát triển mới

3.5.2. thành phần tham dự

3.5.2.1. Nhóm phát triển

3.5.2.2. Product Owner

3.5.2.2.1. có thể mời thêm

3.5.2.3. Scrum Master

3.5.3. thời gian

3.5.3.1. thời gian tối đa được đóng khung trong 1h tương ứng với 1 tuần làm việc của Sprint

3.5.4. kiểm tra kết quả Sprint

3.5.4.1. nhóm phát triển và PO trao đổi và nắm tình hình của nhau

3.5.4.1.1. Nhóm phát triển cap nhật nhu cầu của thị trường

3.5.4.1.2. PO cập nhật tiến độ của sản phẩm

3.5.4.2. bắt đầu PO trình bày tổng quan về các hạng mục trong Product backlog được lựa chọn đã hoàn thành và các hạng mục chưa được hoàn thành

3.5.4.3. nhóm phát triển trình bày

3.5.4.3.1. kết quả mà nhóm đã đạt được

3.5.4.3.2. khó khăn mà nhóm đã gặp phải

3.5.4.3.3. giải pháp mà nhóm đã đưa ra

3.5.5. trực tiếp sử dụng sản phẩm

3.5.5.1. đây là cơ hội để người tham gia trực tiếp thanh tra kết quả của Sprint

3.5.5.1.1. từ đó đưa ra các khuyến nghị và đóng góp cho các phát triển tiếp theo của sản phẩm

3.5.5.2. rà soát Product Backlog và thị trường xác định các thay đổi có thể có

3.5.5.2.1. từ đó rút ra những thứ giá trị nhất có thể làm vào thời gian tới

3.5.5.3. kết quả của quá trình ra soát là đưa ra Product Backlog mới đã được sắp xếp phù hợp với các Sprint tiếp theo

3.5.5.4. nếu có những thay đổi lớn ảnh hưởng tiến độ của sản phẩm cần cập nhật lại tiến độ phát hành của sản phẩm

3.5.6. hiểu lầm nên tránh

3.5.6.1. đây là buổi demo sản phẩm, thực ra đây chỉ là 1 hạng mục trong buổi sơ kết Sprint

3.5.6.2. nếu chỉ tập trung vào demo sản phẩm sẽ bỏ qua 1 hoạt động quan trọng khác là THẢO LUẬN giữa các thành viên tham gia

3.5.6.2.1. như vậy Sơ kết Sprint sẽ mất đi ý nghĩa là THANH TRA và THÍCH NGHI mà scrum đang xây dựng

3.5.7. điều chỉnh sản phẩm

3.6. Cải tiến Sprint

3.6.1. Mục đích của buổi Cải tiến Sprint

3.6.1.1. là buổi diễn ra vào cuối sprint, ngay sau buổi sơ kết Sprint

3.6.1.2. mục đích là thanh tra và thích nghi qui trình làm việc

3.6.1.2.1. tìm ra cách làm tốt hơn trong Sprint tới

3.6.2. Thành phần tham dự

3.6.2.1. Nhóm Phát triển

3.6.2.2. Scrum Master

3.6.2.3. Không bắt buộc

3.6.2.3.1. Product Owner

3.6.3. Thời gian

3.6.3.1. Sprint 1 tháng: 3 giờ

3.6.3.2. Sprint 2 tuần: 1h 30 phút

3.6.3.3. 45p cho 1 tuần

3.6.4. Nội dung của buổi Cải tiến Sprint

3.6.4.1. ScrumMaster(hoặc người khác bên ngoài nhóm) hỗ trợ buổi cải tiến

3.6.4.1.1. trao đổi chéo ScrumMaster giữa các team

3.6.4.2. liệt kê những điểm đã làm tốt

3.6.4.2.1. ví dụ

3.6.4.3. liệt kê những điểm đã làm chưa tốt

3.6.4.3.1. ví dụ

3.6.4.4. đưa ra các hành động để cải tiến

3.6.4.4.1. ví dụ

3.6.4.4.2. nên đưa 3-5 hạng mục vào cải tiến mà thôi nhằm giúp tập trung hơn trong cải tiến

3.6.4.4.3. không nên đưa vào quá nhiều hành động cải tiển, điều này sẽ không gây hiệu quả

3.6.4.5. nên tránh cách làm không tốt

3.6.4.5.1. chỉ tập trung cách làm không tốt, không quan tâm đến các vấn đề đã làm tốt

3.6.4.6. một số kỹ thuật cải tiến Sprint

3.6.4.6.1. Glad - Sad - Mad

3.6.4.6.2. SpeedBoat

3.6.4.6.3. Tail board

3.6.4.6.4. tham khảo thêm

3.6.5. Kỹ thuật Glad, Sad, Mad

3.7. Làm mịn Product Backlog

3.7.1. Mục đích của hoạt động làm mịn Product Backlog

3.7.1.1. mục đích phân tách các hạng mục lớn thành hạng mục nhỏ hơn

3.7.1.2. phân tích tìm hiểu các hạng mục

3.7.1.3. tái ước lượng kích thước

3.7.1.4. tái đánh giá độ ưu tiên của các hạng mục nhằm chuẩn bị sẵn sàng đưa vào sản xuất trong các Sprint sắp tới

3.7.2. Ai thực hiện?

3.7.2.1. diễn ra với sự cộng tác của nhiều bên bao gồm

3.7.2.1.1. Product Owner

3.7.2.1.2. Nhóm phát triển

3.7.2.1.3. ScrumMaster

3.7.2.1.4. Người dùng

3.7.2.1.5. Khách hàng

3.7.2.1.6. các bên liên quan khác

3.7.3. Thời gian

3.7.3.1. hoạt động này được Product Owner liên tục cập nhật với các bên liên quan

3.7.3.2. đối với Nhóm Phát triển tổng thời gian dành cho hoạt động này không nên vượt quá 10% 1 Sprint

3.7.3.2.1. ví dụ với Sprint 2 tuần, tổng thời gian làm mịn sẽ không vượt quá 1 ngày

3.7.4. Làm mịn Product Backlog như thế nào?

3.7.4.1. chia nhỏ, phân tách các hạng mục Product Backlog

3.7.4.1.1. nội dung của các hạng mục sẽ nhỏ hơn, rõ ràng hơn và không gây hiểu lầm quá lớn

3.7.4.1.2. giúp ước tính kích thước và đánh giá độ ưu tiên trở nên chính xác hơn

3.7.4.1.3. giúp các hạng mục đủ nhỏ để hoàn thành trong 1 Sprint, nếu hạng mục quá lớn chúng ta sẽ khó hoàn thành trong 1 Sprint và sẽ khó tạo ra phần tăng trưởng có thể chuyển giao được trong 1 Sprint

3.7.4.1.4. nên chia nhỏ hạng mục có thời gian ít hơn 1/4 tổng thời gian của Sprint

3.7.4.2. thêm các chi tiết cần thiết cho từng hạng mục (xác định tiêu chí chấp nhận)

3.7.4.2.1. các chi tiết chấp nhận nên dừng lại ở 1 mức độ tương đối, thể hiện được ý muốn của người dùng, không nên mất quá nhiều thời gian để liệt kê từng chi tiết nhỏ của từng sản phẩm

3.7.4.3. ước tính độ lớn của các hạng mục

3.7.4.3.1. ước tính các hạng mục mới

3.7.4.3.2. ước tính các hạng mục có độ lớn không còn phù hợp

3.7.4.3.3. sử dụng phương pháp ước lượng Planning Poker

3.7.4.3.4. Product Owner cần đánh giá độ ưu tiên của các hạng mục và tiến hành sắp xếp lại Product Backlog nhằm đảm bảo các hạng mục có độ ưu tiên cao nhất sẽ được đưa vào sản xuất sớm nhất

3.7.5. Tổ chức buổi làm mịn Product Backlog

3.7.5.1. thường tổ chức vào giữa hoặc cuối Sprint hiện tại để chuẩn bị cho Sprint tiếp theo

3.7.5.2. do nhóm Phát triển tổ chức

3.7.5.2.1. có sự tham gia của Product Owner

3.7.5.2.2. nếu cần thiết nhóm Phát triển có thể mời thêm Khách hàng, người dùng hoặc các bên liên quan

3.7.5.3. cách đánh giá buổi làm mịn Product Backlog có hoạt động tốt hay không?

3.7.5.3.1. quan sát buổi lập Sprint

3.7.5.3.2. hoạt động không tốt

3.7.5.3.3. hoạt động tốt

3.7.6. Sự tiến hóa của Product Backlog

3.7.6.1. thời điểm ban đầu

3.7.6.1.1. Product Backlog còn ở dạng thô, các hạng mục còn tương đối lớn

3.7.6.2. sau đó

3.7.6.2.1. Product Backlog sẽ được làm mịn ở phía trên

3.7.6.3. khi sprint 1 kết thúc, các hạng mục cho Sprint thứ 2 đã được làm mịn, sẵn sàng cho việc đưa vào xây dựng sản xuất

3.7.6.3.1. việc cập nhật và làm mịn diễn ra liên tục để đảm bảo Product Backlog luôn ở trạng thái sẵn sàng để hoạt động sản xuất được thông suốt

3.8. Theo doi tiến độ sản phẩm

3.8.1. Tại sao cần theo dõi tiến độ Sản phẩm

3.8.1.1. tiến độ sản phẩm như thế nào luôn là câu hỏi mà các bên liên quan quan tâm

3.8.1.1.1. tình hình phát triển sản phẩm như thế nào

3.8.1.1.2. chúng ta cần đầu tư thêm bao nhiêu nỗ lực

3.8.1.1.3. đến bao giờ chúng ta có thể phát hành

3.8.1.1.4. liệu 2 tháng nữa phát hành thì có được không

3.8.1.2. nắm được tiến độ sản phẩm sẽ đưa ra các điều chỉnh hợp lý liên quan đến lộ trình phát triển của sản phẩm

3.8.2. Ai theo dõi tiến độ sản phẩm

3.8.2.1. Product Owner là người chịu trách nhiệm chính trong việc theo dõi tiến độ sản phẩm và hải đảm bảo tiến độ sản phẩm phải minh bạch với tất cả các bên liên quan

3.8.2.2. khi bắt đầu xây dựng 1 sản phẩm chúng ta xây dựng Kế hoạch phát hành cho sản phẩm dựa vào các hạng mục yêu cầu của khách hàng

3.8.2.2.1. ví dụ

3.8.2.2.2. việc thay đổi Kế hoạch phát hành ban đầu dựa vào

3.8.2.2.3. theo thời gian nhóm am hiểu hơn về sản phẩm, có nhiều thông tin hơn về việc phát triển do đó việc phát hành cũng được điều chỉnh để phù hợp hơn với tình hình mới

3.8.2.3. để theo dõi tiến độ sản phẩm hướng đến mục tiêu, các nhóm thường sử dụng 1 chỉ số quan trọng là lượng nỗ lực còn lại để hoàn thành bản phát hành

3.8.2.3.1. được ước tính bằng việc cộng tất cả các ước tính của hạng mục chưa được phát triển

3.8.2.3.2. giá trị này được thể hiện bằng

3.8.3. Sử dụng BIểu đồ Phát hành Burndown

3.8.3.1. trục ngang

3.8.3.1.1. biểu thị cho các Sprint

3.8.3.2. trục dọc

3.8.3.2.1. biểu thị cho lượng nỗ lực còn lại cho các mục tiêu

3.8.3.3. ví dụ

3.8.3.3.1. tổng lượng nỗ lực là 90 điểm

3.8.3.3.2. sau khi kết thúc Sprint đầu tiên lượng nỗ lực còn lại 77 điểm, điểm này được nối với điểm ban đầu

3.8.3.3.3. sau khi kết thúc Sprint thứ 2 lượng nỗ lực còn lại là 62 điểm, đường biểu đồ lại được kéo dài ra

3.8.3.4. chúng ta có thể vẽ đường biểu đồ lý tưởng trong biểu đồ Burndown

3.8.3.4.1. ví dụ

3.8.3.4.2. trên thực tế thì đường biểu đồ sẽ không được lý tưởng như vậy, chúng ta có thể ước lượng được sự chênh lệch ngày phát hành thực tế

3.8.3.5. các công cụ sử dụng biểu đồ Burndown

3.8.3.5.1. JIRA

3.8.3.5.2. Excel

3.8.3.5.3. PO có thể tự thiết hành biểu đồ Burndown vật lý

3.9. Theo dõi tiến độ Sprint

3.9.1. Tại sao phải theo dõi tiến độ Sprint

3.9.1.1. Scrum hoạt động dựa trên tính thực nghiệm, tất cả các hoạt động của Scrum dựa vào 3 trụ cột là minh bạch, thanh tra và thích nghi

3.9.1.2. nâng cao tính minh bạch hằng ngày dựa vào Scrum hằng ngày, trong đó sự cộng tác, tính tự giác cần được duy trì, theo dõi

3.9.2. Ai theo dõi tiến độ Sprint

3.9.2.1. đây là công việc của nhóm phát triển vì họ làm việc theo hình thức tự tổ chức

3.9.2.1.1. được trao quyền

3.9.2.1.2. chịu trách nhiệm trong toàn bộ quá trình phát triển của Sprint

3.9.2.2. nhóm cần phải

3.9.2.2.1. cần theo dõi tiến độ để nắm được tình hình của Sprint và đưa ra các điểu chỉnh cần thiết kịp thời

3.9.3. Theo dõi tiến độ Sprint như thế nào

3.9.3.1. thường xuyên cập nhật Sprint Backlog

3.9.3.1.1. trong Sprint Backlog các hạng mục đã được ước lượng nỗ lực cần thiết để hoàn thành nó việc này được thực hiện bơi nhóm phát triển trong buổi lập kế hoạch Sprint, các giá trị này được ghi rõ cho từng công việc ta gọi đây là ước tính ban đầu

3.9.3.1.2. sau mỗi ngày làm việc các thành viên sẽ cập nhật lại các giá trị này, nên được cập nhật trước Scrum hằng ngày, các thành viên có thể cập nhật bất cứ lúc nào miễn là thuận lợi

3.9.3.1.3. như vậy sau mỗi ngày làm việc, nhóm có thể biết được mình cần đầu tư bao nhiêu nỗ lực nữa để hoàn thành công việc bằng cách cộng toàn bộ các con số ước tính này lại

3.9.3.2. sử dụng biểu đồ Sprint burndown

3.9.3.2.1. trục ngang

3.9.3.2.2. trục dọc

3.9.3.2.3. trong trường hợp đường thực tế nằm trên đường lý tưởng quá xa thì tỉ lệ cao là nhóm sẽ không hoàn thành các hạng mục trong Sprint và lúc này cần thuong lượng với PO về việc rút bớt các hạng mục công việc ra

3.9.3.2.4. nên được đặt ở bảng vật lý Sprint Backlog