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