— Алексей, привет! У меня тут вопрос есть по твоей теме, а как внедрить Agile в небольшой команде для небольшого бизнеса?

— О! Это очень просто! Agile это про получение результата в соответствии с ожиданиями. Если не вдаваться в технические детали, то тебе подойдет процессный каркас - Scrum. Для начала тебе, как бизнесу, нужно поставить задачу команде: что ты хочешь на ближайшую неделю.

— Хорошо, это я умею.

— Но тут есть риск, что они могут понять тебя неправильно. поэтому лучше всего спросить: Расскажите мне, как вы планируете это делать?

Так, как слова имеют значение, то давайте для начала переведем названием Scrum Master (SM) буквально: "Хозяин Скрама". Непривычно да? Согласен! Однако, Скрам (Scrum)- это процессный каркас, поэтому предлагаю обобщить: "Хозяин процесса". Так чуть лучше, но предлагаю не использовать термин "Владелец процесса" здесь, так, как можно быть владельцем дома, но не быть его хозяином.

Колонка эксперта. Мы - как компания, и Я - как консультант часто провожу тренинги по управлению проектами в которых есть тема "про Agile". Но так, как "мой Agile" имеет элементы Теории Ограничений (как и в BIPULSE, и в Методе управления проектным бизнесом), управления проектами и учитывает реальность, что среда всегда много-проектная с множеством обязательств и "мой Agile" больше про бизнес, чем про инженеров. Я начал смотреть на Манифест с другой стороны.

Применяя любые управленческие подходы необходимо их применять осмысленно, а не просто потому что "это модно" и "это популярно", "это у ХХХ получилось". И если "Свод знаний по управлению проектом" это сборник лучших практик, где почти в каждой главе указано "выбрите нужные для вас", то такого нельзя сказать про адаптивные подходы (Agile-подходы). Поэтом давайте разбираться с Agile-подходами к разработке программного обеспечения, почему появились и в чём ключевые отличия.

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

Никакое ИТ решение не может реально помочь, когда нет подкрепления методологией обеспечения коммуникаций в компании или команде проекта и фокусирования целях. Поэтому, BIPULSE будет наиболее эффективен если следовать принципам Agile, Теории Ограничений Систем и Бережливого производства которые мы свели в 7 простых правил.

Что такого плохого в гибком (Agile) подходе к управлению проектом по разработке программного обеспечения? Особо ничего, если не считать того что завершение проекта в срок не стоит целью этой методологии.

Эта методология очень хороша для создания Продукта, особенно программного. Вы идете к Заказчику раз в две недели, показываете ему прототип разработанной ИТ системы, уточняете, что еще нужно докрутить, чтобы он был счастлив. Получаете порцию пользовательских историй и....планируете в спринт необходимость переписать половину архитектуры, ибо новые хотелки не стыкуются с уже написанным кодом.