Найкращий спосіб планувати програмування для невеликих команд? [зачинено]

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

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

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

У вас є ідея:

1. У чому причина цього, це спільне для програмістів?
2. Що я можу зробити, щоб підтримати їх у плануванні? Чи існують методи чи засоби, які корисні програмістам у невеликих командах?

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

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

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

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

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

У невеликому магазині розробники часто закінчуються подвоєнням, як систематики, команда підтримки і навіть тестери (хоча з усіх речей, які вони могли б зробити, тестування - це те, чого слід намагатися уникати будь-якою ціною), тому вам потрібно це врахувати. З’ясуйте, скільки часу власне розробники витрачають на роботу над новими можливостями та врахуйте їх у ваших оцінках. Якщо завдання оцінюється в 2 дні, але ваші розробники здатні працювати над новою розробкою лише 60% часу, тоді для його завершення вам знадобиться 4 дні. Ви можете допомогти з цим, також контролюючи конвеєр інших завдань, з якими вони повинні виконуватись, щоб невідкладні завдання адміністратора чи підтримки могли бути об'єднані дещо разом, а не оброблятися на спеціальній основі. Дуже багато програмістів (безумовно, включаючи мене на цьому) - не чудові менеджери часу, тому все, що ви можете зробити, щоб подати руку в цьому відношенні, допоможе. Одночасне завдання програмістам завжди легше, ніж багатозадачність. Блокування часу протягом дня також може допомогти у цьому.

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

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

У чому причина [їхня оцінка за 2 дні, що займають 8 днів], чи це спільне для програмістів?

Це, якщо:

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

Назвати кілька речей.

Можливо, найкраще запитати у своїх розробників, чому вони вважають, що їхні оцінки відсторонені. :-)

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

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

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

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

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

Я сподіваюся, що це допомагає!

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

Зараз у вас є багато можливостей із тих, кого я згадаю дві:

• Планування покеру
• PERT (Техніка оцінки та огляду програми)

Планування покеру

Це досить добре працює в невеликих спритних командах.

Уривок із вікіпедії:

• Модератор, який не буде грати, очолює зустріч.
• Менеджер продуктів надає короткий огляд. Команді надається можливість задати питання та обговорити, щоб уточнити припущення та ризики. Короткий огляд дискусії записує керівник проекту.
• Кожна особа відкладає картку обличчям вниз, представляючи свою оцінку. Використовувані одиниці різняться - вони можуть бути тривалістю днів, ідеальними днями або пунктами історії. Під час обговорення цифри взагалі не повинні згадуватися стосовно розміру функції, щоб уникнути прив’язки.
• Кожен телефонує одночасно своїми картками, перевертаючи їх.
• Людям з високими і низькими оцінками дають мильну коробку, щоб виправдати свою оцінку, а потім обговорення триває.
• Повторюйте процес оцінки до досягнення консенсусу. У розробника, який, ймовірно, був власником результатів, є значна частина "голосу за консенсус", хоча Модератор може домовитися про консенсус.
• Яєчний таймер використовується для забезпечення структурованості дискусії; модератор або менеджер проекту може в будь-який момент перемкнути таймер яєць, і коли він закінчиться, все обговорення повинно припинитися і відбудеться черговий раунд покеру. Структура в розмові заново вводиться мильними коробочками.

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

PERT

Часто важко дати одну точну оцінку. Що простіше - це дати ймовірність. PERT використовує 3 значення для оцінки:

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

Зважуючи ці три оцінки, ви отримуєте більш надійну оцінку.

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

І / або ви можете використовувати ці три значення для побудови розподілу ймовірностей, який може ще більше відображати невизначеність реального світу. Бета-розподіл і трикутний розподіл є важливими варіантами. Використовуючи це, ви тепер можете застосувати статистику на кшталт "наскільки ймовірним є закінчення на дату x з урахуванням поточних оцінок" або "якщо я хочу 95% впевненості, в який момент часу вона буде закінчена".

Насправді PERT складається з більш ніж зазначених тут аспектів, які я опустив заради стислості.

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

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

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

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

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

-Pivotal Tracker - Відмінна програма для відстеження історій і заохочує розбивати -задачі, вона полегшує швидкість введення історій і автоматично виводить швидкість. https://www.pivotaltracker.com/ .

-Документи для документації, оскільки легко редагувати та обговорювати декількох користувачів одночасно.

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

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

Сподіваюсь, це допомагає