“Văn hoá làm việc Agile đáp ứng sự thay đổi nhanh trong dự án và team làm việc rất cởi mở, đó là môi trường làm việc thúc đẩy tốt teamwork, đó là một bức tranh đẹp mà các nhà quản lý luôn muốn doanh nghiệp/đội nhóm của mình đạt được”.

Điều đó dẫn tới mong muốn triển khai agile trong các tổ chức, nhưng phía sau đó, thách thức của chúng ta sẽ là gì?

Văn hóa

Văn hóa phân cấp trong công việc: Chúng ta làm việc trong môi trường công sở, nơi mỗi người có những kỹ năng chuyên biệt để thực hiện những nhiệm vụ khác nhau. Thông qua đó, để điều phối công việc trở nên đúng trật tự, chúng ta cần những vai trò khác nhau để vận hành tổ chức. Văn hóa sếp-nhân viên có thể là rào cản đầu tiên gây cản trở văn hóa agile trong tổ chức. Xem thêm

Definition of Done (DoD) là một danh sách các yêu cầu mà các user story phải tuân theo để nhóm được xác nhận là hoàn thành một công việc. Trong khi đó Acceptance Criteria (tiêu chí chấp nhận) của một User Story bao gồm một danh sách các kịch bản kiểm thử cần được đáp ứng để xác nhận rằng “phần mềm” hoạt động giống như “kỳ vọng – hay yêu cầu” của khách hàng.

Sự khác biệt giữa DoD và AC ở chỗ: DoD là những yêu cầu chung nhất cho tất cả các User Story, trong khi đó AC sẽ được áp dụng cho những User Story cụ thể. Acceptance Criteria của mỗi User Story sẽ khác nhau, dựa trên yêu cầu của mỗi User Story. Xem thêm

Chúng tôi biết Scrum Master là người đóng vai trò quan trọng trong các nhóm Scrum mới, nhưng chính xác thì anh ấy hoặc cô ấy đã bận rộn những gì trong suốt ngày làm việc của mình?

Đối với những người mới bắt đầu, chúng tôi biết Scrum Master không lập kế hoạch phát hành, vì điều đó được thực hiện bởi chủ sở hữu sản phẩm và nhóm. Chúng tôi biết anh ấy không quản lý các nhà phát triển vì nhóm Scrum tự tổ chức; và chúng tôi biết anh ấy thậm chí không phải là người phải chịu trách nhiệm nếu kết quả cuối cùng tệ hại (đó cũng là trách nhiệm của chủ sở hữu sản phẩm).

Một nhóm khởi đầu sẽ cần được tranning về các quy trình, sự kiện. Việc này cần lặp đi lặp lại trong vài sprint để nhóm có thể thực hành một cách có chủ đích các sự kiện trong scrum framework. Thông qua quá trình này, scrum master có thể sẽ phải “tương tác” nhiều với các thành viên trong nhóm để họ hiểu mục đích và ý nghĩa các sự kiện.

Vậy Scrum thực hiện quản lý rủi ro dự án bằng cách nào? Hay như thế nào? Scrum framework được tổ chức gồm 3 vai trò: product owner, scrum master, development team; cả 3 vai trò trên đều thực hiện việc quản lý rủi ro dự án theo các công việc mà mình đảm nhận, được thiết kế thông qua các sự kiện trong framework. Thông qua đó, việc đánh giá và xử lý các rủi ro được trao cho các vai trò cụ thể. Mỗi vai trò sẽ có trách nhiệm giải quyết những vấn đề ảnh hưởng tới sự thành công của dự án liên quan công việc mà mình đảm nhận.

Trong các nhóm truyền thống, các xung đột có thể được cấp trên đứng ra giải quyết. Ví dụ khi bạn không thể thống nhất về cách sắp xếp thứ tự ưu tiên cho các dự án, hay các deadline cần thay đổi. Lúc này tean có thể đưa lên và trưởng nhóm sẽ ra quyết định. Một ví dụ khác có bao giờ bạn nghĩ rằng đồng nghiệp đang cư xử cộc cằn hay công việc của họ quá cẩu thả? Lúc này nhóm sẽ cung cấp thông tin cho quản lý và chờ người đó đứng ra giải quyết. Nhưng với một nhóm lớn hoặc nhóm tự tổ chức, đây không phải là một lựa chọn. Nhóm tự tổ chức phải xác định các cách khác nhau để tìm kiếm và giải quyết các xung đột hàng ngày. Xem thêm

Quản lý rủi ro trong dự án Agile (Scrum) là câu hỏi nhiều người gặp phải trong quá trình tìm hiểu về Agile và Scrum. Ở bài viết này mình sẽ chia sẻ về nội dung này để mọi người có thêm góc nhìn.

1. Đặc điểm quản lý rủi ro trong dự án Agile/Scrum.
2. Thực hành quản lý rủi ro trong Agile.
3. Có thể sử dụng 2 phương pháp quản lý rủi ro cùng nhau không.
4. Tổng kết.

Phần 1: Đặc điểm của quản lý rủi ro trong dự án áp dụng Agile và Scrum

Đầu tiên, xin quay lại với tuyên ngôn Agile:

Cá nhân và tương tác hơn là quy trình và công cụ.
Phần mềm chạy tốt hơn là tài liệu đầy đủ.
Cộng tác với khách hàng hơn là đàm phán hợp đồng.
Phản hồi với thay đổi hơn là tuân theo kế hoạch.
Mặc dù những điều ở bên phải vẫn còn giá trị, nhưng chúng tôi đề cao những điều ở bên trái. Xem thêm

Chà, có rất nhiều sách, bài báo, bài đăng trên blog và cộng đồng dành riêng cho scrum và huấn luyện viên Agile, nhưng sự thật là điều này không bao giờ phù hợp với các tình huống thực tế. Không có mẫu mô tả nào về scrum và huấn luyện viên agile, nhóm của bạn luôn thay đổi và phát triển khi dự án triển khai, chìa khóa là thích ứng với những thay đổi đó, việc triển khai của bạn có thể không tuân theo tất cả các quy tắc agile / scrum nhưng vẫn có thể truyền tải các đặc tính của agile, bằng cách này bạn có thể hoàn thành công việc. Có rất nhiều cách diễn giải về scrum và agile và điều đáng nhớ là

Chúng ta biết rằng Scrum và Kanban là 2 phương pháp làm việc theo nguyên lý Agile. Scrum là phù hợp nhất cho sản phẩm và các dự án phát triển. Kanban là tốt nhất cho việc hỗ trợ sản xuất. Chúng ta sử dụng Scrumban – sự kiết hợp giữa các tính năng tốt nhất của 2 framework này cho các dự án bảo trì.
Ngày nay Scrumban trở nên phổ biến trong các ngành dịch vụ, nơi chúng ta có các dự án phát triển và bảo trì. Xem thêm

Đối với những nhóm mới áp dụng scrum, các vai trò và công việc trong scrum là khá mới. Để giúp các bạn dễ dàng bắt đầu và biết được công việc cụ thể của mình trong từng thời điểm, hãy sử dụng các danh mục kiểm tra được đính kèm sau đây (check list) như một gợi ý và hướng dẫn cơ bản nhất.

Danh mục kiểm tra của PO bao gồm:

Kiểm tra hàng ngày

1. Đã làm rõ yêu cầu sản phẩm cho Nhóm Phát triển (nếu có).
2. Đã làm mịn các hạng mục product backlog, đặc biệt các hạng mục ở trên.

Kiểm tra theo sprint

1. Đã làm việc với các bên liên quan để cập nhật các kì vọng mới về sản phẩm.
2. Đã sắp xếp các hạng mục trong product backlog để đảm bảo tối ưu hoá ROI.
3. Đã làm mịn các hạng mục của product backlog.
4. Đã xác định các tiêu chí chấp nhận cho các hạng mục sẽ phát triển trong sprint tới.
5. Đã tham gia lập kế hoạch sprint để trình bày về tổng quan sản phẩm, từng hạng mục sẽ làm trong sprint tới và giải đáp mọi thắc mắc về yêu cầu trong lập kế hoạch sprint.
6. Đã tham gia và đưa phản hồi trong sơ kết sprint.

Nguồn: Trích nội dung sách “Cẩm nang Scrum” Xem thêm