Agile *

▍ Разработка ПО — это исследование

Сегодня в методах разработки ПО исключения не подтверждают, а скорее заменяют правила. Чистокровный Аgile днем с огнем не сыщешь ни в одной компании. Зато плодятся разные гибридные методологии. Некоторые проджекты задаются совсем уж крамольным вопросом: зачем нужны эталонные системы, если на практике все работают по-разному?

Думается, что они выступают в качестве удачных базовых рабочих процессов, которые можно и нужно модифицировать. Однако перед тем, как что-то менять, постараемся в общих чертах разобраться, что не так с популярными методологиями разработки, в чем их особенности и как выбрать подходящую.

Спойлер: многие затронутые вопросы спорные, и готовых решений у нашей команды нет (как, наверное, у большинства PM). Так что заранее приглашаю всех желающих к диалогу и обмену опытом в комментариях.

Что такое Scrum?

Scrum — это Agile-система управления проектами, «помогающая людям и командам инкрементно и совместно приносить пользу» — цитата со Scrum.org.

Agile не является: Библией разработки ПО, догматическим набором строгих правил, тикетами Jira или коучами Agile, суетящимися в вашей компании.

Каждый, кто сталкивался с внедрением новых подходов, испытывал весь спектр эмоций. Особенно, если дело касается государственного сектора. РТЛабс использует практики SAFe® с 2022 года. Как мы провели продуктовую трансформацию — подробно в другой статье. 

Здесь расскажем про важную часть SAFe® — PI-планирование: как мы готовимся к нему, проводим и как управляем планом в течение квартала. С какими ограничениями сталкиваемся и как обеспечиваем работу 1 500 человек в квартальном цикле.

Будет полезно тем, кто хочет изменить подходы к производству ПО, начинает или уже работает с государственным сектором. Мы — самый большой кейс внедрения практик SAFe® в России.

Бытует мнение, что ретроспектива это скучная встреча без явной пользы. Если ставить цель, фиксировать прогресс и подбирать интересный формат ретроспективы, то польза от этой командной встречи не заставит себя ждать. В статье вы найдете 3 варианта эффективных ретроспектив, проводимых в командах разработки Ozon.

Как же часто мне приходилось слышать от рекрутеров одну и ту же фразу:

Мы работаем по Agile. Спринты по 1-2 недели

Под "Agile" они, конечно же, имеют в виду Scrum. Но я с уверенностью могу сказать, что ни в одной компании, что я работал, Agile'ом даже и не пахло. И тут я даже не говорю о том, что Agile каким он был задуман в принципе не дошел до массовой разработки (о чем рассказывал один из создателей Agile Дейв Томас на конференции GOTO 2015). Я говорю об Agile в общепринятом значении этого слова.

В дальнейшем, на техническом интервью, если спрашивать по пунктам, практически любой реальный работник компании подтвердит вам, что никакого Agile в компании нет, а используются лишь элементы Agile.

По некоторым причинам команде разработчиков либо не получается наладить работу по Agile, либо руководство знает, как лучше, и навязывает собственное видение методологии разработки. Эту проблему адресовал в своей статье Рон Джефрис (вот перевод на русский), дав красноречивое название подобным практикам — "Dark Scrum". Существует и более мягкая формулировка для тех, кто считает подобное положение вещей скорее фичей, а не багом — "Pseudo Agile" или "Post Agile".

В этой статье я постараюсь расставить точки над Ё и разобраться, что такое Agile на самом деле, и какие проблемы существуют у современных гибких методологий.

Фрейморк Scrum в представлении не нуждается, и его преимущества многократно описаны. Однако о недостатках подхода говорят реже, и успешно применять его получается далеко не у всех. Зачастую после первых неудач команда разочаровывается в подходе и начинает считать его полностью бесполезной пустышкой. Но может быть дело не в самом Скраме, а в том, где и как его применили?

Попробуем рассмотреть, какие есть ограничения и допущения в применимости этого подхода, какие риски и предварительные условия нужно учесть.

Перевод статьи Лукаса Ф. Косты "Why your daily stand-ups don't work and how to fix them" с некоторыми размышлениями переводчика (выделены курсивом).

Ежедневные стендапы — классический пример выученной беспомощности. Мы все знаем, что они отстой. Тем не менее, мы ничего с этим не делаем. В наши дни мы проводим стендапы потому что нам так говорят, а не потому что они решают какие-то конкретные проблемы.

Подобная статья должна была появиться раньше, лет десять или пятнадцать назад, когда Agile только начинал внедряться в ИТ-компаниях. Сколько можно бы было избежать ошибок, проблем, конфликтов, , если бы менеджеры сразу подходили к вопросу правильно, не отвлекаясь на лишние действия …

Зато за это время накопился опыт "внедрений" Agile в разных условиях, в разных компаниях, который следует обобщить и повсеместно распространять.

Всем привет! Я Виталий Дощенко, ньюбиз-директор AGIMA. Обычно на Хабре мы рассказываем, как работаем над цифровыми продуктами. Над мобильными приложениями, высоконагруженными системами или чат-ботами. Но только не в этот раз. В этой статье я расскажу, как Канбан-метод помог нам устранить последствия пожара. Не того пожара, где куча задач и ты ничего не успеваешь, а самого настоящего пожара, который чуть не уничтожил дом моей семьи.

Всем привет. Меня зовут Рома, я-разработчик. За короткое время, в одной команде, на одном проекте, я поработал в трёх разных вариациях скрама. Ощущались они по-разному, и каждый новый вариант нравился мне меньше предыдущего. В этой статье я поделюсь своим опытом и выводами.

Статья коллеги про отношение к вынужденной удалёнке вдохновила меня рассказать о самом серьёзном испытании, с которым я столкнулся в первые полгода такого режима: грумминг сложных задач стал невыносим. Под катом я постарался не только рассказать о проблеме, но и поделиться своими соображениями о её решении. Возможно, кто-то сочтёт мои рассуждения очевидными и подумает, что были допущены детские ошибки. Но я также верю, что найдутся и те, кому мой опыт окажется полезен.

Начало декабря. Утро понедельника. В переговорной собралась команда для обсуждения планов на спринт.

Накидали несколько задач из бэклога. По требованиям — всё понятно, по срокам — всё адекватно, но в воздухе чувствуется какая-то недосказанность.

Владелец продукта кивнул, принимая тяжёлое, но важное для команды решение, и твёрдо произнёс: «Нам нужно поставить ёлку».

В мире на сегодня накопилось много неприятных вещей и тенденций, о которых почему-то стало неприлично негативно высказываться. Даже фраза появилась: «Вы не понимаете, это другое!»  Немалая часть явлений так или иначе связана с ИТ. В рамках проводимого мероприятия «Стань автором, получи футболку!» решил выложить на обсуждение некоторые моменты с комментариями, почему я считаю их вредными, а иногда и опасными.

Поехали.

Выдался у меня как-то на работе хороший год. Я сделал пару серьёзных проектов, за что получил существенную прибавку к окладу. Естественно, я захотел этот опыт повторить. Пришёл к директору и говорю – хочу +30%, готов стараться от всей души.

Тот почему-то обрадовался. Давай, говорит, всё-превсё автоматизируем в течение года, и будет тебе прибавка. Чтобы понять, кто такое «всё-превсё», мы собрали совещание всех отделов. Люди с радостью притащили хотелки, мы из сгруппировали в 13 проектов.

Увидев предстоящий объём работы, я, конечно, приуныл. А директор – наоборот. Когда все отделы ушли с совещания, он сказал: я тебе помогу. Ну, думаю, поможешь ты мне. Уже помог, спасибо.

Директор же сказал: я знаю, как тебе легко и быстро сделать все эти проекты. Ты, говорит, сам от себя офигеешь. Будем делать по-гибкому, в стиле эджайл.

Основано на реальных событиях.

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

Я давно интересуюсь скрамом, был опыт его применения, но вживую настоящего скрам-мастера я никогда не видел. Разве что на паре конференций, где удавалось посмотреть феерические выступления истинных мастеров этого ремесла. И вот, откуда не возьмись, в наших провинциях возник Виктор, дипломированный скрам-мастер. Более того, он сам прислал нам резюме. Не на конкретную должность, как соискатель, а для обсуждения возможного сотрудничества, как потенциальный партнер.

 - Итак, меня зовут Иван, я руковожу группой программистов. Справа от меня – Александр, ключевой руководитель проектов в нашей компании. Утверждает, что тоже знаком со скрамом. – пытаюсь немного пошутить, чтобы Александр улыбнулся, но тот продолжает сидеть с каменным лицом.

 - Да, добрый день, друзья. – начинает Виктор. – Меня зовут Виктор, я принёс вас настоящий скрам. Предлагаю обсудить варианты сотрудничества.

Повисла неловкая пауза. С одной стороны, у меня в голове был целый ворох вопросов по методике и практике применения скрама, но они вряд ли подходили для собеседования. С другой стороны, я примерно представлял, кто такой скрам-мастер и чем он занимается, поэтому не знал, что спросить на тему «а чем вы у нас будете заниматься?». Но выручил Александр.

 - Итак, скрам... – Александр сложил ладони вместе, медленно опустил их на стол, выдержал паузу («завис»), будто обдумывая следующую фразу. – Иван заставил меня изучить, что это за методика, в рамках подготовки к этой встрече. Я сразу честно скажу – прочитал лишь половину книги. Поэтому, Виктор, если не затруднит, можете в двух словах рассказать, что именно хотите нам предложить? Чем будете заниматься, проще говоря?

Статей о TDD достаточно много, и я обратил внимание на то, что все они затрагивают преимущественно техническую составляющую этого подхода, и практически никак не описывают ментальные принципы, лежащие в основе TDD.

Поэтому я не хотел писать еще одну статью с описанием техники Red-Green-Refactor. Мне хотелось взглянуть на TDD немного глубже и описать, как и почему TDD влияет на поведение человека.

В статье речь пойдет о неких абстракциях, которые применимы на разных слоях мировоззрения и, вне зависимости от контекста, помогают достигать хорошего результата. Универсальность этих абстракций и факт, что они применимы даже к процессу написания кода, сделали меня ярым приверженцем как TDD подхода, так и этих абстракций.