Làm thế nào Agile CNTT có thể biến đổi ngành công nghiệp CNTT?

NộI Dung

• Tại sao phải nhanh nhẹn CNTT?
• Phương pháp Agile giải quyết các vấn đề của mô hình thác nước như thế nào?
• Agile đã tác động đến ngành CNTT như thế nào?
• 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ý do BT chuyển sang thực hành Agile
• Quản lý yêu cầu kém
  
• Thiết kế phần mềm kém
• Những hạn chế phát triển
• BT đã làm gì để giải quyết các vấn đề trên?
• Phần kết luận

Nguồn: Darkovujic / Dreamstime.com

Lấy đi:

Đối với nhiều người, mô hình thác nước phát triển phần mềm đã trở thành tiêu chuẩn trong nhiều thập kỷ, nhưng giờ đây nó đã được thay thế bằng phương pháp Agile linh hoạt hơn nhiều.

Phương pháp Agile để phát triển phần mềm có thể tác động tích cực đến ngành CNTT. Các kết quả của việc áp dụng phương pháp Agile có thể được đo lường bằng một số cách. Quay vòng nhanh hơn các yêu cầu thay đổi phần mềm, ít lỗi hơn, đo lường định lượng hiệu suất của nhóm và các tắc nghẽn là tất cả các phản ánh về việc triển khai thành công Agile. Để đo lường thành công tác động của Agile, một tổ chức cần so sánh các số liệu khác nhau liên quan đến sự phát triển trước Agile và sau Agile. Tác động thực sự của Agile không thể được đo lường chỉ bằng việc tăng doanh thu hoặc bằng cách tăng số lượng lỗi đã được sửa. Một số thông số nội bộ cần được xem xét để hiểu tác động thực sự. (Để biết thêm về phát triển Agile, hãy xem Phát triển phần mềm Agile 101.)

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

Ngành công nghiệp CNTT đã nghiêng về thực tiễn Agile chủ yếu vì những hạn chế của mô hình thác nước phát triển phần mềm. Nói chung, người ta đã thấy rằng các công ty CNTT không thể đáp ứng nhu cầu thay đổi của khách hàng hoặc tình hình thị trường hoặc giảm chi phí với mô hình thác nước phát triển phần mềm. Ngay cả khi chúng ta đối trọng với độ nghiêng áp đảo này đối với phương pháp Agile và coi một số sự phấn khích chỉ là cường điệu, có rất nhiều phản hồi theo kinh nghiệm chống lại mô hình thác nước.

Nói một cách đơn giản, mô hình thác nước là một mô hình phát triển phần mềm, nơi công việc được thực hiện một cách tuần tự - hết giai đoạn này đến giai đoạn khác. Có năm giai đoạn của mô hình này: yêu cầu, thiết kế, thực hiện, xác minh và bảo trì. Thông thường, sau khi một giai đoạn đã được hoàn thành, rất khó, nếu không nói là không thể thực hiện các thay đổi cho giai đoạn trước đó. Vì vậy, giả định là các yêu cầu được cố định khá nhiều. Sự khác biệt chính với mô hình Agile là ở giả định rằng sẽ không có thay đổi trong yêu cầu. Agile cho rằng các tình huống kinh doanh sẽ thay đổi và các yêu cầu cũng vậy. Vì vậy, phần mềm được phân phối theo khối nhỏ hơn ss, trong khi đó trong mô hình thác nước, lần phân phối hoặc phát hành đầu tiên được thực hiện sau một thời gian dài. (Để biết thêm về phát triển, hãy xem Cách Apache Spark giúp phát triển ứng dụng nhanh chóng.)

Những lời chỉ trích đáng chú ý nhất đối với mô hình thác nước là giả định của nó rằng sẽ không có thay đổi trong yêu cầu. Giả định rất thiếu sót và không thực tế. Ví dụ, vào năm 2001, một nghiên cứu về 1.027 dự án CNTT ở Hoa Kỳ đã chỉ ra rằng giả định này là lý do lớn nhất cho sự thất bại của các dự án CNTT.

Trong một ví dụ khác, Craig Larman, tác giả của cuốn sách "Phát triển nhanh và lặp lại: Hướng dẫn của người quản lý" đã chỉ ra cách một số dự án được Bộ Quốc phòng (DoD) thực hiện bằng mô hình thác nước ở Mỹ đã thất bại đạt được mục tiêu của họ. Trong suốt những năm 1980 và 1990, DoD được yêu cầu sử dụng mô hình thác nước cho các dự án phát triển phần mềm của mình theo các tiêu chuẩn được công bố trong DoD STD 2167. Thống kê gây sốc cho thấy 75% các dự án phần mềm này không bao giờ được sử dụng. Sau báo cáo này, một nhóm đặc nhiệm đã được đưa ra dưới thời Tiến sĩ Frederick Brooks, một chuyên gia kỹ thuật phần mềm nổi tiếng. Lực lượng đặc nhiệm đã đưa ra một báo cáo nhận xét rằng DoD STD 2167 cũng cần một cuộc đại tu triệt để để phản ánh thực tiễn tốt nhất hiện đại. Phát triển tiến hóa là tốt nhất về mặt kỹ thuật, nó tiết kiệm thời gian và tiền bạc.

Bốn giả định sau đây của mô hình thác nước đã thất bại trong các tình huống thực tế:

• Các yêu cầu được đưa ra được xác định hợp lý và do đó, sẽ không thay đổi đáng kể.
• Ngay cả khi các yêu cầu thay đổi trong giai đoạn phát triển, chúng sẽ đủ nhỏ để được cung cấp trong chu kỳ phát triển.
• Tích hợp hệ thống, xảy ra sau khi phân phối phần mềm, sẽ đi theo kế hoạch.
• Đổi mới phần mềm và nỗ lực cần đổi mới sẽ đi theo một lịch trình được lên kế hoạch và dự đoán.

Phương pháp Agile giải quyết các vấn đề của mô hình thác nước như thế nào?

Phương pháp Agile khác về cơ bản với mô hình thác nước và điều đó rõ ràng với các giả định của nó:

• Không ai, thậm chí không phải khách hàng, có thể biết hoặc hiểu đầy đủ các yêu cầu. Không có gì đảm bảo rằng các yêu cầu sẽ không thay đổi.
• Thay đổi yêu cầu có thể không nhỏ và có thể quản lý được. Trong thực tế, chúng sẽ có nhiều kích cỡ khác nhau và sẽ tiếp tục đến. Vì vậy, phần mềm sẽ được phân phối theo từng bước nhỏ để theo dõi các thay đổi.

Agile đã tác động đến ngành CNTT như thế nào?

Agile đang được áp dụng ở rất nhiều nơi, trong khi rất nhiều công ty đang lên kế hoạch áp dụng Agile. Mặc dù Agile chắc chắn đã thực hiện những thay đổi cơ bản cho ngành CNTT, nhưng sự thật và số liệu vẫn còn một chút khó khăn để có được. Nhưng tác động của Agile có thể được hiểu với trường hợp nghiên cứu về British Telecom (BT) được đưa ra dưới đây.

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

Bạn không thể cải thiện kỹ năng lập trình của mình khi không ai quan tâm đến chất lượng phần mềm.

Lý do BT chuyển sang thực hành Agile

BT bắt đầu gặp một số vấn đề với các hoạt động phát triển phần mềm từ năm 2004. BT đã phát triển một số dự án phần mềm, cả đơn giản và phức tạp. Nhiều dự án phần mềm không thể phát triển đầu ra chất lượng trong khung thời gian đã thỏa thuận. BT thấy rằng các vấn đề nợ gốc rễ của họ cho mô hình thác nước. Vì vậy, củng cố mô hình thác nước sẽ không giúp được gì. Các nguyên nhân chính của các vấn đề được đưa ra dưới đây:

Quản lý yêu cầu kém

• Quá nhiều yêu cầu đã được đưa ra để được thực hiện trong một thời gian quá giới hạn.
• Nhiều yêu cầu không liên quan đến nhu cầu kinh doanh.
• Hầu như tất cả, nếu không phải tất cả các yêu cầu được gán trạng thái ưu tiên cao.
• Các yêu cầu đại diện cho nhu cầu kinh doanh hiện tại mà không để mắt đến các kịch bản trong tương lai. Điều đó đã bỏ ngỏ khả năng thay đổi phần mềm trong tương lai.

Thiết kế phần mềm kém

• Với số lượng yêu cầu khổng lồ, các nhà thiết kế đã dành quá nhiều thời gian chỉ để cố gắng tìm hiểu ý nghĩa của các yêu cầu. Ít thời gian còn lại để thiết kế thực tế.
• Các nhà phân tích yêu cầu chuyển sang các bài tập khác, mang theo những kiến ​​thức không thành thật, ngầm.
• Hai yếu tố trên dẫn đến thiết kế kém. Các nhà thiết kế vẫn phải giao hàng theo dòng thời gian ban đầu.

Những hạn chế phát triển

Mã hóa là vội vàng và chất lượng kém vì thiết kế phần mềm thiếu sót. Các nhà phát triển sẽ nhận ra rằng một thiết kế phần mềm kém sẽ dẫn đến mã kém, tuy nhiên phải cung cấp theo dòng thời gian đã thỏa thuận. Rất nhiều lỗi sẽ được báo cáo trong quá trình tích hợp vì các bài kiểm tra đơn vị và kiểm tra hồi quy không được chạy.

Vào thời điểm phần mềm được triển khai, khách hàng lưu ý rằng các yêu cầu đã thay đổi và kịch bản kinh doanh cũng vậy. Phần mềm cũng có rất nhiều vấn đề. Hiệu quả, toàn bộ nỗ lực phát triển phần mềm hiện được coi là lãng phí.

BT đã làm gì để giải quyết các vấn đề trên?

BT nhận ra rằng việc củng cố mô hình thác nước không phải là câu trả lời cho các vấn đề. Nó cần một cách tiếp cận mới. Vì vậy, nó đã quyết định thực hiện phương pháp Agile. Theo cách tiếp cận mới, những điều sau đây đã được quyết định:

• Thay vì chu kỳ phát triển 12 tháng, BT giờ đây sẽ cung cấp các phần mềm khả thi trong chu kỳ 90 ngày. Ý tưởng là tập trung vào một hoặc hai vấn đề kinh doanh và nhắm mục tiêu cung cấp giải pháp phần mềm trong vòng 90 ngày. Sự khởi đầu của chu trình này được đánh dấu bằng một cuộc thảo luận căng thẳng giữa các bên liên quan khác nhau để các yêu cầu được xác định rõ ràng, phân tích và ưu tiên.
• Mục tiêu là cung cấp các giá trị kinh doanh rõ ràng, hữu hình. Các khách hàng nội bộ đã chịu áp lực để cung cấp các yêu cầu rõ ràng. Vì vậy, thay vì những mục tiêu mơ hồ, những câu chuyện của người dùng đã được đưa ra với tiêu chí chấp nhận rõ ràng.
• Phần mềm sẽ được cung cấp sẽ được kiểm tra và ghi lại đầy đủ. Phần mềm sẽ trải qua các bài kiểm tra tích hợp thường xuyên để xác định các vấn đề trước đó.

Với phương pháp Agile, BT có thể thích ứng với các yêu cầu thay đổi hoặc tình huống kinh doanh dễ dàng hơn. Chất lượng mã được cải thiện và các lỗi cơ bản vào phút cuối đã được xử lý.

Phần kết luận

Agile, vì tất cả các lợi thế của nó và sự cường điệu xung quanh nó, vẫn đang ở giai đoạn mà tiềm năng của nó chưa được thực hiện đầy đủ. Điều này là do rất nhiều tổ chức đang tùy chỉnh cách tiếp cận đến mức sửa đổi các nguyên tắc ban đầu của nó. Do đó, mô hình thác nước đang trở lại trong một số trường hợp. Mặc dù việc tùy chỉnh sẽ tiếp tục, điều quan trọng là giữ lại các nguyên tắc cơ bản của Agiles. Rất nhiều tổ chức tuyên bố là Agile hoàn toàn, nhưng họ vẫn còn một số cách để trở thành một công ty Agile thực sự.