К основному контенту

ХВОСТ ВИЛЯЕТ СОБАКОЙ: создаем мини-привычки для устойчивых и безболезненных изменений.

Автор: Наталья Тренина
Внедрение любых реорганизационных изменений - будь то гибкие процессы на базе Scrum или Kanban, или освоение технических практик, таких как TDD, парное программирование, автоматизация тестирования в инженерную культуру команды, связано с изменением привычного поведения человека.

Мы можем многое говорить о культуре организации, стиле управления, уровне вовлеченности сотрудников, особенностях проекта - всем том, что коучи одним словом называют “контекстом”, когда увиливают от давания советов ;)

Но, в конечном счете, способность организации совершенствоваться упирается в способность каждого ее конкретного сотрудника изменяться. И эта способность может быть тренирована как навык!

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


Я не могу быть гидом и советчиком по каталке в Гудаури, никогда не побывав там. Но опустившись до уровня базовых законов природы (гравитации, к примеру), вполне могу давать советы начинающему лыжнику: “чем круче склон, тем более наклоненным вперед должен быть корпус твоего тела в момент начала движения”. Ведь только в перпендикулярном склону положении корпуса, лыжа становится управляемой.

Я помню свое прозрение, когда впервые услышала об этом от тренера. Более “естественным” движением было присесть на пятую точку, пытаться примагнититься спиной к склону.. что угодно - но только не корпусом вниз. И только после слов инструктора и массирования силы воли, телом начала понимать закон природы.

Точно такое же противоречие раздирает начинающих скрам-мастеров и менеджеров проекта когда они слышат “Чем больше автономии - тем больше дисциплины”. Как в поговорке, “если любишь - отпусти”.

Я вполне понимаю, почему так сложно довериться командной самоорганизации, ответственности и дисциплине. Каждым “загорелся, пообещал, но не смог” подтекают метафорические вазы нашего доверия. А эти емкости - вполне конечного размера.

Что же мы упускаем, когда просто отпускаем?

Несмотря на самый высокий уровень энтузиазма, большинство людей попросту не умеет меняться. Точнее, часто мы не умеем меняться эффективно - не понимая базовые законы нашей внутренней природы: как функционирует наш ум, и как обойти его встроенные ограничения.
  • Почему одной только мотивации не достаточно?
  • Как связаны мотивация, автономность и сила воли?
  • Как усыпить свое экономное (ленивое) подсознание?
  • Чем отличается личная дисциплина от командной?
  • Как же начать устойчиво и радостно меняться самому?
  • И как помогать это делать своим командам и заказчикам?

Базовые законы нейробиологии, доступным языком, с прикладными примером и проработкой вашего собственного плана развития мини-привычек (процесс создания которого вы вполне сможете использовать в дальнейшем, вместе со своими командами) - все это ждет вас на встрече Agile-сообщества, 9 июля.

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations


Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко.


Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности.

Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь):
«Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы приблизиться…

Календарь тренингов по Agile

Наши партнёры по тренингам: