Это текстовая выжимка выпуска подкаста SDCast, в котором гостем был Евгений Кривошеев.
Куча умных идей, разложенных по полочкам, которые хотелось зафиксировать для себя и может для других.
Agile - это концентрированный здравый смысл.
Набор процессных техник: процессные, инженерные, культурные
Соответствующая процессная практика применяется в зависимости от контекста решаемой задачи и уровня неопределённости.
Если мы решаем не новые проблемы, а решаем одну и ту же каждый день, то строгая формализация процесса вполне уместна (то есть когда понятно что делать и как делать). Так мы можем обеспечить хорошую устойчивость бизнеса (пример: процессы работы call-центра).
Когда неопределённость высокая (например: продуктовая разработка), то agile подходит лучше.
Команда должна быть замотивированная, самоорганизованная. Очень важны навыки коммуникации.
Регламенты - более простая точка входа в процессы. Становятся "защитным механизмом", который скрывает проблемы в команде. Это мины замедленного действия. Пусть лучше будут конфликты сразу и явные, чем постоянно что-то будет подтачивать эффективность компании.
Бизнес модель компании должна формировать культуру компании.
Когда мы принимаем решения - мы должны понимать конфликт разных требований.
Часто же мы руководствуемся желанием удовлетворить инженерные амбиции. Этот структурный конфликт. Нужен компромисс - например, "зелёные пятницы" - время для собственных экспериментов с рассказом остальным. Можем использовать новые технологии "сбоку", а не в критических местах проекта. Не используя новые технологии, мы рискуем как демотивировать людей, так и уменьшить свою эффективность.
Разумная консервативность (цель которой делать всё проще и предсказуемее) должна разбавляться новыми вещами.
Мы всегда допускаем архитектурные ошибки и частые поставки - это инструмент быстро узнавать ошибки. Выигрывает не тот, кто правильно сделал, а тот - кто быстрее понял свою ошибку. Делаем маленькими кусками для проверки инженерных и бизнес гипотез.
Платим за инкрементальное развитие рефакторингом.
Проектирование архитектуры - обозначение ключевых точек, в которых наибольшая концентрация максимального риска, вместе с бизнесом (какие наши решения могут убить бизнес). За всё приходится платить, за что-то и чем-то.
У нас всё зашибись, но бизнесу пофиг, т.к. ценность в итоге он может получать долго и мучительно.
Так давайте продлим конвейер вправо. Вберём в себя Ops, научимся с ними нормально контактировать. Мы им поможем, снимем коммуникационные, процессные трения. Можно на этом не останавливаться и вобрать себя и поддержку.
Тесты - необходимый технический налог. Иногда очень дорогие. Но это необходимое условие движения вперёд (чтобы попасть куда надо и вовремя). Позволяют нам трансформировать проект ритмично. Без тестов вы умрёте под дефектами.
Это инвестиции в "кросовки" при беге - можно и без них, но будет больно и быстро начнём замедляться. Если в рамках проекта мы мыслим большими потоками изменений и фич, то отказаться от этого нельзя.
Куча умных идей, разложенных по полочкам, которые хотелось зафиксировать для себя и может для других.
Agile - это концентрированный здравый смысл.
Набор процессных техник: процессные, инженерные, культурные
Культурный уровень
Agile культура - культура ответственности. Каждый член команды принимает ответственность, готовность каждого оторвать попу от стула и сделать дело вне зависимости от наличия или отсутствия соответствующего регламента.Соответствующая процессная практика применяется в зависимости от контекста решаемой задачи и уровня неопределённости.
Если мы решаем не новые проблемы, а решаем одну и ту же каждый день, то строгая формализация процесса вполне уместна (то есть когда понятно что делать и как делать). Так мы можем обеспечить хорошую устойчивость бизнеса (пример: процессы работы call-центра).
Когда неопределённость высокая (например: продуктовая разработка), то agile подходит лучше.
Команда должна быть замотивированная, самоорганизованная. Очень важны навыки коммуникации.
Регламенты - более простая точка входа в процессы. Становятся "защитным механизмом", который скрывает проблемы в команде. Это мины замедленного действия. Пусть лучше будут конфликты сразу и явные, чем постоянно что-то будет подтачивать эффективность компании.
Процессный уровень.
Очень важна ретроспектива. Поиск ограничений рабочей системы для их снятия. Нужно научиться слышать и слушать друг друга. Общение без лишних обид, драм. Ключевые проблемы - проблемы коммуникации. Трансформация персональных культур людей. У каждого должно появится желание взаимодействовать. Нужны харизматичные люди для формирования такой культуры как для существующих сотрудников, так и для найма только подходящих под неё новых.Бизнес модель компании должна формировать культуру компании.
Когда мы принимаем решения - мы должны понимать конфликт разных требований.
Часто же мы руководствуемся желанием удовлетворить инженерные амбиции. Этот структурный конфликт. Нужен компромисс - например, "зелёные пятницы" - время для собственных экспериментов с рассказом остальным. Можем использовать новые технологии "сбоку", а не в критических местах проекта. Не используя новые технологии, мы рискуем как демотивировать людей, так и уменьшить свою эффективность.
Разумная консервативность (цель которой делать всё проще и предсказуемее) должна разбавляться новыми вещами.
Частые релизы (CI+CD)
Если по бизнесу нужно работать в условиях высокой определённости - нам нужно поставлять часто, иначе подохнет компания. Должны быстро проверять гипотезы. У инженеров тоже есть неопределённость (неуверенность в использовании новых инструментов/технологий/подходов) и она подчас больше бизнесовой.Мы всегда допускаем архитектурные ошибки и частые поставки - это инструмент быстро узнавать ошибки. Выигрывает не тот, кто правильно сделал, а тот - кто быстрее понял свою ошибку. Делаем маленькими кусками для проверки инженерных и бизнес гипотез.
Платим за инкрементальное развитие рефакторингом.
Проектирование архитектуры - обозначение ключевых точек, в которых наибольшая концентрация максимального риска, вместе с бизнесом (какие наши решения могут убить бизнес). За всё приходится платить, за что-то и чем-то.
DevOps
Мы формируем потоки создания ценностей для компании. Ищем узкие места и оптимизируем в первую очередь их и не перегружаем там, где не надо. Наши потоки имеют границы на входе и выходе. Границы на входе - заказчик. Должен быть максимально доступен и не должен стать ограничением (это решил agile своим требованием). Границы на выходе - мы быстро поставляем продукт и всё упирается в людей, которые занимаются внедрением и установкой.У нас всё зашибись, но бизнесу пофиг, т.к. ценность в итоге он может получать долго и мучительно.
Так давайте продлим конвейер вправо. Вберём в себя Ops, научимся с ними нормально контактировать. Мы им поможем, снимем коммуникационные, процессные трения. Можно на этом не останавливаться и вобрать себя и поддержку.
Инкрементальная архитектура
Использование продуктовой механики - MVP. Мы будем платить за это рефакторингом.Тесты - необходимый технический налог. Иногда очень дорогие. Но это необходимое условие движения вперёд (чтобы попасть куда надо и вовремя). Позволяют нам трансформировать проект ритмично. Без тестов вы умрёте под дефектами.
Это инвестиции в "кросовки" при беге - можно и без них, но будет больно и быстро начнём замедляться. Если в рамках проекта мы мыслим большими потоками изменений и фич, то отказаться от этого нельзя.
Комментариев нет:
Отправить комментарий