Як утримати управління від нашого процесу розвитку

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

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

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

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

Мені довелося мати справу з подібними сценаріями, і я відповів на це питання на подібну тему . Я також блогував про те, як я тут справився з цим:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Якщо вам не подобається переслідування посилань, я повторю своє резюме з відповідного питання:

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

Мій висновок на основі цього досвіду:

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

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

Правило номер один, яке слід дотримуватися, незалежно від методу, який ви використовуєте, це таке

1. Розробники повинні мати право оцінювати власну роботу.
2. Зацікавлені сторони повинні мати право на пріоритет серед цих робіт.

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

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

Розкажіть про технічну заборгованість та вартість тестування одиниць

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

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

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

ІМХО вам потрібно записати своє первісне планування, додати глави 1 та 2 (не в додатку), в яких ви пояснюєте технічну заборгованість та значення тестування одиниць. Надайте їм альтернативи:

• менше годин (не цілих 150, що звучить смішно), коли кожна зміна (на етапі розробки та під час технічного обслуговування) займе в середньому:
  • малий 4 години
  • середній 16 годин
  • великі 40 годин
• ваші орієнтовні години, коли в середньому буде тривати кожна зміна (етап розробки та під час обслуговування)
  • малий 2 години
  • середній 8 годин
  • великі 20 годин

(Години просто показові. Ви набагато кращі, щоб дати належні оцінки.)

Не забудьте включити свою послужну послугу щодо своєчасних бюджетних поставок.

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

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

Перш за все, не розбивайте «тестування одиниць запису» як окреме завдання, яке слід оцінити, запланувати та, можливо, вирізати. Ваші оцінки повинні бути на рівні функції "Впровадити XYZ - 18 годин". Ці 18 годин повинні включати все, що потрібно у вашому процесі, щоб отримати цю функцію "Зроблено", включаючи "написання тестових одиниць".

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

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

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

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

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

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

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

Якщо припустити, що немає терміну "краплі мертві", я б запропонував 2 речі.

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

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

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

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

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

Що б зробив Уоллі?

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

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

Ти в солінні. Якщо ви дотримуєтесь своїх гармат і хочете дотримуватися одиничних тестів і хочете вимагати 300 годин, ви зробите ворогів.

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

У будь-якому випадку ви програєте.

Або так здається.

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

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

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

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

Іншими словами: робіть те, що вам сказали. Якщо керівництво знає, що робить, ви вийдете попереду. Якщо ні, то ви без роботи, одиничні тести чи ні.

Яку рентабельність ви запитуєте? Прибуток на інвестиції. Хоча це погане ім’я. Це повинно бути поверненням своєчасних інвестицій (ROTI), тому що терміни - це все в інвестиціях.