Вы обсудили с Заказчиком и договорились выпустить в ближайшем релизе
важные для продукта фичи, которые так давно и с нетерпением ждут
Пользователи. Вы на крыльях несетесь на PlanningPoker, начинается оценка
и бац…
— Давайте не лезь в этот модуль. Код недокументирован, все начнет глючить и сыпаться, особенно биллинг.
— До нас работала команда дураков, они учились программировать на этом проекте. Если сюда лезть, в команде упадет мотивация…
— Как это работает… Это надо в код смотреть. Люди, писавшие, уже ушли, документации нет. Месяц минимум.
— Мы залили данные, и все стало тормозить. Надо спринт посвятить исследованию причин. (и так несколько спринтов подряд)
Вы понимаете, что происходит что-то странное, что проект «заболел», что можно было наверно этого избежать, если знать заранее…
Постараемся понять, кому «бить морду» сейчас и кого отмутузить
профилактически когда к нам придет следующий проект — чтобы избежать
подобного коллапса. ?
Старый проект
Ситуация предсказуема. Когда проект достался нам в наследство, нередко
случается, что код — непонятен, а документации нет или она безнадежно
устарела. Разработчики при упоминании названия проекта начинают
плеваться.
PlanningPoker выявляет проблему — коллеги пытаются понять, как устроен
тот или иной модуль, чтобы оценить, СКОЛЬКО ВРЕМЕНИ ДОБАВЛЯТЬ ФИЧУ в
этот модуль, но — все настолько запутано, что с ужасом понимаем: чтобы
дать адекватную оценку нужно потратить несколько недель на разбор этого
г… окода. А чтобы переписать/жестко отрефакторить — потребуются месяцы,
если не больше.
А еще нужно уметь рефакторить не только код, применяя с пониманием их
сути шаблоны проектирования, но и успешно вытащить с внутренностями г…
логику из недокументированной базы данных.
Нужен системный подход. Кому поручить, с кем договориться?
Новый проект
А вот это может стать для начинающих ProductOwner настоящим сюрпризом! Новый проект — который начинает разлагаться.
Пока проект только начинается, нет повода для опасений. Оценки на
PlanningPoker постепенно становятся точнее, скорость команды
увеличивается, регулярные демонстрации повышают настроение и веру в
достижение цели релиза. Четкий бодрый ритм.
Симптом 1: Технический бэклог начал расти
Постепенно, однако, все больше задач начинает появляться в техническом
бэклоге — туда разработчики ставят фичи для рефакторинга. Да, мы знаем,
чтобы код проекта не «протух», нужно «разрешать» разработчикам выявлять
кривые/сложные моменты в коде, говорить о них на ретроспективах, и
регистрировать данный класс задач, чтобы в фоне ими заниматься.
Иногда это признак… начала конца. Команда, осознав, что пошла не туда,
усложнила код, который начал на глазах рассыпаться, пытается начать
снова и снова его переписывать — пытаясь выделить для это время на
очередном распределении задач:
— Мы вот обсудили… Мы написали модуль, использовали библиотеку ORM — но
она нам не подходит, слишком сложная, мы хотим писать запросы в базу
напрямую (потрачено 2 месяца)
— Мы тут усложнили объектную иерархию наследования, черт не разберется. Надо переписывать (новый проект!, дайте калаш).
Симптом 2: «Нестабильные» спринты
Еще один признак возможного конца — написанный в предыдущих спринтах
функционал почему-то… не стабилизируется :-). Он сыплет багами и на их
исправление уходит все больше и больше времени. Да, в какой-то момент
вроде поток багов останавливается — но при минимальном изменении
функционала — открывается с новой силой. Мы же должны, по идее,
принимать изменения требований с распростертыми объятьями, а тут —
кашлянуть страшно.
Симптом 3: «Тормоза»
Все шло как по маслу. Но вот загрузили в систему тестовые данные и… она
легла. Оказывается, не все программисты понимают, что код должен
работать практически «независимо» от объема данных, нельзя выбирать из
таблицы все записи и обрабатывать их в коде, ворочая в памяти сотнями
мегабайт и т.п.
Нередко, чтобы научить систему работать с ожидаемым объемом данных,
потребуется серьезное переписывание, которое может растянутся на месяцы
(!). А потом еще тестировать, тестировать…
Симптом 4: Матрица «независимости»
Есть еще страшная штука, о которой знают только опытные бойцы, прошедшие
крупные проекты. Пока проект помещается у команды в голове — нет причин
для беспокойства. Добавить фичу несложно — собираемся и понимаем, что
будет и где в системе отразится, если вот тут и тут поменять логику.
Но когда система/веб-сайт становится большим, то… люди начинают теряться. Простой пример из жизни:
PO: Коллеги, нужно добавить поддержку дополнительного алгоритма применения скидки…. Оцениваем.
Разработчики: Для этого нужно поправить библиотеку тут, поправить шаблон вывода там. Наверно (!) всё.
Так вот. Оказывается после внедрения фичи… вылетели несколько платежных
систем. Причем об этом сразу узнали Клиенты и «положительно»
отреагировали.
А мы знаем, что существуют инструменты отслеживания зависимостей,
и во «взрослых» процессах разработки они применяются, т.к. без них
слово «наверно» в команде будет повторяться все чаще и чаще.
Автоматизированные тесты… да, они протестируют код, да и то, если их
писать сразу и ГРАМОТНО. А как они сложные бизнес-требования
протестируют, зависимости между алгоритмами? Нужны другие инструменты,
уже для аналитиков.
Усложнение — коварный враг
Создается ощущение, что чем больше проект, тем более неуправляемым и
запущенным он становится — как для разработчиков, так и для
ProductOwner, так и для Заказчика.
Каши становится все больше.
Самое страшное, что имеется (по секрету), так сказать «точка
невозврата», после которой вернуть проект в управляемое состояние очень и
очень сложно и его дешевле закрыть к черту, т.к. все запутались и все
безмерно глючит и зловонно растекается.
Кому бить морду?
Когда запускаешь десятки проектов, то начинаешь естественным образом
анализировать причины неудач и, следуя духу ретроспективы, делаешь
выводы. Проходят годы и вырабатывается чутье на баланс производственного
процесса, который наверно можно сравнить с музыкальным слухом.
ИМХО в компании, использующей Agile, должен быть сильный технический
директор, спинным мозгом чувствующий БАЛАНС используемых методологий и
инструментов. Чтение книжек по процессам разработки поможет отчасти —
нужно именно чутье.
Причем чем проекты сложнее, тем требуется больше знаний, опыта и воли,
чтобы они не прошли «точку невозврата». Техдир немного проспит и
пара-тройка проектов пройдут точку невозврата — можно конечно
полгода-год создавать видимость работы, улыбаться и всем видом
показывать что все хорошо и под контролем, а потом внезапно уволиться по
отвлеченной причине.
Ключевые задачи техдира
Итак мы увидели, что в agile-разработке техдир как бы должен постоянно
выигрывать в Тетрис — сколько сверху не спускается проектов,
ПРОИЗВОДСТВО должно быть сбалансированным и сложность не зашкаливать.
Всегда O(1) и хорошее настроение ;-):
— Архитектура остается простой, за счет грамотного использования, когда
это необходимо, шаблонов проектирования (Simple Design в XP). Если
разработчики, наученные техдиром, видят спинным мозгом усложения,
начинается рефакторинг. Или техдир ставит сильных опытных архитекторов
на сложные проекты.
— Код проектов не «протухает» — разработчики, наученные техдиром,
развили обоняние и ставят задачи по вычищению плохого кода в технических
бэклог.
— Код готов к большим объемам данных — разработчики квалифицированны,
понимают что пишут. Тем не менее, техдир прописал в чеклист готовности
проекта обязательное проведение нагрузочного тестирования.
— Либо сразу используются юнит и другие виды автотестов, либо они
используются для сложных частей проекта. Тут же можно, иногда,
прикрутить разновидность Continuous Intergration.
— Проект обязательно грамотно разбит на модули и они максимально
независимы друг от друга — поэтому изменение в одном модуле скорее всего
не затронет остальные части системы.
— Техническая документация ведется либо с использованием
автоматизированных инструментов (типа phpdoc), либо настроен
бизнес-процесс и изменения уходят в отдел документации.
— Аналитическая документация, диаграммы, схемы БД и все, что делают
аналитики — разбита на помещаемые в голову модули и аккуратно
поддерживается ими в актуальном состоянии. Аналитики не смотрят в код,
но должны ясно понимать все бизнес-процессы в системе/модуле, чтобы быть
способными что-то спроектировать дальше.
— Талантливые люди остаются в команде, т.к. им дают заниматься
интересными и сложными задачами. В командах уважительная
профессиональная атмосфера, за которой следит Техдир, не подпуская к
людям непрофессинальных карьеристов.
Если такого человека не удается найти — остается одно, выстроить сложный
мегаформализованный процесс с взаимозаменяемыми сотрудниками. Это
наверно будет дороже и дольше.
Итог
Чтобы ProductOwner был счастлив, чтобы фичи делались в оцененный срок и
сохранялось уверенное движение по плану релизов, чтобы живое существо
под названием «Программный продукт» не извергалось фонтанами нечистот в
самые неожиданные моменты, особенно перед клиентми — нужно найти
грамотного и опытного технического директора, работающего по
разновидности вышеперечисленного чеклиста, ощущающего спинным мозгом
баланс процессов и инструментов.
Иначе — буйного коня Agile вам не оседлать.
|
Главная 
