Не удалось вовремя выловить баги? ❤️🐞

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

Например, в спринте остаётся слишком мало времени на тестирование. Или в системе накапливается легаси-код, который затрудняет понимание системы и мешает определить, где скрывается ошибка.

Чем сложнее архитектура, тем больше потенциальных точек отказа (point of failure) — а значит, тесты не покрывают большую часть рисков.

Поэтому, чем проще устроен продукт, тем проще его протестировать и отладить

А когда работа разбита на небольшие части, любые изменения в требованиях обходятся дешевле — ведь переделать небольшой фрагмент гораздо проще, чем переписывать целый модуль.

Эти проблемы есть почти у всех. Но хорошая новость в том, что с ними можно бороться.

Иногда кажется, что какая-то фича слишком большая, чтобы поместиться в спринт, а как её разбить — непонятно. На недавнем тренинге по Scrum один из участников сказал:

— У нас есть фича, которую невозможно разбить на мелкие подзадачи.

Для этой ситуации существует выражение, придуманное одним из авторов Agile-манифеста, — Elephant Carpaccio, или карпаччо из слона 🐘

Оно означает, что любую фичу можно нарезать на тонкие, функционально завершённые элементы. При этом каждый из них будет нести в себе какую-то ценность.

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

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

На первом же ревью может оказаться, что представления заказчика о том, как должна работать фича, отличаются от изначально озвученных. Вот ради таких несостыковок и нужна ранняя обратная связь.

❤️А у вас есть пример фичи, которую невозможно нарезать? Предложите в комментариях — и мы покажем, как это можно сделать.

Может показаться, что Scrum не до конца продуман, раз в нём нет привычных ролей. Из-за этого многие команды сами пытаются договориться, кто за что отвечает, но делают это по-старому — и ничего не меняется.

❤️ С одной из команд клиента мы обсуждали вопрос:

— За что отвечает аналитик в Scrum и почему его нет в списке ролей?

Это сделано специально. В Scrum всего три роли — владелец продукта, Scrum-мастер и разработчик продукта.

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

Scrum принципиально устроен иначе

❤️ Чтобы к концу спринта появился небольшой инкремент продукта, который можно показать заказчику, участники команды свободно подключаются к задачам — не дожидаясь, пока кто-то закончит свою часть. Так фича быстрее становится частью продукта.

Первый спринт после майских — всё ☀️

Как вы там, держитесь?

❤️Команда впервые видит задачи на планировании

Уточнение бэклога — это обязательное событие. Но в отличие от планирования или ретро, это не всегда отдельная встреча, а скорее непрерывная работа по уточнению и оценке задач, которые войдут в следующий спринт.

Не обязывает проводить актуализацию каким-то особым способом:

«Уточнение Product Backlog — это постоянная деятельность по добавлению деталей, таких как описание, порядок и размер».

Руководство по Scrum

Иногда достаточно задержаться на 5-10 минут после дэйли, чтобы Владелец продукта рассказал команде про новую проработанную фичу, а команда быстро уточнила, всё ли им понятно.

Главное, чтобы к началу планирования большинство задач уже были оценены и готовы к взятию в работу.

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

В нашей статье о backlog refinement мы рассказываем о том, как навести порядок в бэклоге и сделать так, чтобы он продолжал помогать команде.

Друзья!

Мы хотим стать немного ближе к вам и чаще появляться в вашей ленте — с полезными материалами и разбором сложных вопросов, касающихся применения Agile-практик.

Если вам интересно видеть нас в историях, и вы считаете наш канал полезным — поддержите нас голосом!

Это поможет нам развиваться и чаще радовать вас.

❤️Проголосовать за наш Telegram-канал OnAgile.

Трижды выросла текучка ❤️

Если вам случалось ходить по коридорам с немым вопросом в глазах «Почему все уходят?», но никто не мог сказать, что идёт не так — не переживайте, такое может случиться в любой компании.

Например, в одной крупной IT-компанни тоже заметили, что люди стали чаще увольняться — будто они знают что-то, чего не знает руководство:

За последний год процент увольнений вырос в три раза — это повлекло за собой увеличение нагрузки на оставшихся сотрудников и срывы сроков. Несмотря на регулярные exit-интервью с уходящими сотрудниками и усилия HR-отдела, руководство так и не смогло выяснить, почему люди увольняются. Директор чувствовал, что информации недостаточно, а сотрудники что-то недоговаривают...

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

😊 Календарь ближайших тренингов OnAgile

• 24 - 26 сентября
🔹 Профессиональный сертификационный тренинг по Agile и Scrum

Я хочу понять, как начать внедрять гибкие подходы Agile, Scrum и Kanban в своей компании и научиться планировать в условиях неопределенности.

• 27 - 29 августа
🔹 Cертифицированный Скрам-мастер и фасилитатор

Я хочу научиться проводить командные встречи, организовывать ретроспективы даже в сложных ситуациях и создавать атмосферу доверия и тесного сотрудничества внутри своей команды.

• 01 - 03 октября
🔹Сертифицированный Владелец продукта в Agile

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

• 22 - 24 октября
🔹 Сертифицированный Delivery и Project менеджер в Agile

Я хочу ощутить ценность применения Agile и Scrum для своих проектов и овладеть самыми актуальными инструментами управления.

После прохождения каждого курса вы получите именной сертификат от международного консорциума ICAgile.

• 08 - 10 декабря
🔹 Масштабирование Agile на основе SAFe, LeSS и Flight Levels

Я хочу научиться управлять несколькими кросс-функциональными командами и синхронизировать их работу.

📍Сейчас самое время успеть воспользоваться выгодными условиями для тех, кто регистрируется заранее.

Надоели конфликты в команде 😡

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

Между такими специалистами могут возникать конфликты — один считает другого занудой, а второй уверен, что если не остановить первого, то он всех нас погубит.

Есть простая модель, которая помогает понять, почему люди ведут себя по-разному на работе — как они принимают решения, общаются с другими и что для них важно в команде.

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

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

Программа развития управленческих навыков руководителей 🤝

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

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

У руководителя в подчинении были два опытных специалиста с доминантным типом личности (тип D), которые часто спорили и не могли договориться. При этом руководитель тратил много времени на урегулирование конфликтов между ними, выступая посредником.

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

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

Никто не купит то, чего не понимает 👛

Представьте, что на рынок выходит стартап — умный виджет для управления домом. Команда инженеров вложила душу в эту технологию, но забыла о главном — стратегии выхода на рынок (Go-to-Market).

Продаж не случилось, и склады заполнились нереализованной продукцией.

Спустя год рынок заняли конкуренты с продуманной GTM-стратегией. А у стартапа закончились деньги, и он закрылся — не потому что продукт был плохим, а потому что никто не узнал, зачем он нужен.

Разбираемся, на что стоит обратить внимание при запуске, и как выглядит эффективная GTM-стратегия↖️

Я и сам знаю, как всё организовать ⭐️

Так думают многие руководители, и часто — это правда. Но даже у самых опытных бывают слепые зоны.

💬 А теперь представьте, что вместо указаний можно просто задавать вопросы: «Как вы думаете, что мешает нам двигаться быстрее?», «Как лучше подойти к этой задаче?» — и команда сама ищет ответы.

Мы уже писали о таком случае, когда отдел из 20 человек сам сформировался в три кросс-функциональные команды.

С чего начать, если вы хотите попробовать самодизайн, и зачем он нужен даже уже сформированным командам — рассказываем в статье о том, как провести сессию самодизайна↖️

Инструменты people-менеджмента 👥

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

🗣Опять этот бесполезный созвон.
🗣Опять эти бонусы, которые никто никогда не получает.

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

Что действительно влияет на мотивацию сотрудников, и как её повысить с помощью современных практик и стилей управления.