Это иллюстрация к предыдущей стратье "Как дряхлеют большие конторы"
Хочу поделиться реальным примером неэффективности. Для молодых разработчиков и/или тех, кто никогда не работал в больших конторах, он может показаться нереалистичным, но это правда.
Задача: расширить функциональность существующей системы. Система – огромна и стара. Несколько ХХ млн строчек кода, много харда, несколько 10ков лет жизни.
Суть расширения: система может обрабатывать материалы типа А и 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? Должно же что-то уже быть наработано по количеству кода и времени на его имплементацию?
ссылка на оригинал статьи http://megamozg.ru/post/14882/
Добавить комментарий