В данном разделе собраны все заметки из других разделов, которые могут пригодиться Вам при работе по гибкой методологии, а также некоторые уточнения и комментарии к ним. При желании подробнее ознакомиться с методологией Agile вот тут курс.

Вводная

Agile — это итеративный подход к управлению проектами и разработке программного обеспечения, который помогает командам быстрее и с меньшими трудностями приносить пользу своим клиентам. Вместо того, чтобы делать ставку на «big bang», agile-команда выполняет работу небольшими, но расходными частями.

Согласно модели Херши-Бланшара, существует 4 стиля лидерства(S) и 4 стиля готовности(R).

S1 R1 Директивный (Разработчикам ставятся четкие задачи,нужно полное погружение в проект)

S2 R2 Наставнический (Вы приходите с несколькими решениями по проблеме и получаете от команды обратную связь о рисках, сроках итд)

S3 R3 Поддерживающий (Есть проблема - команда предлагает решение. Вы выбираете)

S4 R4 Делегирующий (Вы приходите с проблемой, разработчики полностью сами принимают все решения. Нет необходимости быть погруженному в системный контекст)

Соответственно, даже если вы работаете по гибкой методологии разработки, но команда у вас типа S1 R1, то при разработке требований вы все равно будете задавать требования на низком (системном) уровне. В случае команды типа S4 R4 некоторые требования могут быть более верхнеуровневыми и не расписываться до системного уровня, так как основной задачей документации НЕ является доведение её до идеала, а прежде всего выполенение своего предназначения. Но это не отменяет проверки на полноту функций и данных.

Концепция системы:

Существует несколько подходов разработки концепции для системы:

Концепция разрабатывается для всей системы, а техническое задание разрабатывается на итерацию по реализации.
Концепция разрабатывается на объем итерации.
Гипотетическая концепция, существующая еще до этапа предварительного обследования, которая может быть уточнена на этапе разработки ТЗ, например в стартапе

Первые два подхода используются при разработке по Agile.

Первый подход более консервативный, и позволяет оценить всю систему сразу. Лучше подходит при стабильном проекте с понятным вектором движения. Обычно, с длинными спринтами.

Второй подход больше подходит при постоянном изменении вектора движения, ориентированности на пользовательские потребности и обычно короткие спринты. А также, когда систему можно разделить на логически понятные “модули”.

Заметка к контекстной диаграмме.

В случае существующего ПО, существует 2 способа работы над контекстной диаграммой:

Доработка существующей контекстной диаграммы, путем изменения модельного соглашения для новых потоков данных и взаимодействующих с проектируемым объектом элементов окружения (например, новые потоки могут обозначаться стрелками синего цвета). Минус: нагруженность диаграммы может мешать восприятию. Данный способ не очень подходит для Agile, особенно с короткими итерациями, так как нужен анализ всей концепции сразу.