Là nhanh nhẹn hơn chỉ là những thác nước nhỏ?

Tôi hầu như đã sử dụng phương pháp thác nước trong các dự án của mình, nhưng bây giờ tôi đang mở rộng tầm nhìn của mình thành các phương pháp nhanh. Từ những gì tôi đã đọc cho đến nay và có lẽ tôi đã đọc những điều sai, nhanh nhẹn có nghĩa là những thác nước nhỏ. Thay vì một thác nước lớn trải dài trong một hoặc hai năm, bạn có những thác nước nhỏ kéo dài hàng tuần hoặc có thể là vài tháng.

Là sự hiểu biết của tôi đúng hay còn nhiều điều hơn thế? Những triết lý nhanh nhẹn là gì?

Ở mức độ đơn giản, có. Đơn giản chỉ cần thực hiện một Thác nước hai tuần một lần không khiến bạn nhanh nhẹn , nhưng đó là lặp đi lặp lại (là một nửa của nhanh nhẹn).

Mô hình thác nước xác định các giai đoạn - yêu cầu, kiến ​​trúc, thiết kế, thực hiện, xác minh (thử nghiệm), xác nhận (thử nghiệm chấp nhận) và phát hành. Trong bất kỳ phương pháp lặp nào, bạn đều trải qua từng giai đoạn trong mỗi lần lặp. Có thể có sự chồng chéo giữa chúng, nhưng bạn nêu ra và nắm bắt các yêu cầu, chấp nhận kiến ​​trúc và thiết kế của hệ thống để cho phép thực hiện, phát triển các tính năng mới hoặc sửa lỗi, kiểm tra các mô-đun mới và sau đó trình bày cho khách hàng chấp nhận thử nghiệm và triển khai.

Tuy nhiên, có rất nhiều thứ để nhanh nhẹn hơn là chỉ lặp đi lặp lại và tăng dần. Những người thuê nhà nhanh nhẹn bị bắt trong Tuyên ngôn phát triển phần mềm Agile . Có bốn điểm chính được đưa ra trong Tuyên ngôn:

Các cá nhân và tương tác qua các quy trình và công cụ

Bạn liên quan đến những người cá nhân thường xuyên. Nhiều triển khai được tập trung xung quanh các nhóm tự tổ chức và tự điều hành. Gần như tất cả đều có sự tương tác thường xuyên với khách hàng hoặc ai đó có tiếng nói của khách hàng. Thay vì có một bộ quy trình chính thức để tuân theo và các công cụ để sử dụng, bạn hãy để những người làm việc trong dự án điều khiển dự án được thực hiện như thế nào để cho nó được thực hiện theo cách tốt nhất có thể.

Phần mềm làm việc trên tài liệu toàn diện

Trong một dự án phần mềm, mục tiêu chính là phân phối phần mềm. Tuy nhiên, trong một số dự án, sản xuất tài liệu lãng phí mà không có giá trị. Scott Ambler đã viết một bài viết hay về Tài liệu Agile / Lean . Đó không phải là về việc không sản xuất tài liệu, mà là về việc chọn tài liệu làm tăng giá trị cho nhóm của bạn, nhà phát triển trong tương lai, khách hàng hoặc người dùng. Thay vì sản xuất tài liệu không tăng thêm giá trị, các kỹ sư phần mềm của bạn thay vào đó sản xuất phần mềm và các thử nghiệm liên quan.

Hợp tác khách hàng qua đàm phán hợp đồng

Thay vì xác định các điều khoản và thời gian biểu và chi phí trước, nó trở thành một nỗ lực liên tục với khách hàng. Ví dụ: bạn có thể nắm bắt các yêu cầu của mình dưới dạng câu chuyện của người dùng và gán cho họ điểm. Sau một vài lần lặp, bạn giải quyết một vận tốc (điểm / lần lặp) và có thể xác định có bao nhiêu tính năng mà nhóm của bạn có thể thực hiện trong một lần lặp. Vì khách hàng của bạn cung cấp phản hồi về các tính năng nào thêm giá trị nhất, họ có thể quyết định khi nào dự án được thực hiện tại bất kỳ thời điểm nào. Bất kỳ điều gì cũng có thể xảy ra với việc giao hàng và tương tác khách hàng thường xuyên - các yêu cầu đã được thỏa mãn và dự án kết thúc bảo trì và cuối cùng, khách hàng phát hiện ra rằng họ không cần mọi thứ họ nghĩ nên quyết định chấm dứt dự án, dự án đang thất bại và khách hàng nhìn thấy điều này sớm và có thể hủy bỏ nó ...

Đáp ứng để thay đổi theo kế hoạch

Bạn không có một thiết kế lớn hoặc kế hoạch cuối cùng lên phía trước và phải thực hiện làm lại bất cứ khi nào thiết kế hoặc kế hoạch đó phải thay đổi. Bạn liên tục ước tính và sửa đổi các ước tính dựa trên thông tin mà bạn có. Bạn chọn số liệu của mình một cách cẩn thận để cung cấp cái nhìn sâu sắc về sức khỏe của dự án và khi nào thực hiện thay đổi nội bộ. Bạn thường xuyên thêm, xóa và sắp xếp lại các yêu cầu với khách hàng. Cuối cùng, bạn hiểu rằng thay đổi là hằng số duy nhất.

Nhanh nhẹn có nghĩa là tập trung vào mọi người và đáp ứng nhu cầu của họ bằng cách cung cấp phần mềm bổ sung giá trị, chất lượng cao một cách nhanh chóng. Khi nhu cầu của khách hàng thay đổi, bạn thích nghi với những nhu cầu đó để tập trung vào việc tăng thêm giá trị. Có những triển khai cụ thể của các phương pháp nhanh, nhưng tất cả đều tập trung vào con người, cung cấp kịp thời phần mềm làm việc và thích nghi với môi trường thay đổi nhanh chóng.

Có và không - quá trình thực tế có thể được xem là một loạt các thác nước nhỏ nhưng sự khác biệt là quá trình phát triển và được cải thiện từ đầu vào của toàn đội (dev, qa, business, v.v.), trong quá trình hồi tưởng, nên dẫn đến đến một đơn vị chặt chẽ hơn nhiều có thể phản ứng với các vấn đề và lập kế hoạch và phân phối chính xác. Tôi đơn giản hóa việc đơn giản hóa nó ở đây, có rất nhiều thứ nữa, nhưng tôi không nghĩ đây là điểm khởi đầu tồi.

Tôi sẽ nói rằng đó là một cách đơn giản o đặt nó. Vâng, khi bạn đi xuống nó, đó là những dòng nước nhỏ, nhưng có rất nhiều đằng sau nó làm cho nó hoạt động. Toàn bộ phương pháp thay đổi cách bạn tiếp cận các dự án ... Chưa kể đến tư duy cần thiết cho nó.

Nếu bạn nghiêm túc về Agile, đây là một loạt các webcast tốt (và dài) mà bạn có thể quan tâm:

http://autumnofagile.net/

Quên Agile một phút, nghĩ "thác nước" nghĩa là gì.

Có một giai đoạn yêu cầu, trong đó mọi người đều cố gắng tìm ra vấn đề gì mà sản phẩm cuối cùng cần giải quyết. Mọi người tranh luận về điều này trong một thời gian, và sau đó tất cả họ đều ký vào một loạt các yêu cầu. Tại thời điểm này, phạm vi của bạn được xác định, các hợp đồng được ký kết và khách hàng có thể đi lang thang và chờ bạn đưa ra một sản phẩm giải quyết các yêu cầu được xác định đó.

Tiếp theo là một (hoặc có thể hai) giai đoạn thiết kế. Các nhà thiết kế (có thể hoặc không thể là nhà phát triển), tranh luận về CÁCH hệ thống phải đi cùng nhau để đáp ứng các yêu cầu đã ký. Các vấn đề có thể xảy ra nếu họ không hiểu rõ yêu cầu, điều đó có nghĩa là họ phải quay lại với khách hàng, có khả năng mở lại giai đoạn yêu cầu (và thực hiện một vòng đăng nhập khác) hoặc ít nhất là thiết lập hành động quản lý thay đổi . Thông thường, các nhà thiết kế chỉ đơn giản là đưa ra dự đoán tốt nhất của họ. Họ có thể đưa ra một mô hình dữ liệu logic và rất nhiều UML mô tả một hệ thống mới và cách nó hoạt động. Sau đó, họ đăng nhập vào nó.

Bây giờ các nhà phát triển bắt đầu thực sự bắt đầu mã hóa, dựa trên thiết kế đã ký tắt. Vấn đề có thể xảy ra nếu họ không hiểu rõ về thiết kế, điều đó có nghĩa là họ phải quay lại với nhà thiết kế, có khả năng mở lại giai đoạn thiết kế (và thực hiện một vòng ký hiệu khác) hoặc ít nhất là thiết lập hành động quản lý thay đổi . Các nhà thiết kế có thể lần lượt nhận ra rằng sự nhầm lẫn thực sự quay trở lại với các yêu cầu, có nghĩa là họ phải mở lại các cuộc thảo luận về yêu cầu, đăng xuất và quản lý thay đổi hơn nữa. Thông thường, các lập trình viên (những người có thời hạn thấp thoáng) chỉ đơn giản là đưa ra dự đoán tốt nhất của họ. Họ làm những gì họ có thể để làm mã chức năng. Sau đó, họ phát hành nó để thử nghiệm.

Bây giờ giai đoạn thử nghiệm hệ thống thiết lập. Người kiểm tra thử nghiệm dựa trên sự hiểu biết về các yêu cầu và thiết kế của họ, và đăng ký những gì họ cho là khiếm khuyết vào hệ thống quản lý theo dõi / thay đổi lỗi, khiến các nhà phát triển bắt đầu phát triển lại, trừ khi họ thấy vấn đề như một lỗi thiết kế, sẽ gửi nó trở lại thiết kế, v.v ... Cuối cùng, hệ thống kiểm tra vượt qua và được ký tắt.

Cuối cùng, khách hàng quay lại và thực hiện các thử nghiệm chấp nhận của người dùng trên hệ thống mới. Đây là nơi họ quyết định xem giải pháp mà những người thử nghiệm đã thử nghiệm, các nhà phát triển đã phát triển và các nhà thiết kế được thiết kế có thực sự là những gì họ muốn hay không. Nếu không, bạn có khả năng phải quay lại giai đoạn thiết kế hoặc thậm chí xem lại các yêu cầu.

Ý tưởng đằng sau thác nước là rất khó (và rất không mong muốn) để quay trở lại sau khi một giai đoạn hoàn thành. Những người khác nhau thường tham gia vào các giai đoạn khác nhau, do đó, có nhiều lần bắt tay - mỗi lần đưa ra rất nhiều rủi ro cho việc giải thích sai và mất thông tin. Cũng có một khoảng cách đáng kể giữa khi khách hàng nói những gì họ muốn và khi họ thấy những gì đã được xây dựng, trong thời gian đó các yêu cầu thực sự rất có thể đã thay đổi.

Các phương pháp nhanh nhẹn tập trung vào sự giao tiếp và hợp tác mạnh mẽ giữa tất cả các bên quan tâm. Nguyên tắc "Hợp tác với khách hàng trong đàm phán hợp đồng" có nghĩa là bạn không cần phải trải qua một loạt các lần ký và tắt, mà thay vào đó chỉ nên làm việc cùng với khách hàng, mỗi lần lặp lại xác định các yêu cầu cho một mảnh ghép và ngay lập tức hình thành các bài kiểm tra, một thiết kế và mã làm việc - với tất cả những người chơi giao tiếp trực tiếp nhất có thể (loại bỏ chi phí và rủi ro khi bắt tay). Mã làm việc nhanh chóng được khách hàng kiểm tra, loại bỏ rủi ro trễ thời gian. Tất cả các hoạt động xảy ra trong một vòng xoáy hợp tác, không phải trong một dòng chảy xuống.

Để có cái nhìn tổng quan tuyệt vời về những phương pháp nhanh nhẹn cố gắng thực hiện, tôi rất khuyến nghị Phát triển phần mềm linh hoạt của Allistair Cockburn : Trò chơi hợp tác .

Vâng, điều đó ít nhiều đúng. Đã có nhiều văn bản và thảo luận về cách đi về nó, nhưng một loạt các thác nước nhỏ là mấu chốt của nó.

Việc thực hiện cụ thể về cách sử dụng một loạt các thác nước nhỏ không phải là chuyện nhỏ. Ví dụ, bạn sẽ không chuyển từ thực hiện các dự án lớn trong một vài năm sang thực hiện một số dự án nhỏ. Vẫn còn dự án lớn với 1-2 năm làm việc để thực hiện. Vì vậy, bạn cần chia dự án lớn thành một số dự án nhỏ. Điều đó có vẻ khá rõ ràng, nhưng nó lấp đầy các trang và trang sách.

Điều đó có đúng hay không?

Cả hai. Vâng, đó là một tóm tắt chính xác của khái niệm, nhưng có rất nhiều chi tiết được tóm tắt. Ý tôi là, hầu hết mọi khía cạnh của việc lập kế hoạch đều thay đổi khi bạn lên kế hoạch cho tuần tới thay vì năm sau.

Nếu bạn nhìn vào cấu trúc tĩnh (định nghĩa quy trình) của một dự án nhanh, thì nó trông giống như nhiều thác nước nhỏ. Nhưng mục tiêu của một dự án nhanh là nhận được phản hồi nhanh hơn và tốt hơn .

• Bạn thực hiện phát triển dựa trên thử nghiệm để biết ngay phần mềm của mình có còn hoạt động không
• Một khách hàng có mặt tại chỗ và thực hiện các bài kiểm tra chấp nhận để biết khi nào bạn hoàn thành
• Bạn có quá trình hồi tưởng để điều chỉnh quy trình của mình dựa trên những gì diễn ra tốt đẹp và những gì không.

Bản tuyên ngôn nhanh nhẹn nêu bật một số khác biệt giữa nhanh nhẹn và thác nước (theo cảm nhận của những người đã ký).

Thực sự "nhanh nhẹn" thường có nghĩa là thác nước trong 1-2 ngày chứ không phải tuần. Điều đó không có nghĩa là bạn không tuân theo một kế hoạch tổng thể và chu kỳ phát hành thực tế là 1-2 ngày. Nhưng bạn nên cố gắng có một sản phẩm hoạt động, được thử nghiệm mỗi ngày và bạn có thể phát hành nó - theo lý thuyết - mỗi ngày.

Scrum, ví dụ, sử dụng nước rút trong 4 tuần, nhưng nước rút không chỉ là một thác nước (ít nhất là không nên). Bạn có thể thay đổi các ưu tiên mỗi ngày bất cứ khi nào bạn thấy rằng một cái gì đó không đi theo cách nó đã được lên kế hoạch khi bắt đầu nước rút.