Статьи про IT

Менеджмент

Какой из следующих сценариев эффективнее? Когда все участники команды работают совместно в одном офисе, в одни и те же часы, общаются, обсуждают проблемы, одним словом варятся в общем котле текущего проекта? Или напротив - когда каждый работает там и тогда, когда это будет удобно, выбирая для себя наиболее комфортный и эффективный реим?

Как обычно - однозначного ответа тут нет. У каждого подхода есть свои плюсы и минусы, кому-то подходит один вариант и противопоказан другой. Хочу поделиться статьей, в которой рассмотрены аспекты каждого из подходов и сделаны выводы на тему организации гибкого рабочего процесса.

Все подробности в статье: https://vervoe.com/blog/flexible-working-productive-or-destructive/

В этой короткой статье я хочу собрать воедино примеры наиболее популярных техник, которые помогут оценить масштабы проекта, сделать верхнеуровневую оценку по времени и примерно посчитать бюджет. Речь будет идти не о точной, а об индикативной оценке, часто она нужна, когда обсуждается новая инициатива, общие рамки проекта и еще нет формализованных требований.

Impact Mapping является эффективным методом планирования для разработки ПО, развития продуктов и проектов. Он дает возможность построить мост от высокоуровневых стратегий и концепций бизнеса к реальным возможностям реализации и конкретным задачам на стороне ИТ.

Impact Mapping позволяет организациям и командам при разработке продуктов и выполнении проектов всегда держать в фокусе действительные бизнес цели, согласовывать с ними свою деятельность, а значит и принимать более эффективные решения. Разберемся что из себя представляет данный метод, как его применять.

Один из основных и обязательных артефактов в Scrum, это бэклог задач. Фактически это список требований полученных от бизнеса и сформулированных в виде задач на разработку. Однако, сам по себе список всех задач еще не несет большой ценности, если он не привносит какой-то системы и структуры. Очень важным будет грамотная работа с бэклогом с тем, чтобы задачи в нем были актуальными, можно было провести их сравнения с точки зрения размеров и важности. Именно для этого и необходим Backlog Grooming, далее в статье разберемся как его организовать и провести.

Первый и, возможно, самый главный этап работы с Product Backlog в Agile заключается в декомпозиции задач, разбиении разноплановых требований на атомарные, понятные пользовательские истории (User Stories). Чем качественнее разбиты требования, тем понятнее их смысл и способы реализации, а также тем точнее можно запланировать время работы над ними. Чем задачи, тем выше шансы достичь целей спринта, тем более прогнозируемые составы релизов.

Как же провести декомпозицию требований в Product Backlog? Рассмотрим 8 техник, которые помогут эффективно выполнить разбивку требований на User Stories. В работе по Agile большим плюсом будет одновременное применение нескольких вариантов декомпозиции, поэтому важно представлять спектр возможных методов.

Очень важным этапом работы с Product Backlog является выстраивание задач в порядке их приоритета. Когда мы провели декомпозицию и оценили пользовательские истории необходимо определить, в какой последовательность будет проходить реализация задач, что будет выпущено в первой версии продукта, что может быть включено в последующие поставки, а что может быть оставлено на тот случай, если останется время. Как же определить, что брать за основу при выстраивании приоритезированного списка User Stories?

Подкатегории

О проекте

  • Проведение тренингов и вебинаров: QA, Time management, People management, Agile
  • Консалтинг в области организации рабочих процессов в ИТ
  • Проведение и подготовка к собеседованиям

Информация об авторе проекта

 

Контакты

Skype: xpavnov

E-mail: xpavnov@gmail.com

VK: https://vk.com/doitsmartly

Группа вконтакте

doITsmartly©2024
Яндекс.Метрика

Search