Это текстовая выжимка выпуска подкаста SDCast, в котором гостем был Евгений Кривошеев. Куча умных идей, разложенных по полочкам, которые хотелось зафиксировать для себя и может для других.

Agile – это концентрированный здравый смысл. Набор процессных техник: процессные, инженерные, культурные.

Культурный уровень

Agile культура – культура ответственности. Каждый член команды принимает ответственность, готовность каждого оторвать попу от стула и сделать дело вне зависимости от наличия или отсутствия соответствующего регламента.

Соответствующая процессная практика применяется в зависимости от контекста решаемой задачи и уровня неопределённости.

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

Когда неопределённость высокая (например: продуктовая разработка), то agile подходит лучше.

Команда должна быть замотивированная, самоорганизованная. Очень важны навыки коммуникации.

Регламенты – более простая точка входа в процессы. Становятся «защитным механизмом», который скрывает проблемы в команде. Это мины замедленного действия. Пусть лучше будут конфликты сразу и явные, чем постоянно что-то будет подтачивать эффективность компании.

Процессный уровень

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

Трансформация персональных культур людей

У каждого должно появится желание взаимодействовать. Нужны харизматичные люди для формирования такой культуры как для существующих сотрудников, так и для найма только подходящих под неё новых.

Бизнес модель компании должна формировать культуру компании.

Когда мы принимаем решения – мы должны понимать конфликт разных требований. Часто же мы руководствуемся желанием удовлетворить инженерные амбиции. Этот структурный конфликт. Нужен компромисс: например, «зелёные пятницы» – время для собственных экспериментов с рассказом остальным. Можем использовать новые технологии «сбоку», а не в критических местах проекта. Не используя новые технологии, мы рискуем как демотивировать людей, так и уменьшить свою эффективность. Разумная консервативность (цель которой делать всё проще и предсказуемее) должна разбавляться новыми вещами.

Частые релизы (CI+CD)

Если по бизнесу нужно работать в условиях высокой определённости – нам нужно поставлять часто, иначе подохнет компания. Должны быстро проверять гипотезы. У инженеров тоже есть неопределённость (неуверенность в использовании новых инструментов/технологий/подходов) и она подчас больше бизнесовой.

Мы всегда допускаем архитектурные ошибки и частые поставки – это инструмент быстро узнавать ошибки. Выигрывает не тот, кто правильно сделал, а тот, кто быстрее понял свою ошибку. Делаем маленькими кусками для проверки инженерных и бизнес гипотез. Платим за инкрементальное развитие рефакторингом.

Проектирование архитектуры – обозначение ключевых точек, в которых наибольшая концентрация максимального риска, вместе с бизнесом (какие наши решения могут убить бизнес). За всё приходится платить, за что-то и чем-то.

DevOps

Мы формируем потоки создания ценностей для компании. Ищем узкие места и оптимизируем в первую очередь их и не перегружаем там, где не надо. Наши потоки имеют границы на входе и выходе. Границы на входе – заказчик. Должен быть максимально доступен и не должен стать ограничением (это решил agile своим требованием). Границы на выходе – мы быстро поставляем продукт и всё упирается в людей, которые занимаются внедрением и установкой. У нас всё зашибись, но бизнесу пофиг, т.к. ценность в итоге он может получать долго и мучительно. Так давайте продлим конвейер вправо. Вберём в себя operations, научимся с ними нормально контактировать. Мы им поможем, снимем коммуникационные, процессные трения. Можно на этом не останавливаться и вобрать себя и поддержку.

Инкрементальная архитектура

Использование продуктовой механики – MVP. Мы будем платить за это рефакторингом.

Тесты – необходимый технический налог. Иногда очень дорогие. Но это необходимое условие движения вперёд (чтобы попасть куда надо и вовремя). Позволяют нам трансформировать проект ритмично. Без тестов вы умрёте под дефектами. Это инвестиции в «кросовки» при беге: можно и без них, но будет больно и быстро начнём замедляться. Если в рамках проекта мы мыслим большими потоками изменений и фич, то отказаться от этого нельзя.