Bài viết

Kanban là gì?

Kanban là một phương pháp Agile dựa trên Phương  thức Sản xuất Toyota với bốn nguyên lý:

  • Trực quan hóa công việc
    Bảng Kanban là công cụ để trực quan hóa công việc. Bảng Kanban bao gồm các cột tương ứng với trạng thái của công việc. Mỗi công việc khi ở trạng thái nào thì được đặt ở cột tương ứng. Chúng ta có thể dùng một bảng vật lý hoặc một phần mềm hỗ trợ Kanban như Trello.

    kanban boardHình 1. Minh họa một bảng Kanban đơn giản

  • Giới hạn công việc đang làm (Limit WIP – Limit Work In Progress)
    Số lượng công việc đang được làm đồng thời ở mỗi trạng thái cần được giới hạn. Nguyên lý này giúp giới hạn những việc chưa hoàn thành trong tiến trình, từ đó giảm thời gian mỗi công việc đi qua hệ thống Kanban. Nguyên lý giới hạn WIP còn giúp cho nhóm làm việc tập trung, tránh lãng phí do phải việc chuyển qua lại giữa các công việc khác nhau.
  • Tập trung vào luồng làm việc
    Việc áp dụng nguyên lý giới hạn WIP và phát triển những chính sách hướng theo nhóm giúp nhóm có thể tối ưu hóa hệ thống Kanban để cải tiến luồng làm việc trơn chu.
  • Cải tiến liên tục
    Nhóm đo mức độ hiệu quả bằng cách theo dõi chất lượng, thời gian làm sản phẩm, v.v. để từ đó có những phân tích, thử nghiệm để thay đổi hệ thống nhằm tăng tính hiệu quả của nhóm.

Kanban đã không chỉ được ứng dụng trong làm việc nhóm mà còn cho cả quản lý công việc cá nhân với tên gọi Kanban cho cá nhân.

Xem thêm:

Cải tiến sẽ tăng năng suất?

Nghệ thuật cải tiến liên tục

Con người tinh gọn.

 

Phần tăng trưởng có vai trò gì trong Scrum?

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?

Hạng mục Product Backlog là gì

Hạng mục Product Backlog là tên gọi dùng cho các phần tử của một Product Backlog. Product Backlog là một tập hợp của nhiều Hạng mục Product Backlog.

Một Hạng mục Product Backlog có thể được mô tả dưới bất cứ hình thức nào, chẳng hạn như: User Story, User Case, User Scenario,…

Các Hạng mục Product Backlog thường được ước tính giá trị (đối với khách hàng) và độ lớn (lượng nỗ lực cần thiết để hoàn thành).

Những hạng mục ở phía trên của Product Backlog thì được làm mịn hơn so với những hạng mục ở phía dưới, bởi vì những hạng mục ở phía trên sẽ được đưa vào phát triển sớm hơn.

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.

Đọc thêm:

Cải tiến Sprint với Speedboat

Cải tiến Sprint với Sailboat

Cải tiến Sprint với Glad, Sad, Mad.

Sơ kết Sprint

Sơ kết Sprint là sự kiện diễn ra ở cuối Sprint nhằm thanh trathí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.