Agile/Scrum - Phần 1 - Agile là gì? Agile giúp gì cho chúng ta?
Mở đầu
Để có thể làm tốt vai trò của một PO/PM, trong mô hình làm việc nào, thì điều quan trọng nhất là làm sao để biết được “the right problems to solve", “the right things to build”, còn việc vận hành một scrum team với vai trò là một PO không quá phức tạp. Do đó, ban đầu mình không định viết về chủ đề này. Tuy nhiên, có vài lý do khiến mình thay đổi và quyết định viết về Agile/Scrum:
Thứ nhất, trong quá trình hướng dẫn các bạn newbie, mình thấy rằng có nhiều bạn với background kinh tế, chưa biết trước về các mô hình phát triển phần mềm, cũng gặp nhiều khó khăn khi bắt đầu vận hành một scrum team. Chính mình với technical background, đã được học trước về Agile/Scrum ở Đại học, thì cũng mất khoảng 2-4 tuần để làm quen cách làm việc của một scrum team thực tế.
Thứ hai, trước đây mình nghĩ việc áp dụng scrum đã phổ biến rồi, cho đến khi mình biết có nhiều doanh nghiệp công nghệ, hoặc có áp dụng công nghệ với đội ngũ hàng chục, hàng trăm kỹ sư vẫn đang sử dụng mô hình waterfall và đang gặp vấn đề với nó, cần chuyển đổi. Các bạn Product hay BA đã có kinh nghiệm ở vẫn chưa thể vận hành trơn tru một scrum team.
Thứ ba, mình muốn trang proup.vn giúp các bạn trang bị đầy đủ các kiến thức, kỹ năng xuyên suốt để từ một newbie trở thành một PO/PM giỏi.
Bài viết này, mình sẽ đi từ lý thuyết (bạn có thể tìm kiếm ở nhiều nơi, nhưng có sẵn ở đây cũng tốt) cho đến thực tế, các trải nghiệm của mình trong quá trình vận hành nhiều scrum team, đặc biệt là khi làm các dự án cross-team.
Trước khi đi vào Scrum framework (một phương pháp Agile được sử dụng phổ biến nhất), mình cần đi qua về Agile methodologies.
Agile methodologies ra đời như thế nào?
Ngày nay, Agile/Scrum đã trở nên rất phổ biến và được nhiều doanh nghiệp công nghệ trên toàn cầu sử dụng. Các doanh nghiệp khi chuyển từ một mô hình phát triển phần mềm kiểu cũ (hoặc thậm chí không có quy trình) sang scrum (một framework thuộc Agile Methodology), thì câu hỏi đầu tiên cần trả lời là: “Tại sao? Agile/Scrum giúp được gì?”
Và câu trả lời cho câu hỏi trên cũng chính là lý do tại sao Agile Methodology ra đời.
Câu chuyện ra đời của Agile bắt đầu vào những năm 1990 khi một nhóm các chuyên gia phát triển phần mềm nhận thấy rằng các phương pháp truyền thống không đáp ứng được nhu cầu của thị trường, đặc biệt là trong các dự án phần mềm có sự biến động lớn hoặc yêu cầu sự linh hoạt. Ngay khi bắt đầu dự án, rất khó để xác định được một sản phẩm, một phần mềm như thế nào sẽ là tốt trong dài hạn cả. Nếu áp dụng Waterfall, viết thật rõ và chính xác yêu cầu/đặc tả phần mềm thì sẽ tốn rất nhiều thời gian để nghiên cứu và thiết kế, nhưng sau đó vẫn phát sinh nhu cầu cần thay đổi trong quá trình phát triển cũng như sau khi sản phẩm được hoàn thành.
Vào năm 2001, 17 chuyên gia phần mềm tập trung tại Snowbird, Utah và họ đồng ý rằng vấn đề là các công ty đã quá tập trung vào việc lập kế hoạch và ghi chép quá mức về chu trình phát triển phần mềm của mình đến nỗi họ đánh mất điều gì thực sự quan trọng – làm hài lòng khách hàng của họ. Từ đó, "Manifesto for Agile Software Development" (Tuyên ngôn Agile) ra đời, tài liệu này đã thiết lập các nguyên tắc cơ bản của Agile, đặt trọng tâm vào việc tạo ra phần mềm linh hoạt, mục tiêu hướng tới hài lòng khách hàng, sự tương tác thường xuyên giữa các cá nhân và sự thích ứng với sự biến đổi.
Trong 17 chuyên gia, có vài nhân vật quan trọng với nhiều “khái niệm” phổ biến vẫn được dùng đến ngày nay:
Kent Beck: Người đồng sáng lập Extreme Programming (XP), một trong những phương pháp phát triển phần mềm Agile đầu tiên.
Ward Cunningham: Được biết đến với khái niệm "Wiki" và đã đóng góp quan trọng cho Agile thông qua việc giới thiệu các khái niệm quan trọng như "technical debt" (nợ kỹ thuật) và "refactoring" (tái cấu trúc).
Martin Fowler: Nhà phát triển phần mềm nổi tiếng, đã góp phần quan trọng vào việc giới thiệu và phổ biến các nguyên tắc và phương pháp Agile.
Alistair Cockburn: Người sáng lập Use Case, đã đóng góp vào Agile thông qua quan điểm về "project box” và sự cần thiết của sự tương tác giữa con người trong quá trình phát triển phần mềm.
Jim Highsmith: Đồng sáng lập Agile Manifesto, đã đóng góp ý kiến về sự linh hoạt và sự phản hồi liên tục trong phát triển phần mềm.
Tuyên ngôn chỉ với 68 từ và tài liệu ngắn gọn, nhưng đã thay đổi quá trình phát triển phần mềm. Trong hơn 20 năm từ khi được tạo ra, tuyên ngôn và 12 nguyên tắc Agile đã được nhiều tổ chức áp dụng.
Tuyên ngôn Agile
Bốn giá trị cốt lõi của Agile là:
Cá nhân và Tương tác hơn là Quy trình và Công cụ
Phần mềm hoạt động hơn là Tài liệu chi tiết
Hợp tác với Khách hàng hơn là Đàm phán Hợp đồng
Phản ứng với Biến đổi hơn là Tuân theo Kế hoạch
Ở đây, cần lưu ý rằng các yếu tố bên phải cũng quan trọng, nhưng các yếu tố bên trái quan trọng hơn.
Một vài lầm tưởng từ tuyên ngôn này:
“Quy trình là không quan trọng”: Tuyên ngôn Agile xác định rằng Cá nhân và tương tác quan trọng hơn Quy trình, không đồng nghĩa với Quy trình không quan trọng. Quy trình vẫn giúp cho công việc được thực hiện đồng nhất, đảm bảo kết quả và hiệu quả.
“Phần mềm chạy là được”: Tuyên ngôn Agile không cổ suý điều này. Sản phẩm không được thiết kế tốt, về cả UI/UX lẫn kiến trúc sẽ để lại nhiều vấn đề, nhiều “debt” cần giải quyết và khó khăn khi phát triển về sau.
“Tài liệu không quan trọng, product requirement (PRD) thiếu cũng không sao”: Tuyên ngôn Agile đề cao kết quả hơn so với việc viết tài liệu quá chi tiết (comprehensive), không đồng nghĩa với việc product requirement (PRD) không quan trọng. PRD vẫn cần thiết, không thể thiếu để trao đổi giữa các team (business, product, tech) và giúp team tech biết được cần phải phát triển sản phẩm như thế nào, chi tiết ra sao. Việc thiếu và thay đổi quá nhiều ảnh hưởng đến quá trình phải triển sản phẩm.
“Cần phản ứng với biến đổi, PRD thay đổi là điều bình thường”: Tuyên ngôn Agile cổ vũ mọi người thích ứng với sự thay đổi, từ những thay đổi của thị trường, của khách hàng, hoặc team phát hiện ra các “insight” mới, … không đồng nghĩa với việc Product Owner có quyền thường xuyên thay đổi PRD, đặc biệt nếu lý do là chuẩn bị chưa đủ kỹ.
12 nguyên tắc Agile
Nguyên tắc 1: Ưu tiên cao nhất là làm hài lòng khách hàng thông qua việc bàn giao phần mềm/sản phẩm có giá trị trong thời gian sớm và liên tục.
Nguyên tắc 2: Sẵn sàng cho những thay đổi - thậm chí những thay đổi này xuất hiện muộn. Quy trình Agile khai thác sự thay đổi này nhằm gia tăng tính cạnh tranh cho khách hàng.
Nguyên tắc 3: Cung cấp phần mềm hoạt động được trong thời gian ngắn từ 1 vài tuần đến 1 vài tháng, càng ngắn càng được ưu tiên.
Nguyên tắc 4: Người kinh doanh và đội ngũ phát triển phải làm việc cùng nhau mỗi ngày trong suốt dự án
Nguyên tắc 5: Xây dựng dự án xung quanh những cá nhân có động lực. Cho họ môi trường làm việc thuận lợi và sự hỗ trợ cần thiết. Hãy có niềm tin rằng họ sẽ làm tốt công việc của mình.
Nguyên tắc 6: Đối thoại trực tiếp mặt đối mặt là phương pháp hữu hiệu nhất trong việc truyền đạt thông tin.
Nguyên tắc 7: Phần mềm chạy được là thước đo chính của tiến độ dự án.
Nguyên tắc 8: Phát triển bền vững và duy trì việc phát triển liên tục.
Nguyên tắc 9: Liên tục quan tâm đến kỹ thuật và thiết kế để tăng cường tính linh hoạt.
Nguyên tắc 10: Đơn giản - nghệ thuật tối đa hóa số lượng công việc không làm - là điều cần thiết.
Nguyên tắc 11: Các kiến trúc, yêu cầu và thiết kế tốt nhất được tạo nên từ các nhóm tự tổ chức.
Nguyên tắc 12: Trong khoảng thời gian đều đặn, nhóm phản ánh về cách trở nên hiệu quả hơn, sau đó điều chỉnh cho phù hợp.
Vậy, Agile là gì, Agile Software Development là gì?
Agile là một triết lý, một khung tư duy để nhanh chóng thích ứng và phản hồi với thay đổi, từ đó đạt được thành công trong một môi trường liên tục biến động và không chắc chắn.
Triết lý Agile xuất phát từ ngành công nghệ và được mô tả bằng 4 giá trị và 12 nguyên lý cốt lõi trong Tuyên ngôn Agile (Manifesto for Agile Software Development). Tuy nhiên, triết lý Agile cho đến ngày nay không chỉ đã làm thay đổi cách làm việc trong công nghệ mà còn lan tỏa mạnh mẽ và thể hiện giá trị trong rất nhiều lĩnh vực như: Quản lý dự án (Agile Project Management), nhân sự (Agile HR và Agile People), hay Marketing (Agile Marketing) …
Tổng kết
Agile, ngoài là một phương pháp, thì còn là văn hoá, lối tư duy để giúp đội nhóm phối hợp làm việc mà ưu tiên cao nhất là nhu cầu của khách hàng, là giá trị mà sản phẩm mang lại cho khách hàng, một cách nhanh nhất và liên tục.
Có vài framework thuộc phương pháp này, ví dụ như Extreme Programming (XP), Scrum, Kanban. Agile đưa ra 4 giá trị cốt lõi và 12 nguyên tắc, để các team tìm được cách làm việc phù hợp nhất.