Sau hơn hai năm làm việc trong một cấu trúc bộ phận phát triển rất "im lặng", chúng tôi đang áp dụng Agile SCRUM. Tuyệt quá. Tôi thích Agile; như một nhà phát triển, nó giúp bạn tập trung, bận rộn và làm việc hiệu quả mà không có vô số các bên liên quan đẩy dự án sau khi dự án xuống cổ với mong muốn tất cả đều được thực hiện vào ngày hôm qua.
Tuy nhiên, có một khía cạnh của việc chuyển sang SCRUM so với "mô hình" hiện tại của chúng tôi, mà tôi nghĩ rằng những người bên ngoài Phát triển sẽ không thích một chút nào. Đó là khả năng hiện tại của họ để chúng tôi thực hiện những thay đổi nhỏ "trong khi bạn chờ đợi". Một phần lớn sự phát triển của chúng tôi chỉ dành cho tiêu dùng nội bộ, và hầu hết chúng ta đều ở trong cùng một tòa nhà. Vì vậy, việc nhiều người đứng đầu bộ phận hoặc người quản lý ở nơi khác đến với "chủ sở hữu cơ sở" của một ứng dụng cụ thể và yêu cầu những thứ nhỏ nhặt (đôi khi không quá nhỏ, nhưng chúng tôi khá tốt về việc không tham gia ba các dự án tuần dựa trên các "ổ đĩa" này). Ngay cả ông chủ của chúng tôi đôi khi chuyển tiếp những thứ mang đến cho anh ta theo cách này. Rất thường xuyên, nếu chúng ta đang làm việc trong cơ sở mã được đề cập vào thời điểm đó, chúng ta có thể chỉ cần bật lên tệp nguồn,
Với phương pháp Agile SCRUM cơ bản, các chỉnh sửa này sẽ được ghi lại là lỗi (chúng tôi không đáp ứng yêu cầu được chỉ định trong câu chuyện đã sử dụng trước đó) hoặc câu chuyện nhỏ mới (chúng tôi đáp ứng tất cả các yêu cầu đã nêu, nhưng những yêu cầu đó không đầy đủ, mơ hồ hoặc không chính xác hoặc họ đã thay đổi sau khi giao hàng khi người dùng thấy các tính năng mới). Dù bằng cách nào, đại đa số sẽ chỉ là một con trỏ nếu không phải là số 0 và có mức độ ưu tiên tương đối thấp (hệ thống có thể sử dụng được ở trạng thái hiện tại, nhưng sẽ tuyệt hơn rất nhiều nếu ...), khiến chúng khó có thể đưa vào một cuộc chạy nước rút khi làm việc tồn đọng từ trên xuống.
Khả năng này đã được đưa ra tại một cuộc họp dev như là một nguồn phản đối tích cực đối với quy trình Agile của chúng tôi bởi các bộ phận khác, những người sẽ thấy nó ít "nhanh nhẹn" hơn khả năng hiện tại của chúng tôi để thực hiện các điều chỉnh nhỏ theo yêu cầu. Đó là một mối quan tâm hợp lệ IMO; các bên liên quan đằng sau PO không phải lúc nào cũng đồng ý về những điều quan trọng nhất, bởi vì tất cả họ đều không có cùng quan điểm, nhưng thông thường chỉ có những người quản lý đưa ra quyết định cuối cùng, và do đó, sự thiên vị của họ là vấn đề cho thấy trong các sản phẩm tồn đọng.
Một giải pháp sau đó đã được đề xuất, được gọi là "lọ kẹo" (một thuật ngữ khác được ném ra là "thuyền hấp dẫn"). Những điều chỉnh nhỏ được yêu cầu bởi các "kẻ nhỏ" trong các phòng ban khác nhau, không phải là khiếm khuyết trong một câu chuyện hiện có, được ước tính bằng sự đồng thuận hoặc tung hô trong nhóm để mất ít hơn một nửa ngày của nhà phát triển và điều đó sẽ có tác động tích cực, đáng kể, tích cực đến trải nghiệm người dùng theo ý kiến của người dùng cuối, được đưa vào danh sách song song với tồn đọng chính. Chúng được xác định là "câu chuyện", nhưng sẽ được tách biệt khỏi phần tồn đọng chính của những câu chuyện "lớn" được ưu tiên. Nếu, tại bất kỳ thời điểm nào trong quá trình chạy nước rút bình thường, chúng tôi tình cờ làm việc trong một khu vực của hệ thống trong đó một trong những điều chỉnh này có thể được thực hiện, làm cho tinh chỉnh trở nên tầm thường, chúng ta có thể mang tinh chỉnh vào giai đoạn nước rút và mã hóa nó cùng với câu chuyện lớn hơn. Làm cái nàykhông được gây nguy hiểm cho việc hoàn thành câu chuyện lớn hơn hoặc bất kỳ công việc cam kết nào khác. PO cũng sẽ có quyền truy cập vào danh sách này và nếu họ đang thực hiện một câu chuyện người dùng sắp tới chạm vào tính năng cơ bản liên quan đến tinh chỉnh, họ có thể xếp nó vào câu chuyện theo yêu cầu và sau đó chúng tôi sẽ đáp ứng yêu cầu như chúng tôi sẽ làm khác Điều này, người ta đã nghĩ, sẽ làm cho các tinh chỉnh có nhiều khả năng được thực hiện sớm hơn sau này.
Điều này đã kích hoạt phản ứng giữa những người trong chúng ta với chương trình đào tạo "uh-uh" của ScrumMaster. Có một tồn đọng. Hai hồ sơ tồn đọng giới thiệu câu hỏi mục số 1 nào thực sự quan trọng nhất, mục nào trong danh sách xác định vận tốc thực và câu chuyện nào trong hai câu chuyện thực sự thuộc về (bất kỳ ranh giới nào về kích thước / độ phức tạp sẽ có một số trường hợp tương đối giảm tùy ý sang bên này hay bên kia). "Hãy để quá trình làm việc", chúng tôi nói; nếu sự thay đổi thực sự có ý nghĩa đối với người dùng cuối, họ sẽ gây ra đủ tiếng ồn để khiến các trưởng bộ phận đưa ra quyết định về thời gian / tiền bạc, và nó sẽ bị cuốn vào ý thức của nhóm phát triển về phía đầu của hồ sơ tồn đọng.
Tôi nghĩ rằng tôi sẽ đặt câu hỏi xuống sàn: Theo ý kiến của bạn, liệu một danh sách song song các câu chuyện "cỡ cắn" có giá trị trong việc thay đổi nhỏ, hữu ích nhưng cuối cùng có mức độ ưu tiên thấp được thực hiện nhanh hơn hay nói chung là một quyết định tốt hơn để xếp chúng vào tồn đọng chính và để cho quá trình cơ bản chi phối sự bao gồm của chúng trong một lần chạy nước rút?