Một thời gian dài Microsoft mang tiếng xấu như một lập trình viên phần mềm. Vấn đề mà Microsoft gặp phải không phải là chất lượng phần mềm, mà là cách họ phát triển và phát hành sản phẩm của mình. Mô hình truyền thống của công ty bao gồm việc sản xuất ra một phiên bản mới quan trọng của Office, Windows, SQL Server, Exchange trong 3 năm một lần hoặc trong nhiều năm.

Các phiên bản phát hành có thể không thường xuyên, nhưng việc trì hoãn hoặc ít nhất có ý tưởng trì hoãn là hoàn toàn không có. Danh tiếng của Microsoft không bao giờ gắn liền với thực tại, công ty có xu hướng tạo ra các thông báo trịnh trọng cho đến ngày công ty công bố phần mềm, nhưng những bản rò rỉ, thông tin ảo, hay những động thái quan sát thị trường là những việc mà Microsoft hay áp dụng.  Hệ điều hành Windows 95 đã phát hành trễ, Windows 2000 cũng vậy, Windows Vista thì lại rất trễ chỉ ra đi sau khi phần mềm chính thức bị loại bỏ.

Mặc dù có những điều đó xảy ra, nhưng Microsoft đã thành công một cách khủng khiếp. Sau tất cả những việc đó, nhiều đối thủ cạnh tranh của họ đã làm việc nhiều hơn hoặc ít hơn với cách tương tự, vài năm một lần lại phát hành những phiên bản cập nhật phần mềm. Microsoft đã không thực hiện bất kỳ sự khác biệt cá biệt nào. Thậm chí ngày cả việc trì hoãn cũng không thường lệ, với cả đối thủ của Microsoft và tất cả  những dự án phát triển phần mềm phải chịu đựng những điều này.

Không có lý do đặc biệt nào cho các phát hành và trì hoãn định kỳ này. Phát triển phần mềm là một lĩnh vực kinh doanh phức tạp và được coi là khô khan đáng ngạc nhiên; không có một cách chính xác nào để phát triển và quản lý một dự án. Đó không phải là một quy trình hay một phương pháp cụ thể để bảo đảm rằng một đội nhóm có đủ khả năng có thể làm việc thực sự có chất lượng , tạo ra một phần mềm chất lượng đảm bảo đúng tiến độ và đủ ngân sách đầu tư. Một hệ thống làm việc tốt với một nhóm trên một dự án có thể dễ dàng bị sai sót mà chuyển sang một nhóm khác hay trên một dự án khác.

Nhưng dù sao đi nữa, các nhà khoa học máy tính, các kỹ sư phần mềm và các lập trình viên luôn cố gắng để mô tả và chính thức hóa các quy trình khác nhau trong việc xây dựng và phát triển phần mềm. Quy trình được liên kết với Microsoft theo lịch sử, quy trình được biết đến với hầu hết các quy trình phát triển và việc trì hoãn của họ được biết như  quy trình thác nước.

Tiền đề cơ bản là sự phát triển ngày càng đi vượt bậc. Các yêu cầu của một phần mềm được thu thập lại và sau đó phần mềm được thiết kế từ các yêu cầu đã được tập hợp đó, sau có quá trình thiết kế phần mềm được thực thi, sau khi hoàn thành phần mềm được kiểm tra và xác định chất lượng, quá trình sản xuất phần mềm hoàn tất sau đó phần mềm được chuyển đi, cùng với đó là sự bảo trì phần mềm để phần mềm luôn được đảm bảo tốt nhất.

Mô hình thác nước

Mô hình thác nước luôn luôn bị ngờ vực. Thậm chí lần đầu tiên được đặt tên và mô tả vào những năm thập niên 70, nó không phải là một quy trình lý tưởng mà các tổ chức mong đợi. Đúng hơn là , đó là một sự mô tả về một quy trình mà các tổ chức đã sử dụng cùng với các thiếu sót, làm cho quy trình này không phù hợp với hầu hết các công việc trong phát triển phần mềm.

Tuy nhiên quy trình này đã được duy trì đến ngày nay, vẫn được sử dụng phổ biến bởi vì nó có một sự lôi cuốn về trực giác. Trong công nghiệp sản xuất và xây dựng, công việc thiết kế phải được hoàn tất trước tiên bởi vì có những thứ như là những chiếc xe hơi hay một tòa nhà thì vô cùng khó khăn để thay đổi một khi mà chúng đã được làm ra và đã xây dựng xong. Vì vậy bắt buộc giai đoạn thiết kế nên thiết kế chính xác nhất có thể trước khi bắt đầu một dự án nào. Đó là cách duy nhất để chúng ta tránh được chi phí thu hồi xe cộ và sự giật xuống của tòa nhà.

Phần mềm thì dễ dàng hơn và chi phí rẻ hơn khi thay đổi so với các tòa nhà¸nhưng để hình thành một phần mềm chính xác theo yêu cầu một cách hiệu quả thì đầu tiên công việc thiết kế phần mềm là vô cùng quan trọng, hơn là chúng ta xây dựng một số thứ xong rồi sau đó lại thay đổi. Mặc dù, quy trình thác nước bị phê bình rộng rãi. Có thể vấn đề lớn nhất là điều đó, nó không như những chiếc xe hơi hay là các tòa nhà, nhìn chung chúng ta có một hiểu biết hạn hẹp về phần mềm. Trong khi có một số chương trình điều khiển các chuyến bay với các yêu cầu chặt chẽ, khít khao , cùng với các thuật toán nghiêm ngặt thì hầu như chúng hay thay đổi nhiều hơn cả.

Chẳng hạn như, nhiều công ty phát triển các ứng dụng trong nhà để tự động quy trình kinh doanh đa dạng. Dĩ nhiên với việc phát triển những ứng dụng  này, chúng ta thường nhận ra là quy trình cũ không còn tuyệt vời và phù hợp cho các ứng dụng đó nữa. Các lập trình viên phải khám phá ra những bước nào thừa, hay hai quy trình nào nên được hợp nhất lại thành một, hay chúng nên được tách ra làm hai.  Thực hành cách bố trí các mô hình điện tử tương tự trên các miếng giấy gương, có thể cho bạn dễ dàng hình dung hơn, nhưng thường là trong trường hợp này, việc sắp xếp lại các mô hình có thể tạo sự logic hơn. Các quy trình được suy nghĩ ra để có thể dễ dàng hiểu được và được thể hiện trên các cuốn sách mà chúng ta có thể nhận thấy có chút khác nhau trong việc thực hành.

Thường thì, những điều này chỉ được khám phá sau khi quy trình phát triển bắt đầu, cũng như suốt quá trình phát triển hoặc thậm chí sau khi quá trình phát triển kết thúc chuyển đến người dùng cuối.

Thật tuyệt vời khi mà  chúng ta cố gắng hoàn tất tất cả các bản thiết kế trước tiên. Các bản thiết kế có thể là một ý tưởng hoàn toàn  tốt, nhưng nếu bản thiết kế sai hoặc cần thiết phải thay đổi để đáp ứng hồi đáp của khách hàng hoặc nếu  không giải quyết được vấn để mà mọi người hy vọng rằng nó có thể giải quyết (là điều vô cùng phổ biến), thì dự án đó không thành công. Nếu chúng ta chờ đợi cho đến khi kết thúc quá trình thác nước mới nhận ra những bài toán này đồng nghĩa với việc mất nhiều thời gian và tiền bạc, điều đó hoàn toàn sai lầm.

Phát triển nền tảng Visual Studio bằng mô hình thác nước

Microsoft không áp dụng mô hình thác nước này theo cách thuần túy nhất, quy trình phát triển phần mềm của nó hơi lặp đi lặp lại nhiều lần nhưng giống với mô hình thác nước.

Một ví dụ hay đến từ nhóm Visual Studio về cách làm việc này. Khoảng một vài năm về trước, Visual Studio có chu trình phát hành nhanh hơn hệ điều hành Windows và Office. Những phiên bản chính sẽ phát hành hai năm một lần hoặc hơn là ba năm một lần.

Chu trình hai năm bị chia thành nhiều giai đoạn nhỏ. Có 4 đến 6 tháng để lập kế hoạch và thiết kế chu trình làm việc. Mục tiêu là tính toán ra những chức năng gì mà đội nhóm mong muốn thêm vào sản phẩm các cách để thêm vào. 6 tháng đến 8 tuần tiếp theo tiến hành code, sau khi code hoàn thành tiến hành kiểm thử và gỡ lỗi trong chu trình 4 tháng vững vàng.

Suốt giai đoạn này, nhóm kiểm thử sẽ tìm lỗi, còn các lập trình viên sẽ phải sửa đổi nhiều nhất các lỗi có thể  mà các kiểm thử viên tìm ra. Không có phát triển mới nào xảy ra trong suốt quá trình này, giai đoạn này là chỉ tìm lỗi và sửa lỗi thôi.

Tóm lại qua giai đoạn ổn định này, phiên bản beta sẽ được sản xuất. Có hai chu trình phát triển phần mềm kéo dài 6 đến 8 tuần, và sau đó là 4 tháng để ổn định sản phẩm và đưa ra sản phẩm chất lượng đến người tiêu dùng. Sản phẩm hoàn tất là việc hợp nhất tất cả các quy trình này.

Hơn một vài tuần quản lý sự chuyển tiếp giữa các giai đoạn phát triển phần mềm, khoảng thời gian mở rộng cho việc sửa đổi vào những phút cuối kể cả phiên bản beta và phiên bản cuối cùng được hoàn tất, và một vài tuần để sửa đổi lại giữa các version, kết quả là một quy trình phát triển kéo dài hai năm trong đó chỉ trong vòn 4 tháng là khoảng thời gian dành cho việc viết code. Và 8 tháng dành ra để sửa đổi code.

Cấu trúc tổ chức của Microsoft có xu hướng phản ánh phương pháp tiếp cận sự phát triển này. Công ty có 3 vị trí xứng đáng: quản lý chương trình (PM), chịu trách nhiệm xác định và thiết kế các chức năng, lập trình viên (developer) chịu trách nhiệm xây dựng các chức năng đó, và QA chịu trách nhiệm đảm bảo chất lượng các chức năng được tạo ra. Ba vị trí đó đóng vai trò tương đương nhau (các quản lý chương trình báo cáo cho quản lý các quản lý chương trình v.v)

Phần 2

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