Участники:
Андрей Степанов, Асхат Уразбаев, Денис Миллер, Никита Филиппов
Темы
* Жизненный цикл.
* Этапы разработки в Agile.
* Почему Agile не получается и проваливается?
* Политика и эффективная работа.
* Внедрение сверху и внедрение снизу.
* Боевой пример: советы по внедрению Agile в стартапе (приглашенный гость)
* Вредные советы.
Ждём ваши комментарии и вопросы. Будем отвечать и обсуждать в Agile Podcast!
Прямая ссылка на Звук
Ссылка: http://agilepod.ru
1 коммент.:
Сложилось впечатление, что на вопрос Андрея (что же ему делать с изменяющимися требованиями в start up проекте) так толком и не ответили (и к сожалению, у слушателей может сложиться впечатление, что agile не пригоден для start up проектов). Хочу высказать свое мнение. Начнем с самой проблемы... так понимаю, что проблема не в том, что требования меняются быстро (Асхат предложил решение - еще короче итерации или вообще отказ от них и переход на канбан... Андрей очень вяло отреагировал на это предложение, т.е. это не его проблема), а проблема в том, что требования меняются координально (типа статический сайт и вдруг полноценный портал на CMS или каталог товаров с корзиной). Это первая проблема. Вторая проблема (проскочила вскользь) - Андрей путает понятия задачи и фичи (Асхат поправил Андрея, что в продукт back log-е должны быть фичи, а не таски... и через пару секунд Андрей опять начал говорить про таски в back log-е). Третья проблема - Андрей не совсем понимает зачем роль product owner существует и зачем нужен вижен. Для решения второй и третьей проблем порекомендовал бы перечитать (если уже читал) "Scrum And XP From The Trenches" (есть на русском)... или сходить на тренинг к Асхату ;-). А вот для решения первой проблемы - надо вводить proxy-product owner. В оригинале методики такой роли нет, но когда заказчик не может выполнять эту роль (похоже это кейс Андрея), приходится ее вводить в команде. Это должен быть человек, который бы "сглаживал" для команды "колебания" требований от инвестора (путем более глубокого понимания целей проекта, возможных направлений развития, умения предложить и отстоять свою точку зрения... естественно, для этого нужен опыт в подобных проектах). Вариант (который Андрей озвучил), что эту роль сейчас выполняет архитектор системы - не верен. Т.к. архитектор (обычно) технический человек... он "думает решениями", т.е. скажи ему, что надо сделать - он без проблем предложит решение. А тут нужны совсем другого плана знания и умения - тут надо понимать бизнес... уметь задавать три раза подряд вопрос "зачем?" :-)На эту роль больше подходят бизнес аналитики (если говорить терминами waterfall). Т.е. в случае Андрея, проблема не в методологии (что она не применима для старт-ап проекта), а в том, что методологию не дочитали или недопоняли (да... она кажется простой, но за простотой скрывается глубокий смысл каждой проктики). Похоже команда "кидается" выполнять задачи (!), не видя куда вообще проект должен придти (т.е. получается code & fix). Естественно, что в таких условиях планировать ничего не получается даже на неделю... и task board становиться не инструментом для управления тем, что надо сделать сейчас, а "игрушкой програмистов"). Кроме того, назначение архитектора product owner-ом, отсутствие вижина (не как такового, а как практики... т.е. понятия куда проект движется), не понимание разницы между фичей и таском и приводит к ощущению, что это Agile (scrum) не работает :-). Надеюсь, Андрей перечитает описание Scrum методики и попробует найти "настоящего" product owner и все у него наладится в команде, о чем и расскажет всем слушателям :-)
Отправить комментарий