Який найкращий спосіб розділити роботу серед розробників

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

Тож після того, як я провів багато часу за читанням (напевно, недостатньо), у мене виникли проблеми з питанням, як розділити роботу між розробниками.

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

Який найкращий / найбільш прийнятий спосіб розподілити роботу між розробниками?

• Надання кожній людині іншого модуля для роботи.
• Призначте всіх розробників до одного модуля та розділіть роботу на різні частини модуля (UnitTesting, DAL та Mapping, Logics, UI)
• Призначте всіх розробників до одного модуля та розділіть роботу за різними логіками (Наприклад, кожен розробник відповідає за певну логіку (можливо, метод в BL) і це UnitTesting, DAL та Mapping та UI ...

А може, щось зовсім інше?

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

• Розділення розробників на модуль:

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

• Усі працюють над тим самим модулем одночасно

  • Ми намагалися це зробити за один реліз, коли керівництво вирішило, що вони накладуть спритність на всю команду, і це буде повністю їх шлях. Це як абсолютна аварія поїзда. У нас була команда з 9 розробників, які постачали за рік, що зазвичай робив би один розробник. (Я, можливо, тут перебільшую, але не дуже).
  • Ніхто не відчував, що там немає дихальної кімнати. Ті, хто не переймався програмним забезпеченням, відчували себе як вдома, тому що, будучи частиною більшої упаковки, вони просто розбавляються в групі. Ті з нас, хто мав пристрасть до програмного забезпечення, відчували себе абсолютно задушеними, оскільки не було свободи рухатися чи виходити за межі, про що домовилися 9 людей.
  • Всі зустрічі йшли назавжди до того, що я хотів знімати себе. Занадто багато людей з думкою в одній кімнаті змушені працювати над тією ж вигаданою DLL. Жах.
• В останньому випуску ми вирішили спробувати щось інше
  • Перш за все, розбийте групу розробок на менші команди з 3-4 розробників. Кожна команда працювала у відносній ізоляції один від одного, але всередині колективу люди працювали набагато більш злагоджено
  • При такому підході стадії швидко проходять, а планування зустрічей займає 1-2 години порівняно з твердими 4 години.
  • Усі відчувають себе залученими, тому що кожна команда лише обговорює те, про що піклуються розробники в цій команді.
  • Періодично кожен ведучий з кожної команди спілкується з іншими технічними ведучими, щоб переконатися, що загальний проект іде на шляху.
  • Замість того, щоб зробити людей "власником" конкретного модуля, ми призначили людям сфери знань, тому коли ми вперше розпочали проект, здавалося, що люди мають власний модуль, але через кілька місяців розробники почали розглядати код інших, як області почали перекриватися.
  • Огляди коду є важливими. Це був другий випуск, де у нас була сувора політика перегляду коду, і всі в команді їх люблять. Експерт певної області завжди переглядає код, коли хтось інший модифікує цей код.
  • З оглядом коду ми маємо багато обміну знаннями, і ви можете побачити загальне поліпшення якості коду наших команд. Крім того, що код перевіряється так часто, коли люди заходять у чужу сферу знань, ймовірно, вони вже бачили код хоча б кілька разів.
  • Більша частина кожної команди всмоктується на зустрічі з перегляду дизайну, тому навіть якщо вони ніколи не бачили код, всі знайомі із загальним потоком усіх модулів, за які відповідає їх команда.
  • Ми робимо це близько 10 місяців, і таке відчуття, що ми почали з ізольованого модульного підходу і потрапили в кожен, хто працює над усім. Але в той же час ніхто не відчуває, як вони тісні або обмежені. І щоб переконатися, що хлопці все ще відчувають якийсь авторитет, ми залишили їх як експертів у галузі, хоча це зараз переважно формальність.

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

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

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

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

Нарешті, і це дуже важливо і завжди не помічається. ВИ НЕ ЗДАНИТЕ ЦЕ ПРАВО (якщо ви не супермен чи принаймні Бетмен). Регулярні ретроспективні зустрічі є надзвичайно важливими. Коли ми розгортали ретроспективи, вони були зроблені за книгою, і здавалося, що ще один процес, який ви повинні пройти. Це не те, що ретроспектива. Це для прослуховування вашої команди, визначення областей, які завдають найбільшого болю, та виправлення їх, щоб кожен міг продовжувати свою роботу. Мабуть, інженери програмного забезпечення в цілому люблять доставку продуктів та функцій, а найважливіше повідомлення, яке потребує ретроспективної зустрічі, полягає в тому, що це виключно на їх користь. Ви хочете визначити і вирішити перешкоди, починаючи з найбільших (або найпростіших, там "

Проведіть зустріч з командою, покажіть їм список справ і запитайте, хто хоче чим займатися.

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

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

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

Хоча я згоден з відповіддю Девіда, я вважав, що це може отримати користь від деяких детальних:

• Agile означає, що ви не приймаєте цих рішень і не підштовхуєте їх до команди. Такого керівника проекту / керівника немає. Тільки команда.
• Ті, хто найкраще знає, як розділити роботу, - це самі члени команди.
• Обговоріть свої відсталі та з’ясуйте, що ви хочете реалізувати в наступній ітерації / спринті.
• Використовуйте планування покеру або подібні методи, щоб отримати уявлення про те, скільки роботи ви збираєтеся розділити, і тільки потім почніть ділити фактичні робочі пакети разом .

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

Найпростіший підхід часто є найкращим.

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

Зіткнувшись з такою ж дилемою, я застосував такий підхід:

• Обсяг проекту. Дайте собі уявлення про те, в що ви потрапляєте, і розробіть список функцій, розбивши проект на низку завдань.

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

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

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

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

• Не бійтеся, щоб розробники працювали з перекриваючими ітераціями, і керуйте своїми випусками відповідно. Це допоможе мінімізувати витрачений час між релізами, які чекають виконання завдань.

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

Жодна організаційна дискусія команди розробників не була б повною, не згадуючи хірургічну групу доктора Фреда Брукса .

Основна формула: одна хірургічна група на одиницю роботи

Визначення хірургічного колективу

Концепція хірургічного колективу базується на двох фундаментальних ідеях:

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

Хірургічний колектив складається з 3-10 розробників:

1. Головний програміст. Високопродуктивний розробник, який робить більшість фактичних програм.
2. Копілот. Ще один розробник з високою продуктивністю, який виконує деякі програми, а також деякі адміністративні завдання, такі як відвідування зустрічей та зборів.
3. 1 - 8 помічників. Брукс описує це як розробників, відповідальних за такі речі, як документація, очищення коду, дослідження, інструменти / алгоритми написання, тестування тощо. Ще в 60-х Брукс запропонував рівно 8 ролей, але для сучасних інструментів вам може знадобитися не менше 1 або 2, і ймовірно, слід призначити, виходячи з потреб вашого проекту.

Визначення одиниці роботи

Тож тепер, коли ми можемо скласти команду, що ми їм присвоюємо?

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

Ви повинні побачити три основні прийнятні схеми:

1. Рівно 1 підгрупа для кожного шару (UI, DAL тощо)
2. Рівно 1 підгрупа для кожного модуля (домашня сторінка, сайт підтримки, магазин)
3. Мікс двох (команда низького рівня та команда, орієнтована на користувальницький інтерфейс для кожного модуля)

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

Звичайно, це не завжди працює ...

Ось що я б робив:

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

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

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