Phần 1

Quy trình Grim hiệu quả hơn hay ít hiệu quả hơn

Quy trình này không có chút nào trong tâm trí. Hãy cân nhắc, chuyện gì xảy ra khi mà một người dùng Visual Studio cài đặt phiên bản beta và sau một tháng thì họ tìm thấy lỗi. Có thể quá trễ để thực hiện bất cứ điều gì cho phiên bản đã phát hành. Cho đến khi lỗi được sửa chữa và phê chuẩn, quy trình phát triển gần như được hoàn thành. Nếu lỗi quá nghiêm trọng thì nó có thể được chú trọng trong giai đoạn ổn định sản phẩm, nhưng trong một số trường hợp nó có thể không được sửa chữa, và cũng có thể lỗi đó có cả trong phiên bản sau này mà vẫn chưa được sửa.

Nếu lỗi vẫn tồn tại cho đến khi phát hành, chúng có nguy cơ rủi ro không được liệt kê trong danh sách sửa lỗi trong khoảng vài năm nếu chúng không được báo cáo nhanh chóng  trong giai đoạn lập kế hoạch và thiết kế sản phẩm. Và sẽ thông báo đến khách hàng biết rằng vấn đề của họ sẽ được sửa trong vòng 3 năm thì điều này sẽ làm mất lòng tin ở khách hàng, phá vỡ mối quan hệ tốt đẹp với họ.

Lỗi không phải là vấn đề duy nhất trong quy trình phát triển này. Chẳng hạn như, sau một vài năm đình trệ, tài liệu kỹ thuật của ngôn ngữ C++ vẫn đang được cập nhật với sự pha trộn nhiều bản cập nhật cho tài liệu kỹ thuật  chính của nó, những tài liệu kỹ thuật nhỏ hơn được gọi là các tài liệu kỹ thuật (TS). Các tài liệu kỹ thuật thêm vào các tính năng mới được hội tụ nhiều cách hơn, ví vụ có các tài liệu kỹ thuật cho network, truy cập filesystem,  chương trình tương tự vậy và còn rất nhiều các tài liệu kỹ thuật khác. Một vài năm tới đây, 8 tài liệu kỹ thuật này hoặc nhiều hơn  nên  được hoàn tất.

Các bản phát hành không được đồng bộ hóa với chu trình phát triển của Microsoft. Chu trình sản phẩm trong vòng hai năm có thể dễ dàng kết hợp chặt chẽ các tài liệu như thế, tài liệu kỹ thuật phải được hoàn tất một cách hợp lý nếu như không được hoàn thành một cách trọn vẹn trong giai đoạn lập kế hoạch. Nếu như bỏ lỡ chúng trong giai đoạn lập kế hoạch thì quá trễ cho một chu trình sản xuất thực tế, chúng ta phải đợi từ 18 tháng đến 24 tháng cho giai đoạn lập kế hoạch kế tiếp và 24 tháng tiếp cho phát hành sản phẩm sau đó.

Phương pháp tiếp cận hoàn toàn quy trình phát triển của Visual Studio kéo dài quanh năm. 

Thêm vào đó sự hình thành nhóm Visual Studio vô cùng lãnh đạm, phương pháp tiếp cận quy trình phát triển này không tốt cho tinh thần của nhóm. Một tính năng được phát triển suốt giai đoạn đầu của quy trình phát triển sẽ không đưa đến tay khách hàng trong vòng 18 tháng. Chu trình phát triển 3 năm của hệ điều hành Windows và bộ Office, kết quả thậm chí vô cùng tệ. Thậm chí ngay cả khi sản phẩm đã được chuyển đến người dùng cuối sử dụng, một lập trình viên vẫn có thể chờ đợi hơn hai năm. Hầu hết các lập trình viên thực sự mong muốn phần mềm của họ sẽ được sử dụng, một khi bạn thực hiện đầy đủ một số tính năng mới vô cùng tuyệt vời mà không ai sử dụng nó thì thật sự là đáng buồn, các lập trình viên thực sự không muốn điều đó xảy ra.

Với chu trình phát triển lâu dài của Microsoft, một lập trình viên không thể ở trong cùng một nhóm , có thể thậm chí không cùng công ty, suốt thời gian đó họ sẽ code trên các máy tính cá nhân của họ.

Cấu trúc phát triển có một hiệu quả tương tự. Chỉ dành ra 4 tháng để viết code mới và nghỉ ngơi suốt thời gian làm việc với một khối lượng lỗi khổng lồ không phải là điều mong đợi của bất kỳ một lập trình nào.

Và sau đó thế giới đã thay đổi

Gặp phải các vấn đề và thách thức này nhưng dù sao Microsoft vẫn thành công khủng khiếp như một lập trình viên phần mềm. Trước sự phát triển của thế giới web, các bản phát hành không thường xuyên, các rắc rối mà họ có thể gặp phải, thực sự mang nhiều ý nghĩa. Trong những ngày này, phân phối phần mềm cũng có nghĩa là chuyển đi một khối lượng lớn các đĩa mềm hoặc CD, và phải trải qua một quy trình cài đặt nhàm chán.  Giới hạn quy trình này vài năm một lần phải gặp phải không phải là một điều quá tồi tệ, và quy trình thác nước hay một số quy trình mang ý nghĩa tương đồng là một quy tắc tiêu chuẩn trong lĩnh vực công nghiệp phần mềm.

Tuy nhiên,  nó không chỉ là một quá trình phát triển, cùng với sự nổi dậy của công nghệ web thúc đẩy các phương pháp tiếp cận khác trở nên nổi bật. Các ứng dụng web thay đổi mô hình phân phối phần mềm bằng một số phương pháp quan trọng. Chúng làm cho “việc cài đặt” vượt ra khỏi các phương trình toán học. Trong khi các lập trình viên ứng dụng phải triển khai các bản cập nhật cho các máy chủ và người dùng không phải làm bất cứ việc gì cả. Họ chỉ cần ghé thăm các trang web và khám phá sự xuất hiện của các trang web hay để biết xem các tính năng được thay đổi như thế nào so với ghé thăm trước đó.

Điều này cũng tạo ra các rắc rối, phiền toái khi làm việc với phần mềm truyền thống.  Một ứng dụng web có thể tung ra những tính năng mới hoặc các thiết kế mới đến một bộ phận người dụng để đánh giá nhu cầu của người dùng và xác định cách chúng hoạt động, sau đó tùy thuộc vào sự phản ứng của người dùng để xem xét lại các tính năng hay để tung sản phẩm tới tất cả mọi người tiêu dùng. Hãy thẳng thắn kiểm thử A/B để so sánh hiệu quả của sự cạnh tranh của các bản thiết kế. Rất dễ dàng để cho các lập trình viên Web nhanh chóng thu thập cách sử dụng các dữ liệu và quyết định dựa trên các dữ liệu tìm được này.

Chúng cũng thay đổi mô hình giá cả đang lưu hành. Thay vì mua một licence vĩnh viễn cho 3 năm một lần, người sử dụng các ứng dụng Web chỉ cần hoặc là chi trả bất kì mọi thứ ( bởi vì ứng dụng mất tiền trong quảng cáo)  hoặc là chi trả cho việc mua dài hạn. Trong khi phần mềm có xu hướng “cần”có  các sự khác biệt thực tế giữa các phiên bản để bào chữa cho một số lượng lớn các bản nâng cấp mới, các ứng dụng web không tương xứng để khích lệ chuyển giao các bản cập nhật quan trọng. Các bản cập nhật ngày một cải thiện và sự cải tiến dần dần có hiệu quả.

Những tính năng này của Web cũng làm cho quy trình thác nước không phù hợp với thực tế. May mắn là quy trình thác nước không phải là mô hình duy nhất. Khi các ứng dụng web ngày một tăng trưởng thì vô cùng tốt để áp dụng các quy trình phát triển web phù hợp.

Quy trình phát triển Agile cho một thế giới đang thay đổi

Tính từ được dùng để mô tả các quá trình này là “agile”. Có nhiều quá trình phát triển agile khác nhau, nhưng tất cả những tính năng phổ biến chắc chắn vẫn được duy trì. Về cơ bản quy trình agile được thiết kế cho chu trình phát triển ngắn, quá trình cải tiến được lặp lại nhiều lần, và khả năng dễ dàng thay đổi để đáp ứng sự thay đổi.

Các quy trình phát triển lặp lại của một hay nhiều loại gần như cho sự phát triển phần mềm của chính nó. Các loại thực hành được biết đến như một sự nở rộ của quy trình “agile” vào thập niên những năm 90, nhãn hiệu “agile” được hệ thống hóa vào năm 2011 khi một nhóm  các lập trình viên công bố “Tuyên ngôn Agile” đọc là:

“Chúng tôi phát hiện ra các phương pháp tốt hơn để phát triển phần mềm bằng việc thực hành nó và giúp đỡ những người khác thực hành những điều này. Thông qua việc này chúng tôi đã đạt được những điều thực sự giá trị:

-Các cá nhân và sự tác động qua lại của các quy trình và công cụ

-Phần mềm làm việc trên tài liệu hoàn thiện

-Sự hợp tác với khách hàng thông qua việc  đàm phán hợp đồng

-Ứng phó với sự thay đổi theo sau một hoạch định

Trong khi có giá trị trong các chỉ mục bên phải, chúng tôi coi trọng các mục ở bên trái hơn.”

Quy trình phát triển agile có xu hướng đòi hỏi nhiều sự mua vào của các tổ chức. Tất cả mọi người đều chấp nhận mô hình thác nước cũ để viết một tài liệu kỹ thuật lớn, và vài tháng sau đó, một phần của phần mềm được hoàn thiện được đưa đến trình biên dịch thoải mái. Thực tế các dòng ứng dụng trong lĩnh vực kinh doanh và các ứng dụng tương tự cho phép mỗi cá nhân hoặc công ty đang đảm nhận nhiệm vụ phát triển ứng dụng để kết thúc sự tham gia sau giai đoạn thiết kế và  lập tài liệu kỹ thuật. Khi được phát triển ứng dụng bên ngoài sẽ hỗ trợ một tiêu chuẩn ngay thẳng dựa trên việc thực hiện bản hợp đồng và có suy xét đến việc tuân thủ của hai bên : các chương trình có đáp ứng các đặc điểm  kỹ thuật mà hai bên đã thỏa thuận hay không?

Tương tự như vậy hàng loạt các tài liệu đang được xem lại để bảo đảm. Các tài liệu và các tài liệu kỹ thuật cả hai đều có xu hướng đáp ứng thực tế, ngay khi không phải là một lập trình viên, phần mềm thường không đáp ứng những vấn đề này. Làm thế nào để một khách hàng có thể biết được công ty phần mềm viết phần mềm theo yêu cầu nếu như không có các tài liệu để chứng minh điều đó?

 Với quy trình agile, các tài liệu kỹ thuật này được ưu tiên nếu không bị bỏ chúng hoàn toàn. Khách hàng hoặc người sử dụng có xu hướng tham gia vào quy trình phát triển , sử dụng phần mềm khi mà phần mềm ngày một được phát triển, chuyển giao  và thường xuyên cung cấp các phản hồi về sản phẩm. 

Lợi thế của quá trình phát triển agile trái ngược với các bất lợi của quá trình phát triển thác nước. Việc thực hành đa dạng, nhưng một chu trình phát triển của một nhóm agile sẽ khoảng trong vòng 2 đến 4 tuần. Trong khi các nhóm phát triển có thể vẫn có triển vọng lâu dài hơn, những dự định mà họ muốn thực hiện trong 6 tháng tới trong năm thậm chí có thể lâu hơn nữa việc ưu tiên phát triển rõ ràng các hoạch định được xử lý trong quy mô nhỏ hơn nhiều, và điều này dễ dàng tạo ra nhiều biến đổi.

Kết quả của mỗi lần lặp đi lặp lại ngắn hạn nên được sử dụng nhiều lần hơn hoặc ít hơn. Mặc dù các tính năng quan trọng sẽ có thể được chia thành nhiều sự lặp lại, mỗi phiên bản phát triển của  phần mềm nên có thể được sử dụng. Điều này sẽ làm cho nó trở nên dễ dàng hơn đối với các thông tin phản hồi được chuyển giao. Có thể cách bố trí trên màn hình vụng về; có thể các tính năng  không hoạt động như những gì mà mọi người mong đợi nó làm việc thì có thể chúng là lỗi. Trong bất kỳ trường hợp nào, các kiểm thử viên phần mềm và người dùng có thể phản ứng lại đối với những gì mà họ thấy trước khi họ nói cho các lập trình viên sao cho phù hợp với hoàn cảnh.

Trong khoảng thời gian ngắn, các lập trình viên phải đáp ứng các nhu cầu này.

Phần 3

Nguồn bài viết : arstechnica.com