Làm thế nào để xem xét mã hiệu quả trong cơn sốt phát hành?

Hạn chót cho một bản phát hành là vào ngày mai, đồng nghiệp của bạn cuối cùng đã hoàn thành nhiệm vụ quan trọng của mình cho bản phát hành này, người quản lý dự án đang đứng trên vai bạn và ép bạn cuối cùng thực hiện một bản dựng và bạn nhận thấy một lỗ hổng trong mã trường đại học của bạn trong quá trình xem xét. Không phải là một vấn đề quan trọng, nhưng một cái gì đó bạn sẽ không cho đi nếu nó không được phát hành vào ngày mai. Và để làm cho mọi thứ tồi tệ hơn, bạn có công việc của riêng bạn, bạn cần phải hoàn thành càng sớm càng tốt. Vậy bạn làm gì? Bạn có phản đối bất chấp áp lực hay bạn chỉ để điều này trượt?

Một cách tôi tìm thấy là tạm thời hợp nhất cam kết này trên một chi nhánh khác và để lại đánh giá cho lần sau. Nó hoạt động nếu vấn đề chỉ là vấn đề thẩm mỹ và nếu đó là vấn đề duy nhất vẫn đang chờ xem xét mã. Tuy nhiên, có cách nào hiệu quả hơn để xử lý việc này? Ví dụ: bạn có đề nghị cam kết một người chỉ kiểm tra mã và kiểm tra không?

Câu trả lời ở đây là giao tiếp.

1. Nói với trưởng nhóm kỹ thuật / về vấn đề này
2. Nói chuyện với QA về tác động tiềm năng
3. Nói với quản lý dự án (người ở ngay sau bạn) rằng có thể có một vấn đề khiến việc phát hành bị trì hoãn và bạn sẽ quay lại với họ càng sớm càng tốt (trong vài phút hoặc vài giờ)
4. Đánh giá xem vấn đề này có phải là điểm dừng cho phát hành không

Nếu vấn đề không phải là một điểm dừng chương trình, tiếp tục phát hành. Thông báo cho QA và người dùng của bạn về vấn đề này và cam kết ngày theo dõi, nơi vấn đề sẽ được khắc phục. Điều này chỉ trở thành một rủi ro khác đi vào sản xuất.

Nếu đây là một công cụ chặn hiển thị (có nghĩa là nó sẽ có tác động tiêu cực đến điểm mấu chốt hoặc sức khỏe của ai đó) truyền đạt điều này lên chuỗi rằng khuyến nghị của bạn là trì hoãn việc phát hành, và cho biết lý do. Sau đó quay lại với nhà phát triển và tính xem sẽ mất bao lâu để khắc phục sự cố và thông báo cho ban quản lý rằng bạn cần X số phút / giờ / ngày.

Cơ hội là quản lý sẽ không hài lòng về một điểm dừng chương trình vào cuối trò chơi này, nhưng sẽ không muốn nó được phát hành để sản xuất.

Giao tiếp, và để quản lý thực hiện cuộc gọi.

Đừng chỉ truyền đạt vấn đề, hãy ghi lại

Mối quan tâm lớn của tôi với các câu trả lời khác cho đến nay: Bất cứ điều gì bạn nói dọc theo những dòng này với người quản lý dự án điển hình phải đối mặt với thời hạn sắp xảy ra có thể sẽ bị bỏ qua hoặc lãng quên. Sau đó, bạn vẫn có thể rơi vào tình trạng khó khăn trong việc truyền đạt rủi ro, nếu có sự cố xảy ra.

Hãy cho người quản lý dự án biết về vấn đề bạn đã tìm thấy và cho anh ta biết bạn sẽ ghi lại nó. Bạn cần phải có khả năng chỉ ra sự siêng năng của bạn.

Tài liệu ở đâu và ai sẽ nói tùy thuộc vào môi trường làm việc của bạn, nhưng chắc chắn bao gồm sếp của bạn.

Xác định rủi ro và tác động

Bạn đề cập đến vấn đề không phải là vấn đề quan trọng nhưng thực sự không xác định điều đó có nghĩa là gì. Bỏ qua đó là bước tiếp theo của bạn.

Thực hiện phân tích rủi ro và tác động nhanh chóng để xác định vấn đề, khả năng gây ra sự cố (rủi ro) và mức độ nghiêm trọng của hậu quả nếu rủi ro xảy ra. Sử dụng các thuật ngữ được xác định rõ (mà người quản lý dự án của bạn nên biết) giống như các thuật ngữ được tìm thấy trong liên kết ở trên, nhưng cũng cung cấp một mô tả sao lưu phân tích của bạn.

Tài liệu của bạn cũng nên bao gồm quá trình hành động được đề nghị của bạn . Có , bạn có thể nêu ra mối quan tâm và vẫn khuyên bạn nên tiếp tục phát hành. Đó là chính xác để xác định rủi ro .

Khi nào là bản phát hành tiếp theo của bạn?

Nếu, sau khi hoàn thành phân tích rủi ro / tác động của bạn, bạn vẫn đang trên hàng rào về những gì cần đề xuất, hãy tính đến lịch phát hành của bạn. Một số mã không hoàn hảo có thể phát hành nếu bạn có thể bao gồm sửa lỗi trong hai tuần.

Nếu có cơ hội khắc phục mối quan tâm của bạn sẽ nhận được sự hủy hoại của người Viking (nghĩa là, bị bỏ qua để ủng hộ sự cải tiến sáng bóng tiếp theo) thì đó là một lý do nữa để ghi nhận vấn đề càng sớm càng tốt sau khi bạn phát hiện ra: đồng hồ về vấn đề này.

Trong trường hợp này, chỉ cần thông báo cho tất cả mọi người và để họ quyết định. Đây có lẽ không phải là lỗi đầu tiên bạn phát hành.

Hạn chót là vào ngày mai, nhưng bạn thấy mình trong tình huống này:

quản lý dự án đang đứng trên vai của bạn và ép bạn để cuối cùng thực hiện một công trình

Đây có thể là ngoại lệ, vì vậy đừng thực hiện bất kỳ thay đổi mạnh mẽ nào đối với quy trình của bạn chỉ vì một lỗi xảy ra. Những gì bạn nên làm là đưa ra một số biện pháp, vì vậy bạn sẽ không thực hiện các bản dựng vào phút cuối. Hy vọng rằng, bạn đang thực hiện các bản dựng với tần suất đủ thường xuyên để giúp bạn tự tin rằng nó sẽ thành công. Đó vẫn chưa phải là một lý do đủ tốt để chạy chúng vào phút cuối. Có những thứ được kiểm tra tốt là một phần khác để tăng sự tự tin.

Trình bày kịch bản này cho bất cứ ai đang dẫn dắt điều này.

• Xác định loại vấn đề nên được trình bày.
• Xác định các tùy chọn.
• Ai ra quyết định
• Khi nào tất cả những điều này nên được quyết định bởi? Nó có thể sẽ liên quan đến ngày phát hành.

Mặc dù điều này không trả lời phải làm gì với vấn đề vào phút cuối này, nhưng nó đưa ra một cách để đảm bảo bạn có thể giải quyết chúng trong tương lai. Đặc biệt là khi có áp lực để giải phóng, bạn muốn có cách xử lý mọi việc theo cách suy nghĩ thấu đáo và không bị chi phối bởi cảm xúc.

Nếu có thời hạn, và người quản lý của bạn ở ngay sau bạn nhìn qua vai bạn, bạn bảo anh ta đi. Anh đi xa hoặc em đi xa. Giải thích cho anh ta rằng bị buộc phải xem xét dưới áp lực, bạn cũng có thể không xem lại mã.

Trong tình huống như thế này, bạn có thể khá chắc chắn rằng một số lỗi nghiêm trọng sẽ xảy ra.

Bạn có thể đang ở trong một tình huống may mắn, như gửi tới App Store của Apple, nơi bạn có một vài ngày để rút lại một phiên bản mới. Nhưng nếu mã của bạn được chuyển đến khách hàng, đó là một công thức cho thảm họa. Lần sau tôi hy vọng người quản lý của bạn có kế hoạch tốt hơn.

Các câu trả lời khác tập trung vào vấn đề người quản lý của bạn đang cố gắng bẻ cong quy trình chất lượng của bạn.

Tuy nhiên, điều tôi nghĩ bạn đang hỏi là làm thế nào để đối phó với thực tế là việc xem xét mã yêu cầu ít nhất 2 người, và do đó đưa ra sự chậm trễ đáng kể. Ví dụ: nếu một nhiệm vụ mất 2 giờ để thực hiện và 2 giờ để xem xét, thường sẽ có một khoảng dừng dài giữa hai hoạt động. Trong thời gian thực, nhiệm vụ có thể mất 2 hoặc 3 ngày để hoàn thành.

Đây là một vấn đề cổ điển của thông lượng so với độ trễ. Trong các bộ chuyển đổi bối cảnh của máy sản xuất phần mềm (con người) rất tốn kém, do đó, việc ưu tiên công việc của ai đó để ngay lập tức thực hiện đánh giá không phải là một cách phổ biến.

Dưới đây là một số mẹo để giảm thiểu vấn đề:

• Trong khi thực hiện một nhiệm vụ, hãy gửi mã thành các phần nhỏ để người đánh giá sẽ không phải dự trữ thời gian dài liên tục.
• Thúc đẩy văn hóa ưu tiên cao cho đánh giá mã. Đừng dừng đơn vị công việc hiện tại của bạn khi bạn nhận được yêu cầu, nhưng khi bạn đang tự hỏi phải làm gì tiếp theo, hãy luôn chọn đánh giá từ hàng đợi của bạn.
• Tận dụng sự khác biệt múi giờ trong các đội của bạn, nếu có.
• Đừng cam kết một người chỉ đánh giá mã. Nó phản tác dụng. Anh ta sẽ không thể xử lý tải, nếu anh ta sẽ nghiêm túc với nhiệm vụ của mình. Người quản lý của bạn sẽ không chấp nhận ý tưởng về việc ai đó nhàn rỗi, chỉ để có khả năng tiết kiệm một ngày.