Giới thiệu về Agile trong lĩnh vực học thuật
Trong bối cảnh giáo dục đại học hiện đại, đặc biệt là trong các chương trình khoa học máy tính và kỹ thuật, việc chuyển đổi từ các phương pháp truyền thống kiểu thác nước sang các khung Agile đã trở thành một mục tiêu học tập quan trọng. Sinh viên thường bước vào đại học với hiểu biết lý thuyết về phát triển phần mềm nhưng lại thiếu trải nghiệm thực tế về các quy trình làm việc lặp lại. Khoảng cách này có thể dẫn đến xung đột khi quản lý các dự án tốt nghiệp phức tạp hoặc các bài tập nhóm. Scrum cung cấp một khung làm việc có cấu trúc nhưng linh hoạt, giúp giải quyết hiệu quả những thách thức này.
Bài viết này trình bày chi tiết một nghiên cứu trường hợp toàn diện về một nhóm sinh viên đại học đã thành công trong việc phát triển một ứng dụng di động bằng các nguyên tắc Scrum. Trọng tâm không nằm ở bộ công cụ công nghệ được sử dụng, mà nằm ở các quy trình, chiến lược giao tiếp và cấu trúc tổ chức đã giúp nhóm liên tục tạo ra giá trị. Bằng cách xem xét các bước cụ thể đã thực hiện, những trở ngại gặp phải và các giải pháp được triển khai, chúng ta có thể hiểu được cách Scrum được chuyển đổi từ môi trường doanh nghiệp sang các sáng kiến do sinh viên dẫn dắt.
Bối cảnh dự án
Nghiên cứu trường hợp tập trung vào một nhóm năm sinh viên đại học đang theo học môn học kỹ thuật phần mềm năm cuối. Nhiệm vụ của họ là thiết kế, phát triển và triển khai một ứng dụng di động hoạt động, nhằm giải quyết một vấn đề cụ thể trong cộng đồng sinh viên trên khuôn viên trường đại học. Phạm vi dự án đủ lớn để đòi hỏi nhiều tháng làm việc, nhưng lại bị giới hạn bởi các mốc thời gian học thuật.
Mục tiêu dự án là tạo ra một công cụ giúp sinh viên tìm kiếm các không gian học tập còn trống theo thời gian thực. Nhóm gồm những cá nhân với trình độ kỹ năng khác nhau, từ những người đã có kinh nghiệm lập trình trước đó đến những người mới bắt đầu lĩnh vực này. Sự pha trộn kỹ năng này là phổ biến trong môi trường học thuật và làm tăng độ phức tạp trong việc quản lý dự án.
Để thành công, nhóm cần một phương pháp để:
- Quản lý các ưu tiên và hạn chót mâu thuẫn nhau.
- Đảm bảo tất cả các thành viên nhóm đều đóng góp công bằng.
- Thích nghi với các yêu cầu thay đổi khi dự án phát triển.
- Duy trì nhịp độ làm việc bền vững giữa các lịch thi cử.
Xác định các vai trò Scrum cho một nhóm sinh viên đại học
Một trong những trở ngại đầu tiên là phân công vai trò. Trong môi trường doanh nghiệp, các vai trò thường được chuyên môn hóa. Trong nhóm sinh viên, các thành viên thường đảm nhận nhiều vai trò cùng lúc. Tuy nhiên, để tuân thủ các nguyên tắc Scrum, nhóm đã đồng thuận phân chia trách nhiệm rõ ràng. Sự rõ ràng này giúp tránh được sự nhầm lẫn về ai chịu trách nhiệm cho điều gì.
Bảng sau đây nêu rõ cách nhóm đã chuyển đổi các vai trò Scrum sang các vai trò tương ứng với sinh viên.
| Vai trò Scrum | Trách nhiệm sinh viên | Vùng tập trung chính |
|---|---|---|
| Người sở hữu sản phẩm | Trưởng nhóm | Xác định tính năng, ưu tiên danh sách công việc, liên hệ với giảng viên hướng dẫn. |
| Master Scrum | Phụ trách dự án | Loại bỏ các trở ngại, hỗ trợ tổ chức các cuộc họp, đảm bảo tuân thủ quy trình. |
| Đội phát triển | Lập trình viên và Nhà thiết kế | Xây dựng ứng dụng, viết mã nguồn, tạo mẫu giao diện người dùng, kiểm thử. |
Người sở hữu sản phẩm chịu trách nhiệm về tầm nhìn. Họ thu thập phản hồi từ người dùng tiềm năng (các sinh viên khác) và chuyển đổi thành danh sách các tính năng mong muốn. Master Scrum đảm bảo nhóm có thời gian và không gian để làm việc mà không bị gián đoạn không cần thiết. Đội phát triển tự tổ chức, nghĩa là họ tự quyết định cách thức kỹ thuật để đạt được mục tiêu do Người sở hữu sản phẩm đặt ra.
Giai đoạn lập kế hoạch: Tạo danh sách công việc
Nền tảng của dự án là Danh sách công việc sản phẩm. Đây là danh sách các công việc được ưu tiên mà nhóm hướng đến hoàn thành. Khác với tài liệu yêu cầu tĩnh, danh sách này mang tính động và thay đổi theo thời gian khi nhóm hiểu rõ hơn về không gian vấn đề.
Đội đã dành tuần đầu tiên để tạo danh sách công việc ban đầu. Họ sử dụng một kỹ thuật gọi là Câu chuyện người dùng để mô tả các tính năng. Một câu chuyện người dùng tuân theo định dạng đơn giản: Là một [loại người dùng], tôi muốn [mục tiêu nào đó] để [lý do nào đó].Định dạng này buộc các sinh viên phải suy nghĩ về giá trị dành cho người dùng cuối thay vì chỉ tập trung vào các thông số kỹ thuật.
Ví dụ về các mục trong danh sách công việc ban đầu bao gồm:
- Là một sinh viên, tôi muốn xem bản đồ các tòa nhà để có thể di chuyển dễ dàng trong khuôn viên trường.
- Là một sinh viên, tôi muốn lọc các phòng theo dung tích để có thể tìm được những chỗ học tập yên tĩnh.
- Là một sinh viên, tôi muốn nhận thông báo khi một phòng trống để có thể nhanh chóng chiếm chỗ.
- Là một quản trị viên, tôi muốn cập nhật trạng thái phòng để dữ liệu luôn được chính xác.
Mỗi mục sau đó được ước lượng về nỗ lực thực hiện. Đội đã sử dụng điểm câu chuyện thay vì giờ. Cách tiếp cận này tập trung vào mức độ phức tạp tương đối của nhiệm vụ thay vì dự đoán khung thời gian chính xác, điều này thường không chính xác trong các dự án học thuật khi các sự kiện đời sống can thiệp vào lịch làm việc.
Thực hiện Sprint 1: Hai tuần đầu tiên
Dự án được chia thành các chu kỳ hai tuần gọi là Sprint. Sprint đầu tiên là rất quan trọng vì nó thiết lập nhịp độ cho đội nhóm. Mục tiêu là tạo ra một phần tăng trưởng có thể triển khai được, ngay cả khi chỉ là phiên bản cơ bản của ứng dụng.
Lên kế hoạch Sprint
Sprint bắt đầu bằng một buổi họp lập kế hoạch. Người sở hữu sản phẩm trình bày các mục ưu tiên cao nhất từ danh sách công việc. Đội phát triển sau đó chọn các mục mà họ cho là có thể hoàn thành trong khung thời gian hai tuần. Cam kết này rất quan trọng để đảm bảo trách nhiệm.
Trong buổi họp này, đội đã chia nhỏ các câu chuyện cấp cao thành các nhiệm vụ nhỏ hơn. Ví dụ, câu chuyện Bản đồđược chia thành:
- Tích hợp API bản đồ.
- Tạo lược đồ cơ sở dữ liệu cho vị trí phòng.
- Thiết kế giao diện bản đồ.
- Viết mã để lấy dữ liệu phòng.
Các nhiệm vụ này được phân bổ cho các thành viên đội dựa trên sở thích và kỹ năng. Trợ lý Scrum điều phối cuộc thảo luận để đảm bảo mọi người đều hiểu rõ các tiêu chí chấp nhận.
Các buổi họp hàng ngày
Việc giao tiếp được quản lý thông qua buổi họp hàng ngày diễn ra vào một khung giờ cố định. Buổi họp này kéo dài không quá mười lăm phút. Mỗi thành viên trả lời ba câu hỏi:
- Tôi đã làm gì hôm qua?
- Tôi sẽ làm gì hôm nay?
- Có trở ngại nào đang cản trở tiến độ của tôi không?
Thói quen này giúp đội nhóm luôn thống nhất. Trong tuần đầu tiên của Sprint 1, một lập trình viên báo cáo có một trở ngại: họ không thể truy cập tài liệu hướng dẫn API bản đồ. Trợ lý Scrum ngay lập tức can thiệp để tìm nguồn thay thế và giải quyết vấn đề truy cập, giúp công việc tiếp tục mà không bị chậm trễ.
Xử lý các trở ngại trong quá trình phát triển
Không có dự án nào tiến triển mà không gặp thách thức. Trong nghiên cứu trường hợp này, đội đã đối mặt với một số vấn đề phổ biến thường gặp ở các nhóm sinh viên.
Xung đột học thuật
Giữa chặng đường của Sprint 1, hai thành viên trong đội đã có kỳ thi quan trọng được lên lịch. Điều này đe dọa đến tốc độ làm việc của đội. Thay vì hủy sprint hoặc để công việc tích tụ, đội đã điều chỉnh kế hoạch. Những thành viên bị ảnh hưởng đã giảm khối lượng công việc trong sprint đó và tập trung vào tài liệu hóa và kiểm thử, trong khi các thành viên khác đảm nhận khối lượng phát triển. Điều này đã thể hiện sự linh hoạt của khung làm việc.
Bùng nổ phạm vi
Sau buổi xem xét sprint đầu tiên, Người sở hữu sản phẩm nhận được phản hồi đề xuất thêm tính năng đặt phòng trực tiếp. Mặc dù có giá trị, nhưng tính năng này không nằm trong mục tiêu sprint hiện tại. Việc thêm vào sẽ làm ảnh hưởng đến tiến độ. Người sở hữu sản phẩm đã đưa yêu cầu này vào danh sách công việc chờ xử lý để xem xét trong tương lai. Sự kỷ luật này đã ngăn dự án trở nên khó kiểm soát.
Nợ kỹ thuật
Để đáp ứng tiến độ, đội ban đầu đã chọn một giải pháp nhanh cho lưu trữ dữ liệu nhưng không thể mở rộng. Trong buổi tổng kết, họ đã thừa nhận quyết định này. Họ dành thời gian trong sprint tiếp theo để tái cấu trúc mã nguồn. Việc thừa nhận nợ kỹ thuật một cách cởi mở là điều cần thiết cho sức khỏe lâu dài của dự án.
Sprint 2 nghiên cứu sâu: Tinh chỉnh và ổn định
Sprint thứ hai tập trung vào độ ổn định và trải nghiệm người dùng. Với chức năng cốt lõi đã được thiết lập trong Sprint 1, đội có thể tập trung vào tinh chỉnh giao diện và đảm bảo độ tin cậy.
Mục tiêu Sprint
Mục tiêu chính cho Sprint 2 là đảm bảo ứng dụng có thể xử lý nhiều người dùng đồng thời mà không bị sập. Mục tiêu phụ là hoàn thiện thiết kế hình ảnh.
Phân bổ công việc
Các nhiệm vụ trong sprint này phức tạp hơn. Đội phải phối hợp công việc chặt chẽ hơn. Một thành viên làm việc trên API phía máy chủ, trong khi thành viên khác làm việc trên giao diện phía khách hàng. Họ họp thường xuyên để đảm bảo định dạng dữ liệu khớp nhau. Việc phối hợp này thường khó khăn hơn trong các dự án sinh viên so với môi trường doanh nghiệp do ít kinh nghiệm tích hợp.
Quy trình kiểm thử
Đội đã triển khai quy trình kiểm tra chéo. Trước khi bất kỳ mã nguồn nào được gộp, một thành viên khác trong đội phải kiểm tra nó. Thói quen này giúp phát hiện lỗi sớm và hỗ trợ các thành viên trẻ học hỏi từ những người có kinh nghiệm hơn. Nó cũng đảm bảo mã nguồn luôn nhất quán, ngay cả khi các thành viên khác nhau viết các mô-đun khác nhau.
Xem xét Sprint và Tổng kết Sprint
Vào cuối mỗi sprint, hai nghi thức riêng biệt đã diễn ra: Xem xét Sprint và Tổng kết Sprint. Hai nghi thức này thường bị nhầm lẫn, nhưng chúng phục vụ các mục đích khác nhau.
Xem xét Sprint
Buổi xem xét là một buổi trình diễn công việc dành cho các bên liên quan (giảng viên và sinh viên được mời). Đội đã trình bày ứng dụng hoạt động. Phản hồi được thu thập về tính dễ sử dụng. Người sở hữu sản phẩm cập nhật danh sách công việc chờ xử lý dựa trên phản hồi này. Chu kỳ này đảm bảo sản phẩm luôn phù hợp với nhu cầu người dùng.
Tổng kết Sprint
Buổi tổng kết là một cuộc họp nội bộ dành cho đội. Mục tiêu là cải thiện quy trình, chứ không phải sản phẩm. Đội thảo luận về những điều đã diễn ra tốt, những điều không tốt và những điều có thể cải thiện. Trong buổi tổng kết đầu tiên, đội nhận thấy các cuộc họp kéo dài quá lâu. Phản ứng lại, họ áp dụng đồng hồ bấm giờ nghiêm ngặt cho sprint tiếp theo. Trong buổi tổng kết thứ hai, họ nhận thấy giao tiếp qua email quá chậm. Họ chuyển sang sử dụng kênh tin nhắn chuyên dụng cho các cập nhật khẩn cấp.
Vòng lặp cải tiến liên tục này chính là trái tim của Scrum. Nó cho phép đội hình phát triển phương pháp làm việc của mình khi tích lũy được kinh nghiệm.
Kết quả cuối cùng và tích hợp học thuật
Đến cuối học kỳ, đội đã hoàn thành một ứng dụng hoạt động, được hàng trăm sinh viên trong khuôn viên sử dụng. Quy trình chấm điểm khác biệt so với các dự án truyền thống. Thay vì nộp một bài cuối cùng, giảng viên đánh giá đội dựa trên tài liệu quy trình, chất lượng mã nguồn và hiệu quả hợp tác của đội.
Việc sử dụng Scrum đã cung cấp bằng chứng cụ thể về tiến độ. Đội có thể trình bày cho giảng viên danh sách công việc chờ xử lý, nhật ký sprint và ghi chú họp hàng ngày. Tính minh bạch này giúp dễ dàng chứng minh giá trị công việc của họ trong suốt học kỳ thay vì chỉ vào cuối kỳ.
Điểm cuối cùng phản ánh nỗ lực và quy trình làm việc. Đội nhận được điểm cao nhờ khả năng thích ứng với thay đổi và duy trì nhịp độ bền vững. Giảng viên nhận xét rằng những sinh viên tham gia sâu vào khung Scrum đã tạo ra phần mềm chất lượng cao hơn so với những người thử áp dụng phương pháp truyền thống.
Bài học cốt lõi cho các dự án tương lai
Tổng kết lại nghiên cứu trường hợp này mang lại nhiều bài học quý giá cho sinh viên và giáo viên đang tìm cách áp dụng các phương pháp linh hoạt.
- Vai trò quan trọng:Ngay cả trong một đội nhỏ, việc xác định ai chịu trách nhiệm cho điều gì sẽ ngăn ngừa sự nhầm lẫn. Một Người sở hữu sản phẩm được chỉ định đảm bảo đội xây dựng đúng điều cần thiết.
- Lặp lại tốt hơn:Chờ đến cuối mới trình bày công việc là rủi ro. Trình bày tiến độ mỗi hai tuần cho phép điều chỉnh sớm.
- Giao tiếp là chìa khóa:Các buổi họp hàng ngày giúp mọi người luôn được cập nhật thông tin mà không cần phải tổ chức những cuộc họp dài.
- Quy trình quan trọng hơn công cụ:Đội không phụ thuộc vào phần mềm đắt tiền để quản lý dự án. Họ sử dụng các công cụ đơn giản, dễ tiếp cận. Trọng tâm nằm ở các quy tắc tham gia, chứ không phải công nghệ.
- Chấp nhận thất bại:Khi mọi thứ không như mong đợi, đội đã biến điều đó thành cơ hội học hỏi. Buổi tổng kết đã biến các vấn đề thành những cải tiến cụ thể có thể thực hiện được.
Kết luận về học tập linh hoạt
Hành trình xây dựng ứng dụng bằng Scrum trong môi trường học thuật làm nổi bật giá trị của phát triển theo từng bước lặp. Nó dạy sinh viên rằng phần mềm không chỉ là mã nguồn, mà còn là sự hợp tác giữa con người. Khung làm việc cung cấp cấu trúc cần thiết để quản lý sự phức tạp, đồng thời tạo điều kiện cho sự sáng tạo cần thiết cho đổi mới.
Đối với giáo viên, việc tích hợp Scrum vào chương trình học sẽ chuẩn bị cho sinh viên bước vào thế giới chuyên nghiệp. Đối với sinh viên, nó mang lại một khung thực tiễn để quản lý quá trình học tập và kết quả dự án của chính mình. Nghiên cứu trường hợp cho thấy rằng với vai trò rõ ràng, các nghi thức nhất quán và tập trung vào giá trị, các đội sinh viên có thể đạt được kết quả chuyên nghiệp.
Thành công của dự án này không đến từ một công nghệ cụ thể hay một ý tưởng thiên tài. Nó đến từ sự kỷ luật trong quy trình. Bằng cách tuân thủ khung Scrum, đội đã duy trì sự tập trung, quản lý khối lượng công việc hiệu quả và đưa ra sản phẩm đáp ứng nhu cầu của cộng đồng. Cách tiếp cận này có thể áp dụng cho bất kỳ dự án nhóm nào đối mặt với những thách thức tương tự.
