phục hồi thảm họa phần mềm khi một kỹ sư đột nhiên không có

Gần đây trong công ty của tôi, chúng tôi đã có một dự án trong đó thời hạn rất chặt chẽ và mọi thứ diễn ra theo đúng kế hoạch cho đến khi tôi không có mặt do các vấn đề cá nhân cực đoan.

Cuối cùng, chúng tôi đã bỏ lỡ thời hạn 4 ~ 5 ngày.

Các kế hoạch phục hồi thông thường cho các điều kiện này là gì? công ty của tôi có nên thuê ngoài một nhà phát triển để hoàn thành công việc của tôi không? thậm chí có thể mất một vài ngày để tìm thấy một?

Nó phụ thuộc vào thời gian dự kiến ​​của sự không có sẵn, thời gian còn lại của dự án, cách phân phối các nhiệm vụ và hậu quả của việc bỏ lỡ thời hạn.

Các nhà phát triển phần mềm không thể thay thế cho nhau theo ý muốn. Các nhà phát triển xây dựng kiến ​​thức trên hệ thống khi hệ thống phát triển và việc thêm một tài nguyên mới đòi hỏi phải đối phó với kiến ​​thức bối cảnh còn thiếu của các tài nguyên mới.

Một số thực hành tốt làm giảm các rủi ro liên quan đến việc không có sẵn đột ngột:

• đánh giá ngang hàng đảm bảo rằng kiến ​​thức về sự phát triển được chia sẻ giữa một số nhà phát triển. Trong trường hợp không có sẵn, phần còn lại của nhóm có thể tổ chức lại để tiếp quản, hoặc trong trường hợp xấu nhất mang đến một lập trình viên mới và tổ chức chuyển giao kiến ​​thức.
• các nhóm được tích hợp kết hợp chặt chẽ với nhau để đưa ra quyết định thiết kế có thể giảm thiểu sự không có sẵn trong cùng một kiểu. Các kiến ​​thức được chia sẻ về thiết kế tổng thể tạo điều kiện phân phối lại công việc và tóm tắt những người mới đến.
• tài liệu chính thức cuối cùng có thể giúp đỡ. Tuy nhiên, trong thực tế, điều này chỉ hoạt động tốt nếu tài liệu được tạo bởi một nhà phát triển được sử dụng bởi một nhà phát triển khác (hoặc các mô hình được sử dụng trong các công cụ tạo mã). Tài liệu chỉ được đọc bởi chính mình thường xuất hiện mơ hồ hơn nhiều. Nếu một nhà phát triển mới phải đảm nhận công việc đó, tài liệu tự có thể đưa ra nhiều câu hỏi mà nó trả lời.

Đưa vào các nhà phát triển mới khi có thời hạn chặt chẽ là rất khó khăn, bởi vì việc tóm tắt những người mới sẽ mất thời gian của nhóm, trong giai đoạn không có thời gian rảnh. Nếu bạn bị ốm trong 1 tuần thì không có ý nghĩa gì. Sẽ được dự tính nếu chi phí cho người mới tham gia được bù đắp bằng lợi ích của tài nguyên mới, thông thường nếu có chi phí trễ cao hoặc nếu không thể hoãn lại hoặc nếu không có thời gian dài hơn.

Các kế hoạch thông thường cho việc này là xây dựng dự phòng vào thời hạn. Những điều xảy ra, bạn thường không bao giờ đạt đến thời hạn. Bạn không có mặt chỉ là một trục trặc khác trong các kế hoạch được đặt cẩn thận không bao giờ đi theo kế hoạch!

Đây được gọi là "yếu tố xe buýt". Về cơ bản, rủi ro đặt ra cho dự án nếu nhà phát triển bị xe buýt đâm. Có một nhà phát triển không có sẵn trong một tuần là một trục trặc nhỏ so với việc mất một nhà phát triển vĩnh viễn. Nó có thể là một tai nạn hoặc bệnh bất ngờ, nhưng ít nghiêm trọng hơn, nó chỉ có thể là một nhà phát triển cốt lõi chuyển đổi công việc trong thông báo ngắn hoặc bị sa thải. Hoặc một nhà phát triển cốt lõi được chuyển sang một nhiệm vụ ưu tiên cao khác trong bộ phận khác.

Nói tóm lại, bạn phải lên kế hoạch hạ thấp hệ số xe buýt, hoặc bạn phải chuẩn bị để giảm thiểu nó, ví dụ như có bộ đệm trong thời hạn hoặc chỉ cần đủ linh hoạt để có thể đẩy thời hạn. Những gì bạn thường không thể làm chỉ là thuê ngoài một nhiệm vụ phức tạp trong một thông báo ngắn hoặc thuê một nhà phát triển mới - hầu như sẽ luôn mất nhiều thời gian hơn để giới thiệu một nhà phát triển mới cho một hệ thống hiện có hơn là đợi một tuần để nhà phát triển cốt lõi quay trở lại. Nếu một nhóm nhỏ mất một thành viên thì tất nhiên họ sẽ chậm hơn, nhưng nếu cũng phải giới thiệu một thành viên mới, họ sẽ còn chậm hơn nữa.

Bạn có thể hạ thấp yếu tố xe buýt bằng cách nhóm liên tục chia sẻ kiến ​​thức và đánh giá ngang hàng (hoặc thậm chí lập trình cặp). Nhưng tất nhiên đây là điều phải xảy ra trước khi xe buýt đâm vào.

Bất kỳ nhân viên nào cũng có thể không có mặt trong một tuần, hoặc một tháng hoặc mãi mãi mà không có bất kỳ thông báo nào vào bất cứ lúc nào. Tai nạn, bệnh tật, đã có đủ công việc này, nhiều lý do khác. Tùy thuộc vào quản lý để đảm bảo rằng một dịp như vậy là gây phiền nhiễu, có thể tốn kém, nhưng không phải là một thảm họa.

Nếu bạn có một nhóm mười người, bạn có thể mất 10% nhóm của mình. Công ty sẽ có thể xử lý rằng nếu phần còn lại của nhóm có động lực (trả tiền cho giờ làm thêm là động lực cao). Nếu bạn là một nhóm, thì công việc sẽ không hoàn thành. Nếu bạn có những nhân viên khác có thể bước vào, sự chậm trễ có thể được giảm thiểu. Thuê một ai đó từ bên ngoài sẽ khó khăn, mặc dù bạn có thể tìm thấy một số nhà thầu có thể bắt đầu sau một thông báo vài ngày trong một vài tuần với tốc độ rất cao hàng giờ.

Điều tốt nhất để làm là có các hợp đồng, vv để việc trì hoãn hoàn thiện sản phẩm không phải là một thảm họa tài chính. Và để có một ngày hoàn thành theo kế hoạch và có thể đạt được trước thời hạn. Có nhân viên có thể giúp đỡ lẫn nhau (nhưng có thể có vấn đề để đạt được).

Và nếu bạn có một thời hạn phải đạt được, thì có lẽ phạm vi công việc linh hoạt hơn. Nói cách khác, bỏ các tính năng để đáp ứng thời hạn của bạn.

Một cách chính để giảm "Yếu tố xe buýt" mà @JacquesB đề cập ở trên là lập trình cặp như một kỹ thuật cốt lõi. (Thực tế của tôi là sử dụng thuật ngữ "Yếu tố xổ số" vì nó ít bệnh hoạn hơn nhưng hiệu quả là như nhau.)

Nhiều nhà phát triển ghét lập trình cặp; nhiều nhà quản lý cũng ghét điều đó, vì những lý do hoàn toàn khác nhau (một số nhà phát triển ghét bị buộc phải giao tiếp với người khác trong thời gian dài; một số nhà quản lý thường cảm thấy không chính xác như thể họ đang trả gấp đôi số tiền cho một đầu ra).

Nhưng việc lập trình cặp hoàn toàn loại trừ nguy cơ một điểm thất bại duy nhất của con người, bằng cách đảm bảo rằng bất kỳ nhiệm vụ phát triển nhất định nào đều được thực hiện và hiểu bởi ít nhất hai nhà phát triển.

Có một số cách tôi đã thấy loại điều này được xử lý:

Chia sẻ công việc

Điều rõ ràng nhất để làm là chia sẻ công việc giữa các tài nguyên hiện có (giả sử điều này là có thể). Làm thế nào để đảm bảo các nhà phát triển tiếp tục chạy gần như là một câu trả lời, nhưng cuối cùng, nó nắm bắt được các yêu cầu, thiết kế và tiến độ đúng. Những thứ như lập trình cặp cũng có thể hỗ trợ rất nhiều ở đây.

Đẩy lùi thời hạn hoặc cố gắng vuốt ngược thời gian

Kiểm tra với khách hàng để xem liệu thời hạn có thể được gia hạn không. Ngoài ra, có thể có được thời gian phát triển bổ sung bằng cách làm việc buổi tối, cuối tuần và ngày lễ.

Bỏ các nhiệm vụ khác

Có bất kỳ nhiệm vụ không quan trọng nào khác có thể được tạm thời bỏ để nhường chỗ không?

Đi trước

Có công việc nào được lên kế hoạch sau khi phát triển có thể được đưa ra như tài liệu, tập lệnh thử nghiệm và cấu hình không?

Thừa nhận nó có thể bị trễ

Nói chuyện với khách hàng sớm. Có thể có thể cung cấp một phần - hoặc ít nhất, bạn có thể có được một chỉ đạo đàng hoàng về các ưu tiên tương đối của những thứ khác.

Tài nguyên bổ sung

Một khả năng - nhưng điều này tự nó mang rủi ro. Sẽ mất thời gian để giúp họ tăng tốc và vì chúng là tạm thời, họ có thể rời đi khiến bạn thậm chí còn tệ hơn.

Kiểm tra đường dẫn quan trọng

Nếu các bên khác có liên quan - hãy kiểm tra xem họ có còn đúng mục tiêu không. Có rất ít điểm trong việc di chuyển trời và đất để hoàn thành một cái gì đó nếu nói, nhóm thử nghiệm chậm hơn một tháng so với thử nghiệm mọi thứ.

Chấp nhận thực tế của rủi ro

Có một cụm từ phổ biến trong nghề luật nói rằng các vấn đề khó tạo ra giải pháp kém. Nó có thể hấp dẫn để thử và khiến mọi người hiểu mọi thứ để bao quát tất cả các tình huống. Tuy nhiên, đây là một việc vặt.

Các nhà phát triển nên dành thời gian chất lượng cho sự phát triển của chính họ. Tiêu thụ một lượng thời gian ngày càng tăng trở thành au fait với các phát triển khác là một hoạt động rất đáng nghi ngờ. Một nền tảng trung bình hợp lý có thể có một chuyên gia về vấn đề và một phó phòng.