Сколько Минут Занимает Добавление 1 Строки Кода В Крупной Организации?

Это иллюстрация к предыдущей статье» Как большие компании приходят в упадок " Хочу поделиться реальным примером неэффективности.

Для молодых разработчиков и/или тех, кто никогда не работал в большом офисе, это может показаться нереальным, но это так.

Задача: расширить функционал существующей системы.

Система огромная и старая.

Несколько XX миллионов строк кода, много кропотливой работы, несколько десятилетий жизни.

Суть расширения: система может обрабатывать материалы типов А и Б.

Необходимо добавить тип С.

Естественно, это сложная задача, требующая анализа и оценок: сколько все это будет стоить в человеко-летах? Оценки нужны, чтобы понять: есть ли экономическая целесообразность? У нас много команд разработчиков со своими лидерами и архитекторами.

И все они должны дать свои оценки.

С помощью инструментов мы легко можем найти места в системе, где написан следующий код:

   

 typedef enum {
     OBJECT_A,
     OBJECT_B
 } object_types;
 
 
     switch(object){
         case OBJECT_A: printf("This is object A");
         case OBJECT_B: printf("This is object B");
         default: raise_error("Unknown object!!!"); break;
 
 

   

Те.

в данном конкретном случае, чтобы решить проблему добавления C, нам нужно всего лишь развернуть enum и добавить одну строку: case OBJECT_C: printf("Это объект C"); Теперь внимание, вопрос: сколько времени занимает это изменение?

• Если вы разработчик своего домашнего проекта – несколько секунд?
• Если вы разработчик в полуформальной группе: еще немного.

  проверка/проверка/проверка/тестирование - час-два?

• Если вы разработчик в крупной конторе: еще до того, как вы сможете начать оформление заказа, вам нужно будет подготовить некоторые документы, которые обосновывают необходимость изменения и доказывают, что тесты будут проведены и результаты в порядке.

Из-за этого даже такое крошечное изменение не может занять меньше 1 дня.

Физически он не может. Также внутри крупных офисов, занятых бизнесом, ресурсов на «общие улучшения» почти нет, поэтому существуют «джентльменские соглашения», что команды могут добавлять ~20% к функциональным изменениям.

Когда офис только начинает работу, для оценки усилий используются человеко-часы.

По мере ухудшения состояния это занимает человеко-дни.

Позже – человеко-недели.

Детали становятся неизвестными, и люди просто включаются в работу «время разобраться, о чем мы вообще говорим?!» Вернемся к нашему примеру: В общем, поговорив с архитектором группы, в которой должно быть сделано это изменение, мы сошлись на 0,5 недели.

2,5 дня на добавление одной строки (и выполнение всего соответствующего учета/администрирования).

Уже здесь становится понятно, насколько все плохо внутри больших монстров.

Но это еще не все, после того как в дело вмешался П.

Л.

, он, не вдаваясь в подробности, скромно доложил "наверх" - 10 недель.

И самое ужасное, что люди выше не спорят. 10 недель - правильный ответ на вопрос темы :( Интересно: кто-нибудь знает хорошие материалы по KPI? Должно быть, что-то уже было разработано по количеству кода и времени на его реализацию? Теги: #дряхлый #Управление проектами

• Бюретки

  19 Oct, 24

• Рекламный Сюжет Yahoo: Вклад Компании В Индустрию И Видеоролики Для Собственного Продвижения

  19 Oct, 24

• Главу Apple Оценили В $20 Млрд.

  19 Oct, 24

• Когда Быть Хорошим – Плохо

  19 Oct, 24

• Самогонный Аппарат Полностью Автоматический. Часть 2. Сепаратор. Холодильник. Алгоритмы Куба

  19 Oct, 24

• Как Работает Сервис Поиска Уникальных Специалистов Для Междисциплинарных Проектов?

  19 Oct, 24

• Как Мы Запускали Телеканал В Интернете. Идея

  19 Oct, 24

• 10 Июня 19.00 — Онлайн-Митап Scrum Masters

  19 Oct, 24

• Terapixel - Мир Тележек С Поддонами

  19 Oct, 24

• Цифровые Мероприятия В Санкт-Петербурге С 10 По 16 Февраля

  19 Oct, 24