Đã gần 2 thập kỷ kể từ khi Agile – phương pháp phát triển sản phẩm nhanh/ linh hoạt ra đời, và nhanh chóng in sâu trong tâm trí của mọi người. Các nhóm tiếp thị với chính sách gấp rút thử nghiệm sản phẩm, các nhóm vận hành sản phẩm áp dụng mô hình scrum và các nhóm nhân sự thì tìm cách mang lại sự linh hoạt hơn cho các chiến lược của mình.

Vậy còn các nhóm CNTT thì sao? Có rất nhiều tranh luận trong vấn đề đâu là framework tốt nhất để agile, nhưng về bản chất, agile thực sự chỉ là một bộ nguyên tắc giúp giải quyết các dự án lớn và phức tạp.

Agile – nên hay không?

Thông thường, các dự án CNTT phức tạp, luôn đòi hỏi sự liên kết giữa các chức năng (cross-functional alignment). Các nhóm CNTT muốn hoạt động nhanh chóng và áp dụng mô hình lặp đi lặp lại (iterative), nhưng đôi khi điều này là không thể khi xem xét đến tất cả các đầu vào cần thiết để thực hiện một dự án và ảnh hưởng của chúng đến mọi khía cạnh của công việc kinh doanh. Hơn nữa, các nhóm CNTT không phải lúc nào cũng có khả năng sử dụng cách tiếp cận lặp đi lặp lại trong tất cả các dự án.

Agile không chỉ là làm rõ các yêu cầu và hiểu về toàn bộ dự án trước khi công việc bắt đầu. Đối với một sản phẩm kết hợp giữa các công ty lớn, các yêu cầu đầu cuối và kết quả cuối cùng cần được hiểu rõ trước khi bắt tay vào làm việc. Vậy thì có thể áp dụng agile trong một dự án khổng lồ như thế hay không?

Atlassian nghĩ là có thể, nhưng có lẽ không phải agile mà bạn đang nghĩ đến.

Hãy nhớ rằng, agile không phải là một bộ các quy tắc mà mọi người cần phải tuân theo. Nó là một phương pháp, một tập hợp các nguyên tắc và giá trị mà các nhóm luôn cố gắng tuân thủ mỗi ngày. Trong công nghệ phần mềm, các nhóm thường sử dụng một khung như Scrum hoặc Kanban để xác định các công việc, nhưng đối với một dự án mà các khung đó không phù hợp, thì không có nghĩa rằng đó không phải là agile, đặc biệt là trong giai đoạn đầu xây dựng nền tảng cho dự án. Agile có thể rất đơn giản, chỉ là nhìn vào mục tiêu của dự án, chia nó thành các phần nhỏ có thể hoàn thành được, và quá trình lặp đi lặp lại trên các phần nhỏ đó.

Waterfall hữu ích khi nào?

Cùng xem xét một dự án cụ thể: thay thế một hệ thống thanh toán.

Vấn đề đặt ra là các yêu cầu tổng thể của hệ thống thường phụ thuộc lẫn nhau và đôi khi mâu thuẫn nhau. Hãy xem xét một tình huống cụ thể, chẳng hạn như khách hàng mua một sản phẩm và nhận được mã giảm giá khi sử dụng một phần mềm dịch vụ có tính phí hàng tháng (SaaS), hoặc khách hàng mua một số lượng lớn nhiều sản phẩm khác nhau từ một nhà sản xuất.

Khi nào các yêu cầu sẽ được giải quyết? Khi nào bạn sẽ bắt đầu xây dựng sản phẩm đầu tiên? Bạn có để các thành viên của sản phẩm thứ hai tham gia quá trình xây dựng hệ thống để có thể giải quyết các nhu cầu của sản phẩm thứ nhất hay không? Điều gì xảy ra khi có nhiều gói sản phẩm (multiple bundling) hoặc có một số lượng lựa chọn cực kỳ lớn có sẵn trên các cấu hình khác hoặc được kích hoạt tự động thay thế, chẳng hạn như trên 5 sản phẩm? Lúc này, cách tiếp cận agile bắt đầu trở nên không phù hợp.

Các yêu cầu nghiệp vụ (business requirements) xác định cái gì, còn các yêu cầu về giải pháp (solution requirements) xác định cách làm như thế nào. Bạn không nhất thiết phải hoàn toàn tuân theo mô hình thác nước (waterfall) và chờ đợi những dòng mã nguồn đầu tiên được viết ra cho đến khi hoàn thiện tất cả các yêu cầu nghiệp vụ và tất cả các yêu cầu giải pháp, nhưng bạn cần kết nối tất cả mọi thứ lại với nhau để mang lại một giải pháp đầu cuối (end-to-end solution) cho các yêu cầu nghiệp vụ và kỹ thuật. Đồng thời, bạn cần xác nhận giải pháp này với các bên liên quan, trải qua những cuộc kiểm định gắt gao đối với edge cases – những tình huống xảy ra trong điều kiện khắc nghiệt nhưng có khả năng là một nhiệm vụ quan trọng.

Điều này còn quan trọng hơn nếu bạn làm trong một doanh nghiệp Nhà nước, chẳng hạn như chăm sóc sức khỏe hay công nghiệp năng lượng hoặc các ngành sản xuất khác. Bắt đầu giai đoạn xây dựng mà không kiểm tra kỹ lưỡng các yêu cầu và điều luật sẽ dẫn đến một kết quả thất bại, chưa kể đến sự chậm trễ và vượt quá ngân sách.

Việc các thay đổi xuất hiện trong quá trình phát triển sản phẩm là một điều không thể tránh khỏi. Các hệ thống mới, những sự thay đổi trong yêu cầu hoặc luật lệ mới có thể ảnh hưởng đến bộ quy tắc cần tuân thủ. Do đó, giai đoạn xây dựng dự án có thể sử dụng nguyên lý của agile để linh hoạt khi cần thiết, đồng thời thêm một khoản phí trong hợp đồng khi các hệ thống và tính năng mới xuất hiện trong giai đoạn phát triển sản phẩm.

Chậm thì mượt, mà mượt thì sẽ nhanh

Tất cả chúng ta đều hiểu rằng, đôi khi cần phải chậm lại để đi nhanh hơn. Khi các doanh nghiệp CNTT chuyển đổi từ tâm lý cũ – duy trì doanh nghiệp sang tâm lý mới – phát triển, xây dựng doanh nghiệp lớn mạnh, họ cần suy nghĩ nhiều hơn ở giai đoạn khởi đầu để xây dựng những điều đúng đắn. Cho dù bạn tiếp cận theo cách nào, thì mục đích cuối cùng cũng đều là mang đến những giá trị đích thực cho khách hàng.

Nguồn: Atlassian Blog