Case Study Scrum Project tại Na Uy - Luận văn thạc sĩ khoa học máy tính

Nghiên cứu dự án Scrum tại Na Uy, phân tích phương pháp phát triển phần mềm Agile, quy trình Sprint Planning, Daily Stand-up và Product Backlog trong thực tế.

• Tác giả: Alf Børge Bjørdal Lervåg
• Người hướng dẫn: PTS. Eric Monteiro, IDI
• Trường học: Norwegian University of Science and Technology
• Chuyên ngành: Computer Science
• Đề tài: Nghiên cứu dự án Scrum tại Na Uy
• Loại tài liệu: Thesis
• Năm xuất bản: 2006
• Địa điểm: Trondheim

Tóm tắt

I. Cách nghiên cứu điển hình dự án Scrum thành công tại Na Uy

Nghiên cứu điển hình về một dự án Scrum tại Na Uy do Alf Børge Bjørdal thực hiện năm 2006 cung cấp cái nhìn sâu sắc về cách một nhóm phát triển phần mềm áp dụng Scrum framework giữa chừng dự án. Dự án này thuộc lĩnh vực kiểm soát phương tiện giao thông, thay thế quy trình thủ công bằng hệ thống điện tử tích hợp PDA, giao diện web và máy chủ trung tâm. Nhóm phát triển từ công ty tư vấn phần mềm (Company 2) đã chuyển sang sử dụng các thực hành từ Scrum methodology vào cuối năm 2005 nhằm cải thiện sự phối hợp khi đội ngũ mở rộng. Dù không áp dụng Scrum một cách nguyên bản, nhóm vẫn ghi nhận nhiều lợi ích như tăng sự tập trung, cấu trúc công việc rõ ràng và tinh thần làm việc tích cực. Nghiên cứu nhấn mạnh rằng Agile project management không nhất thiết phải tuân thủ máy móc, mà có thể được điều chỉnh linh hoạt dựa trên bối cảnh thực tế. Tài liệu gốc cho thấy các nhà phát triển cảm thấy hài lòng với phương pháp mới, đồng thời đề xuất một số cải tiến dựa trên nguyên tắc cốt lõi của Scrum. Đây là minh chứng cho thấy Scrum implementation có thể thành công ngay cả khi được áp dụng từng phần, miễn là vẫn giữ được tinh thần cốt lõi của Agile.

1.1. Bối cảnh và mục tiêu của dự án Scrum điển hình

Dự án được thực hiện cho một cơ quan quản lý giao thông lớn tại Na Uy (Company 1), với mục tiêu số hóa quy trình kiểm tra xe. Hệ thống mới bao gồm PDA để thu thập dữ liệu tại hiện trường, máy chủ lưu trữ và giao diện web để lên lịch. Trước khi áp dụng Scrum, dự án gặp nhiều thách thức về phối hợp do đội ngũ phát triển mở rộng từ 1 lên 6 người. Mục tiêu chính khi chuyển sang Scrum là cải thiện sự phối hợp và minh bạch trong tiến độ công việc.

1.2. Quá trình chuyển đổi sang Scrum framework

Nhóm phát triển không thực hiện đào tạo bài bản mà học hỏi từ kinh nghiệm của một nhóm khác trong công ty đã áp dụng Scrum thành công. Họ bắt đầu bằng việc chuyển danh sách công việc hiện có sang product backlog trên công cụ JIRA. Quá trình này diễn ra tự nhiên, không có sự can thiệp từ chuyên gia Scrum, cho thấy tính linh hoạt cao trong Agile transformation tại môi trường doanh nghiệp thực tế.

II. Thách thức và rào cản khi triển khai Scrum trong dự án thực tế

Mặc dù Scrum case study example từ Na Uy cho thấy nhiều điểm tích cực, việc triển khai Scrum methodology trong môi trường thực tế vẫn đối mặt với không ít thách thức. Một trong những rào cản lớn nhất là sự tham gia hạn chế của khách hàng. Trong nghiên cứu, Customer 1 – đại diện khách hàng – không tham dự Sprint planning do bận rộn, dù sẵn sàng hỗ trợ khi được yêu cầu. Điều này làm giảm hiệu quả của việc ưu tiên và xác nhận yêu cầu. Ngoài ra, nhóm phát triển không có Scrum master responsibilities được đào tạo bài bản; Developer 1 kiêm nhiệm vai trò này nhưng thiếu kiến thức chuyên sâu. Một vấn đề khác là cách hiểu sai lệch về product backlog: thay vì là danh sách yêu cầu chức năng từ phía khách hàng, nhóm lại sử dụng nó như danh sách công việc kỹ thuật, khiến khách hàng khó theo dõi và điều chỉnh ưu tiên. Đồng thời, việc thiếu Agile retrospective chính thức và Sprint review meeting đầy đủ làm giảm cơ hội cải tiến liên tục. Những thách thức này phản ánh thực trạng phổ biến trong nhiều tổ chức khi áp dụng Agile: thiếu cam kết từ khách hàng, hiểu sai khái niệm cốt lõi và thiếu hỗ trợ chuyên môn. Tuy nhiên, nghiên cứu cũng cho thấy nhóm vẫn duy trì được hiệu suất nhờ tinh thần tự quản và giao tiếp nội bộ hiệu quả.

2.1. Vai trò mờ nhạt của khách hàng trong Scrum implementation

Khách hàng không tham dự các cuộc họp quan trọng như Sprint Planning và Sprint Review, làm giảm tính minh bạch và khả năng phản hồi nhanh. Dù có kênh liên lạc trực tiếp, sự vắng mặt này cản trở việc xác nhận user stories và điều chỉnh product backlog một cách linh hoạt – yếu tố then chốt trong Agile project management.

2.2. Hiểu lầm về Scrum artifacts và Scrum team roles

Nhóm phát triển xem product backlog như danh sách công việc kỹ thuật thay vì yêu cầu từ khách hàng. Điều này khiến Scrum master responsibilities bị lu mờ và làm mất đi bản chất cộng tác giữa khách hàng và đội phát triển. Ngoài ra, vai trò Scrum Master không được phân định rõ ràng, ảnh hưởng đến việc loại bỏ impediments và duy trì quy trình Scrum đúng chuẩn.

III. Phương pháp tối ưu hóa quy trình Scrum dựa trên nghiên cứu thực tiễn

Dựa trên phân tích Scrum case study example, có thể đề xuất một số phương pháp tối ưu hóa quy trình Scrum phù hợp với bối cảnh doanh nghiệp. Trước hết, cần tổ chức đào tạo ngắn hạn về Scrum framework cho toàn đội, đặc biệt là về vai trò Scrum master responsibilities và cách xây dựng product backlog đúng chuẩn. Thứ hai, nên tách biệt rõ ràng Sprint review meeting và Agile retrospective: cuộc họp đầu tiên dành cho khách hàng để xác nhận giá trị đã tạo ra, cuộc họp thứ hai dành riêng cho đội để cải tiến quy trình. Điều này giúp tăng sự tham gia của khách hàng mà không làm quá tải nội dung. Thứ ba, cần chuẩn hóa cách viết user stories theo ngôn ngữ khách hàng, thay vì thuật ngữ kỹ thuật, để họ dễ dàng ưu tiên và theo dõi. Cuối cùng, nhóm nên sử dụng Scrum metrics như Burndown chart một cách nhất quán để đo lường hiệu suất và dự báo tiến độ. Trong nghiên cứu gốc, nhóm đã sử dụng Sprint Burndown Charts nhưng chưa khai thác hết tiềm năng dự báo. Việc áp dụng các cải tiến này không đòi hỏi thay đổi lớn, mà chỉ cần điều chỉnh nhỏ dựa trên nền tảng hiện có – phù hợp với tinh thần Agile: liên tục cải tiến, không theo khuôn mẫu cứng nhắc.

3.1. Đào tạo và nâng cao nhận thức về Scrum methodology

Việc thiếu kiến thức nền tảng khiến nhóm hiểu sai về Scrum artifacts và Scrum team roles. Một buổi workshop ngắn về nguyên tắc Scrum, đặc biệt nhấn mạnh vai trò của Scrum master và cách xây dựng product backlog, có thể giúp nhóm áp dụng đúng tinh thần Agile hơn.

3.2. Tối ưu hóa Daily stand up meetings và Sprint planning

Nhóm đã tổ chức Daily stand-up meetings đều đặn nhưng có thể cải thiện bằng cách tập trung hơn vào việc báo cáo impediments và giải pháp. Đối với Sprint planning, nên mời khách hàng tham dự phần đầu để xác nhận user stories, đảm bảo sự đồng thuận về mục tiêu Sprint.

IV. Kết quả và bài học thực tiễn từ nghiên cứu Scrum thành công

Nghiên cứu điển hình cho thấy Scrum success factors không chỉ nằm ở việc tuân thủ quy trình, mà còn ở khả năng thích nghi linh hoạt. Nhóm phát triển đã cải thiện đáng kể sự phối hợp và tinh thần làm việc sau khi áp dụng các thực hành Scrum, dù không đầy đủ. Khách hàng đánh giá cao kết quả và mô tả mối quan hệ hợp tác là "tuyệt vời". Điều này chứng minh rằng Agile project management có thể mang lại giá trị ngay cả khi được áp dụng từng phần. Một bài học quan trọng là Scrum challenges như thiếu sự tham gia của khách hàng có thể được bù đắp bằng giao tiếp nội bộ hiệu quả và tinh thần tự quản của đội. Ngoài ra, việc sử dụng Scrum metrics như Burndown chart giúp nhóm theo dõi tiến độ và điều chỉnh kịp thời. Tuy nhiên, nghiên cứu cũng chỉ ra rằng hiểu sai về product backlog có thể hạn chế khả năng ưu tiên linh hoạt – một điểm cần cải thiện trong các dự án tương lai. Tổng kết lại, thành công của dự án đến từ sự kết hợp giữa tinh thần Agile (cá nhân và tương tác, phản hồi thay đổi) và thực tiễn doanh nghiệp, thay vì tuân thủ máy móc Scrum framework.

4.1. Đo lường hiệu quả qua Scrum metrics và Burndown chart

Nhóm đã sử dụng Sprint Burndown Charts để theo dõi tiến độ hàng ngày. Dù chưa được phân tích sâu, biểu đồ này đã giúp nhóm phát hiện sớm nguy cơ trễ hạn và điều chỉnh khối lượng công việc, minh họa giá trị của Scrum metrics trong quản lý dự án Agile.

4.2. Phản hồi tích cực từ khách hàng và đội phát triển

Cả khách hàng và đội phát triển đều đánh giá cao phương pháp mới. Khách hàng cảm thấy được lắng nghe, còn đội ngũ cảm thấy có cấu trúc và mục tiêu rõ ràng hơn. Đây là minh chứng cho thấy Scrum success factors cốt lõi là sự hài lòng và minh bạch, không nhất thiết phải tuân thủ 100% quy trình gốc.

V. So sánh Scrum vs Kanban và hướng phát triển tương lai cho Agile

Nghiên cứu không trực tiếp đề cập đến Scrum vs Kanban, nhưng bối cảnh dự án – với yêu cầu thay đổi liên tục và đội ngũ ổn định – cho thấy Scrum là lựa chọn phù hợp hơn Kanban trong trường hợp này. Scrum in software development đặc biệt hiệu quả khi sản phẩm cần được phát hành theo chu kỳ cố định và có sự tham gia của khách hàng để xác nhận giá trị. Tuy nhiên, trong tương lai, khi dự án chuyển sang giai đoạn bảo trì, Kanban có thể trở thành lựa chọn tốt hơn nhờ tính linh hoạt cao và không giới hạn bởi Sprint. Hướng phát triển tiếp theo cho nhóm là tiếp tục tinh chỉnh Scrum implementation bằng cách áp dụng đầy đủ các sự kiện Scrum như Sprint review meeting và Agile retrospective. Đồng thời, cần xem xét tích hợp các thực hành kỹ thuật từ Extreme Programming (XP) như pair programming hoặc continuous integration để nâng cao chất lượng mã nguồn – điều mà Scrum methodology không đề cập chi tiết. Cuối cùng, việc chia sẻ kinh nghiệm thông qua các Scrum case study example sẽ góp phần lan tỏa văn hóa Agile trong tổ chức, tạo tiền đề cho Agile transformation sâu rộng hơn.

5.1. Khi nào nên chọn Scrum thay vì Kanban

Dự án có chu kỳ phát hành rõ ràng và cần sự phản hồi định kỳ từ khách hàng – điều kiện lý tưởng cho Scrum in software development. Ngược lại, Kanban phù hợp hơn cho các nhóm bảo trì hoặc hỗ trợ, nơi công việc đến liên tục và không theo chu kỳ cố định.

5.2. Tích hợp thực hành XP để bổ sung cho Scrum framework

Scrum tập trung vào quản lý dự án, trong khi XP cung cấp các kỹ thuật phát triển phần mềm. Việc kết hợp pair programming, test-driven development và continuous integration có thể giúp nhóm nâng cao chất lượng sản phẩm, đặc biệt khi dự án mở rộng quy mô.

Trích đoạn nội dung tài liệu

A Case Study of a Norwegian Scrum Project Alf Børge Bjørdal Lervåg Master of Science in Computer Science Submission date: June 2006 Supervisor: Eric Monteiro, IDI Norwegian University of Science and Technology Department of Computer and Information Science Problem Description Do a case study of an agile project in Norway. January 2006 Supervisor: Eric Monteiro, IDI Abstract In this paper I present a case study of a Norwegian development project where the development team adopted practices from Scrum in the middle of the development effort. My study shows that the developers were happy with this new development method, and among other things thought it gave them a better focus and structure for their work. Since the team only adopted practices from the Scrum method, I look at the differences between their method and Scrum and suggest a few im- provements to their method based on my knowledge of Scrum and development methods in general.

Preface I wanted to learn more about agile software development, and after a few talks with my teaching supervisor (Monteiro), we agreed to search for a live project I could use for a case study. Monteiro got me in contact with Torgeir Dingsøyr from SINTEF Department of Software Engineering, Safety and Security (SINTEF) who, despite his paternity leave, agreed to contact some of the companies he was involved with and ask if they could help me out. Since proximity would make the study easier, we tried to find companies that were located in Trondheim first, but in the end we had to broaden our search to include Oslo. Both Dingsøyr and I were searching for companies during this time, but neither of us found any good prospects.

Just when I was about to give up and study an open source software project in- stead, Dingsøyr contacted me and said he had found a project for me. After this things moved very fast. Two researchers at SINTEF combined the start of my study with the start of one of their own projects and booked a meeting with Leader 1 and Senior 2 from Company 2. This meeting was primarily for the researchers from SINTEF but it gave me a convenient entrance to Company 2.

Acknowledgements First of all I would like to thank Developer 1 for his quick and comprehensive replies to my questions during the last weeks before my deadline. Many thanks to my teaching supervisor, Eric Monteiro, for his advice and help with making this paper possible. Torgeir Dingsøyr, without whom I would not have had a project to study; Tore Dybå and Geir Kjetil Hanssen from SINTEF who let me piggyback on one of their own projects to give me a comfortable introduction to Company 1. I would like to thank Leader 1 who opened the doors for me, all the people I talked with at Company 1 and finally Customer 1 and the development team who treated me so well during the study.

I’m very grateful for the help from the people who read through the drafts of i my paper and gave me valueable feedback; Magni Onsøien, Eli Toftemo, Einar Ryeng, Mathiasm Lidal and Truls Tangstad. Thanks for pointing out my stupid errors without poking too much fun at me. ii Contents 1 Introduction 1 2 Development Methods 3 2.1 Definitions and Explanations .2 Iterative and Incremental .2 Sequential Development Methods .1 The Waterfall model .1 The Spiral model .4 Agile Development Methods .1 Why Base the Method on Scrum? .4 The Development Method .4 Priority-Assignment Meeting .5 Sprint Pre-Planning Meetings .6 Sprint Planning Meetings .3 Validity of my Research Data .4 Analysis of My Work .3 The Product Backlog .4 The Sprint Backlog .5 Sprint Planning Meeting .6 Daily Stand-up Meetings .2 Reasons for the differences .3 Sprint Planning Meetings .2 The Product Backlog .3 Meetings at the End of the Sprint .2 What Have I Learned from this Project? .1 The First Visit .3 Interview with Customer 1. 66 vi B Interview Guides 67 B.1 Developer Interview Guide .2 Customer Interview Guide.

68 vii List of Figures 2.1 Level of Formalism .2 The Waterfall Model .3 Boehms Cost of Change Curve .4 Boehms Spiral Model .5 Overview of the Scrum method.7 Project Burndown Chart .8 Sprint Burndown Charts. 23 viii Chapter 1 Introduction Do you know what agile software development is? Does it sound familiar? I suspect it does. Recently agile methods have become more and more popular. A search on google for “agile software development” gives 16 000 000 results.

What is often considered the opposite of agile is sequential software development. Just for fun, I did a search for this on google and it gives 10 600 000 results. While this doesn’t prove anything, it does indicate that agile software development has indeed become popular. How about Scrum? No, I’m not talking about rugby1 , I’m talking about the soft- ware development method.

Since google only gives 629 000 results when search- ing for “scrum software development” I guess you might not have heard of it. Neither had I before I started this project. Anyway, in Chapter 2 I give an introduction to these concepts so don’t worry if this was completely new to you. When we’re all on the same page regarding development methods, I tell the story of this little project and the people involved.

This is covered in Chapter 3. Here I look at how a small team of developers in Norway adopted parts of the Scrum method during their project. By choosing to adopt only what they felt was nec- essary and at their own pace, they are now exploiting some of the benefits of this 1 In case you’re not familiar with rugby, Scrum is the name of how a game begins 1 agile development method. In Chapter 4 I discuss some the research methods I have used to conduct this study.

Finally, in Chapter 5, I try to analyze the results in light of development theory and the books and articles I have read concerning how to best develop software. 2 Chapter 2 Development Methods A development method is commonly referred to as a collection of ideas and prac- tices for planning, designing and developing IT-systems. The word methodology and model is also sometimes used to describe the same thing, but since these dif- ferent terms cause more confusion than clarification I will avoid the term method- ology completely, and limit my use of the word model to where it is part of the name of the method I write about. McConnell says that any approach to programming constitutes a method no matter how unconscious or primitive the approach is [McC04, p657].

He adds that the point of most methods is to reduce communication problems (see Section 2. I start this chapter with a few definitions and explanations to avoid misunderstand- ings. Then I cover the sequential development methods, the incremental develop- ment methods and finally the agile development methods. For each of these I give one or two examples.

Finally I use an entire section on the Scrum method since this is the development method that was used in the project I studied.1 Definitions and Explanations In this chapter and the chapters that follows I will use a few terms that in some cases mean different things to different people. See for instance the first paragraph in this chapter for an example. To avoid misunderstandings I try to define the words and terms I use that I believe might cause problems.1 Formalism As the size of the development team increases, McConnell argues that the number of communication paths increases multiplicatively, proportionally to the square of the number of people [McC04, p650]. As the number of communication paths increases, so does the amount of time spent communicating and the risk of com- munication mistakes increases.

His conclusion is that larger-sized projects need a way to streamline communication or limit it in a sensible way. A typical approach for streamlining communication is to formalize the commu- nication in documents. Different development methods have different levels of formalism, as illustrated in Figure 2. Formalism is also dependant on the criticality of the project, as argued by Cock- burn [Coc02, p162].

If the consequence of a failure in the program will lead to injuries or death then the required level of formalism is higher than if the result is a few hours of lost work.1: Development methods have different levels of formalism. The Water- fall model (see Section 2.1) is very formal, while Evolutionary Prototyping (see Section 2.2) is very informal.2 Iterative and Incremental In the article Iterative and Incremental Development: A Brief History [LB03], Larman and Basili makes a very good summary of the history of Iterative and Incremental Development. Here they write that while some prefer to reserve the phrase iterative development merely for rework, it usually also implies evolution- ary advancement. Despite their definition I have decided to use the phrase iterative development for rework, and the phrase incremental development for evolutionary advancement since this makes it easier for me to separate between the concepts.2 Sequential Development Methods The Sequential Development methods are, as the name implies, methods that go through a set of phases sequentially until the software is complete and delivered.

These methods usually include, but are not limited to • Requirements Specification • Design • Code • Test • Release They have been very popular in some fields since they make it easier to write concrete contracts where the developers promise to deliver the product specified in the requirements specifications within a certain deadline. This makes it easier to make a budget for the project and the corporation feels safe because they have a binding contract promising a delivery. Most sequential methods assume that you can predict the requirements and design needs early in the development project, and that these do not change during the project life time. If this assumption is true, which is probably the case for some 5 but far from all projects, then it is obviously best to collect the requirements and plan a design that fits these requirements as early as possible.

However, experience has showed that it is very difficult, if not impossible, to make perfect predictions. Usually, one encounters issues and learn new things that make it necessary to redo or change the plans during development. Also, with sequential methods it is very difficult to exploit what the developers learn during development since the cost of changing the requirements and design is too high to allow anything but critical changes. There are several reports that show that sequential methods have a high risk of failure.

According to Larman and Basili [LB03], the Standish Groups “CHAOS: Charting the Seas of Information Technology” report [Joh99] that looked at 23 000 projects to determine failure factors shows that the top reason for failure was associated with “waterfall practices” (sequential development). Another study of a sample of the Department of Defences (DoD) software spendings in 1995 by Stanley J. Jarzombek [Jar99] shows that 75% of the projects failed or were never used. Note that DoD projects were expected to use a sequential development method at that time period.

Leisham and Cook [LC02] makes a convincing argument of how the process of gathering requirements needs to be iterative, since the chance of getting it right on the first try is minimal. Often the customer has preconceived notions that he considers obvious and therefore doesn’t mention on the first round, and what is said by the customer isn’t always what the developer hears. The result is that the requirements are wrong or incomplete and the resulting product does not deliver what is needed. Most sequential methods have a high level of formalism, usually in the form of separate documents for each phase of development.

Because of this they are some- times referred to as document driven or plan-driven methods.