Flaccid Scrum

,

Nguồn: https://www.informationweek.com

Tác giả: Martin Fowler | Nguồn: https://martinfowler.com

Tôi đã nghe nói về mớ hỗn độn trong một số dự án gần đây. Những thứ đó cụ thể như thế này:

  • Họ muốn sử dụng một quy trình Agile và đã chọn Scrum.
  • Họ áp dụng các phương pháp trong Scrum, và thậm chí có thể là các nguyên tắc.
  • Sau một thời gian tiến độ bị chậm lại do mã nguồn là một mớ lộn xộn.

Những gì đã xảy ra là họ đã thiếu sự đầu tư cho chất lượng tự thân của phần mềm do mình làm ra. Nếu bạn phạm sai lầm đó, bạn sẽ sớm thấy năng suất của mình bị sụt giảm bởi vì sẽ khó bổ sung thêm những tính năng mới mà  bạn muốn. Bạn đã vướng phải các lỗi kỹ thuật và điều đó khiến Scrum của bạn yếu đi. (Và nếu bạn đang ở trong một scrum thực sự, bạn sẽ biết đó là một Điều Xấu.)

Tôi đã đề cập đến Scrum vì khi chúng ta nhìn thấy vấn đề này, Scrum có vẻ là quy trình đặc biệt phổ biến được đề cử cho các nhóm. Đối với nhiều người, tình trạng này bị Scrum làm cho ngày càng trầm trọng hơn vì khung làm việc này quá trình tập trung vào các kỹ thuật quản lý dự án và cố tình bỏ qua các phương pháp thực hành về kỹ thuật, điều ngược lại với XP (eXtreme Programming – Lập trình Cực hạn).

Để bảo vệ Scrum, điều quan trọng là chỉ ra rằng chỉ vì nó không đưa các hoạt động kỹ thuật vào nên khiến cho mọi người nghĩ rằng các kỹ thuật đó là không quan trọng. Bất cứ khi nào tôi lắng nghe các Scrummers có ảnh hưởng, họ đều nhấn mạnh rằng bạn phải có những phương pháp kỹ thuật tốt để thành công với một dự án Scrum. Họ không nói rõ những phương pháp đó là gì, nhưng bạn cần chúng. Sau khi tất cả các dự án gặp rắc rối vì chất lượng tự thân, trên thực tế có nhiều vấn đề xảy hơn ra khi triển khai Scrum do khung làm việc này rất phổ biến vào thời điểm này. Sự phổ biến và SemanticDiffusion có xu hướng đi cùng nhau.

Vậy giờ làm gì với nó?

Cộng đồng scrum cần phải tăng gấp đôi nỗ lực của mình để đảm bảo rằng mọi người hiểu được tầm quan trọng của các phương pháp kỹ thuật mạnh. Chắc chắn là bất kỳ hoạt động rà soát dự án nào cũng nên bao gồm việc thực thi những phương pháp kỹ thuật. Nếu bạn đang tham gia hoặc kết nối với một dự án như vậy, hãy lưu ý nếu phương diện kỹ thuật bị bỏ qua.

Nếu bạn đang tìm cách để giới thiệu Scrum, hãy đảm bảo là bạn chú ý kỹ đến các phương pháp kỹ thuật. Chúng tôi có xu hướng áp dụng nhiều phương pháp trong XP, chúng rất phù hợp. Các XPers (người thực hành phương pháp XP) thường đùa, có biện minh một ít, rằng Scrum chỉ là XP mà không có các phương pháp kỹ thuật làm cho nó hiệu quả. Gạt sang một bên, các phương pháp kỹ thuật của XP tạo ra một điểm khởi đầu tốt – và chắc chắn sẽ tốt hơn nhiều so với không làm gì cả.

Tôi luôn luôn muốn chỉ ra rằng không phải là các phương pháp luận hành công hay thất bại, mà là các nhóm thành công hay thất bại. Tham gia vào một quy trình có thể giúp một nhóm dựng lên “trò chơi” của mình, nhưng cuối cùng thì chính là nhóm đó quan trọng và chịu trách nhiệm làm những điều có hiệu quả cho họ. Tôi chắc chắn rằng nhiều dự án Flaccid Scrum (Scrum mềm) đang chạy sẽ gây hại cho tiếng tăm của Scrum, và có lẽ rộng ra là danh tiếng của Agile. Nhưng vì tôi thấy SemanticDiffusion là một điều không tránh khỏi, nên tôi không bị báo động quá mức. Các nhóm thất bại có thể sẽ thất bại cho dù họ có áp dụng sai bất kỳ phương pháp nào, các nhóm thành công sẽ xây dựng các phương pháp của họ dựa trên những ý tưởng tốt. Vai trò của cộng đồng Scrum là lan truyền rộng rãi những ý tưởng tốt đẹp này.

Many people are looking to Lean as the Next Big Agile Thing. But the more popular lean becomes the more it will run into the same kind of issues as Scrum is facing now. That doesn’t make Lean (or Scrum) worthless, it just reminds us Individuals and Interactions are more valuable than Processes and Tools.

Nhiều người đang tìm đến với Lean như là một thứ Next Big Agile. Nhưng Lean càng trở nên phổ biến thì nó sẽ càng trở nên giống với những vấn đề mà Scrum đang phải đối mặt. Điều đó không làm cho Lean (hay Scrum) trở thành vô giá trị, nó chỉ nhắc nhở chúng ta một điều rằng Các cá nhân và sự tương tác có giá trị hơn là Quy trình và Công cụ.