Здійснює контроль за читанням версій менеджера

Наш менеджер стежить за зобов'язаннями Git щодо всіх наших проектів; Зазвичай це не проблема, і мені подобається, що контроль версій забезпечує журнал усієї роботи, особливо для подальшого аудиту та аналізу (у випадку, якщо щось піде не так).

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

Чи існує соціальне чи технічне рішення для цього?

Додаткова інформація: це проект технічного обслуговування, тому існує купа "довелося зробити A, потім B, потім C і D, а потім нарешті дістати реалізацію завдань X".

Додаткова інформація: конкретне повідомлення про фіксацію, яке підняло прапор разом із менеджером, було близьким до "включало кращий шлях до X, Y і Z", що є скоріше повідомленням про рефакторинг, а не простим стилістичним виправленням.

version-control management

— Пітер Мортенсен
джерело

Можливий дублікат Чи вважається посиланням на помилку / проблему у повідомленні про переконання гарною практикою?

— гнат

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

— Гурт Робота

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

— Gort the Robot

^^^ що сказав @StevenBurnap - це дуже хороша практика. Просто мати можливість вказати ідентифікатор квитка, а не забруднювати повідомлення про фіксацію з тривалими поясненнями того, що таке поліпшення стилю / рефакторинг, і чому вони потрібні, це вартує того. І в цьому є більше, відстеження зусиль, спілкування з управлінням / QA тощо тощо. І не запускайте мене про те, як це зручно, коли трекер помилок інтегрується з інструментом перегляду VCS / коду

— gnat

Це повністю залежить від ситуації. Чи реагує менеджер на члена команди, який витрачає 50% свого часу на рефакторинг або на одну комісію без посилання на квиток?

— winkbrace

Відповіді:

Чи існує соціальне чи технічне рішення для цього?

Я думаю, але це не проблема .

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

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

— Теластин
джерело

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

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

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

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

— AvetisG
джерело

Гаразд, але якщо це банальне виправлення, то це абсолютно дурно.

— Гонки легкості з Монікою

Технічна заборгованість 99,99% часу не є дрібницею. Ось чому я кажу, зробити квиток замість того, щоб зануритися в щось інше, що є великим контекстним перемикачем. Якщо це щось тривіальне і не пов’язане з тим, над чим ви працюєте, ви все одно можете перевірити це під назвою квитка, над яким працюєте, окремим коментарем. Або ще краще подумайте про такі позначення, як QFIX, для легкої ідентифікації згодом, так що у вас немає випадкових тривіальних змін, що плавають навколо, без організації.

— AvetisG

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

— Рудольф Олах

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

— AvetisG

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

— Gort the Robot

Ця помилка мене теж (жоден каламбур не передбачає :).

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

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

— Занепокоєння
джерело