Agile/Scrum - Phần 2: Scrum - Phương pháp Agile được áp dụng phổ biến nhất
Ở phần trước, chúng ta đã tìm hiểu về Agile Methodologies. Trong đó, Scrum là phương pháp Agile được sử dụng phổ biến nhất hiện này.
Vậy, Scrum là gì?
Từ “scrum” được lấy cảm hứng từ môn bóng bầu dục, khi mà cả đội tập hợp thành một đội hình gọi là scrum để cùng nhau đưa bóng về phía trước.
Trong việc phát triển sản phẩm (phần mềm), Scrum như một cách để hoàn thành công việc theo nhóm, theo từng phần nhỏ, với các vòng lặp thử nghiệm và phản hồi liên tục trong quá trình phát triển để tăng dần giá trị của sản phẩm. Scrum cung cấp framework và cách thức thực hiện để tối ưu quy trình làm việc.
Để làm việc theo scrum framework, cần có nhóm scrum (scrum team), bao gồm Product Owner, Scrum Master và Developers, mỗi vị trí có một trách nhiệm cụ thể riêng, sẽ được giới thiệu trong phần sau. Scrum team tham gia vào 5 sự kiện (scrum events) trong mỗi sprint, để tạo ra các “tạo tác" (scrum artifacts).
Các vai trò trong một scrum - Scrum Team
Trong một scrum team, có ba vai trò: Product Owner, Developers, và Scrum Master.
1. Product Owner - “Build the right thing”
Vai trò: Như tiêu đề, PO có trách nhiệm xác định “right thing to build”. Vậy, như thế nào là “right thing”? Đó là những tính năng, những cải tiến, những sản phẩm giúp khách hàng, người dùng giải quyết một vấn đề gì đó của họ đồng thời mang lại giá trị cho doanh nghiệp. Hơn nữa, những thay đổi đó mang lại giá trị cao nhất, tối đa hoá giá trị của sản phẩm nhờ vào công việc của scrum team trong một thời gian nhất định (Return on investment). Để đạt được điều đó, PO cần làm các công việc dưới đây:
Công việc:
Xác định (cùng với các stakeholders khác) và truyền đạt rõ ràng Mục tiêu sản phẩm
Tạo và truyền đạt rõ ràng các công việc trong Product Backlog. (Product Backlog: Sẽ được chia sẻ thêm ở phần dưới)
Sắp xếp (theo độ ưu tiên) các công việc trong Product Backlog. (Tham khảo thêm các phương pháp sắp xếp độ ưu tiên tại đây)
Đảm bảo rằng Product Backlog minh bạch, rõ ràng và dễ hiểu
Các công việc trên với mục tiêu xác định trách nhiệm của PO trong một Scrum team, không có nghĩa rằng đây là toàn bộ công việc của PO. Trong Product Development Cycle, đây chỉ là một phần công việc nhỏ của PO trong giai đoạn Product Delivery cùng team Tech. Tổng thể công việc của PO trong Product Development Cycle sẽ được chia sẻ ở bài viết sau.
2. Developers- “Build the thing right”
Vai trò: là đội ngũ trực tiếp làm ra sản phẩm một cách đúng nhất với đặc tả từ PO. Điều này không có nghĩa rằng Developer sẽ chỉ nghe và làm đúng chính xác yêu cầu từ PO. Cả scrum team, bao gồm cả developer đều cần nhìn đến “mục tiêu của sản phẩm”, xem xét giải pháp mà PO đưa ra có giúp đạt được mục tiêu đó hay không, đặt ra những câu hỏi, gợi ý để làm rõ hoặc thậm chí thay đổi đặc tả.
Công việc:
Lập kế hoạch cho mỗi Sprint
Phát triển sản phẩm, tuân thủ “Definition of Done”
Điều chỉnh kế hoạch mỗi ngày để hướng tới Mục tiêu Sprint (Sprint Goal)
Tương tự như PO, đây chỉ là những công việc của Developer trong cách làm việc theo mô hình Scrum. Ngoài ra, Developer còn rất nhiều công việc chuyên môn khác, để ngoài việc “build the thing right” thì còn đảm bảo hiệu suất, tính mở rộng, …
3. Scrum Master - “Build the thing fast”
Vai trò: Scrum master giúp Scrum team làm việc hiệu quả bằng cách tuân thủ các nguyên lý, các kỹ thuật và quy tắc của Scrum. Scrum Master không phải là người quản lý của Nhóm mà là một lãnh đạo theo phong cách phục vụ (Servant Leader). Scrum Master làm tất cả những gì trong thẩm quyền phục vụ Product Owner, Developer, và Tổ chức đi đến thành công, bao gồm cả việc huấn luyện và cố vấn cho nhóm hay các cá nhân trong Scrum team.
Công việc:
Huấn luyện các thành viên trong nhóm về cách tự quản lý và làm việc nhóm
Tập trung vào việc tạo ra các Increments có giá trị cao đáp ứng “Definition of Done”
Loại bỏ các trở ngại, các vấn đề đối với tiến độ của Nhóm Scrum
Đảm bảo rằng tất cả các sự kiện Scrum diễn ra hiệu quả
Giúp PO tìm các kỹ thuật để xác định Mục tiêu Sản phẩm và quản lý Product Backlog hiệu quả
…
4. Kiêm nhiệm
Cá nhân mình từng chứng kiến hoặc trải nghiệm việc một scrum team bị thiếu đi vai trò của PO hoặc Scrum Master (không thể thiếu Developers). Sẽ có người nói rằng việc thiếu đi PO hoặc SM thì một scrum team sẽ không hoàn thiện và gặp nhiều vấn đề, cũng có người nói rằng việc thiếu đi PO hoặc SM không làm ảnh hưởng đến kết quả công việc của họ, một developer có thể đóng vai trò của một PO, một PO hoặc developer có thể đóng vai trò của một SM.
Quay lại, Agile ngoài là một phương pháp, thì còn là một lối tư duy, Scrum là một framework (khung) chứ không phải một process (quy trình), do đó, một tổ chức có thể áp dụng sao cho phù hợp và hiệu quả.
Với những trải nghiệm cá nhân của mình, việc một scrum team thiếu đi một trong hai vai trò trên, PO hoặc SM, thì scrum team đó sẽ gặp nhiều vấn đề. Một PO/PM, vai trò quan trọng nhất của họ là xác định “right thing to build”, để làm được điều đó thì cần kỹ năng problem-solving rất tốt, tránh việc bắt đầu bằng một giải pháp (start with a solution). Còn SM, có thể coi là vai trò điều phối, tổ chức hoạt động của một scrum team, họ có thể hỗ trợ cùng lúc nhiều team ở các hoạt động scrum, còn khi thiếu đi thì khi đi sâu vào công việc chuyên môn, PO và Developer có thể sẽ dần quên đi các nguyên tắc cơ bản của Agile, các quy tắc của scrum.
Các “tạo tác” trong scrum - Scrum artifacts
1. Product Backlog
Là một danh sách các công việc cần làm để cải tiến sản phẩm, được sắp xếp theo độ ưu tiên. Đây là nguồn công việc duy nhất của một scrum team (*)
(*) Trong quá trình phát triển sản phẩm, làm việc với nhiều stakeholders, có thể có các yêu cầu qua email, qua chat, qua các buổi họp, qua nói miệng, vân vân.
Để đảm bảo đó là “right thing to build” và các vai trò trong scrum team (hoặc cả các stakeholders khác) biết về công việc đó, thì nó cần được tổng hợp (consolidate) về một nguồn duy nhất (centralized).
Hoạt động Product Backlog Refinement với mục tiêu chia nhỏ, thêm/xoá/sửa, làm rõ các công việc trong Product Backlog, với mô tả rõ ràng, chi tiết, công việc được sắp xếp thứ tự và ước lượng độ lớn.
2. Sprint Backlog
Sprint Backlog, ngoài là những công việc trong Product Backlog được chọn ra để làm trong một sprint (What) thì nó còn bao gồm Sprint Goal (Why) và kế hoạch để tăng trưởng sản phẩm (increment) (How).
Sprint Backlog là một kế hoạch (How), một bức tranh thể hiện các công việc cần hoàn thành trong sprint (What) để đạt được mục tiêu (Why). Do đó, nó cần được cập nhật thường xuyên, ít nhất là hàng ngày (trong Daily Standup) để mọi người cùng nắm được tiến trình (progress) của scrum team.
Sprint Goal: Mục tiêu của sprint không phải là làm hết tất cả những công việc đã được lập kế hoạch trong sprint đó, mà là kết quả của công việc đó mang lại về sản phẩm, về giá trị cho người dùng, khách hàng và doanh nghiệp. Sprint Goal là điều mà cả team cần luôn nhớ trong suốt sprint, để khi có điều gì có thể thay đổi thì mọi người có thể trao đổi, thương lượng dựa trên mục tiêu đó.
3. Increment
Increment là phiên bản hoàn thiện của sản phẩm sau mỗi Sprint, với mục tiêu là tạo ra giá trị cho khách hàng thông qua việc cung cấp các tính năng có thể sử dụng. Increment phải hoàn thiện và có thể chạy được, cho phép khách hàng hoặc bên liên quan kiểm tra và đánh giá. (**)
(**) Quay lại bài viết về Agile, một trong những vấn đề của các phương pháp phát triển phần mềm trước đó (ví dụ: Waterfall) là đến cuối cùng, khi cung cấp sản phẩm dùng được cho khách hàng, cho người dùng thì đó có thể không phải là cái mà họ cần. Scrum chia ra các sprint ngắn (1-4 tuần, thông thường là 2 tuần) với mục tiêu nhận feedback liên tục từ khách hàng, từ người dùng. Do đó, việc “increment phải hoàn thiện và có thể chạy được” là cần thiết để đảm bảo nhận được những feedback rõ ràng nhất từ khách hàng, từ người dùng.
4. Definition of Done
Một task được gọi là “Done”, được gọi là một phần của Increment, đóng góp vào Sprint Goal khi nó thoả mãn “Định nghĩa hoàn thành - Definition of Done (DoD)”.
DoD còn là căn cứ, là khái niệm để các thành viên trong scrum team trao đổi xuyên suốt quá trình phát triển sản phẩm, từ việc làm rõ ràng một yêu cầu trong Product Backlog, cho đến xác định các tiêu chuẩn hay kịch bản kiểm thử sản phẩm.
Các sự kiện trong scrum - Scrum events
1. Sprint Grooming
Theo scrum.org thì không có scrum event này, nó sẽ là một phần của Sprint Planning (kéo dài tối đa 8 tiếng cho sprint 1 tháng và ít hơn nếu sprint ngắn hơn). Tuy nhiên, mình muốn tách nội dung này ra để nói rõ và chi tiết hơn về nó.
Người điều phối: Product Owner/Product Manager (với sự hỗ trợ của Scrum Master khi cần)
Hoạt động: Sprint Grooming được hiểu là buổi mà PO/PM trình bày cho cả scrum team về các dự án, các sản phẩm, các tính năng cần được làm. Đặc biệt lưu ý, PO/PM cần “Start with Why”, trình bày rõ ngữ cảnh, vấn đề của người dùng, khách hàng hay chính doanh nghiệp đang gặp phải; mục tiêu khi giải quyết vấn đề này; sau đó trình bày về giải pháp, PRD (Product Requirements Document). Trong khi hoặc sau khi trình bày, PO/PM cần giải đáp, làm rõ thắc mắc của scrum team, ghi nhận feedback hoặc những đề xuất của team để cải thiện trước khi vào buổi Sprint Planning. Từ đó, chia nhỏ ra thành các epic, user story, task, tương đương với hoạt động Product Backlog Refinement được chia sẻ ở trên.
Output: Kết thúc buổi Sprint Grooming, cả team cần có những tasks đã được chia nhỏ và làm rõ về scope of work, definition of done. Nếu có những thứ cần thay đổi (về PRD, về Design) hoặc Giải pháp kỹ thuật (Technical solution) thì cần có người phụ trách để hoàn thành các công việc này trước Sprint Planning.
Với những trải nghiệm của cá nhân, mình tin rằng nên tách Sprint Grooming ra, thậm chí trước Sprint Planning 1-3 ngày. Để nếu trong quá trình Grooming, sau khi nhận được các câu hỏi, feedback, đề xuất từ scrum team, thì PO/PM hoặc Tech Lead có thời gian để có những điều chỉnh về PRD, Technical solution. Team sẽ tiết kiệm thời gian hơn trong buổi sprint planning.
2. Sprint Planning
Người điều phối: Developer (Tech Lead) và/hoặc Product Owner/Product Manager (với sự hỗ trợ của Scrum Master khi cần)
Hoạt động: Từ buổi Sprint Grooming, scrum team đã có các user story, epic, và task được chia nhỏ, làm rõ và ước tính thời gian/công sức để hoàn thành. Ở buổi Sprint Planning này, cần trả lời 3 câu hỏi:
Why? Mục tiêu của sprint này (Sprint Goal) là gì?
What? Các công việc (task) nào cần được hoàn thành để đạt được mục tiêu đó? Đây là lúc mà các developer cùng cả team “kéo task” vào sprint, sao cho có thể đạt được Sprint Goal và cũng khả thi để hoàn thành được những task đó.
How? Kế hoạch và cách thức để hoàn thành các task kể trên. Ví dụ: Back-end Engineer phải làm trước task A, B thì Mobile Engineer mới có thể làm task C được; Để làm được task D, cần một team khác hỗ trợ công việc E trước ngày thứ 3 của tuần tới.
Output: Mục tiêu của sprint, các công việc cần làm và kế hoạch để hoàn thành các công việc đó. Sau khi planning thì scrum team cũng “start sprint”, bắt đầu một sprint mới.
Trải nghiệm cá nhân: Nếu phần Sprint Grooming được làm hiệu quả, thì buổi Sprint Planning này thường diễn ra từ 1-2 tiếng, tuỳ vào số lượng thành viên của scrum team. Mình thường đề xuất buổi planning này diễn ra vào ngày thứ 3, thứ 4 hoặc thứ 5, để tránh việc mọi người thường nghỉ phép vào thứ 2 hoặc thứ 6 nhiều hơn (ghép với thứ 7, chủ nhật).
3. Daily Scrum
Người điều phối: Developer (Tech Lead) hoặc Scrum Master
Hoạt động: Dựa vào Why, What, How sau khi làm Sprint Planning, cả team sẽ hàng ngày chia sẻ về tiến độ, những khó khăn trong quá trình làm việc (nếu có) để cùng hướng đến việc đạt được Mục tiêu của sprint (Sprint Goal).
Output: Kế hoạch tiếp theo (có thể điều chỉnh so với kế hoạch ban đầu nếu cần) để đạt được Sprint Goal.
Trải nghiệm cá nhân: Hoạt động phổ biến trong Daily Scrum là các thành viên trả lời 3 câu hỏi: Hôm qua làm gì? Hôm nay làm gì? Có gặp khó khăn gì không? Việc lặp đi lặp lại các câu hỏi này trong nhiều ngày có thể khiến cả team chán Daily Scrum và/hoặc chỉ trả lời các câu hỏi trên mà quên mất việc cần làm là đạt được Mục tiêu của sprint, không phải chỉ báo cáo tiến độ và tìm cách giải quyết các khó khăn nếu có.
4. Sprint Review
Người điều phối: Developer (Tech Lead) hoặc Product Owner/Product Manager
Hoạt động: Chia sẻ về Sprint Goal và kết quả thực tế đạt được, demo các “increment” cho cả team cũng như các stakeholders khác và nhận feedback. Lưu ý: Daily Scrum không phải là buổi để báo cáo về tiến độ, thì Sprint Review càng không phải là buổi để báo cáo về tiến độ, mà cần tập trung vào Sprint Goal đã đề ra.
Output: Kết quả thực tế so với Sprint Goal cùng những feedback để tiếp tục cải thiện sản phẩm.
5. Sprint Retrospective
Người điều phối: Developer (Tech Lead) hoặc Scrum Master
Hoạt động: Nhìn lại sprint vừa trải qua, rút trích những bài học và kế hoạch để cải thiện hoạt động của scrum team. Có thể đi qua “Những thứ đã làm tốt”, “Những thứ làm chưa tốt, còn là vấn đề, cần cải thiện”, “Những việc nên làm để cải thiện”.
Output: Những “actionable tasks”, được giao cho một cá nhân phụ trách để triển khai nhằm đảo bảo hoạt động của scrum team sẽ hiệu quả hơn.
Trải nghiệm cá nhân:
Có nhiều format (ví dụ: Drop - Add - Keep - Improve; Keep - Problem - Try), có nhiều tool (Bảng trắng, Parabol, Reetro, …) để thực hiện Retrospective. Bạn có thể chọn hình thức hoặc công cụ nào phù hợp với team của bạn, miễn sao cả team có thể đi sâu vào thảo luận để có những kế hoạch cải thiện hoạt động của team một cách rõ ràng.
Nếu có nhiều “actionable tasks” cần làm để cải thiện hoạt động của team (đặc biệt thời gian đầu thường có nhiều vấn đề) thì cần sắp xếp độ ưu tiên (về mức độ nghiêm trọng, về tần suất lặp lại) để giải quyết từng vấn đề một cách hiệu quả.
Kỹ năng problem-solving là rất quan trọng để điều phối hoạt động retro này (mình sẽ chia sẻ ở các bài viết tiếp theo).
Tổng kết
Scrum là framework được sử dụng phổ biến nhất trong các Agile Methodologies. Bài viết đã giới thiệu tổng quan về scrum, các vai trò, các khái niệm và các sự kiện trong scrum. Để bắt đầu áp dụng scrum, điều quan trọng nhất vẫn là tư duy agile, một scrum team hoạt động đúng với các kỹ thuật của scrum, mà không có tư duy agile, không “open to change” thì scrum sẽ biến thành một quy trình cứng nhắc, không mang lại hiệu quả. Không nhất thiết phải chuẩn bị đầy đủ các công cụ, có đầy đủ các vai trò trong scrum team, … để bắt đầu scrum, hãy thử - hiểu và thay đổi dần một cách agile.