Портал №1 по управлению цифровыми
и информационными технологиями

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

Agile

5 спорных моментов, убранных из Scrum

Сам по себе фреймворк Scrum уже давно перестал быть инновацией. Появившись задолго до подписания Agile-манифеста, Scrum сегодня неразрывно связан с миром гибких подходов. Основой фреймворка уже довольно давно является “Руководство по Scrum” (Scrum Guide). С момента своего появления этот документ довольно сильно изменился. В своей статье голландский специалист Вилем-Ян Агелинг рассказывает о пяти спорных моментах, выпавших из руководства по Scrum за эти годы. Если вы перешли на Scrum пять или более лет назад, то ваше понимание Scrum отличается от того, которое существует сегодня. Есть много вещей, которые когда-то определялись как Scrum, даже упоминались в руководстве по Scrum, но в какой-то…

У скрам-мастера нет ответственности за поставку

Очень часто встречается проблема в понимании ролевых механик  фреймворка Scrum. С одной стороны, у нас есть “командная ответственность” – парадигма, расширяющая ответственность каждого участника процесса за пределы выполнения своей функции и наделяющая его ответственностью за результат в целом. С другой стороны, у нас есть участник скрам-команды (роль), который не несет ответственности за поставку. Речь идет о скрам-мастере, который, на первый взгляд, отвечает только за то, чтобы в команде был Scrum, и не обременен другой ответственностью. Давайте посмотрим, как объясняет эту особенность роли скрам-мастера Уильям-Ян Агелинг в своей статье “A Scrum Master Has No Delivery Responsibility” Один из моих коллег недавно…

Ускорение без новых людей и овертаймов

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

Скрам игнорирует качество?

Проблема отношения к качеству в гибких управленческих практиках существует давно. Миф о том, что в Agile некогда делать хорошо потому, что нужно делать быстро, оказался на удивление живучим. Адепты этой точки зрения последовательно игнорируют весь содержащийся в гибких практиках инструментарий по управлению качеством и сложившуюся инженерную культуру. Донесение до команд правильной концепции управления качеством приводит к диалогам наподобие описанного в статье Уильяма-Яна Агелинга Карла – разработчик в скрам-команде, испытывающей определенные затруднения. Наши сыновья играют в одной футбольной команде и когда мы смотрели их игру, она решила обсудить эти проблемы со мной. Карле известно про мою увлеченность скрамом, поэтому она использует…

Ежедневный скрам – бесполезная потеря времени?

Довольно часто на начальном этапе работы с разными командами приходится сталкиваться с сопротивлением по отношению к ежедневным собраниям. Разработчики не видят ценности в ежедневном стоянии у доски, зачастую им кажется, что это время стоит потратить на что-то более ценное (написание кода, например). Вот как подходит к донесению ценности регулярных собраний Марк Левинсон. Ежедневный скрам – это пустая трата времени, прерывающая мою работу. Ежедневный скрам – шанс для скрам-мастера проявить себя и позаниматься микроменеджментом. Ежедневный скрам предназначен для сообщения о статусе задач, но для этого я могу воспользоваться электронной почтой. Эти жалобы звучат так знакомо. Сейчас очень модно шутить над бесполезностью…

Волшебство коротких пользовательских историй

Итеративные подходы к разработке продуктов требуют декомпозиции и работы с маленькими частями. Это улучшает производительность и управляемость. Несмотря на то, что выгода от такого подхода кажется очевидной, команды раз за разом стараются решить все проблемы в одной задаче, а заказчики пытаются впихнуть все требования в один спринт. Аджайл коуч Дуайт Кингдон, в своей статье собрал основные аргументы в пользу разумного уменьшения размера пользовательских историй, с которыми работают команды, и изложил свой подход к уменьшению размера этих историй. Я часто сталкиваюсь с командами, которые любят большие пользовательские истории. Зачем тратить время на написание, планирование и оценку множества маленьких историй, когда вы…

Почему многие скрам-мастера обречены на провал.

Недавно в статье о запросах на лидерство от команды, раскрывалась тема применимости служащего лидерства в работе с самоорганизованными командами. Сегодня вашему вниманию представляется мнение Мартена Далмайна о роли лидерских и коммуникационных навыков и их влиянии на успешность работы скрам-мастера. Если вы видели начало работы по скраму в какой-либо компании, то наверняка знаете, как это бывает. Компания, познакомившись со скрамом, внезапно понимает, что необходим скрам-мастер (примечание переводчика: обычно «внезапно» скрам-мастеров требуется сразу несколько) Далее компания спрашивает новоиспеченную скрам-команду: «Кто из вас будет скрам-мастером?». Обычно, среди разработчиков находится храбрец готовый сделать шаг вперед со словами: «Я буду скрам-мастером!» Но одно дело иметь…

Нужен ли хорошей команде тимлид?

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

Заблуждения и мифы о Канбан-методе

Вокруг любого управленческого подхода со временем выстраивается огромное количество заблуждений и мифов. Это обусловленно особенностью людей по-разному понимать одни и те же вещи и желанием интерпретировать факты в своих интересах. Канбан, как метод определения, управления и совершенствования сервисов, при разработке интеллектуальных продуктов, сравнительно молод, но уже успел обзавестись своей мифологией. Разработчики Kanban Tool (инструмента для визуализации потока) в своем блоге постарались разобрать наиболее распространенные мифы, возникшие из-за неправильного понимания принципов Канбан. «Канбан на самом деле не метод организации рабочего процесса, а инструмент улучшения рабочего процесса.» Часто говорят, что Канбан – это инструмент для создания знаний, а не метод управления рабочим…

SAFe – это троянский конь?

Крис Матц (Chris Matts) на днях опубликовал в своём блоге заметку с забавными, витиеватыми рассуждениями о том, является ли SAFe троянским конём («SAFe is the Trojan Horse»). SAFe, Scaled Agile Framework – методология масштабирования Agile (речь идёт о попытке масштабировать гибкие подходы на всё предприятие) Далее – краткий пересказ заметки Криса. Нередко я слышу, что Agile-коучи отзываются о SAFe как о троянском коне. Так и есть. Только не в том смысле, который они имеют в виду. Они ошибочно полагают, что SAFe – это легальный способ проникновения Agile-практик в организацию. Они думают, что как только Agile-практики заработают, организация осознает ограничения SAFe…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;