Bài viết

Khóa học online “Scrum Essence”

 

Học Scrum nhanh chóng, hiệu quả theo cách của bạn. Học online là biện pháp phù hợp nhất cho những người bận rộn. Bạn sẽ học những điều cốt yếu nhất, tinh túy nhất để hiểu đúng Scrum, vận dụng Scrum đúng cách vào công việc…

Xem chi tiết tại: http://hocvienagile.com/scrum-essence/

Học trực tuyến tại: https://kyna.vn/scrum-essence

Làm sao để cải thiện Scrum Hằng ngày

ScrumMaster – Sức mạnh của Scrum

Scrum hoạt động như thế nào?


Video mô tả tổng quan về vòng đời phát triển một sản phẩm với mô hình Scrum. Các khái niệm được đề cập bao gồm:

Agile là gì? Scrum là gì?

Video giúp trả lời những câu hỏi tổng quan về Agile và Scrum như:

Agipedia

Cải tiến Sprint

Cải tiến Sprint là một sự kiện quan trọng trong Scrum diễn ra ngay sau buổi Sơ kết Sprint nhằm mục đích thanh tra và thích nghi quy trình làm việc. Nói cách khác đây là dịp để Nhóm Scrum nhìn lại quá trình làm việc của một Sprint và xác định những thay đổi cần thiết đối với quy trình để làm việc tốt hơn trong Sprint sau.

Thành phần tham dự: Nhóm Phát triểnScrumMaster bắt buộc phải tham dự. Product Owner có thể tham dự hoặc không. Ngoài ra Nhóm Phát triển còn có thể mời thêm những người khác cùng tham dự nếu cần thiết.

Thời gian: Sự kiện này được đóng khung trong 3 giờ đối với Sprint 1 tháng. Với các Sprint ngắn hơn thì thời gian có thể ngắn hơn, vào khoảng 45 phút tương ứng với 1 tuần làm việc của Sprint.

Mục đích của buổi Cải tiến Sprint bao gồm:

  • Thanh tra lại Sprint trước, về các yếu tố liên quan đến con người, giao tiếp, quy trình và công cụ.
  • Liệt kê những hạng mục đã làm tốt và những hạng mục có thể cải tiến được.
  • Lên kế hoạch triển khai các cải tiến về cách làm việc của Nhóm Scrum.

Có rất nhiều kỹ thuật để tiến hành một buổi Cải tiến Sprint, chẳng hạn như Glad-Sad-Mad, SpeedBoat, SailBoat,… Trang RetrospectiveWiki có liệt kê một số kỹ thuật thường được dùng.

Có một lỗi mà các nhóm thường gặp phải đó là buổi cải tiến chỉ tập trung vào những vấn đề làm chưa tốt để cải tiến. Điều này thường dẫn đến tình trạng các thành viên có cảm giác không thích thú với sự kiện này và xem nó như một cuộc họp mang tính tiêu cực. Hãy cố gắng tạo ra sự hứng thú và tinh thần tích cực trong các thành viên bằng cách động viên thông qua những công việc đã làm tốt.

Mặc dù việc cải tiến có thể diễn ra bất cứ lúc nào, nhưng sự kiện Cải tiến Sprint vẫn là thời điểm chính thức được quy định để làm việc này. Tuân thủ và thực hiện tốt sự kiện này là cách để tạo một thói quen thanh tra và thích nghi quy trình làm việc trong nhóm.

Lập kế hoạch Sprint

Lập kế hoạch Sprint là sự kiện diễn ra ở đầu mỗi Sprint để chuẩn bị cho toàn bộ Sprint. Buổi Lập kế hoạch Sprint được chia làm 2 phần riêng biệt với 2 mục đích khác nhau. Phần 1 nhằm trả lời câu hỏi: “Chúng ta sẽ làm gì?”. Phần 2 nhằm trả lời câu hỏi: “Chúng ta sẽ làm như thế nào?”.

Thành phần tham dự: Nhóm phát triểnScrumMaster bắt buộc phải tham gia toàn bộ 2 phần của sự kiện này. Product Owner bắt buộc phải tham gia Phần 1 và có thể vắng mặt ở Phần 2 nhưng phải đảm bảo sẵn sàng trả lời các thắc mắc của Nhóm Phát triển. Tuy nhiên, trong thực tế thì Product Owner nên tham gia đầy đủ cả hai phần để cho sự kiện này đạt được kết quả cao nhất.

Thời gian: Đối với Sprint kéo dài 1 tháng thì sự kiện này được đóng khung trong 8 giờ làm việc. Sprint ngắn hơn thì thường sự kiện này sẽ ngắn hơn, ví dụ: Sprint 2 tuần thì thường chỉ cần 4 giờ là đủ. Mỗi phần của sự kiện này được phân bố khoảng thời gian bằng nhau.

Trong phần 1 của buổi Lập kế hoạch Sprint, Product Owner trình bày cho Nhóm Phát triển hiểu rõ tất cả các hạng mục Product Backlog có khả năng được đưa vào sản xuất trong Sprint này. Thông thường, vì việc làm mịn các hạng mục Product Backlog đã được thực hiện liên tục trước đó cho nên lúc này Product Owner chỉ cần làm rõ một số hạng mục còn lại và trả lời các thắc mắc nếu có của Nhóm Phát triển. Nhóm Phát triển lựa chọn các hạng mục Product Backlog để phát triển trong Sprint này. Số lượng hạng mục được lựa chọn hoàn toàn phụ thuộc vào Nhóm Phát triển, có thể dựa vào tốc độ sản xuất của nhóm trong quá khứ để ước lượng. Kết thúc phần 1, Product OwnerNhóm Phát triển đưa ra một Mục tiêu Sprint, Nhóm Phát triển cũng đã biết được tổng quan về công việc mà mình sẽ thực hiện trong Sprint này.

Phần 2 của buổi Lập kế hoạch Sprint là để Nhóm Phát triển phân tích và lên kế hoạch công việc cho Sprint. Nhóm Phát triển bắt đầu bằng việc phân tách các hạng mục Product Backlog thành danh sách các công việc cụ thể. Nhóm Phát triển cũng ước tính lượng nỗ lực cần bỏ ra để hoàn thành từng công việc. Sau khi đã phân tích chi tiết, nếu Nhóm Phát triển thấy cần điều chỉnh (ví dụ, loại bớt một vài hạng mục Product Backlog đã chọn) thì có thể trao đổi với Product Owner để thực hiện thay đổi danh sách các hạng mục Product Backlog đã chọn. Kết thúc phiên này, Nhóm Phát triển có được Sprint Backlog.

Kết thúc buổi Lập kế hoạch Sprint, Nhóm Phát triển đã biết Mục tiêu Sprint và kế hoạch công việc để đạt được mục tiêu đó. Các thành viên có thể bắt tay ngay vào công tác sản xuất.

 

Scrum Hằng ngày

Scrum Hằng ngày là buổi trao đổi ngắn mà Nhóm Phát triển thực hiện đều đặn hằng ngày nhằm cập nhật và đồng bộ công việc giữa các thành viên. Sự kiện này cũng được coi là buổi tái-lập kế hoạch của Nhóm Phát triển.

Thành phần tham dự: Tất cả các thành viên của Nhóm Phát triển bắt buộc phải tham gia sự kiện Scrum Hằng ngày. ScrumMaster không bắt buộc phải tham dự nhưng phải đảm bảo Nhóm Phát triển thực hiện tốt sự kiện này.

Thời gian: Khung thời gian tối đa cho sự kiện Scrum Hằng ngày là 15 phút, bất kể số lượng thành viên của Nhóm Phát triển là bao nhiêu.

Mục đích của buổi Scrum Hằng ngày không phải là để giải quyết vấn đề mà là để thông báo và cập nhật tình hình. Do vậy, không cho phép bất cứ cuộc thảo luận chi tiết nào ở đây. Để đảm bảo tính ngắn gọn, lần lượt các thành viên của Nhóm Phát triển trình bày câu trả lời cho 3 câu hỏi: Tôi đã làm gì từ buổi Scrum Hằng ngày trước cho đến bây giờ? Tôi sẽ làm gì từ bây giờ cho tới buổi Scrum Hằng ngày hôm sau? Tôi đang gặp phải những khó khăn gì?. Nếu có các vấn đề đỏi hỏi phải thảo luận sâu giữa các thành viên thì Nhóm Phát triển sẽ tổ chức các buổi thảo luận ngay sau khi sự kiện Scrum Hằng ngày kết thúc.

Một thành viên của Nhóm Phát triển sẽ ghi lại các trở ngại để ScrumMaster hỗ trợ giải quyết sau khi buổi trao đổi kết thúc.

Scrum Hằng ngày là một thủ tục đơn giản, dễ thực hiện nhưng cũng vì thế mà nó dễ bị làm sai và không phát huy được tính hiệu quả. Hãy thực hiện Scrum Hằng ngày vào cùng một địa điểm và khung thời gian để tạo thói quen cho nhóm và tìm cách để cho sự kiện này diễn ra vui vẻ, đều đặn và hiệu quả.


Đọc thêm: Họp stand-up, hãy làm cho đúng

Video: Làm sao để cải thiện Scrum Hằng ngày

Phần tăng trưởng

Phần tăng trưởng là tên gọi ngắn của Phần tăng trưởng Sản phẩm Có khả năng Chuyển giao được (Potentially Shippable Product Increment) là phần sản phẩm Nhóm Phát triển tạo ra cuối mỗi Sprint. Đây là một khái niệm quan trọng trong Scrum tạo ra sự khác biệt lớn về mặt sản phẩm so với các phương pháp truyền thống. Scrum không chỉ đơn giản tách quá trình phát triển thành các Sprint nhỏ liên tiếp nhau, mà cuối mỗi Sprint đòi hỏi Nhóm Phát triển phải chuyển giao một phần tính năng “hoàn chỉnh” của sản phẩm. Hoàn chỉnh ở đây được hiểu theo nghĩa được Product Owner chấp nhận dựa theo Định nghĩa Hoành thành đã được thống nhất trước đó.

Đối với sản xuất phần mềm, điều đó có nghĩa là cuối mỗi Sprint, Nhóm Phát triển cần bàn giao một gói tính năng hoạt động tốt, đã được kiểm thử, tích hợp vào hệ thống và có đầy đủ tài liệu người dùng theo yêu cầu. Nhờ vậy, ở bất cứ thời điểm cuối Sprint nào thì sản phẩm đều đạt được trạng thái sẵn sàng phát hành mà không cần làm thêm bất cứ công việc nào liên quan đến đóng gói, tích hợp hay tinh chỉnh nhỏ. Điều này mang lại lợi ích cho nhiều phía từ các góc độ khác nhau, chẳng hạn như gia tăng sự minh bạch, sớm chuyển giao được giá trị kinh doanh và giảm thiểu rủi ro…

Khái niệm “chuyển giao được” ở đây không có nghĩa là sản phẩm phải được phát hành ngay. Việc có phát hành sản phẩm hay không là phụ thuộc vào quyết định liên quan đến kinh doanh. Còn trạng thái “chuyển giao được” thể hiện sự “tin tưởng” vào tính sẵn sàng của sản phẩm.

Có thể nói, việc chuyển giao được một Phần tăng trưởng ở cuối mỗi Sprint là nhiệm vụ cốt lõi và không hề dễ dàng đối với Nhóm Phát triển. Thông thường thì đối với các nhóm mới sử dụng Scrum, họ thường thất bại trong những Sprint đầu tiên. Bởi vì, để đạt được kết quả mong muốn này, Nhóm Phát triển cần phải áp dụng rất nhiều kỹ năng, công cụ, cộng tác và đưa ra các quyết định tốt trong suốt quá trình diễn ra Sprint. Có thể kể đến một số yếu tố ảnh hưởng đến việc này như:

  • Nhóm Phát triển có đảm bảo tính liên chức năng để thực hiện các công việc như được thống nhất trong Định nghĩa Hoàn thành không?
  • Nhóm Phát triển có biết cách lập kế hoạch Sprint để đảm bảo thuận lợi cho việc tạo ra phần tăng trưởng không?
  • Nhóm Phát triển có được trang bị các công cụ tự động để giúp cho quá trình phát triển, kiểm thử, tích hợp,… được diễn ra nhanh chóng không?
  • Nhóm Phát triển có vận hành tốt để đạt được mục tiêu chung hay không?
  • Khung thời gian của Sprint có đủ dài để hoàn thành các công việc hay không?

 

Sơ kết Sprint

Sơ kết Sprint là sự kiện diễn ra ở cuối Sprint nhằm thanh tra và thích nghi sản phẩm đang được xây dựng. Sự kiện này bao gồm 2 hoạt động chính đó là dùng thử sản phẩm và thảo luận về tình hình của sản phẩm, hướng đi tiếp theo và những điều chỉnh đối với sản phẩm nếu cần thiết.

Thành phần tham dự: Nhóm Phát triển, ScrumMasterProduct Owner bắt buộc phải tham dự. Ngoài ra, Product Owner có thể mời những người khác như người dùng, khách hàng và các bên liên quan khác.

Thời gian: Sự kiện này đóng khung tối đa trong 4 giờ đối với Sprint 1 tháng. Với các Sprint ngắn hơn thì thường cần ít thời gian hơn.

Bắt đầu sự kiện, Product Owner sẽ trình bày về những hạng mục đã được lựa chọn cho Sprint, liệu chúng đã được hoàn thành hay chưa. Nhóm Phát triển có thể trình bày về những khó khăn mà mình gặp phải trong suốt Sprint và các giải pháp mà mình đã đưa ra.

Tiếp theo là buổi dùng thử sản phẩm. Thay vì để Nhóm Phát triển trình diễn về những tính năng mới làm được trong Sprint thì nên sắp xếp để những người tham gia có thể trực tiếp dùng thử sản phẩm, đặc biệt là những người dùng thực sự.

Sau đó, tất cả mọi người tham gia sẽ thảo luận và đóng góp ý kiến cho sản phẩm. Product OwnerNhóm Phát triển ghi nhận những ý kiến này. Product BacklogKế hoạch Phát hành có thể được thay đổi nếu cần thiết để phù hợp hơn với tình hình mới.

Sự kiện này cũng được coi là cơ hội để Product OwnerNhóm Phát triển tìm hiểu lẫn nhau. Product Owner tìm hiểu về sản phẩm và tình hình của Nhóm Phát triển. Nhóm Phát triển tìm hiểu về tình hình của Product Owner và thị trường.