Mô hình kiểu thác nước (waterfall)
Được giới thiệu vào năm 1970 bởi Winston Royce, mô hình thác nước (Waterfall) chia việc phát triển phần mềm thành các giai đoạn tuần tự. Mỗi giai đoạn được thiết kế để thực hiện một hoạt động cụ thể và phải được hoàn thành trước khi giai đoạn tiếp theo có thể bắt đầu mà không có sự chồng chéo giữa các giai đoạn.
Mô hình trên có thể được sử dụng được khi:
1. Yêu cầu được mô tả rõ ràng và không thay đổi thường xuyên
2. Công nghệ ổn định, ít biến động
3. Nhân sự được đào tạo và sẵn sàng hoàn thành công việc
Nhưng thực tế là:
1. Một dự án phần mềm thường có hơn 35% yêu cầu ban đầu sẽ phải thay đổi.
2. Các công nghệ chưa từng sử dụng hoặc phải thay đổi trong quá trình thực hiện dự án.
3. Nhân sự có trình độ kỹ năng khác nhau, thái độ làm việc khác nhau, cách thực hiện công việc cũng rất khác nhau và khó dự đoán.
Báo cáo của Chaos, năm 1994
Báo cáo CHAOS năm 1994 cho thấy gần 84% số dự án được mô tả là thất bại một phần hoặc hoàn toàn, trong khi chỉ có khoảng 16% tổng số dự án được phân loại là thành công.
Các vấn đề phổ biến khiến dự án thất bại là:
Đồ thị Stacey là một công cụ hữu ích để đánh giá tính chắc chắn hoặc khả năng dự đoán của công việc. Nó có thể được sử dụng để mô hình hóa ba chiều trong phát triển phần mềm: yêu cầu, công nghệ và con người.
Đồ thị Stacey
Yêu cầu: Từ “làm theo thỏa thuận”, không có rủi ro thay đổi ==> “khác xa với thỏa thuận”, hay các mô tả mơ hồ và có nhiều thay đổi.
Công nghệ: Từ “gần như chắc chắn” ==> “rất ít chắc chắn” liên quan nhiều công nghệ khác nhau trong các dự án phức tạp.
Con người: Từ “biết rõ và ổn định” với một số lượng nhỏ người trong một nhóm ==> các dự án phần mềm liên quan đến hơn năm người, hoặc hàng trăm người và hay thay đổi.
Như vậy, sử dụng đồ thị Stacey, chúng ta thấy rằng các dự án phát triển phần mềm ít nhất là ở vùng phức tạp và đôi khi đến vùng hỗn loạn. Như vậy, mô hình waterfall khó mà giải quyết được các vấn đề phức tạp và biến động trong phát triển sản phẩm phần mềm.
Vào những năm 1990, nhiều phương pháp phát triển phần mềm kiểu mới ra đời để vận hành các dự án phần mềm phức tạp. Các phương pháp mới dựa trên lý thuyết kiểm soát quy trình thực nghiệm hay còn gọi là chủ nghĩa kinh nghiệm. Chủ nghĩa kinh nghiệm khẳng định kiến thức có được từ kinh nghiệm và đưa ra quyết định dựa trên những gì đã biết.
Các phương pháp mới sử dụng cách tiếp cận lặp đi lặp lại, gia tăng để tối ưu hóa khả năng dự đoán và kiểm soát rủi ro.
Agile iterative-incremental delivery
Scrum đã được sử dụng để quản lý công việc trên các sản phẩm phức tạp từ đầu những năm 1990 sau đó được xuất bản vào năm 1995 bởi hai đồng sáng lập Jeff Sutherland và Ken Schwaber.
Tham khảo thêm bài viết “Scrum là gì”
Crystal Method được phát triển bởi Alistair Cockburn vào những năm 1990, là một nhóm các phương pháp Agile tinh gọn. Chúng được coi là tinh gọn bởi vì những phương pháp này xem quy trình là thứ yếu và thay vào đó đặt trọng tâm vào các yếu tố khác. Các yếu tố này là:
Crystal có tám màu sắc khác nhau, tượng trưng cho "tầm quan trọng" của dự án. Tám màu sắc này là:
Một dự án nhỏ, đơn giản có thể sử dụng phương pháp như Crystal Clear, Crystal Orange hoặc Crystal Yellow. Nếu dự án là một nhiệm vụ quan trọng, nơi tính mạng con người có thể bị đe dọa thì các phương pháp Crystal Diamond hoặc Crystal Sapphire sẽ được sử dụng.
Nếu dự án không liên quan đến nguy cơ tiềm ẩn đến tính mạng con người mà chỉ thay đổi về số lượng con người. Crystal sử dụng 5 màu sắc khác nhau tương ứng với 5 quy mô của dự án.
05 màu sắc tướng ứng với 5 quy mô khác nhau của dự án Crystal
Các phương pháp Crystal cùng chia sẻ 7 thuộc tính:
1. Phát hành thường xuyên (frequent delivery)
Thường xuyên cung cấp phần mã đã qua kiểm thử, làm việc được cho người dùng thực. Bằng cách này, nhà phát triển sản phẩm đảm bảo đã không đầu tư sức lực và thời gian vào sản phẩm mà không ai muốn mua.
2. Cải tiến (Reflective improvement)
Với phương pháp Crystal, ý tưởng về các nhóm tổ chức các cuộc họp cải tiến vài tuần một lần được khuyến khích. Các cuộc họp này giúp tìm ra các quy trình đang hoạt động không tốt và giúp nhóm sửa đổi chúng.
3. Giao tiếp gần/thẩm thấu (Close or osmotic communication)
Giao tiếp thẩm thấu nghĩa là thông tin hữu ích chảy giữa các thành viên trong nhóm khi họ làm việc gần nhau và họ tình cờ nghe được các cuộc trò chuyện của nhau.
Nhóm phải ở trong cùng một phòng để thông tin được truyền đi nhanh chóng trong nhóm. Các câu hỏi có thể được trả lời nhanh chóng và tất cả các thành viên trong nhóm đều biết chuyện gì đang xảy ra cũng như có khả năng sửa chữa mọi quan niệm sai lầm có thể phát sinh.
Chi phí giao tiếp được giảm đáng kể bằng cách sử dụng loại hình giao tiếp này. Nhu cầu cập nhật email, tài liệu bổ sung, v.v. được giảm xuống. Bằng cách tập hợp nhóm lại với nhau, mỗi thành viên biết những người khác đang làm gì để họ có thể đảm nhận các phần của đồng đội trong dự án nếu cần.
4. Môi trường an toàn (Personal safety)
Môi trường an toàn, mọi người không e ngại chia sẻ quan điểm cá nhân và thoải mái lên tiếng về các vấn đề hoặc bất cứ điều gì phát sinh.
5. Sự tập trung (Focus)
Tập trung vào công việc để đạt được tiến độ và tập trung mục tiêu chung của dự án
6. Dễ dàng tiếp cận người dùng chuyên gia (Easy access to expert users)
Điều này liên quan đến việc các nhà phát triển làm việc với một chuyên gia trong lĩnh vực dự án để chuyên gia trả lời bất kỳ câu hỏi nào, đề xuất giải pháp cho các vấn đề, v.v. Người dùng chuyên gia phải là người dùng thực tế chứ không chỉ là tester từ nhóm phát triển.
7. Môi trường kiểm thử tự động và tích hợp thường xuyên (Technical environment with automated tests, configuration management and frequent integration
Ý tưởng đằng sau điều này là cần có sự tích hợp và kiểm thử liên tục để nếu có bất kỳ thay đổi nào xảy ra thì các lỗi, sự cố, v.v. có thể được phát hiện. Nếu điều này được thực hiện thường xuyên, các sự cố ít xảy ra hơn vì chúng đã được phát hiện và xử lý sớm trong dự án.
(Nguồn: Wikiversity)
XP là một phương pháp phát triển phần mềm đặt trọng tâm vào sự hài lòng của khách hàng. Điều này đảm bảo rằng những gì đang được sản xuất dựa trên nhu cầu của khách hàng. Một trong những cách để thực hiện điều này là chuyển đổi câu chuyện người dùng (user stories) thành sản phẩm kinh doanh có giá trị (valuable business assets).
Một đặc điểm quan trọng của phương pháp XP là giao tiếp liên tục và cởi mở. Nếu không có khía cạnh quan trọng này, việc áp dụng sẽ không hiệu quả như mong đợi. Một lợi ích quan trọng của phong cách giao tiếp này là tăng sự tự tin cho cả khách hàng và nhóm dự án.
XP được tạo ra để đáp ứng nhu cầu trên thị trường nhằm đáp ứng những thay đổi liên tục mà các nhà cung cấp dịch vụ đang phải đối mặt trong khi phát triển một sản phẩm hoặc dịch vụ mới. Thành công của nó có thể là do khía cạnh giao tiếp và hợp tác giữa tất cả các bên tham gia vào dự án. Điều này có nghĩa là khách hàng, người quản lý, các nhóm và bất kỳ ai khác có liên quan sẽ làm việc cùng nhau từ thời điểm thiết lập phạm vi, câu chuyện người dùng, cho đến kiểm thử và phát hành cuối cùng.
Phương pháp này được thiết kế cho các dự án nhỏ, mặc dù cũng được áp dụng thành công ở các dự án lớn.
Extreme Programming (XP) làm việc như thế nào?
Bước đầu tiên trong XP là thu thập các user stories cũng như tiến hành các giải pháp thử nghiệm với các user stories có rủi ro cao.
Sau đó, một cuộc họp lập kế hoạch phát hành phải được lên lịch. Ở giai đoạn này, phải mời tất cả những người quan trọng bao gồm khách hàng, các nhóm dự án và người quản lý. Mục tiêu chính ở giai đoạn này là xác định một mục tiêu chung mà mọi người đều có thể chấp nhận được. Cuộc họp và thiết lập mục tiêu này được theo sau bởi các cuộc họp lập kế hoạch lặp đi lặp lại để thống nhất về các bản phát hành tiếp theo.
Chỉ với vài bước này, nhóm dự án đã đi theo hướng phát triển các tính năng cần thiết.
Các quy tắc của XP (XP rules)
1. Lập kế hoạch
2. Quản lý
3. Thiết kế
4. Viết mã
5. Kiểm thử
Các giá trị trong XP (XP values)
1. Giao tiếp
Mọi người đều là một phần của nhóm và giao tiếp với nhau hàng ngày trong công việc.
2. Đơn giản
XP khuyến khích làm những gì cần thiết và được yêu cầu, không làm thêm. Điều này giúp tối đa hóa giá trị mang lại cho khoản đầu tư.
3. Phản hồi
XP công bố phần mềm của mình sớm, lắng nghe cẩn thận các phản hồi và thực hiện bất kỳ thay đổi nếu cần thiết.
4. Sự dũng cảm
Sự dũng cảm thể hiện ở việc nói thật về tiến độ và ước tính, không nêu lý do cho sự thất bại, và sẵn sàng thích ứng với những thay đổi.
5. Tôn trọng
Mọi thành viên đều được tôn trọng như nhau vì những cống hiến và đóng góp có giá trị dù chỉ đơn giản là sự nhiệt tình. Nhóm phát triển tôn trọng chuyên môn của khách hàng và ngược lại.
Nguồn: extremeprogramming.org
DSDM là một khung làm việc tập trung vào toàn bộ vòng đời của dự án, chỉ những công việc tối thiểu được thực hiện ở mỗi bước rồi chuyển tiếp cho bước tiếp theo. Tư duy đằng sau điều này là để thích nghi với những thay đổi liên tục của các dự án. Chẳng hạn, yêu cầu kinh doanh có thể thay đổi ngay lập tức, do đó, chỉ thực hiện các công việc cần thiết để tiết kiệm được công sức, nguồn lực và thời gian của nhóm dự án.
Các nguyên tắc của DSDM
Nguồn: Agile Business Consortium
Tất cả các phương pháp mới đều có điểm chung là tinh gọn, chú trọng vào yếu tố con người, đề cao tinh thần làm việc theo nhóm, phát hành phần mềm thường xuyên, hợp tác với khách hàng và khả năng phản ứng nhanh với sự thay đổi.
Từ ngày 12/2-14/2 năm 2001, 17 nhà sáng lập và chuyên gia trong lĩnh vực phát triển phần mềm đã gặp nhau tại một khu nghỉ mát ở Snowbird, Utah để bàn về các phương pháp phát triển kiểu mới. Sau nhiều lần thảo luận, họ đã tìm thấy sự đồng thuận xung quanh bốn giá trị cốt lõi, hình thành tuyên ngôn Agile về phát triển phần mềm, được tất cả những người tham gia ký kết.
Agile manifesto 2001
Xem lại bản gốc tuyên ngôn Agile tại https://agilemanifesto.org/
Xem 12 nguyên lý đằng sau tuyên ngôn Agile tại https://agilemanifesto.org/principles.html
Xem thêm phần giải thích các giá trị và nguyên tắc của Agile ở bài viết “Agile là gì?” phần 2.
Agile trước hết không phải là quy trình, công cụ, hay phương pháp. Agile là tư duy, triết lý, cách tiếp cận mới đề cao con người và hướng đến việc xây dựng các nhóm dự án hay tổ chức mang lại sản phẩm, dịch vụ tốt nhất cho khách hàng, có khả năng thích nghi nhanh với sự thay đổi.
Scrum, XP, Crystal, DSDM là các công cụ triển khai tư duy và triết lý Agile. Một công cụ có thể phù hợp ở môi trường hoặc sản phẩm này nhưng có thể không làm việc tốt với môi trường hoặc sản phẩm khác. Tuy nhiên, nếu hiểu đúng và vận dụng thành thạo tư duy Agile, bạn có thể tự xây dựng quy trình, công cụ hoặc phương pháp phù hợp với tổ chức hoặc nhóm dự án của bạn.
Agile umbrella
Cảm ơn các bạn đã đọc bài viết này.
Đón đọc Agile là gì? (phần 2) - Ý nghĩa tuyên ngôn Agile và 12 nguyên lý đằng sau bản tuyên ngôn Agile
Nếu bạn có câu hỏi, đánh giá, hay góp ý cho tác giả, xin vui lòng để lại comment bên dưới.
