jonka чайнюк оксана 1 vuosi sitten
134
Lisää tämän kaltaisia
система принципов, техник и процедур, использующихся специалистами, работающими в этой области.
рушит российский менталитет ТК РФ
человек в рамках рабочего дня может быть не загружен на 100%, то есть не все восемь часов cотрудник должен что-то делать.
большой уровень гибкости, можно уйти не туда
обеспечение качества
быстрое понимание узких мест системы
визуализация потока предоставления ценности
визуализация всех этапов разработки продукта от грустного клиента к довольному.
цель - получать готовый качественный продукт вовремя
недостатки
плохо подходит для больших команд
требует дополнительной роли scrum - мастера
если известны все требования к продукту - нецелесообразно
страх отпустить вожжи
требуется экспертиза в команде
преимущества
подходит для всего
легко маштабируется
легко адаптировать продукт к рынку
работающий улучшенный продукт после каждой итерации
самоорганизованные команды
основные элементы
Sprint Burndown Chart
диаграмма, которая обновляется по мере завершения задач. по ней легко понимать динамику и уровень продвижения команды в проекте.
Sprint Goal
цель спринта
Sprint Backlog
список требований, которые нужно выполнить в ближайший спринт
Product Backlog
список требований к проекту
ключевые шаги в технологии
проведение ретроспективы
проведение обзора рабочих частей продукта
организация ежедневных пятнадцатиминутных "мин-апов"
планирование спринтов
составление эклог продукта
поиск скрам-мастера
сбор команды проекта
выбор владельца продукта
нужна документация по всем процессам
бюджет ограничен
продукт должен быть создан к конкретному сроку
компания не готова тратить доп ресурсы на налаживание коммуникаций
продукт разрабатывается в сфере, подверженной постоянным изменениям
заказчик выступает в качестве партнера
нужно быстро получить рабочую версию
работает опытная команда
start -up
команда не может механически применить инструменты "гибкой" разработки, необходимо принять ключевые принципы системы
Эта ценность прежде всего характеризует Agile-управление проектами. Agile-команды чутко реагируют на изменения и успешно адаптируются к новым условиям и вызовам.
Agile-команды любят сотрудничество — включая регулярные обновления и обратную связь о том, как продвигается проект, от клиентов и заинтересованных сторон. Чего Agile-команды не любят, так это долгих согласований объемных контрактов.
Agile-команды не очень любят бумажную работу. Для управления данными, отчетами и обновлениями статуса они предпочитают использовать гибкие программные решения, а не традиционную документацию.
То, что общение и межличностные отношения важнее, чем строгие процессы — краеугольный камень Agile-управления проектами. Agile рекомендует персонализированный подход к управлению проектами, когда команды ориентируются на постоянное общение, а не на жестко распланированный выпуск обновлений.
Непрерывное совершенствование — сама суть Agile, и регулярные проверки эффективности команды в целом могут помочь избавиться от вредных привычек и добиваться бо́льшего.
Лучшие команды — это те команды, у которых есть лидер, предоставляющий им свободу самовыражения. Микроменеджмент редко делает команды лучше или продуктивнее, и Agile-команды — отличный пример того, чего можно добиться без микроменеджмента.
Команды Agile не занимаются переусложнением — они просто соблюдают проектные требования и хорошо выполняют свою работу, а затем переходят к следующему проекту.
Agile не работает по принципу «раз — и готово». Каждый новый проект — это возможность для инноваций, а не для повтора одних и тех же идей.
Смысл принципа, который называет работающий продукт основным показателем прогресса, в том, что главная цель команды всегда остается одна — предоставить клиенту как можно более высококачественный результат. Когда клиент доволен, это и есть главный показатель успеха проекта.
Все мы знаем, что главное в управлении проектами — личное сотрудничество. Этот принцип применим и во времена «новой нормы», при гибридных и удаленных моделях работы. Zoom и Teams — отличная альтернатива телефонным звонкам и электронной почте, а в ключевых точках проекта возможны и личные встречи команд.
Agile-команды успешны, потому что в них работают только те люди, которые необходимы для проекта. Если участники Agile-команды получат поддержку, возможность работать вместе и инструменты, необходимые для работы, все остальное приложится.
Сотрудничество — краеугольный камень Agile, причем имеется в виду не только сотрудничество между членами команды, но и сотрудничество с заинтересованными сторонами, разработчиками, клиентами и другими партнерами.
Вспомним, что Agile-команды ценят постоянное общение, а не жестко распланированный выпуск обновлений, которые могут слишком далеко отстоять друг от друга по времени, что может оказаться неприемлемым для клиентов. Команды Scrum, которые тоже работают по методологии Agile, разбивают свою работу на периоды от одной до четырех недель, известные, как спринты.
В этом их преимущество перед традиционными командами, которым обычно не так легко управлять изменениями.
Главное для Agile-команды — удовлетворенность клиентов, поэтому они обязательно представляют результаты своей работы через регулярные промежутки времени, а не заставляют заказчиков ждать финального результата в конце проекта.
этапы планирования и определения требований выполняются согласно методологии водопада, а этапы проектирования, разработки, внедрения и оценки соответствует гибкому подходу
финансовые ресурсы не являются ключевым ограничением
компания не уверена в концепции
компания хочет создать инновационный продукт или крупный проект
создание бизнеса на соблюдении строгой последовательности выполнения задач
нет ограниченности во времени
есть четкая концепция продукта
большая часть или вся работа над проектом проводится на аутсорсе
И, наконец, когда всё протестировано и отлажено, переходят к последнему этапу, в рамках которого сдают проект заказчику, устанавливают, внедряют — в общем, вводят продукт в эксплуатацию. Кроме того, сюда может входить и последующее сопровождение, и поддержка, в том числе техническая.
На этом этапе проводят полноценное тестирование продукта, чтобы найти и исправить критические (и не очень) проблемы.
Затем команда окончательно проясняет, как именно будет происходить разработка проекта, с помощью каких инструментов (языков программирования, оборудования, сервисов и т. д.). Каркас, который проработали на предыдущих этапах, становится более целостным, потихоньку формируется облик продукта. На этот этап приходится большая часть работы над проектом.
Когда первая версия ТЗ готова и есть общее понимание, что нужно сделать, команда приступает к проектированию — детализирует ТЗ, согласует с заказчиком логику работы системы, описывает, что и как будет работать. На выходе этого этапа всё ещё не проясняется вопрос реализации, но уже становится примерно понятно, сколько нужно людей и часов на работу.
Самый первый этап, во время которого определяют и анализируют требования проекта: системные требования, требования к ПО, пожелания заказчика и т. д. и т. п. На основе всей этой информации создают входную документацию, где описывают, что должно получиться в итоге (не важно, что это будет — софт или авианосец), но не то, как именно это всё нужно будет делать. Короче, на этом этапе пишут первую, обобщённую, версию ТЗ.
