Что такое гибкая разработка?
Гибкая разработка - это подход к разработке программного обеспечения, который фокусируется на быстром развертывании функций с постоянными итерациями на основе межведомственных консультаций и отзывов пользователей. Это структура управления проектами, основанная на постепенных разработках на каждом этапе тестируемого процесса и основанная на следующей итерации или повороте продукта на обратной связи или результатах конечных пользователей.
Карты-истории и гибкая разработка
Понимание того, что такое гибкая разработка, - это только начало. Важной частью является включение ее в вашу бизнес-практику. Отличный способ внедрить гибкий подход в практику управления проектами - связать визуальные элементы с гибкой разработкой. Один из распространенных визуальных элементов, с которого следует начать, - это карты пользовательских историй . Карты пользовательских историй - это визуальные изображения пользователей, взаимодействующих с вашим продуктом, а также реакции или действия, которые ваш UX вызывает у пользователей, когда они работают над достижением цели или задачи. Создание карт-историй для ваших пользователей вынуждает вас разбивать продукт на поэтапные этапы, позволяя сосредоточиться на том, как итеративные изменения могут применяться к каждому этапу независимо для улучшения продукта в целом. Карты-истории могут принимать разные формы: линейные путешествия пользователя по вашему продукту, нелинейные циклы или даже графики, отображающие время или приоритет по оси x и сложность задачи по оси y.
Типы гибкой разработки
Scrum
Scrum - это методология гибкой разработки, которая фокусируется на распределении задач проекта по времени в спринты (обычно длительностью от 1 до 4 недель) и позволяет разработчикам внедрять новые функции с заранее определенной частотой. Типичные практики организаций, использующих scrum, - это ежедневные встречи, стартовые встречи спринтов и обзоры после спринтов.
Канбан
Канбан - это методология гибкой разработки, которая включает в себя визуальный список приоритетных задач, которые необходимо выполнить для завершения проекта. Как только эти задачи выполнены, они выпускаются, что приводит к непрерывным итерациям и выпускам продукта. Разработчики могут выбирать задачи, наиболее тесно связанные с их областью знаний, и задачи, которые не ограничены по времени.
Как создать карту-историю для Agile
-
Изолировать проект
Первый шаг во внедрении практик гибкой разработки - это выбор проекта для работы. Гибкая разработка лучше всего работает в сложных проектах с большим количеством движущихся частей. Выберите проект, который может потребовать межведомственного сотрудничества и создания / внедрения ряда новых функций. Затем выберите мастера схватки , человека, который будет следить за тем, чтобы проект продвигался по плану.
-
Создать журнал невыполненных задач
Следующим шагом является создание списка всех необходимых задач, которые потребуются проекту для завершения. После того, как все задачи будут перечислены, распределите их по важности и приоритету. Часто возникают задачи, которые невозможно выполнить, не выполнив в первую очередь одну из других невыполненных задач - это должно быть учтено в вашем списке приоритетов. Список задач будет меняться и расти на протяжении всего гибкого процесса по мере того, как вы осознаете больше задач, которые необходимо выполнить, и, с другой стороны, осознаете, что некоторые задачи не нужны.
-
Разделите на спринты или создайте доску Канбан
Теперь пора решить, какой у вас подход: Scrum или Kanban. Если вы решили использовать Scrum, разделите списки задач на отдельные спринты. Ограничьте свои спринты максимум четырьмя неделями разработки, но стремитесь примерно к двум неделям. Это сократит объем вашего проекта и заставит разработчиков работать над наиболее важными задачами. Если вы используете Канбан, создайте доску Канбан со всеми невыполненными задачами. Попросите разработчиков подойти к доске и физически выбрать задачу, которую он будет считать своей собственной. Переместите задачу по доске от «To-do» к «Doing», к «Done».
-
Принимайтесь за работу
Начать работать! Когда разработчики и маркетологи начинают вместе работать над поставленными задачами, полезно проводить ежедневные быстрые встречи. Эти встречи не должны длиться более 10 минут, и каждый участник должен ответить на три основных вопроса: Что вы делали вчера? Что ты сегодня делаешь? Есть ли что-то, что мешает вам выполнить ваши задачи сегодня?
-
Обзор проекта, процесса и повторения
После завершения спринта или развертывания новой функции проверьте проект, чтобы убедиться, что он приемлем для взаимодействия с пользователем. Также важно проанализировать процесс в целом и активно искать способы повышения эффективности или производительности процесса. После того, как все это будет сделано, повторите с самого начала для следующего проекта или набора функций.
Шаблоны Agile для начала работы
© 2024 - Clever Prototypes, LLC - Все права защищены.
StoryboardThat является товарным знаком Clever Prototypes , LLC и зарегистрирован в Бюро по патентам и товарным знакам США.
