Scrum là một phương pháp Agile (phát triển phần mềm linh hoạt) dựa trên cơ chế lặp và tăng trưởng. Scrum được thiết kế để hỗ trợ việc phát triển, cung cấp và cải tiến các sản phẩm phức tạp.

Với Scrum, sản phẩm được xây dựng trong một chuỗi các quy trình lặp lại, có tên là vòng sprint. Qua đó, bạn có thể liên tục cải tiến sản phẩm, kỹ thuật, team (nhóm) và môi trường làm việc. Cũng nhờ vậy mà bạn có thể cung cấp giá trị cho khách hàng trong suốt quá trình phát triển.

Scrum là một khung tổ chức công việc (framework) dùng trong các dự án phát triển phần mềm với mục tiêu là chuyển giao các sản phẩm mới đều đặn, sau từ 1-4 tuần.

Scrum có phải là Agile?

Có thể nói, Scrum là một trong những cách tiếp cận phổ biến nhất hiện nay khi đội nhóm muốn ứng dụng agile vào công việc. 

Cần lưu ý rằng Scrum là khung làm việc, còn Agile là mindset. Agile mindset là tư tưởng, tư duy làm việc. Triết lý agile chỉ đề cập đến 4 giá trị và 12 nguyên tắc định hướng giúp phát triển phần mềm một cách linh hoạt, nhanh chóng đưa ra thị trường, chứ không chỉ rõ cụ thể ta nên làm như thế nào khi ứng dụng vào đội nhóm. 

Các trụ cột của Scrum

Scrum được xây dựng dựa trên những lý thuyết về quy trình thực tế. Những lý thuyết này dựa trên 3 trụ cột.

Minh bạch (transparency)

Trong Scrum đề ra các sự kiện họp như Sprint Planning, Sprint Review, Sprint Retrospective, daily meeting để giúp tăng cường sự tương tác và trao đổi thông tin giữa các thành viên làm việc. 

Khía cạnh minh bạch này cũng liên quan mật thiết tới 2 trụ cột còn lại. Sẽ rất khó để có thể thanh tra nếu công việc, quy trình không hiển lộ ra cho người khác biết. Và cũng sẽ rất khó để kịp thời, nhanh chóng điều chỉnh kế hoạch nếu bị thiếu thông tin, hoặc nhiễu loạn thông tin.

Ví dụ: Daily meeting là lúc để các thành viên trao đổi, tương tác với nhau về công việc, về sản phẩm đang thực hiện. Đồng thời nhìn vào những công cụ trình bày, như Kanban board, thể hiện rõ quy trình, trạng thái của luồng việc sẽ giúp cả độ phát triển và Product Owner hiểu nhau hơn, đồng thời có thể nhanh chóng xử lý các vấn đề vướng mắc hoặc chưa được làm rõ. 

Thanh tra (inspection)

Để đảm bảo chất lượng cho sản phẩm, tránh những sự sai khác quá lớn về sản phẩm làm ra thực tế so với sản phẩm mong muốn ban đầu, chúng ta cần phải thanh tra những thứ được tạo ra một cách thường xuyên, định kỳ. 

Sự thanh tra được thực hiện ở một thời điểm nhất định, chứ không nên xen ngang vào giữa chừng. 

Ví dụ: Các thành viên đội phát triển cùng với Product Owner tham gia Sprint Review, Sprint Retrospective. Đây là các hoạt động thể hiện tính chất thanh tra. Khi ấy họ sẽ thanh tra chính sản phẩm chuyển giao, và các quy trình phát triển sản phẩm.

Thích nghi (adaptation)

Khi có sự chệch hướng so với Product Roadmap, hoặc do nhu cầu thị trường thay đổi, sản phẩm và quy trình cũng cần được điều chỉnh nhanh chóng để thích nghi với những thay đổi này. 

Ví dụ: Đội phát triển cần thích ứng sản phẩm của mình vào cuối mỗi Sprint, để phù hợp với lộ trình phát triển sản phẩm, với yêu cầu của Product Owner, hay của các Stakeholders

Các giá trị của Scrum

Dũng cảm – Courage

Dũng cảm là một giá trị rất quan trọng mà các thành viên team Scrum cần hướng tới. Đội Scrum hay development team cần phải cảm thấy an toàn để nêu ra ý kiến của mình, để nói không khi cần, và thử nghiệm những điều mới mẻ.

Đội phát triển cũng cần sự dũng cảm để thách thức những mô thức cũ, cản trở con đường đạt được mục tiêu. 

Tập trung – Focus

Scrum coi trọng sự tập trung vào ít thứ. Nghĩa là bắt đầu một thứ và kết thúc nó, hạn chế số lượng công việc đang diễn ra cùng lúc, hạn chế số việc ở trạng thái Doing (limit WIP)

Cam kết – Commitment 

Các thành viên của team làm việc Scrum cần phải có sự cam kết với các mục tiêu của đội nhóm. Họ là người lựa chọn sẽ thực hiện điều gì, và gắn chặt với những điều mình chọn. 

Như bạn đã biết, lõi của Scrum là Sprint. Mỗi Sprint đều cần có những mục tiêu rõ ràng trong 1 timebox (từ 1-4 tuần). Đội phát triển có thể chia nhỏ mục tiêu thành các phần có thể xử lý được và bắt tay vào thực hiện công việc.

Các thành viên cần đánh giá tính thực tế của các mục tiêu đưa để thống nhất các công việc cần hoàn thành cho phù hợp để họ giữ được cam kết với những thứ mình mong muốn chuyển giao.

Tôn trọng – Respect

Các thành viên trong Scrum team hay đội phát triển cần thể hiện sự tôn trọng lẫn nhau, tôn trọng Product Owner và các bên liên quan (Stakeholders), cũng như Scrum Master. 

Các đội nhóm sống với tinh thần Agile cần biết rằng sức mạnh để đạt được mục tiêu nằm ở trí tuệ tập thể, ở cách thức họ cộng tác ăn ý với nhau. Mỗi cá nhân đều có đóng góp nhất định vào mục tiêu của Sprint. Vì vậy, họ cần tôn trọng ý kiến của nhau, ghi nhận nỗ lực của nhau, thậm chí chấp nhận sự không hoàn hảo của các thành viên.

Cởi mở – Openness

Đội phát triển cần không ngừng tìm kiếm những ý tưởng mới, những cơ hội mới để học hỏi. Một đội nhóm agile cũng cần thành thật với nhau khi cần sự giúp đỡ. 

Các công cụ của Scrum

Product backlog

Product backlog là một danh mục các công việc cần hoàn thành, được quản lý bởi Product Owner hoặc Product Manager. 

Danh mục này là một danh sách các tính năng, yêu cầu, nâng cấp hoặc lỗi là đầu vào cho Sprint backlog. Bản chất của Product Backlog là to-do list.

Do những công việc trong Product Backlog có thể bị thay đổi do yêu cầu của khách hàng thay đổi, nhu cầu thị trường thay đổi nên nó cần Product Owner thường xuyên chăm nom, sắp xếp thứ tự ưu tiên và quản lý, duy trì.

Sprint backlog

Sprint backlog là một danh sách các đầu việc, hoặc user story, bug được lựa chọn bởi development team (đội phát triển), mang vào để triển khai trong 1 Sprint. Trước mỗi Sprint, đội phát triển sẽ có buổi họp Sprint Planning để lựa chọn sẽ thực hiện các đầu việc nào từ Product Backlog.  

Sprint Backlog có thể linh hoạt và tiến hóa trong 1 Sprint. Tuy nhiên những mục tiêu cơ bản Sprint goal – điều mà team muốn đạt được trong Sprint đó thì không thể nhượng bộ. 

Increment (Sprint Goal)

Ở Magestore, chúng mình sẽ chuyển giao increment – phần tăng trưởng của sản phẩm vào cuối mỗi tuần cho người dùng.

Sprint của chúng mình được cả công ty ấn định là kéo dài 1 tuần. Và cứ đến sáng thứ 2 của tuần mới, các team sẽ cùng minh họa và giới thiệu các sản phẩm này tới toàn công ty để mọi người cùng hiểu được các team khác đang có bước tiến như thế nào trong sự phát triển của toàn công ty. 

Burndown chart

Burndown chart là biểu đồ thể hiện lượng công việc còn lại tới khi hoàn thành. Nó thể hiện tốc độ team của bạn “đốt cháy” các công việc để tiến tới mục tiêu như thế nào. 

Trục dọc thường là lượng công việc, trục ngang là ngày hoặc Sprint.  

Nhìn vào Product Burndown chart qua các Sprint tuần tự, bạn cũng sẽ thấy nhịp độ chuyển giao công việc của team.

Sẽ không có 1 đường thẳng tắp từ trên xuống dưới vì đội nhóm nào cũng sẽ gặp những biến cố hoặc trắc trở hoặc thuận lợi khác nhau khiến cho nhịp độ chuyển giao lên xuống dao động qua từng Sprint. Nhưng nhìn vào biểu đồ, bạn cũng sẽ có cái nhìn tổng quan hơn về tiến trình thực hiện product backlog hoặc project. 

Các vai trò trong đội nhóm sử dụng Scrum

Product Owner

Product Owner là người chịu trách nhiệm về thành công của dự án, hoặc của sản phẩm. Họ sẽ tập trung vào khía cạnh business (kinh doanh), khía cạnh khách hàng và nhu cầu của thị trường, sau đó thiết lập các ưu tiên cho công việc để đội phát triển tiến hành. 

Một Product Owner hiệu quả là người:

• Xây dựng và quản lý tốt product backlog
• Có mối quan hệ chặt chẽ về phía doanh nghiệp và đội phát triển, đảm bảo rằng tất cả 2 bên cùng hiểu các hạng mục công việc trong Product Backlog. 
• Đưa ra những định hướng rõ ràng cho đội phát triển về các tính năng sẽ chuyển giao
• Quyết định khi nào sẽ chuyển giao sản phẩm và với chu kỳ chuyển giao như thế nào. 

Scrum Master

Scrum Master là người am hiểu rõ về Scrum trong đội phát triển. Họ sẽ coach team, Product Owners và các bên liên quan khi những người này tham gia vào quy trình Scrum.

Một Scrum Master có năng lực là người hiểu các công việc được thực hiện bởi đội phát triển và giúp đội này tối ưu hóa sự minh bạch và hiệu suất chuyển giao. Anh ấy/cô ấy giữ vai trò người điều phối (facilitator), tập hợp các nguồn lực cần thiết (cả về nhân sự lẫn trang thiết bị, logistics…) cho các buổi họp Sprint Planning, Stand-up, Sprint Review, Sprint Retrospective.

Development Team (BA, Developer, Tester…)

Đội phát triển chính là những người thực hiện xây dựng sản phẩm, hoàn thành những thứ cần được chuyển giao tới khách hàng. 

Một đội phát triển hiệu quả bao gồm các thành viên có mối quan hệ thân thiết với nhau, ngồi gần nhau trong cùng 1 không gian (co-located) và thường có từ 5-7 thành viên. 

Một trong những quy tắc để xác định số lượng thành viên cho đội phát triển, dựa trên câu nói nổi tiếng của Jeff Bezos, CEO Amazon: “Một team chỉ nên đủ nhỏ để ăn chung 2 chiếc bánh pizza.” – (8 miếng bánh-> tối đa 8 người)

Đội phát triển này nên là một cross-function team, gồm những người có nhóm kỹ năng khác nhau (skill set), để có thể training lẫn nhau, nhờ đó không ai trở thành nút thắt trong luồng chảy công việc. 

Đồng thời, đội này cùng cần là một đội tự tổ chức (self-organizing team). Họ được trao quyền để lựa chọn sẽ giải quyết các bài toán được đề ra như thế nào. Họ cũng là những người sẽ dự tính khối lượng công việc mà họ có thể hoàn thành được trong Sprint và cam kết với chúng. 

Scrum diễn ra như thế nào?

Tổ chức backlog (hay còn được gọi là backlog grooming)

Đây thường là trách nhiệm của Product Owner. PO là người định hướng sản phẩm tới tầm nhìn đã đưa ra. PO cũng cần có sự nhanh nhạy về mặt thị trường, về khách hàng để thay đổi lộ trình phát triển sản phẩm khi cần. 

PO đồng thời sẽ là cầu nối giữa người dùng và khách hàng với đội phát triển. PO sẽ tiếp nhận ý kiến phản hồi từ cả 2 phía để tạo nên một danh mục các công việc sẵn sàng cho việc triển khai trong thời gian tiếp theo.

Sprint Planning (Họp kế hoạch Sprint)

Đây là cuộc họp lên kế hoạch, đặt mục tiêu cho Sprint của đội phát triển. Các user story cụ thể sẽ được thêm vào Sprint backlog từ Product backlog. Các user story cần được các thành viên đồng thuận với nhau rằng là khả thi để thực hiện trong Sprint này. 

Cuối buổi họp Sprint Planning, đội phát triển cần rõ với nhau về những gì sẽ cần được chuyển giao trong Sprint, và các phần tăng trưởng sản phẩm sẽ chuyển giao sẽ trông như thế nào. 

Diễn biến trong Sprint

Một Sprint kéo dài ít nhất là 1 tuần, nhiều nhất là 4 tuần. Đây là khoảng thời gian đội phát triển làm việc, phối hợp với nhau để hoàn thành phần tăng trưởng sản phẩm (increment). 

Trong khoảng thời gian này, phạm vi công việc của Sprint có thể được Product Owner và đội phát triển (development team) mang ra thương lượng, nếu thấy cần thiết. 

Tất cả các sự kiện từ Planning cho đến Retrospective đều diễn ra trong phạm vi 1 Sprint. 

Thời lượng của 1 Sprint nên được giữ vững trong một khoảng thời gian phát triển sản phẩm, điều này giúp cho đội phát triển học được từ các trải nghiệm trong quá khứ và áp dụng chúng vào các Sprint trong tương lai. 

Daily meeting (Daily Scrum)

Đây là các buổi họp cực ngắn, tổ chức vào một khung giờ cố định, hàng ngày. Các thành viên tham gia trả lời 3 câu hỏi: Hôm qua làm gì? Hôm nay sẽ làm gì? Khó khăn, trở ngại đang gặp phải là gì? 

Cuộc họp này chỉ nên giới hạn trong 15 đến 30 phút. Mục đích là để kiểm tra tiến độ hoàn thành sprint goal và điều chỉnh sprint backlog nếu cần thiết. Ngoài ra, các buổi daily Scrum còn phải đưa ra được kế hoạch làm việc cho 24 giờ tiếp theo.

Sprint Review (Họp sơ kết Sprint)

Cuối mỗi Sprint, team sẽ tụ họp với nhau trong một buổi để demo increment – phần tăng trưởng sản phẩm. Team cũng sẽ chỉ ra những hạng mục công việc đã hoàn thành, và đón nhận góp ý từ product owner. 

Product Owner sẽ là người quyết định có phát hành phần tăng trưởng sản phẩm này hay không.
Sprint Review cũng là lúc để Product Owner nhìn lại vào Product Backlog sau khi Sprint vừa diễn ra, đưa ra những dự định cho Sprint tiếp theo. 

Sprint Retrospective (Họp Cải tiến Sprint)

Retrospective là cuộc họp để đội phát triển cùng ngồi lại với nhau và trao đổi về những gì đã diễn ra thuận lợi, những gì chưa tốt trong Sprint.  Đó có thể là về quy trình, về con người, về công cụ, thậm chí về chính các sự kiện họp diễn ra trong Sprint. 

Mục đích của Retrospective là tạo ra không gian và cơ hội để các thành viên reflect, tìm ra các cải tiến cho Sprint tiếp theo.

Kết luận

Đối với doanh nghiệp nói chung, ứng dụng Scrum có thể giúp doanh nghiệp đẩy nhanh tốc độ phát hành sản phẩm ra thị trường, tăng năng suất làm việc của nhân sự hay mang lại sự hài lòng cho khách hàng.

Tuy nhiên, càng ứng dụng Scrum, bạn sẽ thấy rằng sẽ cần thời gian để thành thạo Scrum. Các khái niệm về phân đoạn nhỏ như Sprint, các cuộc họp daily meeting, Sprint Review và các thực hành của Scrum master có thể là thách thức với nhiều team mới. 

Tham khảo: https://anhtester.com/blog/scrum-la-gi-tong-quan-ve-mo-hinh-scrum-b428.html