Làm thế nào để xin lỗi khi bạn đã phá vỡ tòa nhà hàng đêm [đóng cửa]

Cam kết đầu tiên của tôi trong dự án của tôi dẫn đến việc tòa nhà hàng đêm bị phá vỡ và mọi người ở khắp nơi khi tôi sắp phát hành. Tôi muốn gửi một email xin lỗi nghe có vẻ chân thành và đồng thời gợi ý rằng đây là cam kết đầu tiên của tôi và điều này sẽ không lặp lại nữa.

Là một người nói tiếng Anh không phải là người bản ngữ, tôi gặp khó khăn khi đưa ra các từ chính xác. Ai đó có thể vui lòng giúp đỡ?

Đừng xin lỗi!

• Phá vỡ công trình một lần trong một mặt trăng xanh không phải là một vấn đề lớn, và không bao giờ nên là một điểm dừng show.
• Đó là lỗi của người quản lý của bạn vì không định cấu hình các bản dựng tự động, liên tục.

Ngoài ra, tôi cá rằng nhóm của bạn thất bại trong 'Thử nghiệm Joel' và không thể xây dựng trong một bước.

Nếu vậy, đây sẽ là một điều khác mà bạn không nên xin lỗi. Thật vậy, đó là một đội chống mẫu.

Bánh mì tròn. Bánh rán. V.v. Tại một công ty tôi làm việc trong quá khứ, việc kiểm tra mã bị hỏng hoặc gây ra sự gián đoạn đồng nghiệp thường được giải quyết bằng cách đưa vào thực phẩm xin lỗi vào ngày hôm sau.

Một ngày nọ, chúng tôi đã có một anh chàng thổi bay cơ sở dữ liệu sản xuất, gây ra sự hoảng loạn lớn và một đêm khuya cho cả đội. Ngày hôm sau anh nướng bánh mì kẹp thịt cho bữa trưa.

Tôi yêu lời xin lỗi đồng nghiệp. Ngon, xin lỗi ngon.

Hai trích dẫn cho bạn:

Người đàn ông không phạm sai lầm thường không tạo ra bất cứ điều gì .-- William Connor Magee

Bất cứ ai không phạm sai lầm đều không cố gắng hết sức .-- Wess Roberts

Tôi đồng ý với Jim G. , đừng xin lỗi nhưng hãy học hỏi từ nó và đừng phạm sai lầm tương tự nữa ... hãy giữ nó KHÔ;)

Đừng xin lỗi, chỉ CỐ ĐỊNH CNTT càng sớm càng tốt. Mặc dù vậy cũng không sao, mọi người phá vỡ công trình ít nhất một lần, trong công ty cuối cùng của tôi, đó là một nghi thức khởi đầu. Khi một thành viên trong nhóm phá vỡ tòa nhà, chúng tôi sẽ đặt một con vịt cao su trên bàn của anh ấy vào buổi sáng trước khi anh ấy bước vào, điều này cho anh ấy biết anh ấy đã phá vỡ tòa nhà và anh ấy sẽ sửa nó.

Chúng tôi gọi nó là Duckie Tích hợp liên tục và khi bạn có nó vào ngày mọi người sẽ trêu chọc bạn nhưng tất cả đều vui vẻ, không ai trong số đó được cho là có tinh thần.

Chúng tôi lấy một cái gì đó giống như một bản dựng bị hỏng và biến nó thành một bài tập xây dựng đội nhóm.

"Xin lỗi, lỗi của tôi!" là cách tôi thường xin lỗi khi tôi phá vỡ bản dựng. Nó xảy ra. Nhưng như những người khác đã nói, đây là một cơ hội để cải thiện hệ thống của bạn để một người không thể dễ dàng phá vỡ bản dựng cho những người khác.

Tôi sẽ không đưa ra lời xin lỗi chính thức trong những trường hợp này, nhưng nếu bạn thực sự cảm thấy rằng một lời xin lỗi chính thức hơn là phù hợp, thì lời xin lỗi của bạn nên làm những điều sau:

• Thể hiện sự hối tiếc.
• Nêu vấn đề.
• Chịu trách nhiệm.
• Đền bù.
• Giữ thể diện.

Đó là, "Tôi xin lỗi [ĐĂNG KÝ TUYỆT VỜI] rằng tôi đã gây bất tiện cho bạn [HÃY TRÁCH NHIỆM] bằng cách vô tình [TIẾT KIỆM MẶT] phá vỡ công trình [NHÀ NƯỚC VẤN ĐỀ].

Mỗi phần là cần thiết trong một lời xin lỗi thích hợp; nếu bạn không nêu vấn đề thì không rõ. Nếu bạn không bày tỏ sự hối tiếc, chịu trách nhiệm và sửa đổi, thì mọi người cảm thấy như bạn không thành thật. Phần tiết kiệm khuôn mặt là phần bị bỏ qua nhất trong lời xin lỗi; phần tiết kiệm khuôn mặt là điều nhắc nhở bên bị thương rằng bạn là đồng nghiệp có giá trị đôi khi mắc lỗi và không phải là một thằng ngốc (hoặc một kẻ phá hoại!)

Cuối cùng, một số suy nghĩ về phá vỡ xây dựng:

Tôi làm việc trong nhóm biên dịch C # / Visual Basic. Tất nhiên ngày nay Visual Studio bây giờ là một dự án lớn đến nỗi nó có một đội ngũ của riêng mình chỉ để quản lý cơ sở hạ tầng xây dựng và một căn phòng lớn với hệ thống điều hòa không khí chuyên dụng. Trở lại giữa những năm 1990 khi tôi bắt đầu làm nhân viên thực tập, nhóm xây dựng Visual Basic là một người thực tập - tôi - và một tủ đầy máy móc. Thời gian đã thay đổi!

Quay trở lại những ngày trước khi tích hợp liên tục và quy trình kiểm tra mạnh mẽ, các đội sẽ có nhiều hình phạt cho việc phá vỡ công trình. Ở một số đội, hình phạt là nếu bạn phá vỡ công trình, bạn phải đội một chiếc mũ ngộ nghĩnh mỗi ngày tại nơi làm việc cho đến khi có người khác phá vỡ công trình. Ở một số đội, nếu bạn đội chiếc mũ đó, bạn có trách nhiệm xác minh rằng bản dựng hàng đêm là chính xác.

Điều đó nghe có vẻ tàn nhẫn, nhưng nó thực sự phục vụ một mục đích có giá trị. Vì hầu hết mọi người đã phá vỡ bản dựng lúc này hay lúc khác, cuối cùng, toàn bộ nhóm sẽ tìm hiểu các quy trình để xác minh bản dựng hàng đêm.

Đừng xin lỗi. Đó là đồng nghiệp của bạn, những người đáng trách vì đã không xem xét cam kết đầu tiên của bạn và không có hệ thống phản hồi nhanh cho các bản dựng như một máy chủ tích hợp liên tục.

Ở công việc hiện tại của chúng tôi, chúng tôi có một quy tắc không chính thức rằng ai đó lén lút cam kết ngay trước khi nghỉ việc và hóa ra để phá vỡ công trình phải mang kẹo / bánh / đồ uống cho cả đội vào ngày hôm sau. Nhưng chúng tôi có sự tích hợp liên tục cảnh báo chúng tôi về một công trình bị hỏng trong ngày. Và quy tắc có thể sẽ không áp dụng cho cam kết đầu tiên của ai đó.

Dù sao, một bức thư xin lỗi chính thức có lẽ là một chút quá nhiều.

Một quy tắc cơ bản - khi bạn sai, QUẢNG CÁO CNTT: - | Bạn không cần phải mò mẫm xin lỗi. Ai cũng mắc sai lầm. Các chuyên gia thừa nhận nó. Đó là tinh thần đồng đội. Các thành viên khác trong nhóm nên liên kết với nhau để giúp bạn vượt qua nó. Nếu họ không, HỎI để được giúp đỡ. Điều cần phải nói nhất sau đó là - chúng ta có thể học được gì từ nó?

Họ nói rằng một cuộc hôn nhân thành công dựa trên ba từ nhỏ - "Tôi đã sai".

Nếu ai đó không mắc lỗi thỉnh thoảng, họ sẽ không làm việc, nhưng một lỗi mà người ta không học được là hai lỗi.

Lời xin lỗi tốt nhất là sửa chữa nhanh chóng

Nếu công ty của bạn đã có cách để kiểm tra các thay đổi bản dựng của bạn, thì (A) các thay đổi của bạn không thành công (nhưng dù sao bạn cũng đã kiểm tra chúng) hoặc (B) họ đã thành công (và bạn cần xây dựng trường hợp thử nghiệm mới).

Nếu các đồng nghiệp của bạn cẩn thận kiểm tra các thay đổi của họ và mong muốn tìm thấy sự phá vỡ trên bản dựng hàng đêm, thì (C) bạn có một quy trình dễ vỡ (và bạn cần phải giới thiệu thử nghiệm như trong Lập trình cực đoan).

Có thể (D) Các thay đổi của bạn đã gây ra những thay đổi không lường trước được trong mã của Bill đã được đặt trước hoặc thay đổi trên cùng bản dựng với bản dựng của bạn.

Tùy thuộc vào cách bạn và công ty kiểm tra, tôi sẽ xin lỗi trên cơ sở từng trường hợp cụ thể:

• (A) Tôi đã thất bại trong bài kiểm tra xây dựng nhưng đã kiểm tra các thay đổi của tôi. Xin lỗi, tôi đang thay đổi quy trình của mình vì vậy tôi sẽ không làm lại.
• (B) Tôi đã vượt qua bài kiểm tra xây dựng và thêm bài kiểm tra JUnit XYZtest.java để giảm cơ hội tái xuất hiện.
• (C) Vì chúng tôi không có quy trình thử nghiệm xây dựng, tôi đang tạo một quy trình cho các thay đổi của mình. Tôi muốn chia sẻ với bạn cách chúng tôi có thể cải thiện quy trình xây dựng của mình.
• (D) Tôi sẽ làm việc với Bill để viết bài kiểm tra JUnit XYZtest.java để giảm cơ hội tái xuất hiện.

Tôi chắc chắn có một (E) mà tôi chưa từng nghĩ đến.

Lưu ý rằng tôi đang nói "để giảm cơ hội tái xuất hiện" thay vì "vì vậy nó sẽ không xảy ra lần nữa." Nó sẽ xảy ra một lần nữa. Nhưng bạn có thể cải thiện quy trình của mình để giảm khả năng đó. Điều đó, tôi nghĩ, là một trong những dấu ấn của một lập trình viên chiến thắng.

Đừng xin lỗi. Bạn là con người và bạn sẽ phạm sai lầm. Mọi người sẽ thỉnh thoảng phá vỡ bản dựng, điều quan trọng là chỉ cần sửa nó một cách nhanh chóng.

Đối với những người nhảy qua bạn ... tôi cũng tò mò về việc họ đã từng viết một lỗi chưa.

Làm thế nào để tiếp cận điều này phụ thuộc vào bầu không khí trong nhóm của bạn. Nếu đó là một văn hóa đổ lỗi, tôi sẽ rất cẩn thận về việc xin lỗi và cách bạn làm điều đó. Nếu đó là một bầu không khí hợp tác, tích cực, thì vâng, một cái gì đó dọc theo dòng chữ "Tôi đã làm hỏng, tôi xin lỗi. Làm thế nào chúng ta có thể tránh điều này trong tương lai?" có lẽ là một ý tưởng tốt

Trong mọi trường hợp, một người đi lên như thế này nên đi kèm với một số loại sau khi chết để a) tìm hiểu làm thế nào nó xảy ra và b) làm thế nào để giảm thiểu cơ hội xảy ra lần nữa.

Tôi không quen thuộc với cấu trúc của bạn (tôi làm việc trong một môi trường rất khác) nhưng cuối cùng, thực tế là đôi khi, mọi người mắc lỗi và mọi thứ bị phá vỡ. Bạn học hỏi từ kinh nghiệm và đi tiếp.

Trong môi trường của tôi, nếu bạn phá vỡ công trình, bạn sẽ có được một bản nhạc tốt bụng và một số đồng tiền dí dỏm. Tôi không chắc bạn đang nói tiếng Anh ở nước nào, nhưng có thể là một người nói tiếng Anh không phải là người bản ngữ, bạn không nhận được bản chất cơ bản của các bình luận.

Xuất thân từ phía bên kia với tư cách là nhà phát triển cấp cao, tôi đã từng nhận xét về đánh giá mã rằng một số cách thực hiện x "hút" không phải vì mã xấu mà làm theo cấu trúc của dự án. Đó là bình luận nhiều hơn cho bản thân tôi rằng tôi cần phải khắc phục vấn đề cấu trúc. Chỉ sau đó tôi mới phát hiện ra rằng Dev Dev mặc dù tôi rất giận anh ta vì lời nói không chính xác của tôi.

Ừm. Bạn nhận được mã thông báo xây dựng bị hỏng . Truyền bệnh dại cho người nhận may mắn tiếp theo. Xảy ra mọi lúc. Chất lượng là quan trọng, nhưng sai lầm là không thể tránh khỏi. Sửa chúng. Tiến lên. Xấu hổ cho người nghèo tiếp theo.

Theo nguyên tắc chung, tôi sẽ nói:

Nếu đăng ký của bạn gây ra lỗi trình biên dịch, bạn sẽ tự nhận thấy mình đã thực hiện "lấy mới nhất" trước khi đăng ký, một "rất tiếc, xấu của tôi" là theo thứ tự. (đặc biệt nếu bạn đi dạo vào lúc 10 giờ sáng hôm sau, trong khi mọi người đang quyết định thay đổi nào sẽ quay trở lại)

Nếu đăng ký của bạn gây ra hành vi bất ngờ chung, thậm chí lỗi thời gian chạy, tôi không nghĩ rằng nó nên được giữ lại đối với bạn. Nó đi kèm với lãnh thổ. Miễn là "bản cập nhật mới nhất" của mọi người thường được thông qua trình biên dịch của họ, mọi người thực sự không nên ném phù hợp (với một vài ngoại lệ như xóa cơ sở dữ liệu, xóa bản sao máy chủ của dự án và tất cả các thay đổi, hoặc bất cứ điều gì khác ngu ngốc mà mọi người phải giả định mục đích xấu).

NHÓM thất bại.

Công ty của bạn cần xem xét mã nhiều hơn trên một nhà phát triển xây dựng lần đầu tiên.

Tôi chỉ không thấy làm thế nào một nhóm cho phép điều này diễn ra mà không cần họ xem xét và đưa ra một số đảm bảo trên đường đi mà bạn đang làm mọi thứ một cách chính xác.

Gần thời gian phát hành không phải là một lý do, nhưng một lý do tốt hơn để kiểm tra lại mã mới.

Nếu bản phát hành của bạn không thể dễ dàng hoàn tác, thậm chí còn có vấn đề lớn hơn với nhóm này.

Tôi không hiểu tại sao mọi người lại ở trên bạn. Nếu hệ thống được thiết lập tốt, họ sẽ có thể trêu chọc những thay đổi của bạn / sửa chúng rất nhanh.

Nhưng một lần nữa, nếu bạn là một trong những kẻ phá vỡ cửa sổ xây dựng, thì ... tôi không thể giúp được. (Thật khó để làm btw - trước khi bất kỳ ai thắc mắc MS xây dựng triết lý, nhưng bây giờ và sau đó ai đó làm điều đó - và toàn bộ công ty QA dừng lại trong một ngày).

Và vâng - đừng xin lỗi. Chỉ cần trò chuyện với người quản lý của bạn và khiến anh ấy hiểu rằng bạn đã học được từ những gì bạn đã làm.

Xây dựng phá vỡ tất cả các thời gian. Lỗi và sai lầm là một thực tế của cuộc sống, và đó là lý do tại sao bạn nên có một quy trình giảm thiểu ảnh hưởng của lỗi và sai lầm.

Nếu một sự phá vỡ xây dựng là một vấn đề lớn, điều đó có nghĩa là quá trình của bạn bị phá vỡ.

Bạn nên làm các bản dựng liên tục, không phải bản dựng hàng đêm.

Tốt hơn là một câu trả lời muộn hơn là không bao giờ ...

Như nhiều người khác đã nói, đừng xin lỗi vì đã phá vỡ công trình. Đơn giản chỉ cần thừa nhận rằng đó là bạn và tiếp tục với công việc. Điều này sẽ xảy ra cho dù bạn có ở đó hay không, và không ai đáng bị đối xử tệ vì điều đó. Mọi người phản ứng xấu dưới áp lực, vì vậy nếu bạn có thể giữ bình tĩnh và đơn giản là bắt tay vào công việc, bạn sẽ nổi bật khi có vấn đề. Lời khuyên của tôi khi mọi người dành cho bạn một khoảng thời gian khó khăn là chỉ cần tránh phòng thủ, xoa dịu tình hình bằng cách cho mọi người biết bạn đang gặp vấn đề hoặc bạn nhanh chóng tìm kiếm lời khuyên nếu bạn thấy mình bị mắc kẹt.

Cá nhân, tôi thấy một bản dựng bị hỏng là một cơ hội.

• Nếu bản dựng bị hỏng và bạn có thể chứng minh đó là lỗi của mình, thì có khả năng nó cho thấy rằng quá trình tích hợp và xây dựng liên tục đang thực hiện công việc của họ. Đây là một điều tốt, vì nó xác nhận các quy trình của bạn. Nếu bản dựng không bao giờ bị hỏng, tôi lo lắng rằng có gì đó không ổn với nó.
• Nếu bạn đã phá vỡ bản dựng theo cách khá phổ biến và nó thường xuyên bị hỏng theo cách này, thì có lẽ thiếu một cái gì đó từ quy trình CI. Đây là một cơ hội để cải thiện các quy trình của bạn để các kịch bản thất bại phổ biến có thể được quản lý tốt hơn.
• Nếu bạn đã vượt ra ngoài nhiệm vụ và thực sự làm rối tung công trình với một vấn đề mơ hồ, thì bạn có cơ hội tìm hiểu về điều gì đó mới có thể đủ quan trọng để đưa ra cảnh báo cho các thành viên còn lại trong nhóm.

Vì vậy, những gì tôi đang nói là thỉnh thoảng phá vỡ công trình có nghĩa là mọi người đang làm việc của họ. Chắc chắn bạn có thể đã phạm sai lầm, nhưng nếu bạn sử dụng nó như một cơ hội để học hỏi, bạn đang làm công việc của mình đơn giản bằng cách học cách làm nó tốt hơn vào lần sau.

Nói với họ rằng họ cần xây dựng CI mỗi lần đăng ký. Bằng cách đó, bạn sẽ không phải đợi đến tối để biết nó bị hỏng. YEA !!! Nói với họ đó là quá trình sai, không có gì khác. Bạn chỉ cần xác định một khoảng cách trong hệ thống của họ .

Nhưng phải, hãy chắc chắn để sửa nó. Không phải là một thỏa thuận lớn. Nó không có trong sản xuất. Chỉ là một đêm vô giá trị.

Một thông lệ trong công ty của tôi là:

• "Không phải là tôi!" (thường là bằng chứng CVS / SVN khác)
• Mặc một chiếc áo phông có chữ "my-userlogin ist Schuld!" (vâng, 50% nhà phát triển của chúng tôi sở hữu một chiếc áo như vậy)
• Khẳng định rằng nó hoạt động trong hộp thư cục bộ và tất cả các bài kiểm tra đều ổn

Công ty của tôi cũng có một cách tốt để xử lý một "sự cố" như vậy:

• Nhân viên phải mặc trang phục sau cho một nửa ngày ( http://www.tradoria.de/kostueme/kruemelmonster-sesamstrasse-kostuem-kruemelkostuem-337103661.html )

• Tôi sẽ không xin lỗi.

• Tôi sẽ đổ lỗi cho lãnh đạo CI vì đã cho phép tôi cam kết xây dựng bị hỏng.

• Cần có một quy trình CI để ngăn chặn các nhà phát triển cam kết mã bị hỏng.

• Nếu xây dựng cục bộ thất bại, thì nó không được phép vào máy chủ xây dựng.

Trong khi tôi nghĩ rằng một số lời xin lỗi có thể được đưa ra, xin đừng nói: "Tôi sẽ đảm bảo điều này sẽ không xảy ra lần nữa." Bởi vì nó sẽ. Và nếu nó làm nó sẽ cắn bạn.

Nếu bạn đang làm việc trên một dự án nguồn mở,

chỉ cần nói "Xin lỗi, tôi đã phá vỡ công trình. Có thể tôi đã quá buồn ngủ!"

và thêm nó dưới dạng một bình luận github.

Đó là bởi vì nhiều nhà phát triển nguồn mở viết mã trong nửa đêm.