Ви шукаєте технічне рішення людської проблеми. Це рідко працює.
Ось кілька підходів, які я або використовував у минулому, або маю на увазі, не маючи на ділі можливості для них. Деякі можуть не стосуватися вашої справи, залежно від займаної вами позиції в команді (якщо ви керівник команди з відмінною репутацією, швидше за все, ви матимете кращу нагоду нав'язати свій погляд, ніж якщо ви студент, який щойно приєднався до команди на час вашого стажування).
Обговоріть це питання зі своїми колегами та поясніть наслідки великих зобов'язань. Можливо, вони просто не розуміють, що складні злиття є прямим наслідком рідкісних комітетів, і, ніж малі, часті внесення зроблять злиття (відносно) легкими.
Я знав багато програмістів, які просто були впевнені, що злиття завжди складні. Вони зробили щонайменше один вчинок на день, уникали використання потужних інструментів, таких як розрізнення та автоматичне злиття Visual Studio, і мали погану практику ручного злиття (якщо тільки “Візьміть мою” без подальшої різної перевірки насправді не є хорошою практикою). Для них це не має нічого спільного з ними , і був властивий характер злиття.
Наведіть конкретні приклади того, що відбувається в інших компаніях (особливо тих, кого ваші колеги дуже поважають). Вони можуть просто не підозрювати, що це питання, і переконані, що максимум один вчинок на день - це те, що робить кожна команда.
Деякі люди не знають, що є команди з 5-10 членів, які виробляють до 50 підштовхувань до виробництва, що в середньому складає 5-10 комітетів на день на людину. Вони можуть не розуміти ні того, як це можливо, ні чому б хто це робив.
Подавати приклад. Зробіть достатньо невеликих зобов’язань. Якщо можливо, зробіть коротку презентацію, де відображатимуться їхні та ваші злиття поруч протягом тижня (я не впевнений, чи витягнути цю інформацію легко з контролю версій). Підкресліть можливі помилки, які вони зробили під час злиття, і порівняйте їх з кількістю допущених помилок (яка повинна бути близькою до нуля).
Використовуйте техніку "Я тобі казав", коли це доречно . Коли ви бачите, що ваші колеги страждають від болісного злиття, голосно коментуйте, що невеликі, часті вчинки можуть зробити злиття (відносно) безболісними.
Поясніть, що немає мінімальної тривалості для здійснення зобов’язання. Зобов’язання може навіть відповідати незначній зміні, здійсненій за кілька секунд. Перейменування файлу, видалення застарілого коментаря, виправлення друкарської помилки - це всі завдання, які можна виконати негайно.
Програмісти не повинні боятися робити невеликі зобов’язання, а скоріше об'єднати багато змін у одну величезну комісію.
Працюйте з людьми замість команди, коли це доречно. Якщо є людина, яка особливо відмовляється робити часті, невеликі вчинки, поговоріть з цією людиною індивідуально, щоб зрозуміти, чому він відмовляється від цього.
Вони можуть дати абсолютно поважні причини, які можуть дати вам підказку про те, що відбувається з командою. З деяких причин я почув себе:
«Мій вчитель / наставник сказав мені, що найкраща практика - це робити один вчинок на день». Це не дивує мене, враховуючи те, що мені довелося почути від моїх викладачів у коледжі .
"Мої колеги сказали мені, що я повинен робити менше зобов'язань". Мені це сказали в деяких командах, і я розумію їхню думку. У нас був журнал, який був практично заповнений моїми зобов'язаннями (що не важко зробити, коли чотири товариші по команді навіть не роблять жодного зобов’язання на день), що засмучувало моїх колег.
"Я думав, що невеликі доручення ускладнюють пошук доопрацювання". Якесь дійсне значення, навіть коли команда докладає зусиль для написання описових повідомлень журналу.
"Я не хочу витрачати занадто багато місця на нашому сервері управління версіями". Людина, очевидно, не розуміє, як зберігаються комікси (а також наскільки дешевим є місце для зберігання).
«Я думаю, що зобов’язання повинно відповідати конкретній задачі». Зважаючи на те, що часто завдання відповідає певній роботі, яка повинна бути виконана за один день (наприклад, на дошках завдань візуального управління), це не випадковість. Потім людина повинна навчитися змінювати завдання між відставанням (2 - 8 годин роботи) та логічно ізольованою зміною, яку слід здійснити (від декількох секунд до кількох годин роботи). Це також пов'язане з пунктом 5.
Шукайте причину, яку команда не виконує, частіше. Ви можете бути здивовані результатами.
Нещодавно я згадував в іншій відповіді, що швидкість виконання комісії має значення, і навіть сотні мілісекунд можуть підштовхнути розробників до виконання більш рідкісних ознак .
Інші причини можуть включати:
Надмірно складні правила написання повідомлення про вчинення.
Правило, яке змушує розробника зв'язувати фіксацію завдання із системою відстеження помилок.
Страх зламати збірку.
Небажання мати справу з ризиком порушити збірку прямо зараз: якщо ви зробите зобов’язання в п'ятницю ввечері безпосередньо перед від'їздом, ви можете відкласти розгляд справи зі зламаною збіркою на понеділок.
Страх зробити злиття.
Визначте, чи розуміють розробники, що часто застосовуються інші переваги . Наприклад, платформа безперервної інтеграції є величезним стимулом до частого вчинення , оскільки дозволяє точно визначити, куди була введена регресія .
Я вважаю за краще платформу CI, яка говорить мені про те, що я порушив збірку в редакції 5023, яка полягає в зміні двох методів в одному файлі, який я робив п'ятнадцять хвилин тому, а не в редакції 5023, що складається зі змін, які охоплюють чотири десятки файлів і представляють 13 годин роботи.