Phương pháp nhanh nhẹn: nhanh và bẩn hay kế hoạch trước?

Câu hỏi nhanh nhẹn: Agile có tin vào việc thu dọn và vận hành cách nhanh chóng và bẩn thỉu hay không - hay Agile thích xây dựng kiên cố từ đầu? Hoặc đây không phải là một câu hỏi về phương pháp, và nhiều hơn một câu hỏi mà bạn đánh giá từng trường hợp?

Về mặt kỹ thuật, tôi đang làm lại hệ thống nền tảng của hệ thống, sau khi tôi đã xây dựng phần lớn cấu trúc ... nó không phải là một khối lượng công việc khổng lồ ... sẽ nhanh chóng muốn tôi tìm hiểu toàn bộ dòng chảy trước, phân tích nó, tinh chỉnh nó, và sau đó xây dựng? Tôi cảm thấy theo cách này tốt hơn theo cách này ... một khi tôi đưa ra một hệ thống lộn xộn, tôi thấy rõ hơn cách nó cần được thực hiện ... mặt khác nó không được tổ chức như vậy ... chỉ tò mò về sự phát triển tốt nhất thực hành là về vấn đề này.

Tôi tin rằng câu hỏi này hơi khác so với Agile và protyping vì tôi không hỏi về nguyên mẫu và mã vứt đi; Tôi quan tâm đến nhanh nhẹn cho mã cấp sản xuất.

Phương pháp nhanh là kế hoạch đầu tiên. Nó chỉ không lên kế hoạch cho mọi thứ đầu tiên. Trong thực tế, bạn thu thập các yêu cầu, thiết kế, mã, kiểm tra, triển khai và trình bày. Bạn chỉ cần làm tất cả những điều đó trong chưa đầy một hai tuần (cho hoặc nhận) trên tính năng nhỏ nhất mà bạn có thể triển khai và nhận phản hồi. Sau đó, bạn làm lại tất cả thêm một tính năng khác hoặc điều chỉnh một tính năng cũ.

Điều quan trọng là viết mã chấp nhận thay đổi để khi cuối cùng bạn thấy "toàn bộ luồng sẽ đi" bạn có thể thay đổi mã để làm điều đó. Theo cách đó khi "con đường nên đi" (hoặc bất cứ điều gì) thay đổi một lần nữa, đó không phải là chấn thương.

Bạn không thể viết nhanh và bẩn. Nhanh chóng và bẩn thỉu cung cấp cho bạn mã vô lý. Hãy nhanh chóng bằng cách làm việc nhỏ. Hãy linh hoạt bằng cách không truyền bá kiến ​​thức . Lý tưởng nhất là bất kỳ thay đổi tính năng duy nhất sẽ chỉ ảnh hưởng đến một nơi trong mã.

Bạn không thể dành hàng tấn thời gian để làm gì ngoài việc lên kế hoạch. Bạn có thể lập kế hoạch nhưng bạn cần có khả năng thay đổi kế hoạch. Bạn cần nhanh chóng khám phá lý do để thay đổi kế hoạch. Khi kế hoạch diễn ra suôn sẻ, không có gì ngạc nhiên để học hỏi, đó là khi kế hoạch đã diễn ra quá lâu. Việc lập kế hoạch và mã hóa phải xảy ra gần nhau. Nếu bạn đang học thì kế hoạch càng cũ thì càng khó.

Về lâu dài, bạn nên lập kế hoạch để thông minh hơn. Viết mã linh hoạt. Sau đó, thông minh hơn không dẫn đến hối tiếc.

Tôi không thích điều đó đối với hầu hết mọi người, đó là "nhanh và bẩn" hoặc "thiết kế lớn lên phía trước". Họ thậm chí không xem xét có những lựa chọn khác.

Agile là về việc xây dựng một hệ thống, trong đó sự thay đổi, thậm chí là muộn trong quá trình phát triển, là chuyện nhỏ. Điều này được thực hiện bằng cách xây dựng phần mềm thành các phần nhỏ, tăng dần và khóa hành vi của các phần đó bằng các bài kiểm tra tự động mạnh mẽ. Và sử dụng thường xuyên, tự động triển khai vào sản xuất để xác nhận giá trị của những thay đổi đó.

Bằng cách có các thử nghiệm tự động mạnh mẽ, việc thay đổi ngay cả những phần khó nhất của kiến ​​trúc trở nên tầm thường, bằng cách tái cấu trúc gia tăng trong thời gian dài hơn. Vì vậy, ngay cả khi bạn nhận ra kiến ​​trúc của mình có thể được thực hiện tốt hơn giữa chừng dự án, thì thực tế có thể thực hiện thay đổi tương đối nhanh chóng.

Một số người nói rằng "một số thiết kế lên phía trước" là tốt với nhanh nhẹn. Nhưng nếu bạn có ý định lặp lại thiết kế này sau đó, bạn vẫn cần đảm bảo văn hóa phát triển của bạn tạo ra một hệ thống dễ thay đổi. Vì vậy, "SDUF" không làm mất hiệu lực nhu cầu thử nghiệm mạnh mẽ, tái cấu trúc nhanh và triển khai liên tục.

Bằng cách xây dựng "dễ dàng thay đổi" vào hệ thống, bạn không cần suy nghĩ kỹ về thiết kế ban đầu của dự án, vì điều đó có thể được thay đổi sau này. Cách tiếp cận "Nhanh và bẩn", hầu hết mọi người gọi nó là "tăng đột biến", chỉ có thể sử dụng được nếu bạn ổn định các tính năng bạn thấy có giá trị. Nhưng bạn không nên để các đoạn mã bị hack trong cơ sở mã của mình quá lâu, vì chúng làm chậm sự thay đổi.

Cũng không.

Đó là "Bắt đầu đơn giản và cải thiện trong khi bạn di chuyển".

Nhanh và bẩn là giòn, nhưng nhanh (nếu dự án đủ nhỏ và ngắn hạn).

Kế hoạch đầu tiên là cứng nhắc, nhưng ổn định (nếu dự án hoàn thành trước khi nó gặp phải những hạn chế về tài chính hoặc thời gian).

Agile là một thay thế cho 2 ở trên. Nó dựa trên một cách tiếp cận lặp đi lặp lại, nơi các tính năng được hoàn thành cùng một lúc, tính năng theo tính năng và kiến ​​thức thu được trong khi hoàn thành các phần đầy đủ chức năng này của chương trình được sử dụng để bổ sung và điều chỉnh kế hoạch khi tiến trình phát triển. Để làm như vậy đòi hỏi một số kế hoạch trước - bạn cần ít nhất là đủ kế hoạch để có thể ước tính số lượng công việc mà các tính năng cá nhân yêu cầu - nhưng vì nhanh nhẹn mong đợi thay đổi, kế hoạch quá mức dẫn đến lãng phí.

Một trong những đặc điểm chính của Agile là thực hiện các bước lặp ngắn và sau đó đánh giá lại. Bạn chạy về phía trước để khám phá lãnh thổ mới, học hỏi từ đó và sau đó lập một kế hoạch. Bằng cách đó kế hoạch của bạn sẽ tốt hơn. Và nếu bạn thất bại (tìm ý tưởng khóa học của bạn không hoạt động), bạn sẽ "thất bại nhanh", điều đó là tốt.

Vì vậy, cách tiếp cận của bạn là tốt. Tuy nhiên, điều nguy hiểm là sau đó phải nói "Đẹp, nó hoạt động, tôi đã xong. Tiếp theo là gì?". Bạn chưa hoàn thành, có rất nhiều góc cắt để làm thẳng ra và bạn nên dành / dành thời gian để thực hiện đúng khi phương pháp của bạn mang lại một hệ thống khả thi và khả thi. Đó có thể là viết bài kiểm tra, tài liệu, StyleCop, tối ưu hóa, giáo dục đồng nghiệp về những gì bạn đã làm và cách bạn đã làm, để nó được xem xét, v.v.

Để thêm vào các câu trả lời trên, một nguyên tắc chính là YAGNI . Nếu thiết kế và lập kế hoạch trước của bạn cho phép bước tiếp theo, thì tốt thôi. Nhưng nếu nó cho phép một bước tương lai giả định mà bạn không thể chứng minh là cần thiết, thì hãy giả sử YAGNI.

Nhiều thiết kế, cả từ trên xuống và từ dưới lên, giả định rằng sẽ có việc sử dụng lại mã đáng kể. Kinh nghiệm cho biết mặc dù việc sử dụng lại mã đơn giản là không phổ biến, bởi vì bạn hiếm khi giải quyết chính xác cùng một vấn đề. Nếu bạn cần phải giải quyết một biến thể của vấn đề đó trong tương lai, cấu trúc lại thiết kế của bạn trong tương lai để thêm biến thể đó, nhưng không xem xét nó ngay bây giờ.

Nói cách khác, lập kế hoạch cho nhiệm vụ trước mắt, nhưng không lập kế hoạch cho bất cứ điều gì phía trước.