Không thể hiểu một điểm nào đó trong Nguyên tắc Tuyên ngôn của Agile

Tôi đã đọc Nguyên tắc Tuyên ngôn của Agile . Mọi thứ dường như rõ ràng và hợp lý ngoại trừ một điểm:

Đơn giản - nghệ thuật tối đa hóa số lượng công việc không được thực hiện - là điều cần thiết.

Tôi không hiểu điều này Điều này có nghĩa là công việc không được thực hiện nên được phóng đại bằng cách nào đó? Nếu vậy, nó không thực sự có ý nghĩa.

Xóa bình luận phụ huynh. Điều còn lại là "Đơn giản là điều cần thiết", nhân tiện là một ứng dụng của nguyên tắc cho chính biểu hiện của nó.

Đơn giản là điều cần thiết, bởi vì bạn đã chắt lọc những gì bạn thực sự cần, loại bỏ những gì đang làm cho nhiệm vụ trong tay nặng nề hơn, kém thanh lịch hơn: phức tạp.

Tôi đã luôn giải thích theo nghĩa của Pascal về sự ngắn gọn : " Tôi sẽ viết một lá thư ngắn hơn, nhưng tôi không có thời gian. " Bạn phải tránh những gì không được tiết lộ (từ thư, từ mã) và đây là một nhiệm vụ tích cực , và không phải là một nhiệm vụ dễ dàng. Nó không phải là một cái gì đó xảy ra bởi chính nó.

Ý tưởng là để tránh làm những công việc không cần thiết, tức là "tối đa hóa số lượng công việc không hoàn thành".

Vì vậy, nếu trong một dự án truyền thống, bạn sẽ lập kế hoạch và xây dựng một hệ thống cơ sở trừu tượng tuyệt vời để cho phép tất cả các nhu cầu có thể của bạn sau này, bạn chỉ cần bỏ qua điều đó và xây dựng điều đơn giản nhất có thể làm việc cho các yêu cầu hiện tại . Đừng xây dựng những thứ mà bạn không cần.

YAGNI là một khái niệm liên quan.

Chúng tôi thường gọi đây là "mạ vàng". Yêu cầu đối với một cái búa là nó có thể đâm một cây đinh vào một miếng gỗ. Nó không làm công việc tốt hơn để trở thành một cái búa mạ vàng.

Nhiều lần, một nhà phát triển sẽ đề xuất sử dụng một khung công tác mới hoặc thêm các tính năng mà mặc dù không cần thiết. Chúng tôi sẽ lưu ý ý tưởng này, nhưng đối với phiên bản này, chúng tôi sẽ không thực hiện nó. Chúng tôi sẽ tối đa hóa công việc không được thực hiện. Việc cung cấp phần mềm đúng hạn là đủ khó, vì vậy đừng cung cấp bất kỳ mã nào nhiều hơn bạn cần. Nếu nó cần phải được thực hiện, cuối cùng nó sẽ có trong kế hoạch và được thực hiện vào thời điểm thích hợp.

Ý tưởng này rất giống với một khái niệm từ Hệ thống sản xuất Toyota (TPS) , dẫn đến Lean Sản xuất chung hơn và sau đó áp dụng các kỹ thuật đó cho Phát triển phần mềm Lean . TPS có trước phong trào nhanh nhẹn, với nguồn gốc sản xuất vào cuối những năm 1950.

Khái niệm tối đa hóa số lượng công việc không được thực hiện tương tự như loại bỏ chất thải. Trong môi trường sản xuất, chất thải bao gồm những thứ như sản xuất quá mức hàng hóa, chờ đợi tài nguyên, di chuyển không cần thiết của người hoặc sản phẩm, quá nhiều hàng tồn kho và sản phẩm bị lỗi. Trong Lean Software Development, những chất thải này được chuyển thành các chức năng không cần thiết, sự chậm trễ trong quá trình phát triển, các yêu cầu không rõ ràng làm chậm quá trình sản xuất phần mềm, thiếu kiểm tra và chậm trễ truyền thông.

Ý tưởng tổng thể của cả hai khái niệm là như nhau - những thứ không thêm giá trị là lãng phí và nên được giảm thiểu. Mục tiêu cuối cùng là tăng chất lượng trong khi giảm thời gian và chi phí để sản xuất.