Phát triển phần mềm Agile 101

NộI Dung

Tóm tắt về Vòng đời phát triển phần mềm
Tại sao phát triển Agile khác nhau
Thực hành Agile
Tại sao phải đi nhanh nhẹn?
Không lỗi, không căng thẳng - Hướng dẫn từng bước của bạn để tạo ra phần mềm thay đổi cuộc sống mà không phá hủy cuộc sống của bạn

Lấy đi:

Phương pháp phát triển phần mềm này khuyến khích sự hợp tác và linh hoạt để giúp cung cấp một sản phẩm chất lượng cao.

Đã có rất nhiều tiếng vang xung quanh Agile trong thế giới phát triển ứng dụng và công nghệ phần mềm. Agile không phải là một khái niệm, mà là một tư duy. Như tên cho thấy, nó tập trung vào sự linh hoạt và năng động. Phương pháp này cũng loại bỏ sự cô lập giữa các giai đoạn phát triển phần mềm và khuyến khích nhóm phát triển cộng tác với (các) nhà phân tích chất lượng. Nó cũng nhấn mạnh sự tham gia của khách hàng để phát triển, xây dựng và cung cấp một sản phẩm chất lượng cao. Ở đây hãy xem Agile, cách thức hoạt động và một số thực tiễn tốt nhất cho phương pháp phát triển phần mềm phổ biến này.

Tóm tắt về Vòng đời phát triển phần mềm

Vòng đời phát triển phần mềm (SDLC) là quá trình tạo ra các giải pháp phần mềm hoặc sửa đổi các cấu trúc hiện có nhằm phục vụ cho một vấn đề cụ thể. Nó bao gồm các bước khác nhau, được theo thứ tự hợp lý. Trong các mô hình SDLC truyền thống, đây là các bước được thực hiện lần lượt từng bước một và thường được thực hiện một cách cô lập:

Yêu cầu thu thập từ khách hàng
Phân tích hệ thống và tính khả thi
Thiết kế và mô hình
Mã hóa hoặc thực hiện
Kiểm tra
Triển khai và giao hàng
Yêu cầu bảo trì và thay đổi

Trong một chu trình phát triển phần mềm điển hình, người dùng thực tế hoặc khách hàng, tham gia vào quá trình thu thập yêu cầu và sau đó trong quá trình thử nghiệm beta. Tuy nhiên, vấn đề với mô hình truyền thống này là phần bảo trì của chu trình trở thành một vấn đề khó khăn và khá tốn kém. Nhiều lần, không có phạm vi cho các cải tiến hoặc thay đổi trong hệ thống. Trong trường hợp xấu nhất, phần mềm đã được thiết kế hoặc phát triển không phù hợp với thông số kỹ thuật và mong đợi thực tế của khách hàng, điều đó có nghĩa là nhóm phát triển có thể cần phải bắt đầu lại toàn bộ quá trình.

Tại sao phát triển Agile khác nhau

Các mô hình truyền thống phổ biến nhất của SDLC - mô hình thác nước, mô hình ứng dụng nhanh, mô hình lặp, mô hình xoắn ốc, v.v. - có những ưu và nhược điểm riêng. Phải mất nhiều thời gian trước khi mọi người thực sự có thể phân tích mức độ thực tế của những mô hình này. Chúng hoàn toàn phù hợp với các kịch bản lý tưởng, nhưng chúng không thực tế khi nói đến các ứng dụng trong thế giới thực. Kết quả là các nhóm phát triển phần mềm phải đối mặt với rất nhiều thách thức. Một số hạn chế của các mô hình SDLC thông thường bao gồm:

Chúng không cho phép các yêu cầu được thay đổi ở các giai đoạn sau vì chúng được đóng băng trong tài liệu đặc tả yêu cầu phần mềm. Trong một số trường hợp nhất định, người dùng mong đợi không được nói hoặc hiểu sai.
Người dùng cuối không nhìn thấy hệ thống cho đến khi hoàn thành. Điều này cung cấp rất ít phạm vi để đưa ra đề xuất và thay đổi.
SDLC truyền thống có thể tạo ra một khoảng cách giao tiếp lớn giữa các nhà phát triển và người thử nghiệm, vì chúng là các giai đoạn riêng biệt và không có sự hợp tác giữa hai bên.
Kiểm tra hộp trắng không thể được thực hiện một cách hiệu quả.

Việc sử dụng Agile giải quyết nhiều vấn đề này bởi vì thay vì theo quy trình từng bước, nó hoạt động như một triết lý và khuôn khổ nhằm giúp các nhóm cộng tác, phản hồi để thay đổi và xây dựng một sản phẩm hoàn chỉnh bao gồm nhiều đầu vào từ tất cả các bên, bao gồm cả người dùng.

Thực hành Agile

Sự xuất hiện của phương pháp Agile không kém gì một cải cách mang tính cách mạng trong phương pháp phát triển phần mềm, bởi vì nó cung cấp đủ chỗ cho các nhóm dự án sáng tạo và linh hoạt trong khi vẫn nắm quyền sở hữu tập thể cho từng giai đoạn của sản phẩm. Bằng cách đi theo con đường Agile, những người tham gia trong nhóm phát triển phần mềm có thể tạo điều kiện cho tâm trí của họ nắm lấy sự không chắc chắn, đối phó với các thay đổi và xây dựng một sản phẩm tốt hơn như một quy trình, thay vì trong các bước rời rạc, không bị ràng buộc.

Mặc dù không có danh sách toàn diện về các nguyên tắc Agile, nhưng có một số thực tiễn nhất định mà Agile truyền bá. Bao gồm các:

Kiểm tra hướng phát triển (TDD)
Lý tưởng nhất, các nhà phát triển trước tiên nên viết các trường hợp thử nghiệm cho phần chức năng mà họ sẽ mã hóa. Điều này sẽ đảm bảo mã chất lượng tốt, ít có khả năng bị phá vỡ trong các điều kiện đặc biệt. Quá trình này cũng giúp đảm bảo rằng các thông số kỹ thuật của người dùng đã được giải quyết.
Lập trình cặp
Trong phát triển Agile, các lập trình viên thường làm việc với cùng một vấn đề theo cặp, trong đó một người đang viết mã (trình điều khiển) và người còn lại đang xem xét mã và cung cấp ý tưởng và đề xuất (hoa tiêu). Điều này giúp tăng năng suất và giảm thời gian cần thiết để xem lại mã.
Lập trình lại
Tái cấu trúc mã liên quan đến việc chia nhỏ mã thành các mô đun nhỏ hơn và đơn giản hơn có thể (và nên) tồn tại độc lập trong kịch bản lý tưởng. Điều này cải thiện khả năng đọc, kiểm tra và khả năng duy trì của mã đến một mức độ lớn.
Sự tham gia tích cực từ các bên liên quan thực tế
Theo các khoảng thời gian đều đặn của một khoảng thời gian xác định (gọi là "ss"), khách hàng sẽ nhận được một nguyên mẫu hoạt động đáng kể của phần mềm. Điều này cho phép các nhà phát triển nhận phản hồi về những gì họ đang xây dựng khi họ đi.
Đối xử với các yêu cầu như một ngăn xếp ưu tiên
Trong Agile, điều cần thiết là phân loại các yêu cầu trên cơ sở tầm quan trọng của chúng. Điều này có thể bao gồm cả mong đợi của khách hàng tiềm ẩn cũng như rõ ràng về sản phẩm phần mềm đang được phát triển. Nhóm phát triển phần mềm nên ước tính chung thời gian và tài nguyên mà họ sẽ đầu tư để triển khai tính năng này và lập bản đồ dựa trên yêu cầu của người dùng và thứ tự tương đối mà họ sẽ giải quyết từng phần của dự án.
Kiểm tra hồi quy
Kiểm tra hồi quy bao gồm kiểm tra chức năng của toàn bộ ứng dụng sau khi thêm một tính năng mới hoặc sửa đổi chức năng hiện có trong mã. Điều này giúp đảm bảo rằng các thay đổi không phá vỡ mã hiện có.

Tại sao phải đi nhanh nhẹn?

Agile quy định một số thực tiễn nhất định, nhưng nó không áp dụng chúng cho nhóm phát triển phần mềm. Rốt cuộc, nếu không có phạm vi điều chỉnh và sai lệch, mục đích của Agile phần lớn bị đánh bại. Việc kết hợp thậm chí một vài khía cạnh của phát triển Agile vào dự án có thể giúp các nhóm phát triển phần mềm đối phó với các thách thức không lường trước được và cuối cùng, xây dựng một sản phẩm tốt hơn theo cách hiệu quả hơn.