Phát triển phần mềm Agile đề cập đến các phương pháp luận phát triển phần mềm tập trung vào ý tưởng phát triển lặp đi lặp lại, trong đó các yêu cầu và giải pháp phát triển thông qua sự hợp tác giữa các nhóm chức năng chéo tự tổ chức. Giá trị cuối cùng trong phát triển Agile là nó cho phép các nhóm phân phối giá trị nhanh hơn, với chất lượng và khả năng dự đoán cao hơn, cũng như khả năng đáp ứng với sự thay đổi cao hơn. Scrum và Kanban là hai trong số những phương pháp Agile được sử dụng rộng rãi nhất. Dưới đây là những câu hỏi thường gặp nhất xung quanh Agile và Scrum, do các chuyên gia của chúng tôi trả lời.
Agile Development là gì?
Agile là một cách tiếp cận để phát triển phần mềm ưu tiên các bản phát hành sản phẩm nhỏ, thường xuyên trong các chu kỳ phát triển lớn. Thay vì các dự án lớn, phức tạp mất vài tháng, các dự án được chia thành các đơn vị công việc nhỏ hơn để có thể được giao nhanh hơn nhiều.
Các đơn vị này được thể hiện dưới dạng câu chuyện của người dùng, trình bày chi tiết điều gì đó mà người dùng muốn hoàn thành với hệ thống. Câu chuyện của người dùng phải được giải thích rõ ràng với các kết quả được xác định rõ ràng và cho các nhà phát triển biết người dùng là ai, họ muốn đạt được điều gì và tại sao điều đó lại quan trọng đối với họ.
Các phương pháp phát triển Agile có từ những năm 1990. Năm 2001, một nhóm các nhà phát triển đã xuất bản Tuyên ngôn về Phát triển Phần mềm Agile, thường được gọi là "Tuyên ngôn Agile"
Tuyên ngôn khuyến khích các nhóm phát triển tập trung vào ba nguyên tắc chính:
Giá trị đáp ứng với sự thay đổi so với việc tuân theo một kế hoạch
Chức năng phần mềm trên tài liệu toàn diện
Hợp tác trong quá trình và thương lượng hợp đồng.
Về cốt lõi, nhanh nhẹn được thiết kế để hợp lý hóa cách tiếp cận phát triển phần mềm của một công ty nhằm cho phép nhóm CNTT, các nhóm xây dựng các tính năng và bản cập nhật quan trọng theo tốc độ của nhu cầu kinh doanh hiện đại ngày nay.
Có nhiều cách khác nhau để tổ chức quy trình làm việc nhanh nhưng có hai cách đặc biệt phổ biến:
Kanban
Kanban rất hữu ích ở những nơi không thể dễ dàng dự đoán được công việc, chẳng hạn như các phiếu hỗ trợ và sửa lỗi. Bảng Kanban được sử dụng để hình dung công việc đang tiến hành trong đó mỗi phần công việc được thể hiện bằng một thẻ trên bảng. Các cột hiển thị các bước trong quy trình và các thẻ được chuyển qua chúng (từ trái sang phải) khi công việc tiến hành.
Nếu bạn đã sử dụng Trello, bạn sẽ quen với bố cục này. Kanban ban đầu xuất phát từ sản xuất tinh gọn và giúp duy trì tiến độ công việc ở mức có thể quản lý được. Chìa khóa của Kanban là khái niệm về công việc đang thực hiện trong tiến trình có giới hạn (WIP). Tổng số WIP không bao giờ được vượt quá dung lượng đã thỏa thuận - nếu bạn đang ở mức giới hạn thì phải hoàn thành một việc gì đó trước khi có thể bắt đầu một nhiệm vụ mới.
Scrum
Scrum là cách tiếp cận mà chúng tôi thấy được áp dụng rộng rãi nhất trong các nhóm SAP. Cách tiếp cận này sử dụng các chu kỳ phát triển ngắn, dài cố định từ hai đến bốn tuần được gọi là chạy nước rút. Trong thời gian chạy nước rút, nhóm sẽ làm việc để phát triển một số lượng câu chuyện người dùng đã thống nhất để hoàn thành. Làm việc theo chu kỳ ngắn giúp bạn có thể phân phối giá trị nhanh hơn. Nhóm có thể nhận được phản hồi sớm hơn và lặp lại, cải thiện chất lượng của phần mềm. Cải tiến liên tục cả sản phẩm và quá trình phát triển là trọng tâm của triết lý Scrum.
Tại sao Agile lại quan trọng?
Phát triển Agile có nhiều lợi thế hơn so với mô hình phát triển thác nước truyền thống thường được sử dụng trong môi trường SAP.
Trong mô hình thác nước (waterfall), công việc được lên kế hoạch từ đầu đến cuối trước khi bất kỳ sự phát triển nào bắt đầu. Tất cả thiết kế được thực hiện trước khi bắt đầu mã hóa và mã hóa được hoàn thành trước khi bắt đầu thử nghiệm. Điều đó hoạt động tốt, miễn là mọi thứ có thể dự đoán được. Nhưng thật không may, nó hiếm khi thành công. Nếu các vấn đề với thiết kế được tìm thấy trong giai đoạn mã hóa (hoặc thậm chí là giai đoạn thử nghiệm), có thể cần phải làm lại rất nhiều để đưa dự án trở lại đúng hướng.
Các dự án Waterfall có thể mất hàng tháng, hoặc thậm chí hàng năm, điều này khiến việc đáp ứng nhanh chóng các nhu cầu kinh doanh đang thay đổi là cực kỳ khó khăn. Vào thời điểm phần mềm đã được triển khai, các yêu cầu của người dùng có thể đã thay đổi. Các tổ chức khó có thể duy trì lợi thế cạnh tranh nếu họ buộc phải đợi hàng tháng giữa các lần cập nhật nhỏ.
Một cách tiếp cận nhanh để phát triển phần mềm giúp:
-
Cung cấp giá trị nhanh hơn: Các yêu cầu quan trọng nhất có thể được cung cấp nhanh hơn nhiều. Trong mô hình Waterfall, không có gì được triển khai cho đến khi mọi thứ đã được xây dựng và thử nghiệm.
-
Giảm thiểu sự không chắc chắn: Phương pháp nhanh nhạy đáp ứng và thậm chí chấp nhận những thay đổi trong yêu cầu. Nó thừa nhận rằng phát triển phần mềm là lặp đi lặp lại và không phải lúc nào cũng có thể trình bày rõ ràng tất cả các yêu cầu ngay từ đầu.
-
Giảm tác động và rủi ro: Với những thay đổi nhỏ hơn, sẽ có ít nguy cơ bị hỏng hóc hơn. Sẽ dễ dàng thấy trước vấn đề hơn khi phạm vi nhỏ hơn và dễ kiểm tra hơn. Cũng có ít tác động hơn đối với người dùng khi các bản cập nhật nhỏ được phân phối thường xuyên so với các thay đổi lớn, không thường xuyên.
-
Ưu tiên và luôn phù hợp: Các nhóm Agile chọn câu chuyện của người dùng nào để phát triển cho mỗi sprint và có thể chọn chúng dựa trên các ưu tiên kinh doanh của ngày hôm nay.
-
Luôn tiết kiệm ngân sách: Việc theo dõi chi phí nhanh hơn sẽ dễ dàng hơn vì các tính năng đã hoàn thiện đang được phân phối thường xuyên. Khó hơn nhiều để theo dõi chi phí trong một dự án phát triển dài mà không có gì tồn tại cho đến khi kết thúc.
-
Tăng khả năng hiển thị: Cung cấp các tính năng làm việc thường xuyên hơn và cộng tác với doanh nghiệp giúp tăng khả năng hiển thị và hiểu biết trong tổ chức.
-
Nhưng còn việc triển khai nhanh nhẹn trong các môi trường phức tạp như SAP thì sao? Mặc dù các cảnh quan SAP có các yêu cầu phát triển độc đáo, các phương pháp luận nhanh nhẹn vẫn có thể được sử dụng.