Home

Автор: Энди Найт (Andy Knight)

Оригинал статьи: http://automationpanda.com/2017/12/04/the-airing-of-grievances-agile/

Перевод: Ольга Алифанова

Agile в целом заменил модель водопада в качестве «правильной» методологии разработки ПО. Это действительно хороший процесс, если он правильно поставлен, но люди все портят, когда неправильно к нему подходят. О, как мощно он может пойти наперекосяк. У меня много претензий к плохим практикам Agile, и сейчас вы все о них узнаете!

Нарушение правил

Agile очень похож на настольную игру «Монополия». Правила у нее длинные и сложные, но они нацелены на то, чтобы сделать игру эффективной. Однако по какой-то причине все настаивают на изобретение своих собственных правил для игры вместо того, чтобы следовать официальным инструкциям. К примеру, игроки не выставляют собственность на аукцион, перейдя на соответствующую клетку, и отказываются ее покупать, или строят дома, не достигнув монополии. В результате игра продолжается бесконечно и теряет свою привлекательность. Что касается Agile, каждая организация, видимо, стремится пойти своим особенным путем, и это практически всегда выходит им боком. Правила не предназначены для того, чтобы их нарушали. А если их нарушают, последствия не заставят себя ждать.

Выход из-под контроля

Agile предназначен для того, чтобы люди фокусировались на наиболее важных задачах. Много времени тратится на планирование и поиск опорных точек, чтобы делать наиболее значимые вещи. Команда не должна отвлекаться от назначенных задач. Не выходите из-под контроля! Не работайте над задачами, над которыми вы не должны работать! Если что-то прям необходимо сделать, обсудите со скрам-мастером изменение ваших обязательств.

Слишком большая команда

Насколько велика ваша Agile-команда? Если ответ – двузначное число и более, команда слишком, чересчур велика. Идеальный ее размер – 5-9 человек, потому что общаться с большим количеством очень тяжело. Большие команды не масштабируются – это закон уменьшающейся прибыли.

Долгие совещания

Никто не стремится застрять на долгом, скучном совещании. У Agile много церемониала (планирование, груминг, стенд-ап, ревью, ретроспектива), но эти совещания должны быть эффективными и продуктивными. Стенд-апы должны длиться не более 15 минут – всем должно требоваться не более трех предложений, чтобы отчитаться о статусе, и никто все равно не хочет слушать больше этих трех предложений! Люди должны приходить на планирование и груминг подготовленными, чтобы эти встречи не занимали целый день. Демонстрации должны быть краткими и симпатичными. Продолжайте движение вперед!

Назначение людей в более чем одну команду

Никто не должен испытать на себе проклятие предоставления отчетности для более чем одной Agile-команды. Это нечестно по отношению к человеку, обязанному дважды нести повинность совещаний, и это нечестно по отношению к команде, член которой не посвящает ей все свое рабочее время. Это верно для любой роли, будь это разработчик, тестировщик, продакт-оунер или скрам-мастер. К тому же это ведет к быстрому профессиональному выгоранию.

Слишком много основных приоритетов

Как-то раз я участвовал в Agile-команде, продакт-оунер которой назначил ей около дюжины «основных приоритетов». Для. Каждого. Спринта. Наша команда никак не могла взять в толк, что на самом деле важно.

Мучения над каждым стори-пойнтом

Стори-пойнты должны быть единицами измерения скорости. Они не должны быть идеально точными. Они не должны занимать целые часы. Не устраивайте из-за них грандиозные потасовки. Не возвращайтесь к ним, чтобы что-то поменять. Не превращайте покер планирования в политический гамбит, ОЧЕНЬ ВАС ПРОШУ!

Пропуск описаний юзер-стори

Юзер-стори – это первичный рабочий артефакт. Он сообщает о том, как должна работать новая фича с точки зрения пользователя… по крайней мере, должен сообщать. Если ваша юзер-стори содержит одну строчку (к примеру, «Создание страницы профиля»), то вы, возможно, неправильно подходите к вопросу. Пишите юзер-стори в формате «Как…, я хочу…, так, чтобы…», и предоставляйте команде дополнительные описания, чтобы она понимала, что покрывает эта юзер-стори. Без описаний они приведут к плохо разработанным фичам.

Пропуск приемочных критериев

Как мы узнаем, завершена ли юзер-стори? Если у нас нет приемочных критериев, то никак! Тестировщики к тому же не будут знать, что им проверять. Пожалуйста, пишите полезные приемочные критерии. Маркированный список – это очень хорошо, а Gherkin – еще лучше.

Отсутствие учета тестирования и автоматизации в критериях готовности

Нет. Нет. Нет. Нет. НЕЕЕЕТ! Стори не завершена, если она не протестирована. Она не должна приниматься без прогона тестов и автоматизации. Если это не так, готовьтесь к лавине технического долга, потому что баги будут копиться, а команда не будет успевать их править. Постулат Agile – поставлять небольшие, рабочие фичи каждую итерацию. Тестирование должно быть включено! Не создавайте для тестирования отдельные стори. Не выпихивайте его в следующий спринт. Если команда не может провести тестирование – возможно, нужно увеличить размер юзер-стори, чтобы включить в него тестирование, или уменьшить объем работы в течение спринта.

Порицание QA за неполные стори

Однажды я слышал, как разработчик рявкнул на мою команду автоматизации, «QA тормозят весь процесс». Не стреляйте в гонца! Тесты падают, потому что у продукта проблемы. В ряде случаев тестировщики получают билд очень поздно. Если стори не прошла приемку, не начинайте искать козла отпущения – это вина всей команды. Попытайтесь сдвинуться влево (возможно, используя BDD) или уменьшить объем работы на спринт.

Игнорирование технического долга

Технический долг – это цена последствий плохих решений разработки. Примеры могут включать использование однопоточности там, где нужна многопоточность, отступление от проектных моделей, и даже построение фреймворка тест-автоматизации. Продакт-оунерам обычно не нравятся задачи технического долга, потому что они не порождают новых фич. К сожалению, этот долг вскоре изуродует способность команды поставлять эти фичи – платите сейчас, или платите позже. Не игнорируйте технический долг!

Смешение Agile c «Коротким водопадом»

Замысел Agile – в сдвиге процессной парадигмы. Он не предназначен для того, чтобы стать сжатой версией модели водопада. Спринты должны быть короткими. Обязанности должны быть разделены. Команды должны иметь собственные полномочия. Разрушайте свои башни, переходите в настоящий Agile!

Использование Agile и Lean как взаимозаменяемых терминов

Lean Startup – методология старта нового бизнеса с минимальными затратами и быстрой реакцией на результаты. Он включает использование Agile для разработки продукта, но он подразумевает намного больше, чем только Agile. Не используйте эти термины, как синонимы! Уясните уже себе сленг, которым жонглируете.

Неправильно употребляемый термин «непрерывная интеграция»

Ночные билды – это не CI. Еженедельный прогон регрессии – это не CI. Вручную запущенные тесты – это не CI. Ручной деплой – это не CI. Написанные вручную отчеты о тестировании – это не CI. Не лгите себе – CI подразумевает непрерывную интеграцию, и все должно быть автоматизировано.

Навязывание Scrum там, где лучше подойдет Kanban

Scrum – пожалуй, самый часто применяемый процесс Agile. Многие даже считают, что Agile подразумевает Scrum по умолчанию. Однако не всем командам подходит Scrum. Kanban намного лучше подойдет, если все должно быть готово «точно в срок» - как тикеты службы поддержки, деплой билда, поддержка системы или ее срочное восстановление. Хорошие кандидаты для Kanban – это службы поддержки IT и команды DevOps. Я очень успешно применял Kanban к командам, создающим инструменты и фреймворки автоматизации. Не запихивайте все подряд в прокрустово ложе Scrum.

Вывешивание манифеста Agile на всеобщее обозрение

Вы там что, коммунисты?

Жалобы на Agile

Жалобы не сделают Agile лучше! Если честно, то по моему опыту больше всех жалуются консерваторы, не любящие перемен. В результате любые проблемы вызывают реакцию «А я предупреждал, что все будет плохо». Или же эти люди стараются нарушить правила и ворчать, когда это не срабатывает. Если вы жалуетесь на Agile в целом, пойдите и внимательно посмотрите на себя в зеркало. Однако если вы нашли проблему в подходе вашей команды к Agile – озвучьте ее на ретроспективе, так работает Agile-механизм автокоррекции. Жаловаться просто ради жалоб значит деморализовать всю команду.

Обсудить в форуме