Як вибачитися, коли ви порушили нічну будівлю [закрито]

Перший мій вчинок у моєму проекті призвів до того, що нічні будівлі були порушені, і люди повсюдно перебувають через мене, коли ми наближаємося до випуску. Я хочу надіслати електронний лист із вибаченнями, який повинен звучати щиро, і в той же час натякаючи, що це було моє перше зобов'язання, і це більше не повториться.

Будучи носієм англійської мови, я маю труднощі придумувати правильні слова. Може хтось, будь ласка, допоможе?

Не вибачайтесь!

• Розбити конструкцію одного разу на блакитному місяці - це не велика справа, і ніколи не повинно бути зупинкою шоу.
• Це вина вашого менеджера, що він не налаштовує безперервні автоматизовані збірки.

Крім того, я сумніваюся, що ваша команда зазнає невдачі «Тест Джоеля» і не може скласти збірку за один крок.

Якщо так, то це буде інша річ, за яку ви не повинні вибачатися. Дійсно, це командна анти-модель.

Бублики. Пончики. І т.д. В одній компанії, над якою я працював у минулому, перевірка зламаного коду чи іншим чином спричиняє зрив колеги, як правило, вирішується шляхом введення продуктів прощення вибачень на наступний день.

У нас один день хлопець підірвав виробничу базу даних, викликаючи масову паніку та пізню ніч для всієї команди. Наступного дня він обсмажив гамбургери на обід.

Я люблю вибачення колег. Смачні, смачні вибачення.

Дві цитати для вас:

Людина, яка не робить помилок, зазвичай нічого не робить. - Вільям Коннор Мейгі

Той, хто не робить помилок, не надто старається. - Весс Робертс

Я погоджуюся з Джимом Г. , не вибачайтеся, але вчитеся на цьому і не робіть знову тієї ж помилки ... продовжуйте це ДУЖЕ;)

Не вибачайтесь, просто ПІНУТИСЯ ІТЕ якомога швидше. Все гаразд, але всі хоч раз ламають складку, в моїй останній компанії це був щось із ритуалу ініціації. Коли учасник команди зламав збірку, ми вранці перед тим, як він зайшов, на робочий стіл поклали гумову качку, це дало йому знати, що він зламав збірку, і він це виправить.

Ми назвали це Duckie безперервної інтеграції, і коли ти мав це на той день, коли люди будуть дражнити тебе, але це було все весело, жодне з цього не повинно було бути злим духом.

Ми взяли щось на зразок розбитої конструкції і перетворили це на вправу командного будівництва.

"Вибачте, мій поганий!" як я зазвичай вибачаюся, коли зламав складання. Це буває. Але, як говорили інші, це можливість вдосконалити свої системи, щоб одна людина не могла так легко розбити склад для всіх інших.

Я б не робив офіційного вибачення за цих обставин, але якщо ви насправді вважаєте, що більш формальне вибачення є доречним, то ваше вибачення має робити такі дії:

• Висловлюйте жаль.
• Сформулюйте проблему.
• Брати відповідальність.
• Вносити поправки.
• Збережіть обличчя.

Тобто, "вибачте [ЕКСПРЕССЬКИЙ ЖЕЛИТИЙ], що я незручно вам [ВІДПОВІДАЮТЬ ВІДПОВІДАЛЬНІСТЬ] випадково [ЗБЕРІТЬ ЛИЦЕ], порушивши конструкцію [ДЕРЖАВНА ПРОБЛЕМА]. Пончики на мене завтра.

Кожна частина необхідна в належному вибаченні; якщо ви не заявите про проблему, то це незрозуміло. Якщо ви не висловлюєте жалю, берете на себе відповідальність і не виправдаєте, люди відчують себе нещирими. Частина, що зберігає обличчя, - це найбільш переглянута частина вибачення; частина, що береже обличчя - це те, що нагадує постраждалій стороні, що ви - цінний колега, який іноді робить помилки, а не ідіот (або диверсант!)

Нарешті, кілька думок щодо розбиття побудови:

Я працюю над командою компілятора C # / Visual Basic. Звичайно, сьогодні Visual Studio - це настільки масштабний проект, що у нього є власна команда просто керувати побудовою інфраструктури та величезна кімната з власною спеціальною системою кондиціонування. Ще в середині 1990-х, коли я почав стажуватися, команда побудови Visual Basic була одним стажистом - мені - і шафою, повною машин. Часи змінилися!

Ще в ті часи, перш ніж безперервна інтеграція та сильний процес перевірки, команди мали б різноманітні покарання за порушення функції. Для деяких команд штрафом було те, що якщо ви зламали збірку, вам доведеться носити смішну шапку щодня на роботі, поки хтось інший не зламав збірку. У деяких колективах, якщо ви носили таку шапку, ви відповідали за те, щоб нічне складання було правильним.

Цей останній шматочок звучить, можливо, жорстоко, але насправді він послужив цінній цілі. Оскільки майже всі розбили збірку в той чи інший час, врешті-решт вся команда дізналася б процеси перевірки нічних збірок.

Не вибачайтеся. Ваші колеги винні в тому, що вони не переглянули ваш перший вклад і не мають системи швидкого зворотного зв’язку для таких конструкцій, як сервер постійної інтеграції.

На моїй нинішній роботі у нас є неофіційне правило, що той, хто підступно чинить перед тим, як залишити роботу і виявиться порушити склад, повинен принести цукерки / торти / напої для всієї команди наступного дня. Але у нас є безперервна інтеграція, яка попереджає нас про поломку протягом дня. І правило, мабуть, не стосуватиметься когось першого зобов'язання.

У будь-якому випадку, формальної пошти вибачень, мабуть, трохи забагато.

Основне правило - коли ви помиляєтесь, ПРИЙМУЙТЕ ІТ: - | Вибачте, ви не повинні принищуватися. Усі роблять помилки. Плюси визнають це. Це командна робота. Інші члени команди повинні зібратися разом, щоб допомогти вам у цьому. Якщо цього не зробити, попросіть допомоги. Найбільше, що потрібно сказати після цього, - це що ми можемо навчитися з цього?

Кажуть, що вдалий шлюб ґрунтується на трьох маленьких словах - «я помилився».

Якщо хтось не допускає випадкових помилок, він не працює, але помилка, з якої не вчиться, - це дві помилки.

Найкраще вибачення - це швидко виправити перерву

Якщо у вашої компанії вже є спосіб перевірити зміни в збірці, то (A) ваші зміни або не вдалися (але ви все одно перевірили їх), або (B) вони вдалися (і вам потрібно створити новий тестовий випадок).

Якщо ваші колеги обережно перевіряють свої зміни і очікують, що ви знайдете перерви в нічному складі, тоді (C) у вас крихкий процес (і вам потрібно запровадити тестування, як у екстремальному програмуванні).

Можливо, що (D) Ваші зміни спричинили непередбачені зміни в коді Білла, які були або раніше, або змінені на тій же збірці, що і ваша.

Залежно від того, як ви та ваша компанія перевіряєте, я прошу вибачення у кожному конкретному випадку:

• (A) Я не вдався до тесту збірки, але перевірив свої зміни. Вибачте, я змінюю свій процес, тому більше не буду це робити.
• (B) Я пройшов тест збірки та додав тест JUnit XYZtest.java, щоб зменшити ймовірність повторного появи.
• (C) Оскільки у нас немає тестового процесу побудови, я створюю його для моїх змін. Я хотів би поділитися з вами, як ми можемо покращити наш процес збирання.
• (D) Я буду працювати з Біллом, щоб написати тест JUnit XYZtest.java, щоб зменшити ймовірність повторного виникнення.

Я впевнений, що є (E), про який я не думав.

Зауважте, що я кажу "зменшити ймовірність повторного появи", а не "щоб це не повторилося". Це відбудеться знову. Але ви можете вдосконалити процес, щоб зменшити таку можливість. Це, я думаю, є одним із знаків переможця програміста.

Не вибачайтеся. Ви людина і будете робити помилки. Кожна людина буде порушувати збірку періодично, головне лише швидко її виправити.

Що стосується людей, що стрибають через тебе ... ну, мені цікаво, чи не писали вони колись у помилку.

Як підійти до цього, залежить від атмосфери у вашій групі. Якщо це культура вини, я б дуже обережно вибачався і як це робиш. Якщо це атмосфера спільної позитивної атмосфери, то так, щось таке: "Я заплутався, пробачте. Як ми можемо цього уникнути в майбутньому?" це, мабуть, гарна ідея.

У будь-якому випадку, подібний випадок повинен супроводжуватися якимось посмертним наслідком, щоб: a) з'ясувати, як це сталося, і b) як мінімізувати шанси його повторення.

Я не знайомий з вашою структурою (я працюю в зовсім іншому середовищі), але в кінцевому рахунку, реальність полягає в тому, що періодично люди роблять помилки, і все порушується. Ви вивчаєте досвід і рухаєтесь далі.

У моєму середовищі, якщо ви зламали збірку, ви отримали б лагідне ребро і трохи дотепного комета. Я не впевнений, у якій країні ви говорите англомовну, але могло бути так, що, як ви, хто не є носієм англійської мови, ви не отримуєте чіткого характеру коментарів.

Будучи з іншого боку як Старший розробник, я одного разу прокоментував огляд коду про те, що якийсь спосіб x "всмоктується" не тому, що код був поганий, але це стосується структури проекту. Мені було більш коментовано, що мені потрібно виправити структурну проблему. Лише пізніше я виявив, що молодший Дев, хоча я дуже сердився на нього через мою неточну нескінченну промову.

Гм. Ви отримуєте зламаний маркер збірки . Передайте сказ наступному щасливому одержувачу. Відбувається весь час. Якість важлива, але помилки неминучі. Виправити їх. Рухайся. Ганьба наступного бідного хлопця.

Як правило, я б сказав:

Якщо ваша реєстрація спричиняє помилку компілятора, ви б зловили себе, якби ви зробили "останню інформацію" перед тим, як зареєструватися, в порядку є просте "ого, моє погано". (особливо якщо наступного ранку ви прогуляєтесь в той час, коли всі вирішують, до якого набору змін повернутися)

Якщо ваша реєстрація викликає загальну несподівану поведінку, навіть помилки під час виконання, я не думаю, що це повинно бути проти вас. Він йде з територією. До тих пір, поки всі "отримують найновіші", звичайно, їх проходять компілятори, люди дійсно не повинні кидати форму (за кількома винятками, такими як видалення бази даних, видалення серверної копії проекту та всіх наборів змін, або будь-чого іншого, що так німий, що людям доводиться приймати зловмисні наміри).

Команда не вдалася.

Вашій компанії потрібен додатковий перегляд коду для розробника, який працює вперше.

Я просто не бачу, як команда дозволяє це продовжувати, не переглядаючи їх і надаючи певні запевнення, що ви робите все правильно.

Наближення часу до випуску - це не привід, а краща причина для повторної перевірки нового коду.

Якщо випуск не може бути легко скасований, з цією групою виникають ще більші проблеми.

Я не розумію, навіщо люди над тобою. Якщо система налаштована добре, вони повинні мати можливість дражнити ваші зміни / виправити їх дуже швидко.

Але знову ж таки, якщо ви один із тих хлопців, які зламали вікна, будували, То ... я не можу допомогти. (Це зробити надзвичайно важко - раніше, ніж хто-небудь ставить під сумнів MS будувати філософії, але час від часу хтось це робить - і вся компанія QA зупиняється на день).

І так - не вибачайтесь. Просто поговоріть зі своїм менеджером і дайте йому зрозуміти, що ви дізналися з того, що зробили.

Споруди постійно ламаються. Помилки та помилки - це факт життя, і саме тому у вас повинен бути процес, який мінімізує наслідки помилок та помилок.

Якщо розрив збірки - це велика справа, це означає, що ваш процес порушений.

Ви повинні робити безперервні побудови, а не щоночі будувати.

Краще пізня відповідь, ніж ніколи ...

Як багато інших сказали, не вибачайтесь за те, що зламали збірку. Просто визнайте, що це були ви та продовжуйте роботу. Цей матеріал трапився б ви там чи ні, і ніхто не заслуговує того, щоб з ним погано поводилися. Люди погано реагують під тиском, тож якщо ти зможеш залишатися спокійним і просто займатись роботою, ти будеш виділятися, коли це має значення. Моя порада, коли люди важко переслідують вас, це просто уникнути оборони, розрядити ситуацію, даючи людям знати, що ви чи не вирішили проблему, або ви швидко шукаєте поради, якщо виявите, що ви застрягли.

Особисто я бачу розбиту конструкцію як можливість.

• Якщо збірка перервана, і ви зможете довести, що це ваша вина, то, швидше за все, буде показано, що безперервна інтеграція та процеси збирання виконують свою роботу. Це гарна річ, оскільки вона підтверджує ваші процеси. Якщо збірка ніколи не ламається, я б хвилювався, що з цим щось не так.
• Якщо ви зламали збірку досить розповсюдженим чином, і трапляється таким чином ламатися часто, то, можливо, чогось не вистачає в процесі CI. Це можливість покращити ваші процеси, щоб покращити управління загальними сценаріями відмов.
• Якщо ви вийшли за рамки обов'язку і дійсно зіпсували складку з незрозумілою проблемою, тоді у вас є можливість дізнатися про щось нове, що може бути досить важливим, щоб викликати попередження для решти команди.

Тож, що я говорю, це те, що час від часу порушувати склад означає, що люди виконують свою роботу. Звичайно, ви могли помилитися, але якщо ви використовуєте це як можливість вчитися, ви робите свою роботу просто, навчившись робити це краще наступного разу.

Скажіть їм, що вони потребують нарощування ІП за час реєстрації Таким чином, вам не доведеться чекати, коли вночі, щоб знати, що вона зламана. ТАК !!! Скажіть їм, що процес неправильний, нічого іншого. Ви щойно визначили розрив у їхній системі.

Але так, не забудьте це виправити. Не велике діло. Це не у виробництві. Просто нікчемна ніч.

Звичайна практика в моїй компанії:

• Кричали "це не я!" (зазвичай докази CVS / SVN інакше)
• Носив футболку з написом "мій-userlogin ist Schuld!" (так, 50% нашого розробника має таку сорочку)
• Стверджуючи, що він працює в локальній скриньці, і всі тести пройшли просто чудово

Моя компанія також має приємний спосіб подолання такого "інциденту":

• Працівник повинен носити такий костюм протягом півдня ( http://www.tradoria.de/kostueme/kruemelmonster-sesamstrasse-kostuem-kruemelkostuem-337103661.html )

• Я б не вибачався.

• Я б звинувачував керівництво CI у тому, що він дозволив мені зробити зламану збірку.

• Має бути створений процес CI для того, щоб зупинити розробників у вчиненні зламаного коду.

• Якщо локальна збірка не вдається, то їй не можна дозволяти входити в сервер збірки.

Хоча я думаю, що може бути якесь вибачення, будь ласка, не кажіть: "Я переконуюсь, що це не повториться". Тому що буде. І якщо це станеться, це вас вкусить.

Якщо ви працюєте над проектом з відкритим кодом,

просто скажіть "Вибачте, що я зламав збірку. Можливо, я був занадто сонним!"

і додайте його як коментар до Github.

Це тому, що багато розробників з відкритим кодом пишуть код протягом півночі.