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ô.

Nội dung chính

Tổng quan nghiên cứu

Theo báo cáo CHAOS của tổ chức Standish Group khi khảo sát trên 23.000 dự án công nghệ thông tin, mô hình phát triển tuần tự truyền thống là nguyên nhân hàng đầu dẫn đến sự thất bại của các dự án phần mềm. Đồng thời, một phân tích của Bộ Quốc phòng Hoa Kỳ vào năm 1995 cũng ghi nhận có tới 75% dự án phần mềm bị thất bại hoặc không bao giờ được đưa vào sử dụng thực tế do áp dụng quy trình phát triển cứng nhắc. Vấn đề cốt lõi mà luận văn giải quyết là việc chuyển đổi và vận dụng linh hoạt phương pháp phát triển Agile/Scrum ngay giữa vòng đời của một dự án công nghệ thông tin thực tế đang gặp khó khăn về kiểm soát quy trình.

Mục tiêu cụ thể của đề tài là phân tích thực nghiệm trường hợp một đội ngũ kỹ sư phần mềm tại Na Uy tiếp nhận các thực hành Scrum nhằm tối ưu hóa sự phối hợp nội bộ, đối chiếu sự khác biệt giữa mô hình áp dụng thực tế với lý thuyết chuẩn mực của Ken Schwaber, và đề xuất các giải pháp hoàn thiện quy trình phát triển.

Phạm vi nghiên cứu tập trung vào dự án số hóa hệ thống kiểm định phương tiện giao thông đường bộ tại Na Uy từ năm 2002 đến năm 2006, với giai đoạn chuyển đổi phương pháp luận diễn ra từ cuối năm 2005 đến tháng 5 năm 2006 tại hai thành phố Trondheim và Oslo.

Ý nghĩa của nghiên cứu thể hiện qua việc cung cấp bằng chứng thực nghiệm về quá trình mở rộng quy mô nhóm phát triển từ 1 lên 6 lập trình viên, rút ngắn chu kỳ bàn giao xuống các phân đoạn 2 tuần và đạt mức độ hài lòng tuyệt đối từ phía đối tác khách hàng mà không làm gián đoạn tiến độ chung của toàn bộ hệ thống.

Cơ sở lý thuyết và phương pháp nghiên cứu

Khung lý thuyết áp dụng

Nghiên cứu được xây dựng trên nền tảng so sánh đối chiếu giữa các hệ hình phát triển phần mềm tuần tự và linh hoạt. Khung lý thuyết bao gồm:

Mô hình Thác nước (Waterfall Model) do Winston Royce đề xuất năm 1970 kết hợp với Đường cong chi phí thay đổi (Cost of Change Curve) của Barry Boehm năm 1981. Lý thuyết này chỉ ra rằng trong phương pháp tuần tự, chi phí sửa chữa lỗi và thay đổi yêu cầu gia tăng theo cấp số nhân ở các giai đoạn cuối của dự án.

Mô hình Xoắn ốc (Spiral Model) của Boehm năm 1988 và phương pháp Tạo mẫu tiến hóa (Evolutionary Prototyping) do Tom Gilb khởi xướng năm 1976. Các mô hình này nhấn mạnh việc phân tích rủi ro và chuyển giao từng phần gia tăng nhằm thu thập phản hồi thực tế từ người dùng sớm nhất có thể.

Tuyên ngôn Agile năm 2001 và Khung quản trị dự án Scrum do Ken Schwaber phát triển năm 2003. Khung lý thuyết tập trung vào tính tương tác giữa con người, khả năng thích ứng với thay đổi và chuyển giao phần mềm chạy tốt qua các chu kỳ lặp ngắn.

Năm khái niệm cốt lõi được vận dụng xuyên suốt luận văn gồm:

• Chu kỳ lặp (Sprint): Khung thời gian cố định để đội ngũ phát triển chuyển giao một phần gia tăng của sản phẩm có giá trị sử dụng.
• Danh mục sản phẩm tồn đọng (Product Backlog): Tập hợp danh sách các tính năng, yêu cầu nghiệp vụ và tác vụ kỹ thuật được sắp xếp theo thứ tự ưu tiên.
• Danh mục công việc chu kỳ (Sprint Backlog): Tập hợp các tác vụ cụ thể mà nhóm phát triển cam kết hoàn thành trong một Sprint.
• Họp đứng hằng ngày (Daily Stand-up Meeting): Phiên đồng bộ hóa tiến độ diễn ra tối đa 15 phút mỗi ngày nhằm xác định các vướng mắc kỹ thuật.
• Mức độ hình thức hóa (Level of Formalism): Tỷ trọng tài liệu hóa và thủ tục quy trình được điều chỉnh phù hợp với quy mô và mức độ rủi ro của dự án.

Phương pháp nghiên cứu

Luận văn sử dụng phương pháp nghiên cứu trường hợp diễn giải (Interpretive Case Study) dựa trên định hướng của Robert Galliers năm 1994. Trong khi khảo sát của Chen và Hirschheim năm 2004 trên 1.893 bài báo khoa học chỉ ra 81% nghiên cứu hệ thống thông tin thiên về phương pháp thực chứng định lượng, phương pháp diễn giải được lựa chọn trong đề tài này nhằm thấu hiểu sâu sắc các yếu tố hành vi, văn hóa làm việc và sự tương tác xã hội phức tạp giữa các bên liên quan.

Cỡ mẫu và quy trình thu thập dữ liệu gồm 6 cuộc phỏng vấn bán cấu trúc chuyên sâu với 5 lập trình viên (bao gồm các kỹ sư kỳ cựu và kỹ sư mới) cùng 1 đại diện quản lý khách hàng chủ chốt. Tác giả đã tham gia quan sát trực tiếp 11 cuộc họp và phiên làm việc chuyên môn với tổng thời lượng hơn 18 giờ quan sát thực địa. Quá trình thu thập dữ liệu diễn ra qua 2 đợt thực địa tại Oslo vào tháng 3 năm 2006 và tháng 5 năm 2006, kết hợp phân tích hơn 150 đầu việc trên hệ thống quản lý JIRA cùng các tài liệu trao đổi qua thư điện tử.

Độ tin cậy và giá trị khoa học của dữ liệu được kiểm định thông qua bộ 7 nguyên tắc đánh giá nghiên cứu diễn giải của Klein và Myers công bố năm 1999, đảm bảo tính minh bạch về định kiến của nhà nghiên cứu và tính nhất quán giữa các nguồn dữ liệu độc lập.

Kết quả nghiên cứu và thảo luận

Những phát hiện chính

Thứ nhất, tính ưu việt của chu kỳ lặp 2 tuần so với chu kỳ 3 tuần hoặc 4 tuần. Nhóm phát triển đã thực nghiệm chu kỳ 3 tuần nhưng ghi nhận sự suy giảm khả năng tập trung và năng suất thực tế không cao hơn chu kỳ 2 tuần. Việc duy trì Sprint 2 tuần giúp tăng nhịp độ hoàn thành công việc và cải thiện khả năng thích ứng kỹ thuật thêm khoảng 30% so với các chu kỳ dài.

Thứ hai, sự tái định nghĩa bản chất của Danh mục sản phẩm tồn đọng. Thay vì duy trì một Backlog chứa các yêu cầu nghiệp vụ mức cao do khách hàng quản lý và hướng tới việc làm rỗng Backlog khi hoàn tất dự án như lý thuyết Scrum của Schwaber, nhóm nghiên cứu ghi nhận một Product Backlog gồm khoảng 150 tác vụ mang tính kỹ thuật chi tiết trên phần mềm JIRA. Đội ngũ phát triển quan niệm rằng một Backlog rỗng đồng nghĩa với việc dự án đã chết, bởi vì các yêu cầu bảo trì và tái cấu trúc mã nguồn luôn xuất hiện liên tục trong vòng đời phần mềm.

Thứ ba, hiệu quả nâng cao độ chính xác dự toán thông qua kỹ thuật Planning Poker. Khi áp dụng kỹ thuật ước lượng nhóm này cho 50% số tác vụ trong các phiên lập kế hoạch kéo dài 4 giờ, sự chênh lệch ý kiến giữa các lập trình viên kỳ cựu và lập trình viên mới được dung hòa, loại bỏ hoàn toàn hiện tượng áp đặt quan điểm và giúp 100% thành viên hiểu rõ cấu trúc kiến trúc phần mềm.

Thứ tư, mô hình hợp tác khách hàng linh hoạt ngoài quy chuẩn. Mặc dù đại diện khách hàng không thể tham dự các phiên họp lập kế hoạch Sprint 4 giờ do rào cản thời gian, sự phối hợp vẫn đạt hiệu quả tối ưu thông qua các phiên họp phân bổ độ ưu tiên riêng biệt và cơ chế phản hồi trực tiếp khi thử nghiệm thực địa trên thiết bị di động PDA.

Thảo luận kết quả

Sự khác biệt giữa thực tế triển khai tại doanh nghiệp Na Uy và lý thuyết Scrum kinh điển bắt nguồn từ nhu cầu tự thích ứng thực tế thay vì áp dụng giáo điều. Việc áp dụng phương pháp lai ghép giữa các công cụ quản lý tác vụ kỹ thuật và nguyên lý giao tiếp Agile đã giải quyết hiệu quả xung đột mã nguồn phát sinh khi quy mô nhóm mở rộng từ 2 lên 4 và 6 lập trình viên.

Dữ liệu tiến độ của nhóm có thể được trực quan hóa tối ưu thông qua Biểu đồ Burndown dự án (Project Burndown Chart) biểu diễn khối lượng công việc còn lại trên trục tung theo thời gian trên trục hoành, cùng Biểu đồ Burndown Sprint (Sprint Burndown Chart) ghi nhận các biến động tác vụ hằng ngày. Bảng tổng hợp đối sánh giữa lý thuyết Scrum và thực tiễn dự án cho thấy sự tương thích cao ở các hoạt động họp đứng 15 phút hằng ngày và quản lý Sprint Backlog, nhưng có sự phân kỳ rõ nét ở cấu trúc Product Backlog kỹ thuật và quy trình phân định vai trò Scrum Master kiêm nhiệm.

Sự hài lòng cao độ từ phía khách hàng khẳng định luận điểm cốt lõi của Tuyên ngôn Agile: giá trị của sự tương tác cá nhân và phần mềm chạy tốt vượt trội hơn việc tuân thủ cứng nhắc các bước quy trình lý thuyết.

Đề xuất và khuyến nghị

Thứ nhất, tổ chức chuẩn hóa chương trình đào tạo Scrum chuyên sâu với thời lượng tối thiểu 16 giờ cho toàn bộ đội ngũ lập trình viên và quản lý dự án. Hoạt động này cần được thực hiện trong vòng 3 tháng nhằm giúp các thành viên nắm vững các nguyên lý gốc, từ đó tối ưu hóa việc phân định vai trò Scrum Master chuyên trách và giải quyết triệt để các trở ngại kỹ thuật (impediments).

Thứ hai, tái cấu trúc Product Backlog theo mô hình phân tầng chức năng trong thời hạn 30 ngày. Cần tách biệt rõ ràng giữa danh mục yêu cầu nghiệp vụ thân thiện với người dùng (User Stories) do khách hàng quản lý và danh mục tác vụ kỹ thuật chi tiết (Technical Tasks) trên JIRA do lập trình viên xử lý, nhằm giảm thiểu 40% thời gian rà soát và đánh giá độ ưu tiên trong mỗi kỳ họp.

Thứ ba, thiết lập định kỳ phiên Họp Đánh giá Sprint (Sprint Review) với thời lượng 60 phút vào cuối mỗi chu kỳ 2 tuần. Nhóm phát triển chủ động thực hiện demo các tính năng hoàn thiện trực tiếp cho khách hàng và người dùng cuối, hướng tới mục tiêu đạt trên 90% tỷ lệ phản hồi nghiệp vụ được ghi nhận và xử lý ngay tại phiên họp.

Thứ tư, mở rộng áp dụng kỹ thuật Planning Poker cho 100% các tác vụ trong phiên Sprint Planning thay vì chỉ dừng lại ở mức 50% thử nghiệm. Giải pháp này cần triển khai ngay trong 2 quý tiếp theo nhằm giảm thiểu sai số ước lượng thời gian thực hiện xuống dưới mức 15%.

Chủ thể chịu trách nhiệm thực thi các giải pháp bao gồm Ban Giám đốc công ty tư vấn phần mềm, Trưởng nhóm phát triển kỹ thuật và Đại diện quản lý dự án phía cơ quan quản lý giao thông.

Đối tượng nên tham khảo luận văn

Nhóm Quản lý dự án và Scrum Master: Khai thác kinh nghiệm thực tế về lộ trình chuyển đổi phương pháp luận linh hoạt ngay giữa chu kỳ dự án, học hỏi cách điều chỉnh quy trình phù hợp khi quy mô nhân sự thay đổi từ 1 lên 6 thành viên mà không làm gián đoạn tiến độ chuyển giao.

Nhóm Kỹ sư phần mềm và Trưởng nhóm kỹ thuật: Nắm bắt các thực hành ước lượng công việc nhóm bằng Planning Poker, kỹ thuật quản lý danh mục công việc 2 tuần và phương pháp điều phối các phiên họp đứng 15 phút hằng ngày nhằm tháo gỡ khó khăn về kiến trúc hệ thống và giao thức truyền thông không dây.

Nhóm Khách hàng, Giám đốc sản phẩm (Product Owners) và Chuyên viên phân tích nghiệp vụ: Nắm rõ cơ chế phối hợp hiệu quả với đối tác gia công phần mềm, tối ưu hóa thời gian thông qua các phiên họp phân bổ ưu tiên định kỳ và quy trình kiểm thử hiện trường trên thiết bị chuyên dụng.

Nhóm Giảng viên, Nghiên cứu sinh và Học viên cao học chuyên ngành Hệ thống thông tin: Sử dụng luận văn như một tài liệu tham khảo chuẩn mực về phương pháp nghiên cứu trường hợp diễn giải, ứng dụng thành công bộ 7 nguyên tắc Klein và Myers trong đánh giá thực nghiệm công nghệ phần mềm.

Câu hỏi thường gặp

Lý do nhóm phát triển quyết định chuyển đổi sang phương pháp Scrum ngay giữa vòng đời dự án là gì? Khi quy mô nhân sự tăng từ 2 lên 4 rồi 6 kỹ sư, việc chia thành 2 nhóm độc lập đã gây ra tình trạng xung đột mã nguồn nghiêm trọng và chồng chéo công việc. Việc áp dụng Scrum từ cuối năm 2005 giúp thiết lập cơ chế đồng bộ hóa hằng ngày và quy chuẩn hóa kế hoạch làm việc tập trung.

Tại sao dự án lại lựa chọn chu kỳ Sprint 2 tuần thay vì 4 tuần như khuyến nghị chuẩn của Scrum? Nhóm đã thử nghiệm chu kỳ 3 tuần nhưng nhận thấy các lập trình viên dễ mất tập trung và năng suất không vượt trội. Chu kỳ 2 tuần tạo ra các cột mốc ngắn hạn rõ ràng, giúp đội ngũ duy trì động lực làm việc liên tục và kiểm soát các tác vụ kỹ thuật nhỏ hiệu quả hơn.

Bản chất của Product Backlog trong dự án này có điểm gì khác biệt căn bản so với lý thuyết Scrum? Thay vì là danh mục các yêu cầu chức năng kinh doanh do khách hàng quản lý và hướng đến trạng thái hoàn thành toàn bộ, Backlog của dự án gồm khoảng 150 tác vụ kỹ thuật chi tiết trên JIRA. Nhóm xem Backlog là công cụ phản ánh độ trưởng thành của hệ thống và luôn tồn tại suốt vòng đời bảo trì phần mềm.

Việc đại diện khách hàng không thể tham dự các buổi họp Sprint Planning có làm suy giảm chất lượng sản phẩm không? Chất lượng sản phẩm không bị suy giảm nhờ sự bù đắp từ các phiên họp phân bổ ưu tiên định kỳ riêng biệt và việc khách hàng luôn sẵn sàng phản hồi nhanh qua thư điện tử, kết hợp tham gia trực tiếp vào các đợt kiểm thử thiết bị PDA ngoài thực địa.

Phương pháp Planning Poker đã mang lại cải tiến cụ thể nào cho công tác ước lượng tác vụ của nhóm? Planning Poker yêu cầu tất cả thành viên đưa ra con số ước lượng độc lập cùng một thời điểm, buộc người có ước lượng cao nhất và thấp nhất giải thích quan điểm. Kỹ thuật này giúp phát hiện các tác vụ tiềm ẩn, đào tạo chuyên môn cho kỹ sư mới và nâng cao độ chính xác của dự toán.

Kết luận

• Luận văn hoàn thành việc phân tích thực nghiệm quá trình tiếp nhận phương pháp Agile/Scrum giữa chừng tại một dự án công nghệ thông tin thực tế ở Na Uy.
• Nghiên cứu chứng minh tính khả thi và hiệu quả vượt trội của chu kỳ Sprint 2 tuần trong việc duy trì năng suất và sự tập trung của nhóm kỹ sư phần mềm.
• Đề tài làm rõ sự biến đổi mang tính thực dụng của Product Backlog kỹ thuật và cơ chế tương tác khách hàng linh hoạt ngoài các quy chuẩn lý thuyết cứng nhắc.
• Đóng góp khoa học quan trọng của công trình là việc vận dụng thành công phương pháp nghiên cứu trường hợp diễn giải và bộ 7 nguyên tắc Klein và Myers vào lĩnh vực kỹ thuật phần mềm.
• Lộ trình tiếp theo hướng tới việc bàn giao chính thức hệ thống kiểm định phương tiện vào tháng 9 đến tháng 10 năm 2006, đồng thời mở ra hướng nghiên cứu thực nghiệm đối chứng về tác động dài hạn của cấu trúc Backlog.

Các tổ chức công nghệ và doanh nghiệp phần mềm đang chuẩn bị chuyển đổi quy trình nên tham khảo và áp dụng các bài học thực tiễn từ công trình nghiên cứu này để xây dựng mô hình Agile linh hoạt, tối ưu hóa năng suất kỹ thuật và gia tăng tối đa sự hài lòng của khách hàng.

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.