eXtreme Programming [Парне програмування]

Сама спірна і сама розповсюджена практика XP (eXtreme Programming).

Що таке ХР ?

Одна із гнучких методологій розробки програмного забезпечення. Кент Бек і ще пару його кентів взяли за основу самі сучасні методології 1990х і довели їх ефективність до максиму своїми ‘Екстримальними практиками‘ - тому це і називають XP (eXtreme Programming).

Всього існує 13 головних пунктів Екстримального програмування.

У цій статті ми розберемо лише одну практику - Парне програмування.

Цілі парного програмування:

Можу виокремити декілька головних цілей цієї практики:

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

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

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

4. Розвиток, якщо команда із 2х розробників одного рівня будуть працювати разом, у короткий термін їх рівень знань буде рости як відсотки по кредиту (дуже стрімко).

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

Недоліки парного прогамування:

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

2. Навіть не пробуйте це робити віддалено, ця практика тільки для offline тренингів.

3. Складно пояснити замовнику чому 2 людини затрекали в одну і туж задачу однакову кількість часу.

4. Перший раз дуже складно налаштувати сам процес парного програмування. Часто не продумуючи план просто сідають і відразу пробують писати код - НЕ НАДА ТАК.

5. Різний темп розробки, або різні ідеї, вам потрібно завчасно вирішити всі питання і тільки тоді сідати за компютер.

Неочевидні недоліки:

1. Є великий шанс стати ворогами із колегою.

2. Після 1 дня парного програмування ввечері не хочеться жити.

3. Це далеко не лайтова штука, ви навіть музичку на ютубі не зможете увімкнути або повтикати у тікток - тільки робота.

Із чого почати:

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

2. План дій. Виберіть у якому форматі буде проходити парне програмування (Розвиток, вирішення складної задачі, менторство). Після конкретного розуміння що ви будете робити, вам потрібно визначити ролі: Книжка каже що є 2 головні ролі (Driver, Navigator) Водій і Штурман, визначте ці ролі між собою.

3. Перед початком ознайомтесь із всіми документаціями які можуть знадобитись при вирішенні поставленої задачі.

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

5. Як часто міняти ролі. Це потрібно вирішити перед початком, рекомендую підходи по 30-40 хвилин писання коду за 1 раз.

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

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

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

Воно того варте ?

Тут немає чіткої відповіді. На мою думку - так, але пам’ятайте що це підходить не всім і точно не кожен день.

Як мінімум кожному девелоперу варто спробувати для персонального розвитку - дуже рекомендую.

Підсумки:

За весь час який я в ІТ - користувався цією практикою разів 10+-.

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

Про ваш досвід з радістю почитаю у коментарях.