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

Видео-продукт “Эмоциональный Scrum”

Полная версия статьи по сслылке

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

Мы создаем продукт для всех, кто работает или собирается работать по Scrum-у, чтобы понимать принципы и трюки управления людьми в Agile командах. Мы опираемся на опыт психологии и расширяем техники, которые использует Scrum. Слушатели научатся определять паттерны поведения участников Scrum-команды, попробуют новые психологические подходы и приемы. Мы разберем артефакты, встречи, принципы Scrum-а с точки зрения психологии. На основании этих знаний и примеров вы будете применять практики и артефакты с большей отдачей.

Цель продукта – добиться большего от команд, которые используют Scrum! 




Об авторах:

Дмитрий Снисарь – практикующий психолог

Обеспечивает научную поддержку проекта
Психолог, тренер с 2004 года.
Автор блога Психология в ИТ – http://it-boost.com.
Специализация: гештальт психотерапия, транзактный анализ, позитивная психотерапия, синтез-технология, НЛП. За время практической деятельности обучил и помог 2000+ людям, в течении 2500+ тренинг-часов.
Дмитрий является главным научным редактором данного проекта и именно он подводит теоретическую основу (базу) под практики Scrum.


Сергей Бережной – практик Scrum и руководитель программ

Обеспечивает знание потребностей рынка и некоторые идеи
Тренер, консультант и практикующий руководитель проектов. Автор блога о работе с Заказчиками в ИТ – http://anotherpm.com.

Сергей является практиком Scrum-а на протяжении 5 лет и хорошо понимает проблемы Scrum-команд в аутсорсинге.


Владимир Железняк – практик Agile и руководитель проектов

Единственный трезвомыслящий в коллективе авторов 
Владимир является практикующим тренером и практиком Scrum. Владимир специализируется на продуктовой разработке и работе в распределенных командах и стратапах.

Автор блога Психология в ИТ – http://it-boost.com.



Откуда мы знаем о проблемах со Scrum в реальных командах?



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

Маркетинг Scrum работает хорошо и менеджмент верит, что выполняя 20 простых правил можно сделать управление проектами на крутом уровне. Тот, кто попробовал «просто выполнять 20 правил», уже не столь оптимистичен. Поэтому на тренингах мы получаем много вопросов от тех, кто начал использовать Scrum и столкнулся с проблемами. Теория и практика оказались «двумя большими разницами»:
  • Менеджмент прекращает эксперименты и команды опять возвращаются к привычной модели разработки. Без всяких «вкусностей» гибких методологий.
  • Обвиняют инженеров в недостаточной квалификации. «Вы настолько тупые, что не можете делать хорошо 20 правил!»
  • Некогда учить, давай внедрять. После одной книги и двухдневного курса – ты ведущий специалист по Scrum в нашей компании. Добавили больше обязанностей, а времени – нет.
  • Scrum-мастер становится просто «секретарем команды» и его главная задача – «напоминать, чтобы подвигали задачи в таск-треккере». У него нет ни авторитета, ни признания.
  • Вторая попытка внедрить Scrum встречает бешеное сопротивление. «Мы  (или кто-то до нас) пробовали внедрить Scrum и через пару итераций поняли, что это фигня и не то, что нам нужно»
  • Виновных находят очень быстро. Менеджеры среднего звена «вдруг» вспоминают, что все они с самого начала не верили в эту затею, и делают крайними именно тех, кто проявил инициативу и решил «не сидеть на попе ровно» (С).
Мы считаем, что многие проблемы со Scrum-ом связаны со слепым копированием этого процесса. Люди не понимают, почему это работает, а просто выполняют ритуал.

Мы не хотим, чтобы проблемы пришли к вам, поэтому создаем видео-курс «Эмоциональный Scrum».

Узнать детали и стоимость курса вы можете ЗДЕСЬ


ПОПУЛЯРНОЕ

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

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

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

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

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn) Перевод с английского Неважно, насколько опытной является Скрам-команда, при этом всегда существует возможность для ее улучшения. Не смотря на то, что хорошая Скрам-команда будет постоянно искать возможности для своего улучшения, она должна выделять короткий период времени в конце каждого спринта для сознательного размышления над тем, как идут их дела, и для поиска способов их улучшения. Все это происходит во время Ретроспективы спринта.

Аджайл Менеджер Проектов – кто это?

Автор: Карлтон Неттлетон (Carlton Nettleton) Переведено с английского проектом Agile Translations . Несколько недель назад я получил сообщение от своего бывшего ученика с печальными новостями – его компания уволила всех Скрам-мастеров и заменила их на “Аджайл Менеджеров Проектов”. Теперь он остался без работы, а Cкрам потерпел серьезную неудачу в их организации. Это было довольно грустно :(

Какие проекты лучше всего подходят для применения Agile

Автор: Майк Кон (Mike Cohn) Переведено с английского проектом Agile Translations . Недавно меня спросили, для какого вида проектов больше всего подходит применение гибкого подхода разработки, и сейчас я хотел бы об этом поговорить. Мне кажется, самыми подходящими для использования гибких методик являются проекты с агрессивными сроками выполнения, высокой степенью сложности и так же высоким уровнем инновации (уникальности). Мы хотим использовать Agile, когда делаем что-то новое, по крайней мере, новое для конкретной команды разработки. Если команда делает то, что она уже делала не один раз, она, вероятно, не нуждается в гибком подходе. На мой взгляд, здесь было бы уместным привести аналогию с промышленным производством. День за днем, собирая один и тот же тип автомобиля, мы довольно быстро учимся всем нюансам сборки этой модели. Здесь нам не нужны гибкие подходы, потому что степень новшества данного процесса является довольно низкой. Однако, инновация сама по себе не означает, что