Tổng quan về Agile - Phần 1

Bài đăng này đã không được cập nhật trong 5 năm

1. Lời mở đầu

Cũng giống như tất cả các ngành sản xuất khác, việc thành công của phát triển phần mềm cũng đòi hỏi phải có những phương pháp phát triển hiệu quả. Một trong số đó là Agile, hiện đang rất phổ biến trên thế giới và được áp dụng tại nhiều công ty phần mềm Việt Nam.

Gần đây mình có tham gia một khóa học "cơ bản" về Agile, trước khi tham gia mình đã nghĩ tới những giờ học lý thuyết nhàm chán và buồn ngủ. Nhưng khi tham gia những giờ học do anh Doãn Văn Toản (Framgia) tổ chức thì mình thấy hoàn toàn trái ngược với suy nghĩ của mình trước đó. Anh mang tới những giờ học bổ ích cùng với nhiều trò chơi hấp dẫn giúp học viên cảm thấy hứng thú với bài giảng và dễ hiểu. Qua hai buổi học và tìm hiểu thêm các tài liệu khác trên internet, mình sẽ chia sẻ những hiểu biết của mình về Agile.

2. Waterfall

"Ơ hay, tiêu đề bảo viết về Agile mà giờ lại xuất hiện Waterfall". Gì mà căng, mình trở về quá khứ một chút nhé! Hihi!

Waterfall là một mô hình của quy trình phát triển phần mềm rất trực quan, và là hệ thống quản lý phát triển phần mềm rất cổ điển. Tất cả những mốc thời gian quan trọng trong quá trình phát triển đều được lên kế hoạch chặt chẽ và cụ thể ngay từ trước khi bắt đầu, và sẽ không được thay đổi trong suốt quá trình phát triển, cụ thể là:

Do đó hình thức này thường được sử dụng cho các dự án dài hạn đòi hỏi được kế hoạch chi tiết và cẩn thận. Hình thức này được ứng dụng trong rất nhiều lĩnh vực như chế tạo máy móc, đóng thuyền hay ngành công nghiệp vũ trụ. Hình thức phát triển Waterfall cũng thường được ứng dụng trong phát triển phần mềm, ví dụ như những phần mềm lớn đang sử dụng hệ thống ERP hay đã có sự yêu thích nhất định, hay phát triển version mới của Android… Do vậy, Waterfall phù hợp với những dự án có yêu cầu đơn giản, rõ ràng ngay từ đầu. Thế đối với những dự án phức tạp, đòi hỏi công nghệ cao hoặc yêu cầu không rõ ràng, đôi khi chỉ là một idea thì sao ? "Tất cả để đó anh xử lý": Agile said .

3. Agile là gì?

Agile (agile software development) hay Phát triển phần mềm linh hoạt là một tư tưởng linh hoạt, một triết lí phát triển phần mềm dựa trên nguyên tắc phân đoạn vòng lặp (iterative) và tăng trưởng (incremental). Theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng. Agile thường sử dụng cách lập kế hoạch thích ứng (adaptive planning), việc phát triển và chuyển giao theo hướng tiến hóa; sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển. Ngày nay, triết lí Agile đã vượt xa khỏi khu vực truyền thống của mình là phát triển phần mềm để đóng góp sự thay đổi trong cách thức làm việc, quản lí, sản xuất ở các ngành khác như sản xuất (manufacturing), dịch vụ, sales, marketing, giáo dục...

Ta cùng sơ lược về sự ra đời của Agile nhé!

Tháng 2 năm 2001, 17 nhà phát triển đã gặp nhau ở Snowbird, Utah, để chia sẻ ý tưởng của họ. Sutherland và những người đề xướng cuộc tranh luận khác cũng nằm trong số đó. Nhưng nhóm cũng bao gồm những người ủng hộ một số phương pháp khác mang tính cạnh tranh với nhau, bao gồm lập trình XP (extreme programming); phát triển phần mềm thích ứng (ASD - adaptive software development); phát triển theo đặc tính (FDD - feature-driven development); và phương pháp phát triển hệ thống (DSDM - dynamic-systems-development method). Tất cả các phương pháp này dễ hiểu và dễ áp dụng hơn bởi vì chúng ít nguyên lý, điều này cho phép sự thích ứng nhanh chóng với những thay đổi từ môi trường xung quanh. Nhưng rất ít người cảm thấy sự “dễ hiểu và dễ dùng” này là một bước tiến. Mặc dù họ bất đồng quan điểm trên nhiều phương diện, nhưng cuối cùng họ thống nhất được một cái tên chung: Agile. Từ này được đề xuất bởi một người tham dự đã đọc cuốn sách “Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer”.

Nhắc đến Agile thì không thể không nhắc tới 4 tuyên ngôn và 12 nguyên lý:

4 tuyên ngôn đọc qua thì cũng dễ hiểu đúng không? Mình không cần phải giải thích gì thêm nữa nhỉ

Sau đây là 12 nguyên lý, xin mời các bạn xem video sau và tự hiểu theo ý của mình nhé:

Sau đây là ý hiểu của mình về đoạn video trên, Agile gồm có 12 nguyên lý:

Thoả mãn yêu cầu của khách hàng thông qua việc giao sản phẩm sớm và liên tục.
Chào đón việc thay đổi yêu cầu, thậm chí là những thay đổi yêu cầu muộn.
Giao phần mềm chạy được cho khách hàng một cách thường xuyên (giao hàng tuần hơn là hàng tháng).
Nhà kinh doanh và người phát triển phải cùng nhau làm việc hàng ngay trong suốt dự án.
Các dự án được xây dựng xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc.
Trao đổi trực tiếp mặt đối mặt là phương pháp hiệu quả nhất để truyền đạt thông tin.
Phần mềm chạy được là thước đo chính của tiến độ.
Agile Project khuyến khích phát triển bền vững, Khách hàng, team và người dùng nên duy trì được nhip độ phát triển một cách liên tục.
Liên tục quan tâm đến kĩ thuật và thiết kế để cải tiến sự linh hoạt.
Sự đơn giản là cần thiết - nghệ thuật tối đa hoá lượng công việc chưa hoàn thành.
Những bản kiến trúc, yêu cầu, thiết kế tốt nhất được tạo ra từ những team tự tổ chức.
Thường xuyên nhìn nhận đánh giá làm sao để hiệu quả hơn, từ đó thay đổi và thích ứng.

Các nguyên lý này, cùng với bốn tuyên ngôn sẽ định hướng cho các nhà thực hành Agile (agile practictioner) vận dụng tốt các phương pháp Agile vào thực tiễn.

4. Đặc trưng của Agile

Các đặc trưng sau sẽ giúp chúng ta xác định xem liệu một phương pháp triển triển phần mềm nào đó có phải là Agile hay không.

Tính lặp (Iterative): Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại. Các phân đoạn (được gọi là Iteration hoặc Sprint) này thường có khung thời gian ngắn (từ một đến bốn tuần). Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử (với các mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm. Các phương pháp agile thường phân rã mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không thực hiện việc lập kế hoạch dài hạn.

Tính tăng trưởng (Incremental) và tiến hóa (Evolutionary): Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng. Các phần nhỏ này thường là đầy đủ, có khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng ngay (gọi là potentially shippable product increment of functionality). Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn. Khác với mô hình phát triển Thác nước – vốn chỉ cho phép nhìn thấy toàn bộ các chức năng tại thời điểm kết thúc dự án, sản phẩm trong các dự án agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ để phát hành.
Tính thích nghi (adaptive): Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc lập kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu v.v.) đều có thể được đáp ứng theo cách thích hợp.
Nhóm tự tổ chức và liên chức năng: Cấu trúc nhóm agile thường là liên chức năng(cross-functionality) và tự tổ chức(self-organizing). Theo đó, các nhóm này tự thực hiện lấy việc phân công công việc mà không dựa trên các mô tả cứng về chức danh (title) hay làm việc dựa trên một sự phân cấp rõ ràng trong tổ chức. Các nhóm này cộng tác với nhau để ra quyết định, theo dõi tiến độ, giải quyết các vấn đề mà không chờ mệnh lệnh của các cấp quản lý. Họ không làm việc theo cơ chế “mệnh lệnh và kiểm soát” (command and control). Nhóm tự tổ chức có nghĩa là nó đã đủ các kĩ năng (competency) cần thiết cho việc phát triển phần mềm, do vậy nó có thể được trao quyền để tự ra quyết định, tự quản lí và tổ chức lấy công việc của chính mình để đạt được hiệu quả cao nhất.
Quản lý tiến trình thực nghiệm (Empirical Process Control): Các nhóm agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tính toán lý thuyết hay các tiền giả định (prescription). Việc phân nhỏ dự án thành các phân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập dữ kiện cho phép điều chỉnh các chiến lược phát triển của mình. Nói cách khác, Agile rút ngắn vòng đời phản hồi (short feedback life cycle) để dễ dàng thích nghi và gia tăng tính linh hoạt. Theo thời gian, các chiến lược này sẽ tiến gần đến trạng thái tối ưu, nhờ đó nhóm có thể kiểm soát được tiến trình, và nâng cao năng suất lao động.
Giao tiếp trực diện (face-to-face communication): Một số mô hình phát triển phần mềm dựa rất nhiều vào công việc giấy tờ, từ việc thu thập yêu cầu người dùng, viết đặc tả hệ thống, các thiết kế hệ thống v.v. Agile không phản đối công dụng của công việc tài liệu hóa, nhưng đánh giá cao hơn việc giao tiếp trực diện thay vì gián tiếp thông qua giấy tờ. Về yêu cầu của khách hàng, agile khuyến khích nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ thuộc nhiều vào các loại văn bản. Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình viên (thực hiện việc mã hóa) và một kĩ sư (thực hiện việc thiết kế) giao tiếp với nhau thông qua bản thiết kế, agile khuyến khích hai người này trực tiếp trao đổi và thống nhất với nhau về thiết kế của hệ thống và cùng nhau triển khai thành các chức năng theo yêu cầu.
Phát triển dựa trên giá trị (value-based development): Một trong các nguyên tắc cơ bản của agile là “phần mềm chạy tốt chính là thước đo của tiến độ”. Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm. Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng), cộng tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho dự án. Nhờ đó các dự án agile thường giúp khách hàng tối ưu hóa được giá trị của dự án. Một cách gần như trực tiếp, agile gia tăng đáng kể độ hài lòng của khách hàng.

Phụ thuộc vào mức độ rõ ràng của requirements và độ khó của technology sẽ giúp chúng ta lựa chọn quy trình phát triển phù hợp.

5. Các phương pháp Agile

Ta có thể hiểu Agile là một tập rule, không định nghĩa một phương pháp cụ thể để đạt được những điều này, nhưng lại có nhiều phương pháp phát triển phần mềm khác nhau thỏa mãn và hướng theo các tiêu chí đó.

Bảng thống kê một phần này cho thấy phần lớn các công ty hiện nay đã bắt đầu sử dụng Scrum như là cách tiếp cận cơ bản. Bên cạnh đó, nhiều công ty đã kết hợp các phương pháp lại với nhau trong thực tiễn. Ví dụ 44.4 % các công ty có sử dụng Waterfall, như vậy có nghĩa là một tỉ lệ nhất định nào đó vừa dùng waterfall, vừa sử dụng Scrum trong hoạt động của mình. Điều này có thể do các nguyên nhân lịch sử, hoặc các ràng buộc về chính sách, luật pháp hoặc văn hóa. Đó cũng là một tình huống khá phổ biến đối với các công ty mới lần đầu “bước chân” vào “ma trận các phương pháp Agile”.

Vậy Scrum là gì? Hãy đón xem phần tiếp theo nhé!

Tổng kết

Trên đây là phần giới thiệu tổng quan về Agile, khái niệm, 4 nguyên ngôn và 12 nguyên lý, các đặc trưng của Agile và cuối cùng là các phương pháp Agile. Cảm ơn các bạn đã đọc bài viết này! 😃))

Xin chào và hẹn gặp lại!