Lập trình trên một chiếc mainframe cần một cấu trúc và quy trình nhất định. Điều này gây ra vấn đề cho các doanh nghiệp đang tìm cách khai thác khả năng của các hệ thống mới này vì không có phương pháp nào có sẵn để tạo các hệ thống doanh nghiệp. Vì vậy, họ đã xem xét các ngành khác để được hướng dẫn.
Ngành xây dựng lại đang bùng nổ vào thời điểm đó. Trong ngành xây dựng, mọi thứ phải tuân theo một quy trình nghiêm ngặt, trong đó mỗi một bước đi tiếp theo đều phụ thuộc vào việc hoàn thành bước đi trước đó trong quy trình. Nếu muốn hoàn thiện một tòa nhà đứng vững và đáp ứng thiết kế ban đầu, ta không thể bắt đầu xây dựng cho đến khi bạn có kế hoạch và phân tích các yêu cầu đối với tòa nhà. Quá trình suy nghĩ này được liên kết độc đáo với phát triển phần mềm, và sự phức tạp của việc thiết kế và xây dựng một tòa nhà cũng đã được liên kết với quá trình tạo ra các hệ thống phần mềm. Waterfall, dựa trên cách tiếp cận của ngành xây dựng, đã trở thành một trong những cách tiếp cận SDLC phổ biến nhất. Như minh họa trong Hình 2-2, Waterfall là một cách tiếp cận nối tiếp
để phát triển phần mềm được chia thành các giai đoạn:
Requirements/analysis: Các tính năng của phần mềm cũng như những nhu cầu của người dung được liệt kê ra và đánh giá, từ đó xác định được những chức năng cần thiết của phần mềm.
Design: Kiến trúc phần mềm được xác định và lập thành tài liệu.
Coding: Phần mềm bắt đầu được xây dựng, dựa trên thiết kế đã xác định trước đó.
Testing: Phần mềm đã hoàn thành được kiểm tra chất lượng và được khách hàng chấp nhận.
Maintenance: Các bản sửa lỗi và bản vá được thêm vào.
Hình 2.2 Waterfall
Mặc dù cách tiếp cận này đã hoạt động thành công trong nhiều năm, nhưng một số thiếu sót đã trở thành điểm yếu trong cách tiếp cận này. Thứ nhất, bản chất của Waterfall là một thác nước, nói một cách dễ hiểu hơn, phạm vi của một dự án phần mềm bị cố định ở giai đoạn thiết kế. Trong xây dựng, việc thay đổi tầng đầu tiên của một tòa nhà sau khi bạn đã bắt đầu xây tầng thứ năm là vô cùng khó khăn, thậm chí có thể không thực hiện được trừ khi bạn đập bỏ tòa nhà và bắt đầu lại từ đầu. Về bản chất, cách tiếp cận Waterfall không xử lý tốt sự thay đổi.
Cuối cùng khi đến giai đoạn viết code của quá trình phát triển ứng dụng, bạn có thể biết rằng tính năng bạn đang xây dựng không còn cần thiết nữa hoặc bạn khám phá ra một cách mới để đạt được mục tiêu thiết kế; tuy nhiên, bạn không thể đi chệch khỏi kiến trúc đã định trước nếu không thực hiện lại phân tích và thiết kế. Xui thay, việc bắt đầu lại thường khó khăn hơn là tiếp tục xây dựng. Việc này giống như xây một cây cầu qua sông mà không còn ai cần qua bờ sông bên kia nữa.
Khía cạnh thách thức thứ hai của Waterfall là phần mềm sẽ không có giá trị cho đến khi kết thúc toàn bộ quá trình. Chúng ta viết ra một phần mềm để tự động hóa một số chức năng cũng như hỗ trợ khả năng kinh doanh và giá trị chỉ được nhận ra khi phần mềm có thể tạo ra kết quả đó. Với cách tiếp cận Waterfall, ngay cả khi ta đã hoàn thành một nửa dự án, phần mềm của chúng ta vẫn chưa chạy được hoặc không có giá trị nào có thể sử dụng để hiển thị cho doanh nghiệp. Hình 2-3 cho thấy khái niệm này.
Hình 2.3 Vấn đề giá trị của Waterfall
Khía cạnh thứ ba của Waterfall là chất lượng. Như đã đề cập trước đó, thời gian là kẻ thù khi nói đến việc cung cấp giá trị. Nếu chúng ta không bị giới hạn về thời gian, chúng ta có thể tạo ra phần mềm hoàn hảo mọi lúc mọi nơi, nhưng đơn giản là chúng ta không sống trong thế giới đó. Khi các nhà phát triển phần mềm hết thời gian, việc testing thường bị ảnh hưởng hoặc bị bỏ qua dưới danh nghĩa đưa dự án ra ngoài. Ba thách thức đối với Waterfall đã dẫn đến việc phát triển một cách mới để tạo ra phần mềm nhanh hơn, tốt hơn và thích ứng hơn với môi trường thay đổi nhanh chóng.
Lean
Sau Thế chiến II, Nhật Bản đang rất cần được xây dựng lại. Hầu hết các khả năng sản xuất của Nhật Bản đã bị phá hủy, bao gồm cả những năng lực trong ngành công nghiệp ô tô. Khi Nhật Bản giải quyết việc xây dựng lại này, họ không chỉ tập trung vào các tòa nhà và cơ sở hạ tầng; họ đã xem xét các cách để làm mọi thứ khác nhau. Với nỗ lực này, Hệ thống Sản xuất Toyota (TPS) đã ra đời. Được tạo ra bởi Taiichi Ohno và Sakichi Toyoda (người sáng lập Toyota), quy trình quản lý và sản xuất này tập trung vào các khái niệm quan trọng sau:
Elimination of waste: Nếu thứ gì đó không tạo ra giá trị cho sản phẩm cuối cùng, hãy loại bỏ nó. Không có chỗ cho công việc lãng phí.
Just-in-time:: Đừng xây dựng thứ gì đó cho đến khi khách hàng sẵn sàng mua nó. Tồn kho dư thừa gây lãng phí tài nguyên.
Continuous improvement (Kizan): Luôn cải tiến quy trình của bạn với các bài học kinh nghiệm và giao tiếp.
Trong khi những khái niệm này có vẻ rõ ràng và thực tế một cách rõ ràng, TPS là cách đầu tiên thực hiện những nguyên tắc này như một triết lý quản lý. TPS là bước khởi đầu của phương pháp sản xuất tinh gọn tổng quát hơn đã được giới thiệu với thế giới phương Tây vào năm 1991 thông qua một cuốn sách do Womack, Jones và Roos viết, The Machine That Changed the World. Cuốn sách này dựa trên một nghiên cứu kéo dài 5 năm của MIT về TPS, và nó đã được ghi nhận là đã đưa các khái niệm của mô hình Lean ra ngoài ngành công nghiệp ô tô.
Tại sao lại dành thời gian này để nói về những cuốn sách quản lý cũ mốc? Lean đã dẫn đến sự phát triển phần mềm Agile, đã đóng vai trò như một cột thu lôi thay đổi cho các hoạt động CNTT.
Agile
Agile là một cách phát triển phần mềm dựa trên những nguyên tắc của Lean. Với Agile, tất cả các bài học kinh nghiệm trong việc tối ưu hóa quy trình sản xuất đã được áp dụng vào nguyên tắc tạo phần mềm. Năm 2001, 17 nhà phát triển phần mềm đã hội tụ tại khu nghỉ mát Snowbird ở Utah để thảo luận về các phương pháp phát triển phần mềm nhẹ hơn, mới hơn. Mệt mỏi vì thiếu thời gian, tài liệu vô tận và sự thiếu linh hoạt của các phương pháp phát triển phần mềm hiện có, những người tiên phong Agile này đã tạo ra bản “Tuyên ngôn cho Phát triển Phần mềm Agile”, hệ thống hóa các nguyên tắc hướng dẫn cho các phương pháp phát triển Agile. 12 nguyên tắc sau là cốt lõi của Tuyên ngôn Agile:
Sự hài lòng của khách hàng được cung cấp thông qua việc phân phối sớm và liên tục các phần mềm có giá trị.
Những yêu cầu thay đổi, ngay cả khi phát triển muộn, đều được hoan nghênh.
Phần mềm làm việc được phân phối thường xuyên (theo tuần chứ không phải tháng).
Quá trình này phụ thuộc vào sự hợp tác chặt chẽ hàng ngày giữa các bên liên quan của doanh nghiệp và các nhà phát triển.
Các dự án được xây dựng xung quanh những cá nhân có động cơ, những người cần được tin cậy.
Trò chuyện mặt đối mặt là hình thức giao tiếp tốt nhất (colocation).
Phần mềm làm việc là thước đo chính của sự tiến bộ.
Phát triển bền vững đòi hỏi phải có khả năng duy trì một tốc độ.
Liên tục chú ý đến sự xuất sắc về kỹ thuật và thiết kế tốt.
Simplicity — nghệ thuật tối đa hóa số lượng công việc chưa hoàn thành là thiết yếu.
Các kiến trúc, yêu cầu và thiết kế tốt nhất phải xuất hiện từ các nhóm tự tổ chức.
Một nhóm phải thường xuyên phản ánh về cách trở nên hiệu quả hơn và điều chỉnh cho phù hợp .
Những nguyên lý cốt lõi này là nguồn gốc chính của phong trào Agile. Mary Poppendieck và Tom Poppendieck đã cho ra cuốn “Lean Software Development: An Agile Toolkit” (Phát triển phần mềm tinh gọn: Bộ công cụ Agile) vào năm 2003, dựa trên các nguyên tắc của Tuyên ngôn Agile và nhiều năm kinh nghiệm phát triển phần mềm của họ. Cuốn sách này vẫn được coi là một trong những cuốn sách hay nhất về các ứng dụng thực tế của Agile.
Phát triển phần mềm thông qua Agile cho kết quả đầu ra rất khác so với cách làm chậm chạp và nối tiếp của Waterfall. Với Waterfall, một dự án không được xem là "hoàn thành" cho đến khi dự án kết thúc. Với Agile, khung thời gian được thay đổi: Agile sử dụng khoảng thời gian nhỏ hơn (thường là 2 tuần), còn được gọi là "sprints", bao gồm toàn bộ quá trình phân tích, thiết kế, viết mã và kiểm tra nhưng trên một khía cạnh nhỏ hơn nhiều của ứng dụng. Mục tiêu là để hoàn thành một tính năng hoặc ít nhất là một khả năng nào đó trong mỗi sprint, dẫn đến một mảnh của phần mềm có thể bàn giao được. Do đó, với Agile, nếu bạn chỉ mới hoàn thành 40% một dự án, bạn vẫn có một phần mềm sử dụng được 100%. Hình 2-4 cho thấy quá trình này trông như thế nào trên dòng thời gian.
Hình 2.4 Agile Development Practices
Bằng cách tận dụng Agile cho việc phát triển phần mềm, doanh nghiệp đã có thể gia tăng giá trị ngay lập tức và nhanh chóng thích ứng với sự thay đổi. Nếu phần mềm của chúng ta cần một chức năng mới, cũng như một chức năng khác đã được lên kế hoạch những chợt nhận ra không còn cần thiết nữa, thì dự án cũng có thể nhanh chóng thực hiện những thay đổi đó.
