Можно ли начать следовать стилю Agile PM до того, как мы пройдем формальное обучение? По-другому этот вопрос был сформулирован так: можно ли использовать такие инструменты, как Pivotal, предназначенные для Agile, еще до того, как мы формально приступим к обучению Agile?
Я слышал/видел множество команд, которые пытались использовать Agile, но в конечном итоге возвращались к водопаду, и это было потому, что команда никогда строго не следовала Agile.
В качестве фона мы (старшие разработчики) решили взять на себя задачи PM в первую очередь потому, что компания решила покончить с ролью PM/AM в проекте (много противоречий, мы недовольны этим, но это что-то нам с этим жить). Обычно клиенту предоставлялась возможность управлять проектом в своем стиле, но мы, разработчики, сочли это катастрофическим. Поэтому мы почувствовали, что нам нужно вернуть процесс управления проектами, чтобы сохранить некоторые стандарты и здравомыслие.
Мы и раньше участвовали в Agile-подобных проектах, но никогда не были «мастером схватки» или человеком, который управляет всем процессом. И мы никогда не проходили формальное обучение этому — обычно мы оставляли менеджера проекта для управления ресурсами и приоритезацией функций, в то время как мы занимались фактической работой разработчиков.
Насколько я знаю, официального обучения по Agile не существует.
Agile — это набор из 4 ценностей и 12 принципов, изложенных в манифесте Agile . Если вы согласны с ними и применяете их в своей работе, вы «проворны».
Обучение, которое я видел, проводится по конкретным методологиям (Scrum, Lean...). Я предлагаю вам пройти обучение или инструктаж, прежде чем пытаться их реализовать, потому что их реализация довольно сложна. Это применимо, если вы работаете в негибкой среде. Если компания уже практикует их, просто следуйте им, это не так уж и сложно — трудная часть — это переход от одного стиля работы к другому.
По моему опыту, их хитрость заключается не в том, чтобы «пристально следовать» методологии, а в том, чтобы глубоко понять, в чем смысл или причина каждой ее части. Команде не обязательно быть идеальной, чтобы добиться успеха, но, как правило, скрам представляет собой набор очень важных и полезных практик, которые напрямую связаны с принципами Agile.
Их изменение может потребоваться в зависимости от ситуации, но в большинстве случаев это сделает вашу команду менее гибкой.
Я бы сказал, что да. На самом деле многие компании пробуют agile без специального обучения.
Я бы сказал, что наиболее важным является общее видение внутри команды проекта. Если вы собираетесь работать гибко, привлекайте клиентов. Каждый раз, когда я видел провал Agile-проекта, это происходило потому, что разработчики или ИТ-специалисты думали, что они работают одним способом, а заказчик (внутренний или внешний) полагал, что они работали иначе, или просто не понимали, что такое Agile.
Относитесь к Agile-обучению как к части самого проекта. Пусть они знают, что это опыт обучения для всех.
Приобретите книгу, например Agile Samurai, которая ясна и лаконична. проведите внутренний семинар, чтобы обсудить, как вы, как проектная команда, собираетесь работать, а затем попробуйте!
В конце итерации проведите честный обзор того, как работает «проект». Что сделано хорошо, что можно улучшить.