Чому графіки програмного забезпечення так важко визначити?

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

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

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

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

Згідно з моїм особистим досвідом, це абсолютно протилежне тому, що сказав Пемдас : з практикою я просто зрозумів, що оцінити, скільки часу вимагатиме завдання, абсолютно неможливо. На початку своєї кар’єри в галузі розробки програмного забезпечення я часто давав оцінки на кшталт "45 днів", "п'ять тижнів" тощо, потім дуже старався закінчити вчасно. Через кілька років я почав давати менш точні оцінки, такі як "приблизно один місяць", "п'ять-сім тижнів" тощо. Насправді я намагаюся або не давати жодної оцінки, або прошу замовника дати власну оцінку або термін, або я даю оцінку якомога грубіше.

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

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

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

3. Вимоги часто недостатньо зрозумілі , але прочитавши їх на початку, ти думаєш, що вони є. Іноді ви можете зрозуміти, що означає «A», і, почавши їх реалізовувати, ви помітите, що вони, можливо, означають «B».

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

5. Ви не можете оцінити мотивацію . Бувають дні, коли ти можеш працювати годинами і успішно працювати. Бувають тижні, коли після написання десяти рядків коду ви переходите на програмісти StackExchange і проводите години, читаючи відповіді на запитання.

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

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

Що ти можеш зробити?

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

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

3. Поясніть, що якщо вимоги змінюватимуться щодня, проект навряд чи буде виконаний вчасно.

4. Наріжте свій графік . Вчасно доставити частини великого проекту простіше.

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

Дуже схоже питання: "Скільки часу знадобиться для вирішення цієї кросворду?"

Ви не можете відповісти на це, поки не подивитеся на це, щоб побачити численні речі, як-от:

• Це відомою мовою? (Іспанська проти англійської проти китайської)
• Це один із типів, який ми вирішили раніше? (Один із серій, що працює в журналі, наприклад)
• Чи потребує будь-якого з підручників додаткові знання, перш ніж ми зможемо це зрозуміти?
• Чи є десь у головоломці речі, які, на вашу думку, потребують додаткової роботи?

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

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

Найбільш очевидна причина, чому ви, інженери, не можете дати точних оцінок, - це неможливо .

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

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

У програмному забезпеченні це гірше:

1. Оцінки часто стають зобов'язанням , тому наше судження видозмінене.
2. Між оцінкою Боба і Карла щодо одного і того ж завдання можуть бути величезні відмінності .
3. Невизначеності дуже поширені, як багато з нас застрягли в дурному помилку або збої на жорсткому диску, що знищує будь-яку явну хорошу оцінку.
4. Зазвичай ми забуваємо про всі інші завдання, крім програмування, включаючи зустрічі, телефонні дзвінки, допомогу колезі тощо.
5. Мозок людини обмежений . Він не був розроблений для оцінки тривалих завдань.

Ось чому неможливо сказати своєму клієнту, що ви зможете доставити за 01.01.2011 з хорошою точністю, і забути про 01.03.2011.

Щоб вирішити всі ці проблеми, я рекомендую вам передові методи оцінки, такі як Планування покеру (відмова від відповідальності: це один з моїх веб-сайтів) та Ітеративна розробка з розрахунком швидкості .

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

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

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

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

Причина, коли ми пишемо нове програмне забезпечення, полягає в тому, що у нас є нова функція, або нова технологія, або те і інше. Нове означає нове - невідоме - непередбачуване.

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

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

Це ніколи нелегко. Ви просто намагаєтеся в цьому поправитись.

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

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

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

Тому що ми робимо графік занадто рано. Дивіться статтю Construx про те, як зробити попередню грубу, а потім кращу пізніше. Крім того, якщо ви не відстежуєте, як ви робили попередні оцінки, важко покращитись. FogBugz робить це [клієнт їхнього безкоштовного, жодного іншого конфлікту інтересів].

Я багато чого навчився з цієї книги:

Оцінка програмного забезпечення: Демістифікація чорного мистецтва

Коротше кажучи, щоб отримати кращі результати оцінки, ми робимо це:

1. всі завдання, окрім тривіальних, оцінюються більш ніж однією людиною (у нашому випадку двома)
2. ми ділимо завдання на менші завдання. Чим більше завдань у вас є, тим більша ймовірність, що ваша оцінка буде хорошою - закон великих чисел, якщо я правильно пам'ятаю з бу
3. ми оцінюємо найгірший, найкращий та найімовірніший сценарій. Іноді кожен з нас оцінює ці сценарії з дерева абсолютно по-різному. Це означає, що ми повинні говорити, і зазвичай виявляється, що хтось із нас не зрозумів завдання. Якби одна людина оцінила завдання самостійно, було б оцінено неправильно.
4. ми помістимо 3 числа з вищезгаданої точки в рівняння і отримаємо оцінку (excell) k

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

Примітка. Це дійсно стосується лише проектів, де ви виставляєте рахунок за годину проти фіксованої / фіксованої тарифи.

Зазвичай я намагаюся спланувати свій графік таким чином, щоб він складався, по суті, з безлічі СКРУМОВИХ Спринтів (використовуючи SCRUM чи ні). Складаючи перед графіком, я визначаю, якою буде довжина кожного спринту та якими будуть особливості проекту. Зазвичай є деякі функції, які потрібно виконати спочатку, тому я намагаюся дати найкращу оцінку (не плутати з оптимістичною) для тих, і будь-які функції, які будуть до кінця проекту, матимуть узагальнені оцінки. Після відображення функцій у спринтах я намагаюся додати 1 - 2 спринти в кінці проекту, щоб врахувати функції, котрі ковзають праворуч, і функції, які були не помічені під час збору оригінальних вимог.

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

Окрім усіх названих речей, я бачу ці дві речі як одні з найбільших проблем. Спочатку ви оцінюєте кінцеву дату, виходячи з того, що кожен розробник буде доступний протягом 8 годин на день 5 днів на тиждень. Це неправильно, і фактично на 100% гарантується, що дата закінчення пропущена в будь-якому проекті, який не є тривіальним. Люди беруть відпустку, відвідують товариські (або непроектні) зустрічі, борються з персоналом щодо претензій на медичне страхування, роблять перерви тощо. Ніколи не приймайте більше 6-годинної наявності на розробника в день.

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

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

1. Чи не коли - або намагатися передбачити , коли інші люди закінчать свою роботу , якщо вам трапиться, залежить від нього. Говоріть тільки для себе.
2. Спочатку проаналізуйте завдання, потім оцініть. Під аналізом я маю на увазі хоча б записати (і не намагатися тримати все в собі в голові!) Список підзадач з оцінкою для кожного з них.
3. Якщо завдання є досить складним, оцініть сам час для такого аналізу. Нехай оцінка є окремим процесом. Ви також можете переконатися, що ваш начальник знає про це.
4. Не оцінюйте під тиском. Дайте зрозуміти, що потрібен час, щоб зробити обґрунтовану оцінку і просто скажіть їм щось на кшталт "Я назву побачення завтра до 11:00, коли закінчу аналіз завдання". Я знаю, що деякі клієнти / менеджери можуть наполегливо тиснути, але вони не пройдуть. Покладіть своє зайняте обличчя і вимагайте свого часу!
5. Попросіть трохи більше часу, ніж ви думаєте, що вам знадобиться, тому що ви, мабуть, забули додати час перерви на каву (та інші розлади) у вашій оцінці.
6. Для великих завдань попросіть ще більше - напевно, буде більше однієї перерви на каву.
7. Якщо ви дійсно не можете оцінити (завдання занадто складне / незнайоме) або ви дійсно не впевнені - попросіть когось, хто може допомогти у вашому аналізі.

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

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

Існують "відомі невідомі" та "невідомі невідомі". :-)

1. Оцінки часто стають термінами.

   • Ніхто не хоче пропустити термін і стати заголовком!

2. Вимоги змінюються (часто раціонально), і програміст не може накласти це вето.

3. Програміст робить / може не контролювати такі фактори, як

   • Наявність коду, від якого вона залежить
   • Якість коду вона залежить
   • Загальна архітектура та дизайн системи
   • API для доступу до інших частин системи