Có những lợi thế cho các thực hành nhanh nhẹn ngoài việc xây dựng hoạt động giữa các lần chạy nước rút?

Gần đây tôi đã trở nên quan tâm đến các thực tiễn nhanh trong phát triển phần mềm và từ đó tôi đã thấy rất nhiều bài viết chỉ ra rằng các thực tiễn này cho phép giảm chi phí chung.

Logic đằng sau thường diễn ra như sau: nếu yêu cầu của bạn thay đổi, bạn có thể phản ánh sự thay đổi này trong lần tồn đọng nước rút tiếp theo và điều này sẽ dẫn đến giảm chi phí, vì thiết kế tính năng mới và thực hiện nó gần nhau về mặt thời gian, vì vậy chi phí đi xuống, theo quy tắc nổi tiếng rằng bạn càng cần phải thay đổi yêu cầu của mình thì càng tốn kém để đáp ứng yêu cầu đó.

Nhưng các dự án phần mềm từ trung bình đến lớn rất phức tạp. Thay đổi yêu cầu đột ngột không có nghĩa là bạn sẽ không phải chạm vào các phần khác trong hệ thống của mình để đáp ứng yêu cầu đó. Trong rất nhiều trường hợp, kiến ​​trúc sẽ cần phải được sửa đổi rất đáng kể, điều đó cũng có nghĩa là bạn sẽ cần phải thực hiện lại tất cả các tính năng dựa trên kiến ​​trúc cũ. Vì vậy, toàn bộ điểm giảm chi phí sẽ biến mất ở đây. Tất nhiên, nếu một yêu cầu mới yêu cầu một phần độc lập mới của hệ thống, đó không phải là vấn đề, kiến ​​trúc cũ chỉ phát triển, nó không cần phải được xem xét lại và thực hiện lại.

Và ngược lại. Nếu bạn đang sử dụng thác nước và bạn đột nhiên nhận ra rằng một yêu cầu mới phải được đưa ra, bạn có thể đi và thay đổi thiết kế của mình. Nếu nó yêu cầu kiến ​​trúc hiện tại bị thay đổi, bạn thiết kế lại nó. Nếu nó không thực sự gây rối với nó mà chỉ giới thiệu một phần mới của hệ thống, thì bạn hãy đi và làm tất cả công việc, không có vấn đề gì ở đây.

Như đã nói, dường như đối với tôi, sự phát triển nhanh nhẹn duy nhất là tính năng hoạt động được xây dựng hoàn chỉnh giữa các lần chạy nước rút, và đối với nhiều người và dự đoán điều này không quan trọng. Ngoài ra, agile có vẻ như dẫn đến kiến ​​trúc phần mềm kém về tổng thể, bởi vì các tính năng bị đánh vào nhau, các nhóm nhanh nhẹn chỉ quan tâm rằng một tính năng hoạt động chứ không phải cách nó hoạt động. Điều này có vẻ như khi các hệ thống phát triển phức tạp theo thời gian, các thực tiễn phát triển nhanh thực sự làm tăng sự hỗn loạn trong kiến ​​trúc sản phẩm tổng thể, do đó cuối cùng dẫn đến chi phí cao hơn, vì sẽ ngày càng khó khăn hơn để giới thiệu các thay đổi, trong khi thác nước cho phép bạn hoàn thiện kiến ​​trúc của mình trước khi bạn phát hành bất cứ điều gì.

Ai đó có thể vui lòng chỉ cho tôi biết tôi đang sai ở đâu không, vì rõ ràng rất nhiều người sử dụng nhanh nhẹn trong môi trường sản xuất, vì vậy tôi phải sai ở đâu đó.

Trước hết, mô hình "thác nước" luôn là một người rơm mô tả cách KHÔNG chạy dự án phát triển phần mềm. Tìm kiếm.

Dù sao đi nữa, hầu hết các dự án SDLC "thác nước" đều yêu cầu quá trình "Quản lý thay đổi", khi mọi người phát hiện ra rằng các giả định được ghi trong thông số kỹ thuật không còn hiệu lực (và điều này luôn xảy ra đối với các dự án phức tạp lớn). Thật không may, quy trình quản lý thay đổi được xây dựng như một biện pháp xử lý ngoại lệ và rất tốn kém, có nghĩa là dự án sẽ kết thúc muộn hoặc có chất lượng kém.

Ý tưởng đằng sau các phương pháp của Agile là sự thay đổi là có sẵn - nó sẽ xảy ra. Do đó, bạn phải thực hiện thao tác chuẩn "quản lý thay đổi" thay vì xử lý ngoại lệ. Điều này không dễ, nhưng mọi người đã thấy rằng nếu bạn sử dụng nhiều thực hành thiết kế tốt, bạn có thể làm được.

Một vấn đề lớn khác với thiết kế tải phía trước là (thường xuyên nhất) rất nhiều thời gian dành cho việc thu thập yêu cầu và thiết kế, phát triển và thử nghiệm phải chịu đựng thời gian. Ngoài ra, nếu thử nghiệm là giai đoạn cuối và một vấn đề nghiêm trọng được phát hiện, rất khó có khả năng khắc phục trong khung thời gian của bạn.

Có lẽ một trong những tính năng tốt nhất của cách tiếp cận Agile là nó đòi hỏi sự tương tác liên tục (nghĩa là giao tiếp thực sự) giữa nhóm phát triển giải pháp và khách hàng cần nó. Các ưu tiên được thực hiện, để các mục ưu tiên cao nhất được thực hiện trước tiên (và nếu hết thời gian, đó là các mục ưu tiên thấp bị cắt). Phản hồi đến nhanh chóng.

Quay trở lại câu hỏi về những thay đổi mạnh mẽ - bạn thực sự cần sử dụng các phương pháp giảm thiểu thay đổi. Hiệu trưởng OO RẮN tốt có thể đóng một phần tốt trong việc này, vì có thể xây dựng các bộ kiểm thử tự động vững chắc để bạn có thể hồi quy kiểm tra phần mềm của mình. Bạn nên làm những việc này bất kể phương pháp của bạn là gì, nhưng chúng trở nên thực sự cần thiết nếu bạn đang cố gắng nhanh nhẹn.

Vâng, có một vài lợi thế. Đầu tiên là khách hàng không đọc tài liệu đặc tả. Không bao giờ. Waterfall giả định rằng tất cả mọi người sẽ đồng ý tốt với một thông số ngay từ đầu và sau đó khi phần mềm được giao cho khách hàng một năm sau đó phù hợp với thông số kỹ thuật, họ sẽ rất vui. Trong thực tế, khách hàng chỉ khám phá tất cả những thứ họ thực sự cần, thực sự không cần và thực sự cần phải là một thứ gì đó khác biệt khi họ đang tích cực chơi với chính phần mềm. Agile có được một nguyên mẫu hoạt động trong tay khách hàng, vì vậy những ngắt kết nối này bị bắt ngay lập tức. Agile không chỉ phản ứng với các yêu cầu thay đổi. Đó cũng là về việc những yêu cầu thay đổi đó xảy ra sớm, khi chi phí thay đổi thấp, không phải cuối cùng, khi chi phí thay đổi cao.

Một lợi thế thứ hai là bởi vì Agile có các sản phẩm có thể nhìn thấy thường xuyên, nên các dự án ít có khả năng đi ra khỏi đường ray. Với một dự án Thác nước lớn, tất cả quá dễ dàng để đi phía sau mà không nhận ra. Thác nước tạo ra các cuộc tuần hành tử vong nhiều tháng ở cuối dự án. Với Agile, bởi vì bạn sẽ giao hàng cho khách hàng vài tuần một lần, mọi người đều biết chính xác dự án đang ở đâu và bị trượt (và điều chỉnh) nhanh chóng. Theo kinh nghiệm của tôi, Waterfall tạo ra các tuần hoặc tháng của 100 giờ cuối tuần. Agile có nghĩa là bạn có thể phải đặt trong một vài ngày 12 giờ vào cuối giai đoạn nước rút.

Một lợi thế thứ ba là các dự án Agile có xu hướng tạo động lực nhiều hơn. Mọi người rất khó có cảm giác lái xe trong một dự án dài một năm. Hạn chót dường như còn rất xa và việc thiếu tính trực tiếp có nghĩa là mọi người có xu hướng trì hoãn, thiết kế quá bóng bẩy và nếu không thì không hoạt động rất năng suất. Điều này đặc biệt đúng bởi vì những tháng đầu tiên được dành cho những việc mọi người không muốn làm, như các tài liệu cụ thể. Bởi vì Agile luôn có thời hạn cụ thể, ngay lập tức trong tương lai rất gần, mọi người có xu hướng có động lực hơn. Khó khăn hơn nhiều để trì hoãn với thời hạn cụ thể cho một nhóm nhiệm vụ cố định vào tuần tới.

Đáp lại lời trích dẫn từ câu hỏi, đó là một quan niệm sai lầm cơ bản về các đối thủ chống nhanh nhẹn

"... trong khi thác nước cho phép bạn hoàn thiện kiến ​​trúc của mình trước khi bạn phát hành bất cứ thứ gì." là một ngụy biện, hãy để tôi sửa nó cho bạn; "... trong khi thác nước cho phép bạn hoàn thiện kiến ​​trúc của mình để bạn không bao giờ tiết lộ bất cứ điều gì. "

Hàm ý rằng Waterfall một số cách cung cấp kiến ​​trúc chất lượng cao hơn về cơ bản là sai và hoàn toàn bị từ chối bởi bằng chứng lịch sử thực nghiệm.

Nếu Facebook được thiết kế theo kiểu thác nước với 500 triệu người dùng là một yêu cầu khó và nhanh và không được phát hành cho đến khi một kiến ​​trúc hỗ trợ được hoàn thiện thì không ai có thể nghe thấy về nó ngày hôm nay.

Tương tự với YouTube, Twitter và vô số công ty khác.

Họ đã nhận được một cái gì đó mà khách hàng có thể chạm vào và phản hồi để làm việc và phát hành nó càng nhanh càng tốt. Họ đã nhận được phản hồi và tinh chỉnh nó và phát hành lại; lặp đi lặp lại Đây là cách trong ba ví dụ này, họ phản hồi chỉ với các tính năng khách hàng chấp nhận và muốn và lãng phí ít thời gian nhất có thể cho những thứ mà khách hàng tìm thấy ít hoặc không có giá trị.

Bất cứ ai có bất kỳ năm kinh nghiệm phát triển phần mềm quan trọng nào cũng sẽ đồng ý rằng không có thứ gọi là kiến trúc hoàn hảo . Chỉ cần một cái bắt đầu xa hơn từ entropy và quả bóng bùn lớn hơn các lựa chọn thay thế khác. Agile thừa nhận điều này và đưa nó vào tài khoản. Xây dựng quy trình, đây là nợ kỹ thuật, ưu tiên tái cấu trúc và tái cấu trúc nhanh chóng.

Scrum tự nó không quy định bất kỳ thực hành kỹ thuật vì nó là một khung chung.

Phát triển phần mềm Agile đòi hỏi sự xuất sắc kỹ thuật từ nhóm. Điều này xuất phát từ việc thực hành kỹ thuật từ XP (lập trình cực đoan). Chẳng hạn, bạn phải tìm hiểu về tái cấu trúc, tdd, toàn đội, lập trình cặp, thiết kế gia tăng, ci, cộng tác, v.v.

Làm như vậy giúp có thể xử lý thay đổi nhanh chóng và an toàn, đó cũng là lý do chính để sử dụng phát triển nhanh ở nơi đầu tiên.

Một phép đo nhanh nhẹn quan trọng là nếu bạn thường xuyên (hàng tuần, hai tuần một lần) quản lý để phát hành phần mềm làm việc có giá trị cho khách hàng của bạn. Bạn có thể làm điều đó? Sau đó, bạn nhanh nhẹn trong cuốn sách của tôi.

Đối với tôi, lợi ích chính của nhanh nhẹn là giảm rủi ro trong dự án.

Bằng cách cung cấp lặp đi lặp lại và nhận được nhiều phản hồi từ cơ sở người dùng của bạn, bạn sẽ tăng cơ hội rằng bạn sẽ cung cấp thứ họ thực sự muốn và bạn sẽ thực hiện điều đó bằng cách cung cấp các tính năng quan trọng nhất cho họ càng sớm càng tốt. Về lý thuyết, điều này sẽ được thực hiện với các ước tính và lập kế hoạch tốt hơn. Điều này rõ ràng là rất hấp dẫn từ quan điểm kinh doanh - nhiều hơn là chỉ xây dựng đáng tin cậy.

Bạn có thể lập luận rằng sự thay đổi liên tục này làm tổn hại đến hệ thống của bạn và làm giảm chất lượng, nhưng tôi sẽ nói hai điều. 1) Dù sao, sự thay đổi này xảy ra đối với các dự án phân phối phần mềm truyền thống hơn - nó không được tính đến và xảy ra sau đó trong dự án, khi mà bạn chỉ ra, mọi thứ khó khăn hơn và tốn kém hơn để thay đổi. 2) Agile có rất nhiều điều để nói về việc xử lý sự thay đổi này về mặt sử dụng những người có động lực và thực tiễn có kinh nghiệm như TDD, ghép nối và đánh giá mã. Không có sự thay đổi trong suy nghĩ về chất lượng và cải tiến liên tục, tôi chấp nhận rằng sự thay đổi thường xuyên mà ngụ ý nhanh nhẹn có thể bắt đầu gây ra vấn đề.

Trong rất nhiều trường hợp, kiến ​​trúc sẽ cần phải được sửa đổi rất đáng kể, điều đó cũng có nghĩa là bạn sẽ cần phải thực hiện lại tất cả các tính năng dựa trên kiến ​​trúc cũ.

Nếu kiến ​​trúc của bạn cần được sửa đổi đáng kể do thay đổi yêu cầu, bạn có kiến ​​trúc xấu hoặc yêu cầu xấu. Kiến trúc tốt cho phép bạn trì hoãn càng nhiều quyết định càng tốt và tách rời các thành phần trong hệ thống của bạn. Yêu cầu tốt (người dùng) không phải là những thứ như "sử dụng cơ sở dữ liệu khác".

Vì vậy, hãy vận hành theo giả định rằng chúng ta có một kiến ​​trúc làm việc tốt. Nếu đó là trường hợp, thì các phương pháp phát triển nhanh sẽ mất "rửa" này với các phương pháp thiết kế lớn lên phía trước. Xét cho cùng, một tính năng cốt lõi của các phương pháp phát triển nhanh là các thực tiễn như TDD thúc đẩy khớp nối lỏng lẻo trong mã, cho phép dự án tiếp tục với tốc độ cao cho dù nó ở gần đầu hoặc rất trưởng thành.

Trong rất nhiều trường hợp, kiến ​​trúc sẽ cần phải được sửa đổi rất đáng kể, điều đó cũng có nghĩa là bạn sẽ cần phải thực hiện lại tất cả các tính năng dựa trên kiến ​​trúc cũ. Vì vậy, toàn bộ điểm giảm chi phí sẽ biến mất ở đây.

Theo một quy trình nhanh, có nhiều khả năng nắm bắt được yêu cầu này trước khi có quá nhiều phần mềm được phát triển (Và cần phải thay đổi.). Khi bạn đi vài tháng mà không làm việc với khách hàng và đưa cho họ một cái gì đó để xem xét, bạn sẽ gặp những vấn đề kiến ​​trúc lớn này chỉ sau khi bạn "nghĩ" rằng bạn đã sẵn sàng để giao hàng.

Tôi thà thử thực hiện những thay đổi này trong một ứng dụng đang hoạt động có phạm vi kiểm tra hơn là một đống mã lớn thậm chí không biên dịch được. Trong khi là người đứng đầu bộ phận hỗ trợ kỹ thuật, tôi đã được trao một đĩa CD của một ứng dụng đã được phát triển trong nhiều tháng và nó thậm chí sẽ không cài đặt. Chúng tôi có thể đã tìm thấy vấn đề đó trong tuần đầu tiên, nhưng thay vào đó là thời gian để đặt hàng thực khách vì đó là một đêm dài.