Это иллюстрация к предыдущей статье "Как дряхлеют большие конторы"
Хочу поделиться реальным примером неэффективности. Для молодых разработчиков и/или тех, кто никогда не работал в больших конторах, он может показаться нереалистичным, но это правда.
Задача: расширить функциональность существующей системы. Система – огромна и стара. Несколько ХХ млн строчек кода, много харда, несколько десятков лет жизни.
Суть расширения: система может обрабатывать материалы типа А и B. Надо добавить тип С.
Естественно, это сложная задача, требующая анализа и оценок: а сколько это всё будет стоит в человеко-годах? Оценки нужны, чтобы понять: а есть ли экономическая целесообразность?
У нас есть много групп разработчиков со своими руководителями и архитекторами. И всё они должны предоставить свои оценки.
Пользуясь инструментарием, мы можем легко найти места в системе, где написан вот такой код:
Во многих случаях этот switch просто рапортует, никакой функциональности, завязанной на тип объекта нет.
Т.е. в этом конкретном случае, чтобы решить задачу добавления С, нам нужно только расширить enum и добавить одну строку:
case OBJECT_С: printf(«This is object С»);
А теперь внимание, вопрос: сколько нужно времени, чтобы сделать это изменение?
И эти документы должны получить гриф «проверено/утверждено» (другие люди должны тратить время). Из-за этого даже такое крохотное изменение не может занять меньше 1-го дня. Физически не может. Также внутри больших контор, которые заняты бизнесом почти нет ресурсов для «общих улучшений», поэтому есть «джентльменские соглашения», что команды могу добавлять ~20% к функциональным изменениям.
Когда контора только начинает жить, то для effort estimates используют человеко-часы. По мере дряхления — человеко-дни. Позже — человеко-недели. Становятся неизвестными детали, и люди просто включают в работу «время на разобраться, а о чем вообще речь идет?!»
Вернемся к нашему примеру: В общем, после разговора с архитектором группы, в которой должно быть сделано это изменение – мы сошлись на 0.5 недели. 2.5 дня, чтобы добавить одну строку (и завершить всю сопутствующую бухгалтерию/администрацию).
Уже здесь становится понятно, насколько всё плохо внутри больших монстров.
Но это не всё, после того как к делу подключился PL, он не вникая в детали скромно отрапортовал «наверх» — 10 недель. И самое ужасное, что люди выше — не спорят.
10 недель — вот правильный ответ на вопрос топика :(
Интересно: кто знает какие-то хорошие материалы по KPI? Должно же что-то уже быть наработано по количеству кода и времени на его имплементацию?
Хочу поделиться реальным примером неэффективности. Для молодых разработчиков и/или тех, кто никогда не работал в больших конторах, он может показаться нереалистичным, но это правда.
Задача: расширить функциональность существующей системы. Система – огромна и стара. Несколько ХХ млн строчек кода, много харда, несколько десятков лет жизни.
Суть расширения: система может обрабатывать материалы типа А и 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? Должно же что-то уже быть наработано по количеству кода и времени на его имплементацию?
