Làm thế nào để bạn đối phó với các chi phí thay đổi quá nhanh?

Giống như hầu hết các nhà phát triển hiện đại, tôi đánh giá các hiệu trưởng Agile như cộng tác khách hàng và phản ứng với thay đổi, nhưng điều gì xảy ra khi chủ sở hữu sản phẩm (hoặc bất kỳ ai xác định yêu cầu và ưu tiên) thay đổi yêu cầu và ưu tiên quá thường xuyên? Giống như nhiều lần một ngày?

Gần đây tôi đã thừa hưởng một cơ sở mã nhỏ bị lỗi, không đầy đủ và thậm chí không thể xử lý kịch bản đơn giản nhất mà nó được cho là. Tôi có thể giải quyết các vấn đề kỹ thuật nhưng tôi nhận được một số email, tin nhắn hoặc cuộc gọi điện thoại mỗi ngày với nội dung "OMG bạn PHẢI làm việc trên QUYỀN NGAY BÂY GIỜ! ƯU TIÊN HÀNG ĐẦU! Đây là một PHẢI !!!" Điều thậm chí còn tồi tệ hơn là hầu hết mọi thứ đều là những chi tiết nhỏ thậm chí không liên quan đến những gì phần mềm thực sự phải làm và sẽ mất nhiều ngày để thực hiện. Tôi đã cố gắng giải thích rằng chỉ có rất nhiều thời gian và chúng ta nên tập trung vào những điều quan trọng nhất trước tiên, nhưng dường như có gì đó bị lạc trong bản dịch bởi vì điều tương tự xảy ra một hoặc hai ngày sau đó.

Có một số loại vai trò của Chủ sở hữu sản phẩm, nghiên cứu chuyên sâu, ẩn dụ hoặc trích dẫn có thể giúp tôi giảm số lượng nỗ lực lãng phí hoặc ít nhất là giải thích chi phí cho hành vi hỗn loạn này?

Đây là những gì tồn đọng là cho. Các yêu cầu mới được đưa vào tồn đọng và các ưu tiên chỉ có thể thay đổi trên các ranh giới lặp. Trung bình chậm một tuần (một nửa thời gian chạy nước rút hai tuần) là đủ nhanh nhẹn để xử lý tất cả các trường hợp khẩn cấp khủng khiếp nhất.

Đây là cách tôi xử lý một vấn đề tương tự .. Quay lại thời mà chúng ta nhanh nhẹn trước Agile.

Đối với bất kỳ yêu cầu thay đổi, khách hàng đặt ưu tiên. Nhà phát triển chỉ có thể và phải dừng công việc trên một nhiệm vụ để thực hiện nhiệm vụ ưu tiên cao hơn. Nhiệm vụ ưu tiên như nhau là lịch trình theo thứ tự đến. (Ưu tiên nhiệm vụ không thể thay đổi khi công việc đã bắt đầu.)

Sẽ thật đau lòng khi bạn nói với khách hàng rằng bạn không thể thực hiện nhiệm vụ của anh ta vì bạn đang làm việc với nhiệm vụ X không quan trọng có cùng mức độ ưu tiên như yêu cầu mới nhất của anh ta. Sau đó, bạn nói với anh ta rằng ở mức độ ưu tiên đó, có 50 nhiệm vụ không quan trọng và không quan trọng trước yêu cầu mới nhất của anh ta. Bây giờ, thực tế - tất cả các nhiệm vụ này đều ở mức ưu tiên 1 (Cao nhất), được đặt bởi ... HIM ... Vì vậy, anh ta không thể đẩy bạn ra khỏi nhiệm vụ bạn đang làm. Bây giờ, khi bạn đã hoàn thành việc di chuyển khung cửa sổ 3 pixel sang trái để nhường chỗ cho từ dài hơn trong bản dịch tiếng Iceland trên tùy chọn cấu hình hiếm khi được sử dụng .....

Tôi cũng đóng cửa vào văn phòng SD, khóa nó và lấy điện thoại ra khỏi móc. Email đã bị bỏ qua cho đến lúc 10 giờ sáng, 12 giờ tối và 2 giờ chiều. Bất chấp những gì mọi người nghĩ và cảm nhận, thế giới vẫn quay xung quanh mặt trời, chúng tôi đã hoàn thành công việc của mình và "Khách hàng" đã giao phần mềm cho họ nhanh hơn và tốt hơn bất kỳ lúc nào trong quá khứ.

Phải mất một vài tuần để các ưu tiên giải quyết một cái gì đó thực tế hơn, chúng tôi đã có thể mở khóa cửa vv .... Nhưng hệ thống vẫn còn khá lâu. Bạn có thể không cần quá cực đoan (chúng tôi đã làm) và sẽ cần hỗ trợ từ quản lý cấp cao. Nhưng nó sẽ hoạt động ....

Sê-ri. Quy trình hoạt động tiêu chuẩn (hoặc ít nhất là một giao thức lỏng lẻo được ký bởi đội ngũ quản lý của bạn). Bộ phận của bạn cần phát triển một hoặc làm việc với nhóm quản lý của bạn để phát triển một. Những người bạn cần nói chuyện ở trên người quản lý sản phẩm / chủ tài khoản.

Một số ví dụ về những gì SOP của bạn nên xác định.

• Những thủ tục nào phải được tuân theo khi khách hàng hoặc thực thể nội bộ yêu cầu thay đổi
• Ý nghĩa và / hoặc tác động đối với việc kiểm soát chất lượng hoặc xác minh sản phẩm này là gì?
• Phương pháp để xác định hợp lý khung thời gian giao hàng là gì? Lặp lại này? Phiên bản tiếp theo?

Nếu không có các thủ tục như vậy, mọi người sẽ chạy vào bạn như thể họ đang bị thây ma truy đuổi và mong đợi mọi thứ NGAY BÂY GIỜ. Những người như thế sẽ không tôn trọng phép lịch sự 'không' hoặc 'vui lòng chờ của bạn. Với một chính sách vững chắc, những người đột biến khao khát mã này sẽ hiểu rằng họ đã sai khi yêu cầu mọi thứ trên cơ sở lỏng lẻo như vậy.

Kết quả cuối cùng làm bạn không hài lòng và đó không phải là lợi ích tốt nhất cho công ty của bạn.

Bên cạnh đó, bạn có thể đã thừa hưởng mớ hỗn độn của ai đó gây ra bởi sự thiếu tôn trọng trắng trợn như vậy đối với vị trí và nghĩa vụ của anh ấy / cô ấy. Những người trong tình huống đó có xu hướng khó tạo ra sản phẩm chất lượng. Có bất kỳ thắc mắc? Kỹ thuật phần mềm 101.

Rất khó để làm việc trong các điều kiện "sẵn sàng, bắn, nhắm" này. Nghe có vẻ như bạn đang nhận được yêu cầu từ một người rất không an toàn, có ý kiến ​​thay đổi mỗi khi một người cao hơn gợi ý một ý tưởng khái niệm.

Trong các loại tình huống này, tôi đã thấy rất có giá trị khi chờ LÚC một giờ trước khi trả lời email. (Tôi sẽ bỏ qua các văn bản, trừ khi nhắn tin đã thay thế toàn bộ email bởi toàn bộ tổ chức của bạn.) Đọc chúng, có thể, nhưng không trả lời. Bằng cách này, bạn có thể dành thời gian tập trung vào công việc thực tế bạn cần làm, chứ không phải thảo luận về những việc khẩn cấp ngẫu nhiên có thể trở nên không liên quan vào ngày mai, hoặc thậm chí hai hoặc ba email sau đó. Trong công việc cuối cùng của tôi, nếu có gì đó thật sự khẩn cấp, ai đó sẽ đến và nói chuyện trực tiếp với tôi, giả sử tôi chưa thấy email (nếu bạn làm việc từ xa, một cuộc gọi điện thoại với một cuộc trò chuyện hai chiều thực sự có thể là tương đương).

Khi bạn có cuộc trò chuyện trực tiếp hoặc qua điện thoại, sẽ rất hữu ích khi lặp lại những gì người đó đang yêu cầu bằng lời nói của bạn, và sau đó đặt câu hỏi của bạn về các yêu cầu và ưu tiên mới. "Nếu tôi hiểu chính xác, bạn đang nói rằng chúng ta nên ngừng làm việc với Ưu tiên hàng đầu hiện tại X và bây giờ tập trung vào Ưu tiên của phút Y. Đó là một sự thay đổi lớn. Bạn có thể giải thích sự thay đổi trong kinh doanh không? Tôi có thể cần làm thêm nền tảng làm việc thay vì chỉ thay đổi giao diện người dùng. Sẽ có thay đổi trong các quy trình kinh doanh khác, chẳng hạn như thanh toán hoặc hàng tồn kho (chẳng hạn)? Bạn có mong đợi các yếu tố dữ liệu mới này xuất hiện trên tất cả các báo cáo hàng tháng không? " Cũng rất hữu ích khi nói điều gì đó với tác động của "Bạn hiểu rằng nếu chúng tôi tiến hành nỗ lực mới này, nó sẽ trì hoãn việc phát hành Ưu tiên hàng đầu X hiện tại ít nhất một (tuần, tháng,

Nếu đó là một trường hợp khẩn cấp thực sự, người yêu cầu có thể trả lời các loại câu hỏi này hoặc ngay lập tức giới thiệu bạn với người có thể. Nếu đó không phải là một trường hợp khẩn cấp thực sự, loại cuộc trò chuyện này sẽ buộc người yêu cầu chậm lại và xác định mức độ thay đổi thực sự quan trọng như thế nào, cho rằng họ cần phải cung cấp cho bạn thêm thông tin. Thường thì họ sẽ thấy rằng những gì đã có trong đường ống là quan trọng hơn, hoặc ít nhất là không đáng để dừng lại, và yêu cầu mới có thể được đưa vào danh sách.

Nếu các thay đổi được xác định là cần thiết, tôi đã thấy hữu ích khi viết ra những gì được yêu cầu và sự hiểu biết của bạn về các thay đổi trong email và gửi cho người yêu cầu ban đầu, hỏi xem họ có đồng ý về phạm vi thay đổi không, một lần nữa, như làm rõ. Bằng cách này, bạn đã có tài liệu bằng văn bản về những gì cần được thực hiện và tại sao nó được yêu cầu, trong trường hợp có bất kỳ lý do nào khiến bạn không còn làm việc với Ưu tiên hàng đầu hiện tại X, hoặc cần giải thích tại sao thời hạn ban đầu không đi được đáp ứng

Điều này hy vọng sẽ cải thiện mối quan hệ của bạn với người yêu cầu, vì bạn đang thể hiện kiến ​​thức của mình và đảm bảo rằng bạn đang làm việc theo những gì họ muốn, nhưng bạn trung thực về những gì cần thiết để thực hiện thay đổi. Bằng cách hỏi về yêu cầu một cách chi tiết, họ thấy rằng bạn nghĩ trước và xem xét những điều họ có thể không có ban đầu.

Có vẻ như chưa có ai đề cập đến nó, Sprint và câu chuyện người dùng của nó ideally should be locked till the next sprint(chạy nước rút thông thường mất 2-4 tuần). Bằng cách khóa - tôi có nghĩa là không có thêm nhiệm vụ nào được thêm vào Sprint đã bắt đầu.

Nếu câu chuyện của người dùng đủ lớn để không phù hợp với nước rút thì hãy đẩy nó xuống các nhiệm vụ nhỏ hơn, có thể đạt được trong giai đoạn nước rút. Ngoài ra, như đã đề cập ngay cả các nhiệm vụ ưu tiên cần phải được giữ lại , và trong lần chạy nước rút tiếp theo, kế hoạch ưu tiên cao một khi có được cờ lên :)

Chỉnh sửa: chỉ những thay đổi nhỏ có thể được giới thiệu trong mùa xuân. nếu họ mang trạng thái khẩn cấp. Tuy nhiên, nếu luôn có một vài trường hợp khẩn cấp trong giai đoạn nước rút, thì cần phải thay đổi kế hoạch của Sprint.

Scrum có vai trò Scrum Master, đó sẽ là người nên giải quyết các vấn đề bạn đã đề cập.

Nếu có ai đó như trưởng nhóm, quản lý dự án, chủ scrum, v.v., người chịu trách nhiệm, tôi sẽ nói chuyện với người đó.

Tôi đã cố gắng giải thích rằng chỉ có rất nhiều thời gian và chúng ta nên tập trung vào những điều quan trọng nhất trước tiên, nhưng dường như có gì đó bị lạc trong bản dịch bởi vì điều tương tự xảy ra một hoặc hai ngày sau đó.

Tôi nghĩ rằng bạn sẽ phải tiếp tục giải thích điều đó nhiều lần. Có vẻ như bạn có thể cần phải chấp nhận rằng một số người bạn làm việc có thói quen không có ích. Nếu bạn may mắn, cuối cùng bạn sẽ thấy một sự thay đổi.

Tuyên ngôn Agile nói rằng một trong những hiệu trưởng cơ bản nhất là:

Chào mừng các yêu cầu thay đổi, thậm chí muộn trong phát triển. Agile quy trình khai thác thay đổi cho lợi thế cạnh tranh của khách hàng.

Tuy nhiên, tôi không tin rằng chúng có nghĩa là thay đổi hàng ngày. Bạn có thể cần thay đổi giá cơ bản của sản phẩm nhiều lần trong ngày, nhưng không thay đổi cách sản phẩm đó có thể được bán nhiều lần trong ngày. Thay vào đó, quy trình bán hàng của một sản phẩm có thể thay đổi theo tuần (trong các doanh nghiệp năng động và nhạy bén).

Một lần nữa, trong khi quy trình bán hàng của một sản phẩm có thể thay đổi mỗi tuần, tôi nghĩ rằng tổng thể sản phẩm sẽ không được thay đổi mỗi tuần. Tôi không thể tưởng tượng một Microsoft mà hôm nay cung cấp cho chúng tôi Office, nhưng ngày mai sẽ cung cấp cho chúng tôi Offooose và một tuần sau Offasooooooooooos.

Không, đó không phải là những gì nhanh nhẹn có nghĩa là thay đổi. Tôi tin rằng nó xuất phát từ tầm nhìn kém, và một sự hiểu lầm sâu sắc lớn về khái niệm thay đổi.

Hãy để một mình đề cập rằng sự thay đổi không được hoan nghênh trong giai đoạn nước rút, nơi các nhà phát triển đi đến hang động của họ và cần phải tập trung vào những gì họ làm. Thay vào đó, các thay đổi nên được thêm vào Product Backlog và được phân tích và ưu tiên trước khi chúng được chuyển đến tay của nhóm scrum. Nói cách khác, Sprint Backlog không phải là bất biến. Nhanh nhẹn hơn nên được tìm kiếm bằng cách sử dụng nước rút ngắn hơn, không phải bằng cách tiêm trực tiếp vào phòng phát triển, nhiều lần trong ngày.