люди и отношения важнее задач и инструментов;
процесс работы над проектом важнее рутины с документацией;
сотрудничество с клиентами важнее, чем формальные отношения;
важно уметь быстро реагировать на изменения в проектах и задачах.
.
постоянно отдавать программы заказчикам;
если заказчик меняет требования к программам даже перед завершением работы, надо работать с этими требованиями;
отдавать работающие программы в короткие сроки;
общаться с заказчиком каждый день, пока идет работа над проектом;
лучший способ общения с работниками или заказчиком — личные встречи;
работать с единомышленниками и создавать для них условия, которые помогут расширять и углублять знания и развиваться как профессионалы;
чем больше работающих программ, тем успешнее разработчики;
гибкий подход в разработке программ помогает развиваться разработчикам;
уделять внимание качеству в технических разработках и дизайне;
способность не делать лишнего — важный навык управления;
самоорганизованные команды создают лучший дизайн;
каждый работник команды сам выстраивает рабочий процесс и думает, как повысить эффективность.
.
Есть задача, под которую собирают команду. Как правило, на одном проекте работает 5−10 человек: это владелец продукта, он же заказчик; скрам-мастера, то есть люди, которые следят за выполнением задач и сроками; разработчики — те, кто будет создавать программу или продукт.
Задачу разбивают на этапы и временные отрезки, за которые эти этапы будут готовы. А общее время, которое команда потратит на проект, называется спринт. Спринт делится на несколько этапов.
Команда разрабатывает бэклог продукта — это то же самое, что техническое задание. В бэклоге прописывают задачи от важных до самых простых и проставляют время, которое готовы потратить на решение.
Каждый день команда проводит планерки или митинги, стендапы, где обсуждают три вопроса: «Что делали вчера?», «Что планируете делать сегодня?», «Почему не получилось выполнить задачу раньше?» Ответы на эти вопросы помогают лучше разобраться в проблемах, которые мешают вести проект.
После каждого этапа команда подводит итоги и решает, что получилось и можно ли показывать продукт. Такие промежуточные итоги называются инкрементами.
.
Начать сейчас. Прежде чем вводить новое, сначала надо проанализировать, что работает в текущих процессах, а что не очень.
Постепенно вводить изменения. Согласно этому принципу, нельзя резко вносить изменения в процесс, к которому привыкли сотрудники и руководство. Новый метод вводят постепенно, в удобном для людей темпе и наблюдают, как это влияет на работников, взаимодействие с клиентом и конечный продукт.
Уважать сотрудников, их должности и обязанности. Метод канбан не призывает к изменениям в кадрах, поэтому не нужно менять команду. Лучше вносить изменения с теми сотрудниками, которые есть, обучать их, давать возможность поработать с новыми правилами. Работники со временем смогут рассказать, какие новшества не очень хорошо работают, а какие сделали работу лучше.
Поддерживать работников в их желании привносить новое. Не только руководство может предлагать новые методы, но и сотрудник на любой позиции должен иметь возможность внести новые идеи.
.
Сделать наглядными рабочие процессы. Для этого создают доски с карточками — физические или виртуальные. По мере продвижения задач карточки переставляют на другие этапы.
Ограничить количество текущих задач. Если команда тянет пять задач, значит, надо заниматься ими, а потом брать новые. Не стоит нагружать команду — лучше поискать способы побыстрее закрыть незавершенные задачи.
Отслеживать поток работы. Следить, чтобы количество задач было посильно работникам, и решать сложности, которые могут помешать выполнить работу.
Прописывать четкие инструкции по работе с проектом. Важно, чтобы люди понимали, что от них хочет заказчик, где начало работы — пункт А, какая итоговая цель — пункт Б. Сам маршрут из пункта, А в пункт Б должен быть прописан подробно.
Получать обратную связь от работников и заказчиков. Чтобы понимать, как двигаются проекты, какие есть сложности, а с чем работники справились быстро, собирают планерки и обсуждают каждый вопрос отдельно. Можно получать информацию без планерки: например, работники могут составлять отчеты один раз в неделю или в месяц.
Развиваться команде и каждому сотруднику.
.
если в команде понимают суть методологии аджайл и готовы работать в ней или учиться этой гибкой системе. Понимают, зачем это надо и как можно применить модели и методы аджайла;
клиент хочет, чтобы процесс работы над проектом был прозрачным, и готов участвовать в обсуждении работы надо проектом на каждом этапе. Если клиент не готов работать по аджайл, а хочет поставить задачу и получить через определенное время готовый продукт, тогда надо поискать другую систему работы над проектом;
участники команды из разных отделов готовы работать вместе над одним проектом, встречаться каждый день на планерки или выходить на видеоконференции, чтобы обсуждать проект. Если между отделами компании есть разногласия или кто-то из команды не может быть на планерках, тогда стоит подобрать другой способ работы;
не хочется заниматься многостраничными отчетами. В системе аджайл один из принципов призывает к сокращению документации, чтобы не тратить на это много времени.
.