Lời tựa

Có người nói với tôi rằng, team của họ đang họp daily meeting, họp planning, thực hiện retrospective, delivery sản phẩm theo các sprint ngắn hàng tuần. Họ đang thực hiện scrum framework để làm dự án!

Tuân theo được quy trình.
Tôi nghĩ như vậy là chưa đủ.

Những điều cần làm

Scrum Master, về cơ bản việc đầu tiên khi làm cùng đội nhóm là giúp họ tuân theo được scrum framework.

Việc bắt đầu với nột nhóm mới, chưa biết về scrum, scrum master sẽ cần trải qua các giai đoạn huấn luyện cho team gồm:
– Tuân theo được quy trình
– Hiểu ý nghĩa các sự kiện
– Xây dựng nhóm tự quản
– Xây dựng agile mindset
– Và một điều quan trọng nữa Xây dựng nhóm liên chức năng.

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.

Giai đoạn này đòi hỏi nhóm và scrum master phải trao đổi rất nhiều để bước đầu thiết lập, làm quen các quy trình và sự kiện. Thay đổi cách delivery sản phẩm, cách làm việc với user stories, quen với việc có sự xuất hiện và phản hồi thường xuyên của khách hàng.

Đối diện với các mong muốn của các manager, scrum master cần đảm bảo nhóm có không gian và thời gian để thực hành và hiểu tầm quan trọng của các sự kiện cũng như khung làm việc.

Tiếp theo khi đã quen thuộc với các sự kiện, và ý nghĩa các sự kiện, việc tôn trọng cách làm việc của nhóm là rất cần thiết. Điều này có thể tác động tích cực tới khả năng commitment của nhóm. Hãy nhớ, mục tiêu là quan trọng, cách để đạt mục tiêu hãy do nhóm chọn lựa. Điều này không chỉ giúp nhóm có cam kết cao mà còn giúp nhóm trưởng thành và học hỏi từ kinh nghiệm của những lần ra quyết định sai lầm. Hãy nhìn lại tư tưởng của agile: “nếu có thể sẽ rơi vào tình huống bất định, hãy sai sớm, sai nhỏ và cải tiến nó, lẩn tránh nó, tránh xa nó!”.
Nhóm tự quản cũng được hình thành thông qua làm việc cùng nhau, ra quyết định cùng nhau, cải tiến cùng nhau, và…phạm sai lầm cùng nhau. Đừng quá lo lắng về sai lầm, tập trung vào việc cải tiến nó, cách tại sao nó xảy ra và cho thấy nhóm đã học hỏi được gì từ điều đó. Khi được tin tưởng, con thuyền dự án sẽ băng băng tới đích, dù có bao nhiêu cơn sóng.

Agile mindset là thứ khó hơn scrum master cần coach cho nhóm. Một thử thách thực sự! Hãy nhớ agile mindset không hình thành, dù bạn dùng “chiêu-trò” gì, nó hình thành từ sự học hỏi bên trong mỗi người. Đừng bắt con ngựa uống nước, hãy làm nó khát!

Một điều quan trọng nữa scrum master và tổ chức cần ghi nhớ: xây dựng nhóm liên chức năng! Điều này dường như là rất khó nếu các bên không đủ sự cam kết. Nhóm cam kết sẽ tuân thủ giá trị của scrum, scrum master cam kết hỗ trợ nhóm tối đa và các nhà quản lý cam kết với việc xây dựng văn hoá agile và tuân thủ chặt chẽ scrum framework. Nghe có vẻ đơn giản, nhưng hãy nhớ, các nhà quản lý luôn muốn nhiều hơn nữa trong một nguồn lực hạn chế!
Thật thú vị khi làm một scrum master và xây dựng một “bước-chuyển-mình” cho công ty.

Hồi kết

Với scrum master, việc tuân thủ được 5 yếu tố trên đảm bảo tổ chức của bạn vận hành trơn tru, tối đa hoá năng suất lao động, tạo ra nhiều giá trị hơn với nguồn lực hiện có. Tuy nhiên việc vác kiếm lên và đi vào rừng thẳm cần có những tính toán cụ thể và phương án hành động, hãy bắt đầu với trái tim nóng và cái đầu lý trí, đừng bao giờ bỏ qua một trong 2. Chúc các scrum master thành công với “dự án” của mình.

Chúng ta quá quen với việc làm việc theo quy trình, chúng ta được hướng dẫn phải thứ tự thực hiện các bước để thu được kết quả tốt nhất. Những hướng dẫn này được kiểm chứng, được phân tích và thử nghiệm nhiều lần trước khi được ban hành. Thế rồi một ngày, bỗng sự cố xảy ra, các hướng dẫn thì chưa để cập tới cách xử lý sự cố này ra làm sao cả. Vậy là cả nhóm loay hoay ngồi tranh luận với nhau làm thế nào. Đôi khi từ tranh luận biến thành cãi vã lúc nào không hay, rồi thì vấn đề lúc đầu biến thành cái gì không biết nữa. Đang giải quyết khủng hoảng truyền thông khi uy tín doanh nghiệp bị tổn hại, cuối cùng sau một hồi tranh luận, lại thấy nguyên nhân đâu đó xuất phát từ chị lao công!

Nói vậy để thấy rằng, điều gì cũng có mặt tốt và hạn chế của nó. Quy trình, không thể phủ nhận là nó rất tốt, rất hữu dụng trong nhiều trường hợp khác nhau. Ở đây muốn bàn tới việc, đôi lúc chúng ta phải agile (linh hoạt) tuỳ vào hoàn cảnh, không phải lúc nào cũng nhất nhất tuân theo một hướng dẫn cụ thể có từ xa xưa để giải quyết một thứ phát sinh rất mới. Nhìn đàn kiến nối đuôi nhau tha mồi về hang, khi gặp trở ngại “bất ngờ” (chúng ta thả một chiếc lá để chặn đường đoàn kiến) chúng đơn giản chỉ đi vòng qua và tiếp tục hành trình, cả toàn lại tiến bước đều đặn.

Xử lý sự cố trong công việc cũng vậy, khi khó khăn hay trở ngại xuất hiện, đừng dừng lại ở đó mà hoang mang, sợ hãi. Hãy dũng cảm làm một cách khác chưa-có-trong-quy-trình để thử giải quyết vấn đề.

Dù sao đi chăng nữa, chúng ta chẳng thể giải quyết được vấn đề nếu vẫn suy nghĩ theo cách đã tạo ra nó.

Tư duy agile là cách chúng ta linh hoạt, trong từng suy nghĩ, hành động, để đạt được cách giải quyết vấn đề hiệu quả hơn, thông minh hơn. Think outside the box, chứ đừng đặt bản thân mình trong những giới hạn nhỏ bé.

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.

Nói một cách khác, cả DoD và AC phải được đáp ứng để hoàn thành User Story. Phần tăng trưởng của sản phẩm không được xem là “hoàn thành”, trừ khi cả 2 danh sách này được thực hiện xong. Vì vậy, chúng ta cần định nghĩa cả 2 khía cạnh “Tiêu chí hoàn thành – DoD” và “Tiêu chí chấp nhận – AC” như hình dưới:

Definition of Done vs Acceptance Criteria

 Definition of Done

Định nghĩa hoàn thành được viết như là một danh sách các nhiệm vụ, mỗi một nhiệm vụ sẽ được sử dụng để xác thực một “Story” hoặc PBI (Product Backlog Item), chúng tồn tại để đảm bảo rằng nhóm phát triển đồng thuận về chất lượng của công việc mà họ đang cố gắng hoàn thành. DoD đóng vai trò như một checklist được sử dụng để kiểm tra tính hoàn thiện của từng hạng mục sản phẩm tồn đọng (hay còn gọi là PBI – Product Backlog Item) hoặc User Story. Các yêu cầu trong định nghĩa hoàn thành (DoD) nhằm mục đích áp dụng cho tất cả các hạng mục trong Product Backlog, chứ không chỉ dành cho một User Story cụ thể. DoD có thể được tóm tắt như sau:

• Thuật ngữ DoD thường được áp dụng cho phần tăng trưởng sản phẩm như là một yêu cầu chung;
• Trong hầu hết các trường hợp, DoD hàm ý rằng, phần tăng trưởng sản phẩm có thể phát hành được;
• Thuật ngữ DoD được định nghĩa trong Scrum Guide;
• DoD được sử dụng như là một cách giao tiếp giữa các thành viên trong nhóm để: Đảm bảo chất lượng phần mềm; Xác định xem phần tăng trưởng có thể bàn giao, hay không;

THE GOALS OF DEFINITION OF DONE

• Xây dựng một hiểu biết chung trong nhóm về “Chất lượng” và “Tính hoàn thiện”;
• Được sử dụng như là một “danh sách kiểm tra – checklist” để kiểm tra các User Story (hoặc PBIs);
• Đảm bảo rằng phần tăng trưởng có thể bàn giao được vào cuối mỗi Sprint có chất lượng cao và “chất lượng cao” được hiểu rõ bởi tất cả các bên liên quan;

EXAMPLE – DEFINITION OF DONE

Ví dụ trong ngành phần mềm, các nhóm có thể cần hỏi một số câu hỏi sau để đưa ra DoD của họ:

• Có cần review chéo code hay không?
• Như thế nào được xem là code đã “xong”?
• Chúng ta sẽ review code như thế nào?
• Unit test đã được kiểm tra hay chưa?
• Function test đã được kiểm tra hay chưa?
• Test chấp nhận đã được tiến hành xong chưa?
• Product Owner đã xem và chấp nhận tính năng mới này chưa?

Acceptance Criteria

User stories là một trong các artifact chính trong phát triển sản phẩm bằng Agile, tuy vậy Scrum không yêu cầu bắt buộc phải sử dụng User Story hay Acceptance Criteria. Nếu các hạng mục Product Backlog được xem xét là quá lớn để đặt trong một sprint, nó thường được chia nhỏ thành các user story và các nhiệm vụ con giống như hình ví dụ sau:

Acceptance Criteria

Các User Story chứa các tiêu chí chấp nhận (Acceptance Criteria – AC), vì vậy chúng ta thường thấy định nghĩa hoàn thành (DoD) và tiêu chí chấp nhận (AC) cùng tồn tại trong quy trình phát triển Scrum. User Story cung cấp “ngữ cảnh – yêu cầu người dùng” của chức năng mà nhóm nên phát hành. Tiêu chí chấp nhận (AC) đưa ra các hướng dẫn chi tiết về các yêu cầu của chức năng và diễn tả cách khách hàng sẽ chấp nhận chúng.

Một vài tiêu chí chấp nhận sẽ được làm rõ trong sự kiện “làm mịn – Backlog Refinement” trước khi bắt đầu Sprint mới, và phần còn lại sẽ được làm rõ ngay sau phiên lập kế hoạch, khi nhóm thảo luận về các user story. Vì vậy tiêu chí chấp nhận (AC) là duy nhất cho một User Story hoặc một hạng mục Product Backlog.

• Thuật ngữ này áp dụng cho một PBI/Story;
• Tiêu chí chấp nhận là khác nhau cho mỗi PBI/Story;
• Nguyên tắc này không được định nghĩa trong Scrum Guide;
• AC được sử dụng như là một cách để thông báo cho tất cả các bên liên quan rằng một PBI/Story đã được hoàn thành;
• Tiêu chí chấp nhận trong một số trường hợp có thể là các Test Case;

THE GOALS OF ACCEPTANCE CRITERIA

• Làm rõ nhóm muốn xây dựng tính năng gì, như thế nào trước khi công việc bắt đầu;
• Chắc chắn rằng tất cả mọi người có chung hiểu biết về “vấn đề”;
• Giúp các thành viên trong nhóm biết rằng khi nào một Story được tính là hoàn thành;
• Giúp kiểm tra Story bằng các kiểm thử tự động;

EXAMPLE – ACCEPTANCE CRITERIA

• Một user không thể “submit” dữ liệu khi chưa nhập tất cả các trường bắt buộc;
• Thông tin từ “form” được lưu trữ trong bảng “registrations” trong cơ sở dữ liệu;
• Có thể thanh toán qua thẻ tín dụng;
• Một email xác nhận được gửi tới người dùng sau khi “submit” form;

Example of User Story with Acceptance Criteria

User Story: Là người dùng, tôi muốn có thể đăng ký online để mua sắm online;
Definition of Done:

• Code cần được review bởi teamleader;
• Code cần được Function test;
• Code cần được Acceptance test;
• Code cần được Intergration test;
• Code cần được merge vào nhánh dev;

Acceptance Criteria:

• Người dùng chỉ có thể submit form sau khi nhập tất cả các trường bắt buộc;
• Email mà người dùng cung cấp phải là một email “cá nhân”;
• Một IP chỉ có thể submit form 3 lần trong 30 phút;
• Người dùng sẽ nhận một email thông báo sau khi đăng ký thành công;

Nguồn paradigm

Những gì Scrum Master không là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).

Nguyên gốc:

For starters, we know the Scrum Master doesn’t plan the release, because that’s done by the product owner and the team. We know he doesn’t manage the developers because the Scrum team is self-organizing; and we know he’s not even the guy who’s accountable if the end result sucks (that’s the product owner too).

Vậy Scrum Master làm gì?

Nếu chủ sở hữu sản phẩm giống như người đứng đầu đưa ra quyết định và nhóm Scrum giống như cơ quan thực hiện kế hoạch của bạn, thì Scrum Master có thể được coi là mắt xích giữ mọi thứ lại với nhau và vận hành nhịp nhàng.

Nói một cách đơn giản hơn, Scrum Master đảm nhận các vai trò quản trị, huấn luyện và lãnh đạo giúp cho việc phát triển theo Scrum trở nên khả thi. Điều đó có nghĩa là anh ấy sẽ thường dành những ngày của mình:

• Tạo điều kiện cho (không tham gia) hoạt động hàng ngày;
• Giúp nhóm duy trì biểu đồ burndown của họ;
• Thiết lập retrospectives (hồi tưởng), đánh giá sprint hoặc các buổi lập kế hoạch sprint;
• Bảo vệ nhóm khỏi bị gián đoạn trong suốt sprint;
• Loại bỏ các chướng ngại vật ảnh hưởng đến nhóm;
• Hướng dẫn chủ sở hữu sản phẩm thông qua kỹ thuật sử dụng user story;
• Khuyến khích sự hợp tác giữa nhóm Scrum và chủ sở hữu sản phẩm;

Lưu ý rằng hầu hết mọi thứ liên quan đến Scrum sẽ được Scrum Master đóng vai trò là “Facilitator” xử lý, hoặc lúc này Scrum Master có thể tạo ra một tình huống mà họ có thể cung cấp các hướng dẫn chi tiết cho nhóm làm việc. Điểm quan trọng ở đây chỉ ra rằng, nhóm phát triển không nên quan tâm quá mức vào quy trình Scrum, mà họ nên tập trung vào công việc phát triển phần mềm. Tương tự như vậy, chủ sở hữu sản phẩm có thể tiếp tục trau dồi các nhu cầu kinh doanh với sự tin tưởng rằng Scrum Master sẽ nhắc nhở cô ấy ở những sự kiện chính, quan trọng như sprint review. Scrum Master đề cao những nhiệm vụ này để đảm bảo rằng quy trình Scrum không cản trở tiến trình làm việc của nhóm.

Vậy chúng ta có cần một Scrum Master không?

Mặc dù những nhiệm vụ này thường đủ để khiến ai đó bận rộn cả ngày, nhưng không phải mọi Scrum Master đều “chỉ” là Scrum Master. Một số nhóm có thể chọn một nhà phát triển hoặc kiểm thử viên để trở thành Scrum Master cho nhóm, vì họ không cảm thấy vị trí này xứng đáng với nhân sự toàn thời gian. Dựa trên các nhiệm vụ mà Scrum Master thực hiện, nhóm của bạn có thể hoàn thành mà không cần một cá nhân chuyên trách nếu:

• Chủ sở hữu sản phẩm của bạn biết mọi thứ về khách hàng và luôn sẵn sàng hỗ trợ nhóm phát triển mà không cần Scrum Master hướng dẫn.
• Nhóm nhà phát triển của bạn có văn hóa giao tiếp mạnh đến mức các cuộc họp hàng ngày là không cần thiết và nếu có thêm các cuộc họp thì chỉ làm tăng chi phí vận hành.
• Biểu đồ burndown và các tạo tác khác được duy trì tự động và không tạo ra bất kỳ chi phí nào cho nhóm phát triển.
• Nhóm hoạt động không bị phân tâm và có thể dễ dàng tự mình loại bỏ mọi trở ngại.

Việc một nhóm trưởng thành như vậy chọn một Scrum Master từ bên trong là điều hợp lý, nhưng mức độ gắn kết cao này không có khả năng từ các tổ chức mới bắt đầu. Cho dù nhóm của bạn có chuyên môn đặc biệt hay không, vai trò Scrum Master vẫn rất quan trọng vì nó hoạt động như một bộ đệm giữa nhóm và bất kỳ quy trình nào mà Scrum có thể tạo ra.

Làm một chén trà đã nhỉ.
Bây giờ chúng ta đã tìm ra Scrum Master làm gì cả ngày, đây là một số điểm chính:

• Đảm nhận các vai trò quản trị, huấn luyện và lãnh đạo để việc triển khai Scrum là khả thi.
• Đảm bảo quy trình Scrum không cản trở công việc của nhóm.
• Đảm bảo mỗi thành viên trong nhóm có thể tập trung vào việc bàn giao phần mềm đúng thời hạn.

Nguồn scrumhub