Pull to refresh

Сколько нужно минут, чтобы добавить 1 строчку кода в большой организации?

Reading time 2 min
Views 11K
Это иллюстрация к предыдущей статье "Как дряхлеют большие конторы"

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

Задача: расширить функциональность существующей системы. Система – огромна и стара. Несколько ХХ млн строчек кода, много харда, несколько десятков лет жизни.

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

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

У нас есть много групп разработчиков со своими руководителями и архитекторами. И всё они должны предоставить свои оценки.

Пользуясь инструментарием, мы можем легко найти места в системе, где написан вот такой код:

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;



Во многих случаях этот switch просто рапортует, никакой функциональности, завязанной на тип объекта нет.

Т.е. в этом конкретном случае, чтобы решить задачу добавления С, нам нужно только расширить enum и добавить одну строку:
case OBJECT_С: printf(«This is object С»);

А теперь внимание, вопрос: сколько нужно времени, чтобы сделать это изменение?

  • Если вы разработчик своего домашнего проекта – несколько секунд?
  • Если вы разработчик в полу-формальной группе: чуть больше… checkout/ревью/checkin/тест – час-два?
  • Если вы разработчик в большой конторе: даже до того как вы сможете начать checkout, вам надо будет подготовить кое-какие документы, которые обосновывают необходимость изменения и доказывают, что тесты будут проведены и результаты — ОК.


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

Когда контора только начинает жить, то для effort estimates используют человеко-часы. По мере дряхления — человеко-дни. Позже — человеко-недели. Становятся неизвестными детали, и люди просто включают в работу «время на разобраться, а о чем вообще речь идет?!»

Вернемся к нашему примеру: В общем, после разговора с архитектором группы, в которой должно быть сделано это изменение – мы сошлись на 0.5 недели. 2.5 дня, чтобы добавить одну строку (и завершить всю сопутствующую бухгалтерию/администрацию).

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

Но это не всё, после того как к делу подключился PL, он не вникая в детали скромно отрапортовал «наверх» — 10 недель. И самое ужасное, что люди выше — не спорят.

10 недель — вот правильный ответ на вопрос топика :(

Интересно: кто знает какие-то хорошие материалы по KPI? Должно же что-то уже быть наработано по количеству кода и времени на его имплементацию?
Tags:
Hubs:
+8
Comments 17
Comments Comments 17

Articles