Cách tốt nhất để xử lý vì vậy, khi nào thì việc này sẽ được thực hiện bởi?

Trong cuộc họp thường trực hàng ngày ở giữa giai đoạn nước rút, người quản lý dự án thực tế / chủ scrum thường hỏi các nhà phát triển một số phiên bản của:

"Vì vậy, khi nào điều này sẽ được thực hiện bởi?"

"Vì vậy, bạn có thể cam kết thực hiện nhiệm vụ này trước 4 giờ chiều ngày hôm nay không?"

"Bạn còn bao nhiêu giờ trên bảng con này?"

Điều này thực sự rất khó chịu và không làm cho mọi thứ được thực hiện nhanh hơn. Kết quả là các nhà phát triển thường cảm thấy chịu nhiều áp lực và đứng lên thường cảm thấy giống như một chiến trường hơn là một sự hợp tác.

Là một nhà phát triển, một cách vững chắc để xử lý việc này là gì?

Cách tốt nhất để xử lý vì vậy, khi nào thì việc này sẽ được thực hiện bởi?

"Ở cuối nước rút".

Tôi nhận ra đó là một câu trả lời ngớ ngẩn, nhưng có một sự thật ẩn giấu trong đó. Nó phụ thuộc vào người đang thực hiện câu hỏi và tại sao họ lại hỏi câu hỏi đó.

Người quản lý dự án thực sự không có doanh nghiệp nào hỏi những câu hỏi như vậy - họ nên hỏi chủ scrum nếu họ cần thông tin chi tiết về các nhiệm vụ đang thực hiện và họ nên làm như vậy ngoài việc đứng lên hàng ngày.

Nếu đó là chủ scrum đang hỏi, có lẽ họ đang hỏi để họ có thể chuẩn bị cho các khối đường sắp tới. Nếu đó là trường hợp, chỉ cần trung thực.

Trong scrum, nhóm không có nghĩa vụ phải hoàn thành bất kỳ nhiệm vụ hoặc câu chuyện cụ thể nào cho đến khi kết thúc cuộc chạy nước rút, giả sử họ đang hỏi về một câu chuyện liên quan đến nước rút hiện tại (so với bản sửa lỗi nóng ngoài băng). Thời hạn cho các nhiệm vụ trong một câu chuyện thuộc sở hữu của nhóm và họ không nên cảm thấy áp lực từ người quản lý dự án.

Tuy nhiên , phát triển phần mềm là một quá trình hợp tác, vì vậy thật hợp lý để đáp ứng những câu hỏi như vậy, theo lý do.

Giải pháp? Từ quan điểm của bạn: trả lời trung thực nhất có thể, ngắn gọn nhất có thể nếu đó là trong thời gian đứng lên. Nếu bạn đang tích cực thực hiện nhiệm vụ được hỏi, bạn luôn có thể nói điều gì đó dọc theo dòng chữ "ước tính mất vài giờ, vì vậy tôi có thể hoàn thành nó ngay hôm nay". Nếu bạn không làm việc với nó, một câu đơn giản "Tôi không biết, tôi đã không bắt đầu làm việc với nó. Tôi nghĩ rằng ước tính vẫn có vẻ khá chính xác".

Từ quan điểm của họ: họ cần chấp nhận câu trả lời của bạn.

"Vì vậy, bạn có thể cam kết thực hiện nhiệm vụ này trước 4 giờ chiều ngày hôm nay không?"

Câu trả lời cho điều đó hầu như luôn luôn là "không". Đơn giản là không cần phải cam kết giao hàng cuối ngày cho một nhiệm vụ ở giữa nước rút. Việc nhiệm vụ kết thúc lúc 4 giờ chiều hôm nay hay 9 giờ sáng ngày mai là không liên quan, miễn là câu chuyện nói chung được kết thúc vào cuối cuộc đua nước rút.

"Bạn còn bao nhiêu giờ trên bảng con này?"

Đó là một câu hỏi hợp lý để hỏi. Chỉ cần trả lời trung thực. Tôi nhận ra rằng điều đó rất khó để làm. Tôi đã từng ở đó. Tôi nghĩ rằng các nhà phát triển vốn đã lạc quan. Chúng tôi sẽ xem xét một nhiệm vụ và nghĩ rằng "sẽ chỉ mất vài giờ" và trước khi bạn biết điều đó, cả ngày đã trôi qua. Đó là lý do tại sao nhanh nhẹn hoạt động - chúng tôi thừa nhận những hạn chế của chúng tôi trong việc ước tính và cố gắng hết sức để chia mọi thứ thành các phần nhỏ nhất có thể.

Yêu cầu bạn Scrum Master làm rõ, mục đích của một cuộc họp Sprint và Stand Up. Hầu như bất cứ ai làm việc với Scrum đều nói rằng mục đích của Sprint là quyết định những gì sẽ được thực hiện trong suốt thời gian của Sprint và tôi chưa bao giờ nghe thấy bất cứ điều gì đến hạn trong giai đoạn nước rút.

Có lẽ bạn có những trường hợp khẩn cấp để tham gia vào đó thực sự không có gì để làm với một lần chạy nước rút. Các nhóm / nhà phát triển có những nhiệm vụ này ngoài chạy nước rút, cần đảm bảo rằng họ không bao gồm thời gian để thực hiện việc này như một phần của kế hoạch chạy nước rút. Có thể bạn có một ngày làm việc 8 giờ, nhưng nếu bạn dành 1-2 giờ để dập lửa, bạn không thể bao gồm đó là một phần của ước tính.

Theo như các cuộc họp chờ, bạn có thể muốn đề xuất một số hệ thống khác để theo dõi khi một số nhiệm vụ trước mắt sẽ được thực hiện như một số hệ thống vé hỗ trợ. Những điều này thậm chí không nên được thảo luận trong thời gian chờ.

Có vẻ như chủ scrum của bạn cần phải được đào tạo lại hoặc suy nghĩ lại tại sao bạn lại làm Scrum ngay từ đầu. Nó không phù hợp cho tất cả các nhóm và tình huống. Ai đó ở đầu đã không mua vào nó.

Tôi đã có kinh nghiệm quản lý vi mô như thế này và cách tôi đã xử lý thành công bằng cách rất minh bạch và giao tiếp. Không mất nhiều thời gian để có được sự tự tin của người quản lý; bạn xây dựng niềm tin và họ ủng hộ. Đôi khi thậm chí còn cho bạn nhiều không gian và vĩ độ hơn. Người quản lý của bạn có thể cảm thấy không an toàn hoặc mất kiểm soát vì vậy điều này sẽ giúp giảm bớt điều đó cho họ. Rõ ràng điều đó không lý tưởng nhưng bạn là một đội và tất cả bạn đều muốn kết quả tương tự. Chúc may mắn.

"Nó sẽ được thực hiện khi nó được thực hiện."

Không có giá trị trong việc cố gắng để có được ước tính hoàn thành từ các nhà phát triển. Ước tính là không chính xác, đặc biệt nếu chúng dựa trên thời gian. Ngoài ra, những người trong vai trò quản lý có xu hướng diễn giải các ước tính đó là các cam kết, dẫn đến hậu quả tai hại mà các nhà phát triển của bạn đang cảm thấy.

Một lựa chọn sẽ là tránh trả lời câu hỏi về các cam kết về thời gian.

"Nhiệm vụ này sẽ được thực hiện sau khi tôi làm những việc A, B và C."

"Được rồi. Và điều đó sẽ mất bao lâu?"

"Chúng ta sẽ thấy vào cuối ngày."

Thay đổi cuộc trò chuyện từ các cam kết về thời gian thành những gì cần phải hoàn thành có thể giúp vượt trội và cho thấy rằng "sẽ mất bao lâu để hoàn thành" ít quan trọng hơn "mất bao lâu để hoàn thành".

Đừng bị đe dọa bởi chủ scrum. Nói chuyện cởi mở và thẳng thắn về công việc phía trước. Đặt câu hỏi của cô ấy / anh ấy như thế nào là khẩn cấp. Tại sao nó phải được thực hiện bởi 4? Nếu nó thực sự cần phải được thực hiện, các nhiệm vụ khác có thể cần phải được đẩy đến sau này. Đó là cơ hội để bạn xây dựng giàn. Frank trả lời tốt hơn sớm hơn là lý do sau.

Quản lý càng "vi mô" thì càng khó đưa ra dự đoán chính xác. Nếu tôi có 20 nhiệm vụ tám giờ, đó là các nhiệm vụ được ước tính hợp lý mất tám giờ mỗi nhiệm vụ, nên hoàn thành trong bốn tuần, hoặc có thể vài ngày hoặc ít hơn. Nếu tôi có một nhiệm vụ như vậy, có nhiều biến động hơn.

Một nhiệm vụ như vậy có thể mất 10 phút nếu vấn đề cần giải quyết hóa ra dễ dàng hơn nhiều so với tôi nghĩ. (Đã xảy ra với tôi, tôi ước tính rằng tôi cần phải viết khá nhiều mã, và hóa ra người khác đã viết chính xác những gì tôi cần). Hoặc có thể mất một tuần (mã của tôi không hoạt động do lỗi trong thư viện cần được sửa chữa và sau đó có tất cả các loại hậu quả xấu). Đối với hai mươi nhiệm vụ, những điều này cân bằng ra. Không cho một nhiệm vụ.

Ai đó đang yêu cầu bạn dự đoán tương lai. Bạn không thể làm điều đó. Và được yêu cầu dự đoán một sự kiện duy nhất, số liệu thống kê không giúp bạn. Loại người hỏi những câu hỏi này không hiểu ý nghĩa của "ước tính" Vì vậy, nếu bạn được hỏi "điều này sẽ được thực hiện trong bốn giờ", câu trả lời có thể là "rất có thể", "có thể, có thể không" và "rất không thể xảy ra ".

Đây là một câu hỏi hay. Tôi sẽ trả lời từ quan điểm của một người có 30 năm kinh nghiệm với một thập kỷ là người quản lý dự án chuyên dụng trong tất cả các lĩnh vực ngoại trừ phát triển phần mềm nhưng gần đây tình cờ phát triển khu vực phát triển phần mềm. Bất kể phương pháp nào được sử dụng trong nhóm của bạn và nó được gọi là gì, vào cuối ngày, các dự án phát triển cũng giống như bất kỳ phương thức kinh doanh nào khác mà mục tiêu phải đạt được trong các hạn chế cạnh tranh về thời gian, ngân sách và chất lượng - - và trong khi các dự án thực hiện, doanh nghiệp tiếp tục di chuyển và phát triển và có cơ hội tốt để đưa các thay đổi vào dự án của bạn. Do đó, cần phải thiết lập và cam kết với các mục tiêu và khung thời gian và có thể cung cấp các cập nhật thường xuyên và khi được yêu cầu. Tôi không

Điều đó đang được nói, theo kinh nghiệm của tôi, điều khiến cho việc ước tính thời gian trong phát triển phần mềm trở nên đặc biệt thách thức là các dự án phát triển đòi hỏi rất nhiều lãnh thổ không thông minh. Định nghĩa kỹ thuật của một "dự án", theo Cơ quan Kiến thức Quản lý Dự án của Viện Quản lý Dự án, là một dự án phải là duy nhất. Tuy nhiên, phần lớn các "dự án" trong CNTT chỉ là việc thực hiện lại các bản thiết kế & thiết kế đã được phát minh trước đó và các cuốn sách thực hiện. Trong phát triển phần mềm, chúng tôi có các khung và các mẫu thiết kế chung chung khác nhau, giúp cho nhiều sự phát triển có thể sử dụng lại được nhưng vẫn là cốt lõi của mỗi dự án là hoàn toàn độc đáo.

Ngoài ra, hầu hết các dự án phát triển đều đòi hỏi phải tích hợp với các hệ thống khác và việc có thể thực hiện nhanh như thế nào là một phỏng đoán lớn. Tôi đang thực hiện một dự án ngay bây giờ vì ước tính thời gian ban đầu của tôi dựa trên giả định rằng 4 hệ thống mà tôi cần tương tác với lập trình sẽ có API và hóa ra không có gì. Ngoài ra, một trong những hệ thống được lưu trữ trên đám mây và tổ chức của tôi có các chính sách cấm công việc đang được thực hiện. Ai có thể dự đoán điều đó?

Khi các khám phá được thực hiện khiến các khung thời gian gặp nguy hiểm, điều quan trọng là phải truyền đạt tốt lý do tại sao sự chậm trễ phát sinh, tại sao nó không thể lường trước được, v.v.

Tôi cũng đã được thông báo rằng khung thời gian đưa ra sẽ không hoạt động và làm cho nó diễn ra "nhanh hơn". Một biến thể khác đang được đưa ra một lượng lớn các thay đổi để đưa vào sự phát triển mà không cần phải có thêm thời gian. Có một định luật trong vật lý nói rằng vật chất không thể được tạo ra hoặc phá hủy, và điều này xuất hiện trong đầu tôi bởi vì dường như với tôi rằng thời gian cũng không thể được tạo ra từ không khí mỏng. Thúc đẩy sự phát triển có thể sẽ có tác động tiêu cực đến chất lượng phát hành, khả năng hỗ trợ của sản phẩm và / hoặc sự phát triển trong tương lai của sản phẩm.

Yêu cầu về lịch trình nên được trả lời trong điều khoản kinh doanh nói chung. "Vâng, chúng tôi đang đi đúng hướng để đáp ứng các khung thời gian đã cam kết trước đó, và không có vấn đề gì về việc sản xuất bia gây nguy hiểm". Yêu cầu thêm phạm vi quan trọng mà không cần thêm thời gian, hoặc chỉ đơn giản là tăng tốc phân phối, nên là một dạng "chúng ta có thể làm điều đó, nhưng chỉ cần tất cả đều biết rằng vốn đã có rủi ro lỗi vì phần lớn thời gian phát triển được thực hiện để chủ động như không giới thiệu lỗi và cũng để kiểm tra toàn diện. " Khi họ trả lời với "vì vậy chỉ cần kiểm tra nhanh hơn", nhận được phản hồi giải thích kiểm tra phát triển không kéo theo thời gian nhàn rỗi và có thể được tăng tốc mà không gây ra một số rủi ro thiếu sót.

Tóm lại, tôi chỉ đề xuất rằng tất cả các nhà phát triển - không chỉ là khách hàng tiềm năng, chủ scrum hay người quản lý dự án, hãy sẵn sàng thảo luận về nhiệm vụ của họ trong bối cảnh kinh doanh và thảo luận về việc thay đổi các tham số dự án bằng cách nhận ra sự đánh đổi mà sẽ dẫn tới.

Khi công việc được thực hiện hoặc hoàn thành, công việc còn lại ước tính được cập nhật.

- Hướng dẫn Scrum , trang 15

Mỗi nhà phát triển nên cập nhật trạng thái nhiệm vụ của họ và ước tính số giờ còn lại mỗi ngày trong bất kỳ công cụ năng suất nào mà nhóm của bạn sử dụng (ví dụ TFS).

Vì vậy, câu trả lời đơn giản cho người quản lý của bạn là hướng anh ta đến cột "số giờ còn lại" trong danh sách nhiệm vụ. Hy vọng anh ta sẽ học được rằng anh ta có thể tự truy cập vào những con số này và ngừng hỏi những câu hỏi ngu ngốc.

Bằng cách hỏi bất kỳ câu hỏi nào ở trên. Chủ nhân của scrum đang cố gắng quyết định xem chúng tôi có đang đi đúng hướng cho lần chạy nước rút này hay không và liệu có bất kỳ vấn đề ngăn chặn nào để bạn có thể cạnh tranh nhiệm vụ này không.

Điểm câu chuyện không tương quan với giờ của con người, chúng không có ý định, nhưng bằng cách hỏi liệu bạn có thể làm gì đó trước một ngày anh ấy thực sự hỏi điều gì ngăn bạn cạnh tranh nhiệm vụ này không? Nếu bạn cần một cái gì đó hỏi, theo quan điểm của tôi, vai trò của anh ấy là đảm bảo bạn có thể cạnh tranh nước rút, đó là những gì anh ấy thực sự yêu cầu ....