Click to edit Master title style
Вжух, и у вас Agile
Андрей Шелёхин
Руководитель отдела собственной разработки
Разрабатываем программные решения для внутреннего использования.
Все заказчики и пользователи – наши коллеги.
80% сотрудников банка каждый день пользуются нашими системами.
2
Кто мы?
В создании продуктов участвуют около 70 человек (разработчики,
тестировщики, аналитики, дизайнеры).
Довольные заказчики и бизнес.
3
Цель руководителя разработки
Счастливые разработчики.
Благодарные пользователи.
4
Роли;
Этапы;
Активности;
Артефакты;
Инженерные практики;
Немного магии.
Процессы в разработке
Ингредиенты
Снижение влияния человеческого фактора.
Не существует идеальных людей и с этим
нужно что-то делать.
Согласованность действий.
Каждый участник знает что/когда/в каком
виде ждут от него, а он от других.
Прогнозируемый результат.
Выработка последовательности шагов,
приводящих к ожидаемому результату в
понятные сроки.
Зачем это надо?
Любое изменение в процессе должно быть осознанным и начинаться
с анализа проблемы и желания ее решить, а не с попытки оправдать
статус руководителя и имитации полезной деятельности.
Писать код?
Задумчиво сидеть и смотреть в монитор?
Выпить кофейку?
Роль разработчика
5
Роль разработчика — осознанно решать задачи бизнеса, удовлетворяя потребности
пользователей.
Заказчик приходит с готовым решением.
Пропадает возможность найти более простое и быстрое решение за счет знаний и
экспертизы разработчиков;
Пропускаются ошибки в постановке, приводящие к багам;
Падает качество архитектуры и растет стоимость владения кодом;
Исчезает ответственность за результат и желание делать хорошо.
6
Разработчик и вопрос «Зачем?»
Для каждой задачи, поступающей разработчику, должна быть понятна
проблема, которая решается, и получаемая ценность.
Рецепты: Техника «5 Whys», доработка формата требований.
Если ничего не делать:
Мир меняется быстрее, чем вы печатаете код.
7
Итеративность или смерть
Если вы все еще пытаетесь бороться с изменениями — вы заблудились;
Скорость — критически важное конкурентное преимущество
• Проверка гипотез, получение обратной связи и анализ цифр, вместо управления
продуктом через галлюцинации;
Развитие каналов доставки обновлений не дает шанса оставаться медленным.
Максимально короткие итерации;
Выделение MVP;
(Микро?)сервисная архитектура;
Продуманная схема версионирования;
Инструменты CI/CD;
Контроль технического долга;
Автоматизация тестирования.
Рецепты
8
Управление ожиданиями
Цель: давать обещания и выполнять их.
Вариативность задач;
Неполнота требований;
Изменения по ходу работы;
Влияние уже написанного функционала;
Ограничение времени на оценку.
Условия
Подключение разработчиков на ранних
этапах;
Понятная всем единица оценки;
Декомпозиция;
Несколько точек зрения;
Накопление статистики;
Анализ ошибок в оценке;
Обещать чуть меньше, делать
чуть больше.
Рецепты
Проблемы командной разработки:
9
Командная разработка
Непрозрачность происходящего;
Позднее обнаружение проблем;
Накладные расходы на контроль за процессом;
Прерывания и вырывания из контекста;
Увеличение числа коммуникаций и снижение скорости распространения информации.
Визуализация работы;
Поддержка и контроль процесса
программными средствами;
Регулирование времени доступности
участников;
Рецепты
Распространение знаний;
Организация небольших
сфокусированных команд.
Как разработчику мне нужно:
10
User Story разработчика
Заниматься интересными для меня задачами;
Чувствовать, что мой профессиональный уровень постоянно растет;
Видеть, что моя работа приносит пользу;
Знать, что мой вклад будет оценен.
Распределение задач, гарантирующее «вызов» каждому участнику с учетом его
уровня;
Возможность принимать решения, контролируемо ошибаться и делать выводы;
Доступ к информации об успехах и провалах продукта;
Регулярная двусторонняя обратная связь с руководителем.
Рецепты
Для того, чтобы работать вовлеченно и с полной отдачей.
Организовать процесс непрерывных улучшений в командах –
важнейшая задача руководителя разработки.
11
Непрерывные улучшения
Самоанализ и гарантия безопасности;
Небольшие изменения с правом на ошибку;
Решения, выработанные внутри, а не
спущенные сверху;
Конкретный план изменений после каждой
итерации;
Контроль выполнения прошлых
договоренностей;
Наличие метрик для отслеживания прогресса.
Правила
12
Не забывайте о людях
—Мы будем разбирать диаграммы Ганта, ПЕРТ-
диаграммы, отчеты о состоянии дел в компании,
взаимодействия с отделом по работе с персоналом,
проведение еженедельных собраний, отчеты о
затраченном времени, отчеты о темпах работы…
... Вы считаете, я что-то упустил из виду?
— Ничего существенного. Вы просто упустили из
виду людей.
— Людей?
— Людей. Проекты делают как раз они.
Спасибо! Ваши вопросы?
Андрей Шелёхин
andrey.shelehin

TechLeads meetup: Андрей Шелёхин, Tinkoff.ru

  • 1.
    Click to editMaster title style Вжух, и у вас Agile Андрей Шелёхин Руководитель отдела собственной разработки
  • 2.
    Разрабатываем программные решениядля внутреннего использования. Все заказчики и пользователи – наши коллеги. 80% сотрудников банка каждый день пользуются нашими системами. 2 Кто мы? В создании продуктов участвуют около 70 человек (разработчики, тестировщики, аналитики, дизайнеры).
  • 3.
    Довольные заказчики ибизнес. 3 Цель руководителя разработки Счастливые разработчики. Благодарные пользователи.
  • 4.
    4 Роли; Этапы; Активности; Артефакты; Инженерные практики; Немного магии. Процессыв разработке Ингредиенты Снижение влияния человеческого фактора. Не существует идеальных людей и с этим нужно что-то делать. Согласованность действий. Каждый участник знает что/когда/в каком виде ждут от него, а он от других. Прогнозируемый результат. Выработка последовательности шагов, приводящих к ожидаемому результату в понятные сроки. Зачем это надо? Любое изменение в процессе должно быть осознанным и начинаться с анализа проблемы и желания ее решить, а не с попытки оправдать статус руководителя и имитации полезной деятельности.
  • 5.
    Писать код? Задумчиво сидетьи смотреть в монитор? Выпить кофейку? Роль разработчика 5 Роль разработчика — осознанно решать задачи бизнеса, удовлетворяя потребности пользователей.
  • 6.
    Заказчик приходит сготовым решением. Пропадает возможность найти более простое и быстрое решение за счет знаний и экспертизы разработчиков; Пропускаются ошибки в постановке, приводящие к багам; Падает качество архитектуры и растет стоимость владения кодом; Исчезает ответственность за результат и желание делать хорошо. 6 Разработчик и вопрос «Зачем?» Для каждой задачи, поступающей разработчику, должна быть понятна проблема, которая решается, и получаемая ценность. Рецепты: Техника «5 Whys», доработка формата требований. Если ничего не делать:
  • 7.
    Мир меняется быстрее,чем вы печатаете код. 7 Итеративность или смерть Если вы все еще пытаетесь бороться с изменениями — вы заблудились; Скорость — критически важное конкурентное преимущество • Проверка гипотез, получение обратной связи и анализ цифр, вместо управления продуктом через галлюцинации; Развитие каналов доставки обновлений не дает шанса оставаться медленным. Максимально короткие итерации; Выделение MVP; (Микро?)сервисная архитектура; Продуманная схема версионирования; Инструменты CI/CD; Контроль технического долга; Автоматизация тестирования. Рецепты
  • 8.
    8 Управление ожиданиями Цель: даватьобещания и выполнять их. Вариативность задач; Неполнота требований; Изменения по ходу работы; Влияние уже написанного функционала; Ограничение времени на оценку. Условия Подключение разработчиков на ранних этапах; Понятная всем единица оценки; Декомпозиция; Несколько точек зрения; Накопление статистики; Анализ ошибок в оценке; Обещать чуть меньше, делать чуть больше. Рецепты
  • 9.
    Проблемы командной разработки: 9 Команднаяразработка Непрозрачность происходящего; Позднее обнаружение проблем; Накладные расходы на контроль за процессом; Прерывания и вырывания из контекста; Увеличение числа коммуникаций и снижение скорости распространения информации. Визуализация работы; Поддержка и контроль процесса программными средствами; Регулирование времени доступности участников; Рецепты Распространение знаний; Организация небольших сфокусированных команд.
  • 10.
    Как разработчику мненужно: 10 User Story разработчика Заниматься интересными для меня задачами; Чувствовать, что мой профессиональный уровень постоянно растет; Видеть, что моя работа приносит пользу; Знать, что мой вклад будет оценен. Распределение задач, гарантирующее «вызов» каждому участнику с учетом его уровня; Возможность принимать решения, контролируемо ошибаться и делать выводы; Доступ к информации об успехах и провалах продукта; Регулярная двусторонняя обратная связь с руководителем. Рецепты Для того, чтобы работать вовлеченно и с полной отдачей.
  • 11.
    Организовать процесс непрерывныхулучшений в командах – важнейшая задача руководителя разработки. 11 Непрерывные улучшения Самоанализ и гарантия безопасности; Небольшие изменения с правом на ошибку; Решения, выработанные внутри, а не спущенные сверху; Конкретный план изменений после каждой итерации; Контроль выполнения прошлых договоренностей; Наличие метрик для отслеживания прогресса. Правила
  • 12.
    12 Не забывайте олюдях —Мы будем разбирать диаграммы Ганта, ПЕРТ- диаграммы, отчеты о состоянии дел в компании, взаимодействия с отделом по работе с персоналом, проведение еженедельных собраний, отчеты о затраченном времени, отчеты о темпах работы… ... Вы считаете, я что-то упустил из виду? — Ничего существенного. Вы просто упустили из виду людей. — Людей? — Людей. Проекты делают как раз они.
  • 13.