Как не допустить управления в наш процесс разработки

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

В нашем планировании мы рассчитывали часы для написания юнит-тестов, их идея - сбросить их, чтобы сэкономить время. Решение еще не принято, и я буду защищать это планирование и юнит-тесты, если это необходимо. Но что мне действительно не нравится, так это то, что менеджмент вмешивается в наш процесс разработки. Как мне не допустить их в наш процесс разработки? И какие аргументы я могу использовать, чтобы сохранить модульное тестирование (помимо качества и долгосрочной экономии времени)?

В качестве примечания, в нашей компании работают 3 команды инженеров, и команда, в которой я работаю, поставляет свое программное обеспечение вовремя (дает или берет 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 часов и проведете тестовые испытания, вы сможете быстрее доставить неисправный продукт, но это приведет к скорби в будущем и увеличит стоимость обслуживания.

В любом случае, вы проиграли.

Или так кажется.

Видите ли, вы не управляете научной лабораторией в университете. Вы предоставляете бизнес-услуги бизнес-единице в компании, которая предоставляет услуги клиентам в экосистеме компаний. Вашей компании может понадобиться ваш продукт, чтобы начать предоставлять своим клиентам более быстрые и качественные услуги и, таким образом, получать необходимые доходы.

Вы видите, что вам нужен анализ ROI, и у вас нет всех данных для этого анализа. У вас есть только часть затрат (вы не знаете всех номеров заработной платы), и у вас наверняка нет частей дохода, особенно прогнозов дохода.

Ваше руководство, хотите верьте, хотите нет, отлично умеет делать прогнозы рентабельности инвестиций (это то, чему они учат в бизнес-школе) и, возможно, выполнило несколько прогнозов рентабельности инвестиций и придумало: «Если мы будем действовать сейчас, мы заработаем гораздо больше денег, даже с оплатой в три раза за обслуживание программного обеспечения, на которое жалуются ИТ-специалисты. "

Итак, если вы хотите запустить совместное предприятие, создайте свою собственную компанию. Вы увидите, это не так просто.

Другими словами: делай то, что тебе говорят. Если руководство знает, что делает, вы выйдете вперед. Если нет, то вы без работы, юнит-тесты или нет.

Какую рентабельность вы спросите? Прибыль на инвестиции. Это плохое имя, хотя. Это должен быть возврат на своевременные инвестиции (ROTI), потому что сроки - это все в инвестициях.