Парне програмування за допомогою Scrum

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

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

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

З огляду на це, який найкращий спосіб врахувати зусилля / години / розповіді в сценарії сполучення, щоб переконатися, що ми відвели належним чином час для створення пари?

Деякі розглянуті варіанти:

1. Дозвольте двом людям підписатися на кожне завдання і (приблизно) подвоїти кількість передбачуваної години
2. Тільки учасник команди "руки на клавіатурі" підписується на кожне завдання, яке оцінюється виходячи з орієнтовних годин цієї людини. Усі в команді, які підтримуватимуть парування, підпишуться на меншу кількість завдань у спринті, щоб мати час на підтримку парування.

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

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

Замініть години на очки, якщо це робить вас почувати себе більш чистим;)

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

По-перше, наше знайомство з Agile, а точніше Scrum, не було дуже гладким. В основному менеджмент зійшов і сказав: з цього дня ви будете робити Scrum, і це буде процес, який ви будете всі слідувати. Стільки для людей над процесом .

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

Ключовим для усвідомлення є те, що Agile та Scrum включені насправді про людей. Коли команда займається плануванням ітерації, не дозволяйте майстру Scrum (який, мабуть, ваш менеджер) призначити вам години, розповіді та завдання. Це повністю ДО КОМАНДИ. Я думаю, що для багатьох людей це дуже важке поняття, щоб пережити його, бо роками до цього вони прийшли на роботу, і вони мали б начальника (керівника, технічного керівника ...), який би просто призначив роботу. Вони занурюються в Scrum, але кожен (включаючи сам майстер scrum) продовжує працювати в тому ж режимі.

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

Крім того, інша річ, яка виправляє лайно у мене, - це те, як людям кажуть, що їх потужність ЗАВЖДИ становить 75% від загальної кількості годин, тож це те, на що вони беруть на себе зобов'язання, а потім протягом усієї тривалості ітерації вони скаржаться, що а) вони не можуть допомогти вам або б) вони не можуть зробити правильно, оскільки їм призначено занадто багато годин. Людям не слід говорити, скільки годин на вчинення, і вони, безумовно, повинні відштовхуватися, якщо майстер scrum намагається витягти щось подібне! Кожен повинен взяти на себе зобов’язання саме того, що їм комфортно. Наприклад, я керівник команди, і часто потрапляю у випадкову незаплановану дискусію щодо дизайну, або допомагаю комусь із кодом, або з вирішенням неполадок у дивних речей, тому мій потенціал ніколи не перевищує 50%.

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

Оновлення 1: Відповідь на коментар Кліффа Ну ви запропонували свої вуха, ось ось це ...

Ви маєте рацію, культурна зміна є ключовою, але цю зміну не потрібно робити на рівні виконавчої влади. Ваш власний менеджер групи може змінити культуру у вашій команді та ізолювати вас, хлопці, від корпоративного BS, з яким він має справу. Те, що ви описуєте, було ТОЧНО у нас з 2007 по 2010 рік. Наша команда (а також інші команди) провалилася після релізу. В одному з випусків, використовуючи "процес управління спритністю", нам вдалося, щоб 9 людей виробляли роботу, яку зазвичай робила одна людина, і це зайняло у нас вдвічі більше часу. У мене було стільки вільного часу, що я навіть оновив своє резюме.

Потім я провів розмову зі своїм начальником і пояснив йому всі ці речі, наскільки спритний щодо людей, і що якщо ви хочете, щоб ми піклувалися про товар, давайте приймати рішення, які впливають на те, як ми працюємо над і доставляємо товар. Я думаю, що він вирішив зробити експеримент із цього, він робив кожну зміну, яку ми… ну, переважно я сам, але я багато спілкуюся з рештою команди, отже, 50% потенціалу :) ... запропоновано. Цілком можливо, що він подумав, що якщо він внесе всі зміни, про які ми просимо, і ми все-таки провалимось, він повернеться з переможною "Я тобі це сказав".

Тож за останні 12 місяців ми усунули стільки "дурних", що це навіть не смішно. Наші зустрічі з stand-up насправді мають сенс зараз, оскільки ми працюємо разом, а не в ізоляції. Ми все ще володіємо (принаймні поки що) певними частинами продукту, але також дуже часто перетинаємо код інших. Ми постійно робимо огляд коду, щоб не тільки члени команди вивчали інший код, але й вивчали кращі методи кодування та дизайну. Ми розбили монолітну, гігантську "спритну" команду на 3 різні команди, тому планування та інші зустрічі набагато коротші, і люди насправді дбають про них, оскільки вони не сидять і слухають речі, які їх не цікавлять. Я ' Я бачив ночі, коли 4 з 5 наших хлопців (одна з команд) були онлайн в 11 вечора, і ніхто насправді не сказав нам, що ми повинні працювати чи колись тиснуть на нас, щоб працювати понад 40 годин. Люди, які не могли піклуватися менше півроку тому, раптом зайняті і схвильовані роботою, яку вони роблять. І все, що потрібно було, щоб наш менеджер зробив це сказати: "Ви, хлопці, вирішуйте, що правильно, і робіть те, що вам потрібно зробити, і я буду уникати корпоративних BS від команди, наскільки я можу".

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

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

У вашому випадку, можливо, парне програмування не є рішенням, якщо ви шукаєте іншу зовнішню силу, щоб зійти в команду і сказати їм, як працювати. Натомість викиньте правила, сідайте з ними без управління і запитайте у них, що вони хочуть робити? Що зробить їх щасливими? Продуктивний? Визначте найбільші проблеми, а потім запитайте КОМАНДУ, яким вони вважають рішення.

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

З посібника з Scrum :

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

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

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

Чому? Оцінка - це сміття. Як це може бути сміття? Тому що, якщо більше оцінювання не принесе більше ділової цінності = це сміття, і його слід зменшити до необхідного мінімуму. Мінімум - це оцінка / розмір історій, що допоможе вам взяти на себе зобов’язання. Після того, як ви взяли на себе зобов’язання, вам не потрібні інші оцінки. Ви просто знаєте, що у вас встановлена ​​дата, щоб доставити щось, що ви зробили. Ви або зможете донести вчинені історії, або ні. Оцінка завдань не допоможе тобі в цьому.

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

Просто, щоб було зрозуміло. Зобов'язання означає = Ми це зробимо . Не ми будемо намагатися це зробити чи щось інше. Так, ви не зможете виконати те, що ви зробили, але ваше зобов'язання має базуватися на вірі, що завдяки вашим сучасним знанням ви будете доносити вибрані історії. Якщо у вас є ця віра, вам не потрібна інша оцінка.

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

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

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