“Năng suất không phải là tất cả, nhưng về lâu về dài thì nó hầu như là tất cả” – Paul Krugman – Nobel kinh tế 2008
Scrum là gì ?
Scrum phổ biến đến nỗi trước khi mình tưởng rằng Scrum chính là Agile, Agile chính là Scrum. Nhưng sau này mới biết Scrum chỉ là một trong hơn chục phương pháp chia sẻ các giá trị trong tuyên bố Agile.
Scrum là một khung làm việc (framework) “dễ hiểu nhưng khó tinh thông”.
Có rất nhiều hiểu lầm rằng Scrum là thần dược để giải quyết mọi cơn đau đầu của các tổ chức hay dự án, hay việc chỉ cần có Sprint Backlog, áp dụng các event của Scrum thì đã được gọi là Scrum. Không phải như thế, để sử dụng Scrum cần phải có một sự thay đổi sâu sắc về cách nghĩ cách làm chứ không phải áp dụng một số công cụ hay thực hiện một số sự kiện của Scrum.
Đặc điểm của Scrum
- Tổ chức công việc theo các chu trình ngắn ( Sprint )
- Khi nhóm làm việc trong Sprint, cấp quản lí không can thiệp ( nhóm được trao quyền tối đa ).
- Nhóm báo cáo trực tiếp cho khách hàng không phải cho quản lí.
- Nhóm ước tính thời gian để hoàn thành công việc.
- Nhóm quyết định khối lượng công việc để làm trong Sprint.
- Nhóm quyết định cách hoàn thành công việc trong Sprint.
- Nhóm tự đánh giá hiệu suất của mình.
- Xác định Sprint goal trước khi bắt đầu Sprint mới.
- Xác định mục tiêu thông qua các User Story.
- Loại bỏ các trở ngại một cách có hệ thống.
Ba trụ cột của Scrum
- Minh bạch (transparency): muốn thành công với Scrum, thông tin tới quá trình phát triển phải minh bạch và thông suốt. Các thông tin đó có thể: tầm nhìn (vision) về sản phẩm, yêu cầu khách hàng, tiến độ công việc, các khúc mắc và rào cản…Từ đó mọi người ở các vai trò khác nhau có đủ thông tin cần thiết để tiến hành các quyết định có giá trị để nâng cao hiệu quả công việc.
- Thanh tra (inspection): Công tác thanh tra liên tục các hoạt động trong Scrum đảm bảo cho việc phát lộ các vấn đề cũng như giải pháp để thông tin đa dạng và hữu ích đến được với các bên tham gia dự án. Truy xét kĩ càng và liên tục là cơ chế khởi đầu cho việc thích nghi và các cải tiến liên tục trong Scrum.
- Thích nghi (adaptation): Dựa trên các thông tin minh bạch hoá từ các quá trình thanh tra và làm việc, Scrum có thể phản hồi các thay đổi một cách tích cực, nhờ đó mang lại thành công cho dự án. Các nỗ lực minh bạch và thanh tra đều để hướng tới hành động thích ứng nhanh và hiệu quả.
Năm giá trị của Scrum
- Dũng cảm: Dũng cảm nói ra vấn đề của mình và chấp nhận rất nhiều rủi ro khi thay đổi cam kết.
- Tập trung: Tập trung vào công việc trong Sprint và Sprint goal của team.
- Cam kết: Mỗi thành viên cam kết với các thành viên khác về những điều mình làm và công việc đã được chọn ở buổi planning.
- Cởi mở: Mọi thứ cần phải rõ ràng, minh bạch để mọi người có thể làm việc hiệu quả.
- Tôn trọng: Khi thiếu tôn trọng, mọi người khó thành thật chia sẻ. Không có tôn trọng, khó có sự cởi mở.
Các vai trò trong Scrum
Có 3 vai trò trong Scrum:
- Product Owner: chịu trách nhiệm quản lí danh sách những yêu cầu công việc ( Product Backlog )
- ScrumMaster: chịu trách nhiệm tổ chức cách thức làm việc theo Scrum cho cả nhóm
- Development team: gồm những người có đủ chuyên môn để hoàn thành mục tiêu mà cả nhóm đề ra
Một mô tả tông quát về một Sprint
Sprint là một phân đoạn ngắn để tạo ra phần chức năng và tính năng hoàn chỉnh. Các sprint sẽ diễn ra nối tiếp nhau. Độ dài Sprint từ 1-4 tuần. Giữ độ dài Sprint không đổi để tạo nhịp cho team. Sprint càng ngắn, chi phí quản lí càng lớn, Sprint càng dài , càng khó giữ sự tập trung của team cũng như giảm khả năng linh hoạt với sự thay đổi. Mỗi Sprint đều có Sprint goal ( mục tiêu của Sprint ) và Sprint back log: tổng hợp các chức năng mà team cam kết hoàn thành trong sprint.
Ở đây mình sẽ lấy ví dụ là team mình đang thực hiện một Sprint như nào nhé:
Step 1: Product backlog sẽ được truyền thông tới team trước 1 hoặc 2 quý, cái này sẽ được xây dựng dựa trên OKR của tổ chức, Product Owner đồng thời thu thập thêm các nhu cầu từ stakeholder để đề ra road map cụ thể cho sản phầm và truyền thông đến team.
Step 2: Tùy vào sprint goal và danh sách tính năng cần cam kết với các stakeholder mà sprint sẽ được triển khai theo 2 tuần, hoặc 3 tuần(rất ít khi, thường thì những Sprint gần ngày nghỉ lễ 30/4, 2/9 nếu lẻ ra vài ngày thì team tính luôn nguồn lực những ngày đó vào), 4 tuần thì cũng có nhưng rất ít khi, trừ khi scope quá to không thể cắt nhỏ ra được nữa, hoặc một tính năng lớn cần bàn giao trong thời gian nhất định.
Step 3 : Grooming là 1 event trong Scrum, đây là một buổi overview về list các tính năng sẽ phát triển trong Sprint tiếp theo, buổi này sẽ đưa cho mọi người những thông tin cơ bản, docs requirement, design ( thường sẽ là unofficial nhưng cơ bản cũng đạt 80% rồi), mọi người cũng đã có thể bàn bạc sơ qua về solution tech, các risk, có thể đưa ra các ý kiến về việc tính năng này có thực sự nên làm hay không…. nếu có thể sau buổi này mỗi thành viên đã có thể break sub-task, est qua về thời gian phải bỏ ra để hoàn thành.
Step 4: Sau buổi họp grooming sẽ là buổi họp planning, ở buổi này cơ bản mọi thứ đều đã được thống nhất, mọi người sẽ dành cho việc estimate nguồn lực cho mỗi ticket, nếu có task nào vẫn cần bàn thêm thì sẽ hoàn thành nốt trong buổi này. Sau buổi này gần như scope đã được chốt, team sẽ hạn chế các sự thay đổi nào nữa về scope.
Ở buổi này cũng sẽ chốt sprint goal (tức là kiểu mục tiêu đạt được cuối cùng sau khi kết thúc sprint).
Step 5: Sau khi đã estimate xong những công việc cần làm và thời gian cần để hoàn thành, team sẽ cùng ngồi lại và xem có bị vượt quá effort của thành viên trong team không, nếu cần điều chỉnh thì ưu tiên cắt bỏ các scope không quan trọng, ưu tiên các scope quan trọng. Hoặc xem xét có thể mượn thêm nguồn lực của team khác sang để hỗ trợ hoàn thành công việc hay không.
Step 6: Sau khi mọi thứ ở trên đã diễn ra xong, thì việc tiến hành sprint bắt đầu, hằng ngày sẽ có daily meeting tối đa là 15p để cả nhóm cùng nhau báo cáo công việc của ngày hôm trước, thường mỗi người báo cáo sẽ theo format sau:
- Hôm qua đã làm những gì, xử lý những gì
- Có gặp issue, blocker gì không
- Hôm nay xử lý những gì
Trong một Sprint có một nguyên tắc đó là: không thay đổi yêu cầu sản phẩm trong suốt Sprint nếu một ai đó ( PO chẳng hạn ) yêu cầu thay đổi req thì team có quyền từ chối, SM sẽ đảm bảo PO không được yêu cầu thay đổi với team phát triển. Nhưng ngược lại nếu team phát triển phát hiện thiếu một công việc để hoàn thành mục tiêu ( ví dụ là bug critial ) thì có thể thêm vào.
Scrum master đảm bảo team phát triển tập trung làm việc mà không bị ai làm phiền.
Bước 7: Cuối mỗi sprint sẽ diễn ra buổi review, cả team ( có thể bao gồm các stake holder ) ngồi lại với nhau để thực hiện demo, review lại những thứ đã làm để đánh giá kết quả, tính năng đã làm được, có yêu cầu improve chỉnh sửa gì không.
Bước 8: Ngày golive tính năng thông thường là ngày cuối Sprint hoặc theo thời gian định kì đã cam kết với các bên team sẽ thực hiện deploy lên môi trường production, fix bug phát sinh nếu có, rollback nếu sản phẩm gặp lỗi không thể khắc phục ( thường sẽ rất ít để xảy ra trường hợp này vì team sẽ phải giải trình tại sao lại lọt bug ).
Trong thực tế vẫn có thể có những Sprint team sẽ không bàn giao tính năng gì cả, nhưng vẫn sẽ có những phản hồi với khách hàng vì sao lại thế.
Bước 9: Sau khi đã hoàn thành hết các đầu việc ở trên, Scrum event sẽ có một buổi retrospective ( có thể gộp luôn với buổi review ở bước 7 luôn cũng được nếu có nhiều thời gian ) ở buổi này team sẽ tìm câu trả lời cho 3 câu:
- Cái gì đã làm tốt trong Sprint vừa rồi
- Cái gì cần cải thiện trong Sprint tiếp theo
- Hành động cải thiện đó là gì
Nếu trong một Sprint có quá nhiều thứ cần sửa đổi, team sẽ vote chọn ra 3 thứ được ưu tiên nhất cần phải cải thiện để thực hiện, các việc còn lại sẽ lại dồn sang buổi retro tiếp theo bàn tiếp. Còn không thì cải thiện tuốt ok không hihi.
Team Agile của mình bao gồm những vị trí nào
- Scrum master: trước đây trong quá trình học hỏi áp dụng thì team có một người có kinh nghiệm đảm nhận vai trò này, nhưng hiện tại team đã được đánh giá là đủ trưởng thành và kinh nghiệm để tự handle, nên một thành viên trong team sẽ đứng ra đảm nhận kiêm nhiệm vị trí này.
- Product Owner: hay được gọi là PO, người này sẽ nhận những yêu cầu từ các khách hàng, stakeholder, người sử dụng sản phẩm cuối và biên dịch Business Requirement ( hiện tại vị trí này trong team mình mình cảm giác hơi thiên về BA hơn )
- Technical Owner: là kiến trúc sư trưởng cho hệ thống, người chịu trách nhiệm cao nhất về mặt coding, hệ thống, solution.
- Developer: chia ra thành các mảng Backend – Frontend ( web – mobile ): là các thợ code hihi
- QC: bao thầu đầu ra của sản phẩm, ngắn gọn là tìm bug bắt bug diệt bug.
Ngoài ra sẽ còn có một số team support về mặt hạ tầng hệ thống môi trường nữa nhé, để giúp team hoàn thành công việc.
Tổng kết
Vậy là ở bài hôm nay chúng ta đã cùng tìm hiểu sơ qua Scrum, đặc điểm cốt lõi của Scrum, một Scrum team hoạt động thế nào.