1. Scrum là gì?

Scrum là 1 dạng của mô hình Agile và là framework phổ biến nhất khi thực hiện mô hình Agile. Scrum là mô hình phát triển phần mềm lặp đi lặp lại. Những khoảng lặp cố định, thường kéo dài 1, 2 tuần được gọi là sprint. Cuối mỗi sprint, các stakeholder và team member sẽ cùng ngồi lại với nhau và lên kế hoạch cho giai đoạn tiếp theo.

Scrum quy định những roles, trách nhiệm và những loại meeting cố định. Ví du, scrum quy quy định các công đoạn của từng sprint cần bao gồm Sprint planning, daiy stand-up, sprint demo và tổng kêt sprint. Trong suốt mỗi sprint, team sử dụng các công cụ như task board hay burndown charts để nhìn tiến độ, và nhận các phản hồi.

Jeff Sutherland đưa ra quy trình Scrum và năm 1993, lấy tên là Scrum dựa và những điểm tương đồng với nguyên cứu của Takeuchi và Nonaka năm 1986 tại Harvard Business Review. Trong nghiên cứu của mình, Takeuchi và Nonaka đã so sánh những team có hiệu suất cao với team Scrum là Rugby. Bối cảnh đầu tiên cho khái niệm này là ngành sản xuất, nhưng Sutherland, cùng với John Scumniotales và Jeff McKenna đã áp dụng mô hình này cho phát triển phần mềm.

2. Ưu điểm của Scrum

Scrum là 1 framework quy định chặt chẽ với các roles và những quy cách nhất định. Mặc dù có thể có nhiều điểm cần phải học, nhưng những quy định này có rất nhiều lợi ích.
Các ưu điểm của Scrum được liệt kê như dưới:

Tình trạng dự án được thể hiện rõ ràng: Với việc thực hiện họp hàng ngày, thường là đứng họp, cả team sẽ biết được ai đang làm gì, tránh được những hiểu nhầm, sự không rõ ràng. Các vấn đề trong dự án được chỉ ra hàng ngày và team có thể giải quyết trước khi chúng trở nên nghiêm trọng.

Tăng tính trách nhiệm của cả team: Sẽ không có 1 PM chỉ ra team scram cần làm gì, khi nào. Thay vào đó, team sẽ tập hợp và quyết định những công việc cả team sẽ hoàn thành trong mỗi sprint. Các thành viên làm việc và hỗ trợ lẫn nhau, tăng sự hợp tác và tạo động lực để mỗi thành viên trong team làm việc độc lập.

Dễ dàng thích ứng với các thay đổi: Với những sprint ngắn và phản hồi tức thì từ các bên, sẽ dễ dàng hơn để xử lý các thay đổi. Ví dụ, nếu team tìm ra 1 user story mới trong 1 sprint, họ có thể dễ dàng thêm chức năng này và sprint tiếp theo trong backlog refinement meeting (cuộc họp để đưa ra và sàng lọc các yêu cầu tồn đọng chưa giải quyết)

Tiết kiệm chi phí: Communication thường xuyên và ngay lập tức đảm bảo được team nhận thức tất cả các vấn đề, thay đổi sớm khi phát sinh, giúp giảm chi phí và tăng chất lượng công việc.
Increased cost savings: Constant communication ensures the team is aware of all issues and changes as soon as they arise, helping to lower expenses and increase quality. Bằng cách coding và test các nhóm chức năng nhỏ, team sẽ nhận được những phản hồi liên tiếp và những lỗi có thể được sửa sớm hơn, trước khi chúng trở nên rất tốn chi phí để sửa lại.

3. Nhược điểm của Scrum

Tuy có nhiềm điểm tốt khi áp dụng scrum, song mô hình này cũng có 1 số nhược điểm. Scrum đòi hỏi team cần có kinh nghiệm, trình độ cao và commitment cao. Dự án cũng có risk về việc không kiểm soát được scope phát triển.

Nhược điểm của Scrum có thể được liệt kê như dưới:

Không kiểm soát được scope phát triển: Nhiều dự án Scrum gặp phải vấn đề này do thiếu thống nhất về ngày kết thúc dự án. Vì không có ngày hoàn thành dự án, khách hàng hay các bên có thể sẽ không dừng việc add thêm nhiều chức năng mới.

Team cần có kinh nghiệm, trình độ cao và commitment cao: Với những role và trách nhiệm cố định, cả team cần phải quen thuộc với những quy định của Scrum. Vì trong team Scrum, không có role chuyên biệt, nên các thành viên trong team đều cần có kinh nghiệm kỹ thuật. Cả team cần cam kết tham gia Scrum meeting hàng ngày, và ở trong team suốt cả dự án.

Scrum Master không thích hợp có thể làm hỏng mọi thứ: Scrum Master rất khác với PM. Về căn bản Scrum Master phải là người có quyền cao hơn team, người này cần tin tưởng team mà họ quản lý và không bao giờ chỉ đạo team cần làm gì. Nếu Scrum Master cố gắng kiểm soát team, dự án sẽ thất bại.

Việc define task không rõ ràng sẽ dẫn đến sự thiếu chính xác: Chi phí dự án và timelineness của dự án sẽ không chĩnh xác nếu các task không được xác định rõ ràng. Nếu mục tiêu ban đầu của dự án không rõ ràng, việc plan sẽ trở nên khó khăn và các sprint có thể sẽ tốn nhiều thời gian hơn dự tính ban đầu.

4. Các vai trò trong Scrum

Có 3 vài trì chính trong mô hình Scrum:

Product Owner: Đây là người biết rõ về việc dự án sẽ tạo ra sản phẩm gì và truyền đạt lại cho team. Product Owner chủ yếu chú trọng và những yêu cầu về nghiệp vụ và thị trường, phân loại công việc cần làm. Người này sẽ xây dựng và quản lý product backlog (những yêu cầu tồn đọng của dự án), hướng dẫn về việc những chức năng nào cần được xử lý tiếp theo, và làm việc với team, cũng nhưng các stakeholder để đảm bảo các bên hiểu được những nội dung trong product backlog. Product Owner không phải là PM. Thay vì quản lý tiến độ và tình trạng dự án, công việc của project owner là tăng động lực của team để hướng đến mục tiêu cuối của dự án.

Scrum Master: thường được cho là người hướng dẫn của team, Scrum Master hỗ trợ team làm tốt nhất công việc của họ. Người này tổ chức các meeting, xử lý các vấn đề, và làm việc với Product Owner để đảm bảo product backlog sẵn sàng cho sprint tiếp theo. Scrum Master cũng cần đảm bảo team đang thực hiện đúng theo quy trình Scrum. Tuy không có quyền hơn các member khác, nhưng người này lại có quyền với quy trình dự án. Ví dụ, Scrum Master không thể bảo mọi người làm gì, nhưng có thể đưa ra những đề xuất về thời gian của 1 sprint.

Scrum Team: Scrum Team thường gồm có 5 hay 7 thành viên. Mọi người làm việc và hỗ trợ lẫn nhau. Không giống như các team truyền thống, không có những vai trò chuyên biệt như programmer, designer hay tester. Mọi người cần hoàn thiện tất cả các công việc cùng lúc. Scrum team đảm nhiệm việc lên kế hoạch cho mỗi sprint, họ quyết định bao nhiêu công việc họ có thể hoàn thành trong mỗi sprint.

5. Các Step trong quy trình Scrum

Có những step nhất định và không đổi trong quy trình Scrum như dưới:

Product backlog: Product Owner và Scrum Team họp để phân loại mức độ ưu tiên cho những nội dung trong product backlog (Những công việc trong product backlog đến từ user stories và các yêu cầu). product backlog không phải là list các công việc cần hoàn thành mà nó giống như 1 list các chức năng mong muốn của 1 sản phẩm. Team phát triển sau đó sẽ đưa ra các công việc dựa trên product backlog để hoàn thành trong mỗi sprint.

Sprint planning: Trước mỗi sprint, Product Owner sẽ đưa ra những nội dung ưu tiên trong project backlog. Team sẽ lựa chọn công việc nào họ có thể hoàn thành trong sprint đó, và đưa những công việc này từ product backlog sang sprint backlog (List những task cần hoàn thiện trong sprint).

Backlog refinement/grooming: Vào giai đoạn của của 1 sprint, team và Product Owner tổ chức họp để đảm bảo nội dung backlog cho sprint tiếp theo. Team có thể bỏ đi những user story không liên quan, tạo story mới, đánh giá độ ưu tiên của các story hoặc chi user story thành những task nhỏ hơn. Mục tiêu của công đoạn “chải chuốt” này là để đảm bảo backlog chỉ bao gồm những nội dung liên quan và chi tiết đúng với mục tiêu của dự án.

Daily Scrum meetings: Họp hàng ngày là cuộc họp ngắn, kéo dài 15 phút và thường là họp đứng. Trong meeting, member sẽ nói về mục tiêu và những vấn đề họ gặp phải. Scrum meeting được tổ chức hàng ngày trong suốt sprint, đảm bảo team đang trong tầm kiểm soát.

Sprint review meeting: Khi kết thúc mỗi sprint, team sẽ trình bày về công việc họ đã hoàn thiện trong cuộc họp này.Cuôc họp này nên có demo, chứ không phải là 1 báo cáo thuyết trình PowerPoint.

Sprint retrospective meeting: Cũng ở giai đoạn kết thúc mỗi sprint, team sẽ phản ánh những điểm tốt khi thực hiện scrum và nói về những điểm cần thay đổi cho sprint tiếp theo. Team cũng có thể nói về những điểm tốt, những điểm chưa tốt, cũng những những điều họ có thể làm khác đi trong suốt mỗi sprint.

6. Tools, Artifacts, and Methods in Scrum

In addition to roles and ceremonies, Scrum projects also include certain tools and artifacts. For example, the team uses a Scrum board to visualize the backlog or a burndown chart to show outstanding work. The most common artifacts and methods are:

Scrum board: You can visualize your sprint backlog with a Scrum task board. The board can have different forms; it traditionally involves index cards, Post-It notes, or a whiteboard. The Scrum board is usually divided into three categories: to do, work in progress, and done. The Scrum Team needs to update the board throughout the entire sprint. For example, if someone comes up with a new task, she would write a new card and put it in the appropriate column.

User stories: A user story describes a software feature from the customer’s perspective. It includes the type of user, what they want, and why they want it. These short stories follow a similar structure: as a <type of user>, I want to

so that I can <achieve some goal.> The development team uses these stories to create code that will meet the requirements of the stories.

Burndown chart: A burndown chart represents all outstanding work. The backlog is usually on the vertical axis, with time along the horizontal axis. The work remaining can be represented by story points, ideal days, team days, or other metrics. A burndown chart can warn the team if things aren’t going according to plan and helps to show the impact of decisions.

Large-Scale Scrum (LeSS): If you want to scale elements of Scrum to hundreds of developers, the Large-Scale Scrum (LeSS) framework helps extend the rules and guidelines without losing the core of Scrum. The principles are taken directly from Scrum, however focuses on scaling up without adding additional overhead (like adding more roles, artifacts, or processes).

Timeboxing: A timebox is a set period of time during which a team works towards completing a goal. Instead of letting a team work until the goal is reached, the timebox approach stops work when the time limit is reached. Time-boxed iterations are often used in Scrum and Extreme Programming.

Icebox: Any user stories that are recorded but not moved to development are stored in the icebox.
The term “icebox” was created by Pivotal Tracker, an Agile project management tool.

Scrum vs RUP: While both Scrum and Rational Unified Process (RUP) follow the Agile framework, RUP involves more formal definition of scope, major milestones, and specific dates (Scrum uses a project backlog instead of scope). In addition, RUP involves four major phases of the project lifecycle (inception, elaboration, construction, and transition), whereas Scrum dictates that the whole “traditional lifecycle” fits into one iteration.

Lean vs Scrum: Scrum is a software development framework, while Lean helps optimize that process. Scrum’s primary goal is on the people, while Lean focuses on the process. They are both considered Agile techniques, however Lean introduces two major concepts: eliminating waste and improving flow.

※Source

https://www.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban

Rate this post

Waterfall vs Agile vs Scrum – Part 3: Scrum là gì?

Other posts