kazminaviktoriya1
Перейти в профиль
Выйти из профиля
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
О чём этот спринт
День в RANA.Software начался с сюрприза. Айгуль и Даня продолжали работу над приложением для сети клиник «Вита» имени Е. Л. Яницкой, когда в офисе появился Артём. Он только сегодня вернулся с семидневного тренинга по гибкой модели разработки ПО. Артём даже не стал заезжать домой, чтобы оставить чемодан, примчался сразу из аэропорта — ему не терпится поделиться с командой своей идеей!
В этом уроке вы узнаете, что важно учитывать системному аналитику при переходе от каскадной модели разработки ПО к гибкой и какие гибкие техники стоит использовать.
Разработке ПО сопутствует высокий уровень неопределённости. В начале этого процесса неопределённость связана с:
- Продуктом — то есть с тем, что команде предстоит реализовать, с функциями ПО;
- Проектом — то есть с тем, как эти функции будут реализованы.
Чем выше неопределённость, тем больше команде подходит гибкая модель разработки ПО (Agile), так как она помогает с этой неопределённостью справиться. А в каскадной модели разработки (Waterfall) неопределённость практически не учитывается.
Каскадная модель
Каскадная модель разработки ПО не принимает во внимание неопределённость, связанную с продуктом. Она предполагает, что разработанные в начале процесса требования — это окончательные характеристики продукта, пользователи не изменят их, не предложат новые и не откажутся от выявленных.
Каскадная модель не учитывает и неопределённость, связанную с проектом. Она предполагает, что до начала реализации команда разработки способна в деталях определить, как именно она реализует функции ПО, и может дать точную оценку сроков выполнения проекта.
Гибкая модель
Неопределённость, связанная с продуктом
Гибкая модель учитывает неопределённость, связанную с продуктом. Пользователи заранее не знают, какие именно функции им нужны, поэтому они неизбежно в ходе разработки предлагают новые идеи и отказываются от старых.
Вместо того чтобы передавать ПО пользователям в самом конце, команда разработки в течение всего проекта реализует только небольшие части этого ПО и регулярно показывает их пользователям.
Увидев часть ПО, пользователи дают обратную связь, и команда может изменить уже реализованные функции, добавить новые или удалить ненужные.
Неопределённость, связанная с проектом
Гибкая модель учитывает и то, что команда разработки не знает точно, как она реализует функции, до тех пор пока не приступит к их реализации.
Итерации должны быть короткими: от двух до четырёх недель. Они ограничиваются по времени, то есть завершаются в срок, даже если команда не успела реализовать несколько функций. В конце каждой итерации команда передаёт пользователям реализованные функции и получает от них обратную связь, которую будет учитывать в следующей итерации.
Вместо скрупулёзного написания требований к ПО, тщательного проектирования пользовательского интерфейса и архитектуры команда в каждой итерации параллельно с реализацией функций проводит необходимую для этого подготовку — маленькими порциями.
Определение сроков проекта
Наконец, гибкая модель учитывает, что команда не может точно оценить сроки выполнения проекта. Это происходит потому, что некоторые возникающие в процессе разработки проблемы невозможно предсказать.
Вместо гадания на кофейной гуще команда определяет примерный объём функций, реализуемых в каждой итерации, и вычисляет темп реализации. А на основании примерного объёма оставшихся функций и темпа своей работы она после каждой итерации пересматривает сроки выполнения проекта.
Разработка короткими итерациями и отсутствие долгой подготовительной работы в начале проекта — это особенности гибкой модели, которые стоит учитывать системному аналитику.
Что важно учитывать в гибкой модели
Если команда выбрала каскадную модель, то на старте проекта системный аналитик должен выполнить большой объём подготовительной работы — разработать все возможные требования к ПО до начала их реализации.
Например, СА может сказать команде: «Мы полгода готовились к началу реализации, я разработал все требования, дизайнер интерфейсов спроектировал весь пользовательский интерфейс, а разработчики — архитектуру. У нас осталось три месяца на реализацию».
В гибкой модели системный аналитик не тратит много времени на подготовку к реализации.
К примеру, он может сказать: «Я примерно понял требования, дизайнер интерфейсов разработал несколько вайрфреймов и часть раскадровки пользовательского интерфейса, а разработчики выбрали стиль архитектуры. Мы готовы начать реализацию».
Фокус на текущей итерации
В гибкой модели системный аналитик работает со значительно меньшим опережением своей команды. Это значит, что он начинает разработку требований к ПО практически одновременно с началом реализации функций.
В процессе разработки требований он руководствуется принципом «точно вовремя» (just-in-time) — иными словами, предоставляет команде ровно столько информации, сколько ей необходимо в текущей итерации. И только когда команда обсудит детали требований и придёт к единому пониманию ожиданий пользователей, системный аналитик сможет приступить к разработке требований для будущей итерации.
СА может сказать команде: «Я пока не думаю о требованиях для будущей итерации. Я сосредоточился на самых важных в данный момент требованиях — мы уже приступили к реализации некоторых из них в текущей итерации».
Обсуждение требований
Поскольку в гибкой модели системный аналитик работает с меньшим опережением команды, он может делиться с ней информацией устно, не составляя многостраничные документы. Ведь если функцию реализуют в ближайшие дни, а не спустя месяцы после описания требований, члены команды не успеют забыть её детали.
При этом системный аналитик передаёт команде как можно больше информации в неформальном общении. Это позволяет быстрее реализовывать функции, потому что СА не тратит время на составление документов и может посвятить его помощи команде — например, тестированию ПО.
Организация обсуждений
В каскадной модели системный аналитик часто становится посредником между пользователями и командой. Он может сказать команде разработки: «Если у вас остались вопросы по требованиям, сформулируйте их, а я поговорю с пользователями и расскажу, о чём мы договорились».
В гибкой модели при организации обсуждения требований СА руководствуется принципом «трёх друзей».
Три друга (three amigos) — это представители трёх основных ролей в команде разработки: системного аналитика, разработчика и тестировщика. Принцип трёх друзей помогает убедиться, что требования обсуждаются с разных точек зрения: что нужно реализовать, как нужно реализовать и как проверить реализованное.
Системный аналитик говорит команде: «Я организую встречу с пользователями для обсуждения открытых вопросов, и мне хотелось бы, чтобы хотя бы двое из вас вместе со мной в этом участвовали».
Также на обсуждение можно пригласить представителей других ролей — например, дизайнера интерфейсов.
Фасилитация обсуждений
В гибкой модели разработки системный аналитик не только приглашает на встречу нужных участников, но и фасилитирует их обсуждения.
Фасилитаторы (facilitators) занимают нейтральную позицию и помогают сделать обсуждение более эффективным. Они направляют процесс и следят за тем, чтобы каждый участник был вовлечён. При этом фасилитаторы стремятся сохранять баланс затраченного времени и результатов обсуждения.
Область знаний о проведении встреч таким образом, чтобы вовлечь всех участников в обсуждение и достичь его цели, называется фасилитацией. Библиотека международной ассоциации фасилитаторов (International Association of Facilitators) включает почти 500 методов проведения воркшопов и групповых процессов.
Например, пользовательские истории (User Story), о которых вы узнаете в этом спринте, относятся как к техникам системного анализа, так и к методам фасилитации, потому что важной составляющей историй является их обсуждение.
Запись требований
В каскадной модели разработки СА описывает в спецификации все возможные требования к ПО. Он может сказать команде: «Я три месяца обсуждал требования с пользователями и ещё месяц составлял спецификацию».
В гибкой модели системный аналитик тоже записывает требования, но в меньшем объёме — например, заносит в таск-менеджер функции, которые нужно реализовать. При этом особенности их реализации он обсуждает с командой устно.
Системный аналитик может сказать: «Я поговорил с пользователями и примерно понял, какие функции им нужны. Добавил в таск-менеджер пять самых важных на данный момент функций, чтобы вы могли приступить к работе. Нужно также обсудить некоторые открытые вопросы».
Возможно, придётся больше записывать, если системный аналитик и другие члены команды работают удалённо из разных городов и стран. В таком случае разница в часовых поясах может помешать устному обсуждению требований.
Собранные системным аналитиком требования должны быть описаны кратко, простым языком и менее формально, чем в спецификации.
Гибкие техники системного анализа
В каскадной модели СА описывает пользовательское требование в виде объёмного варианта использования (Use case) со множеством альтернативных сценариев. В гибкой модели он может заменить их на десяток небольших пользовательских историй (User Story).
Такие гибкие техники помогают команде работать короткими итерациями, сокращая время на разработку требований к ПО и реализацию функций. Работая короткими итерациями, команда может не успеть реализовать весь вариант использования, а вот несколько небольших историй — скорее всего успеет.
Если история кажется слишком большой для короткой итерации, системный аналитик применяет технику декомпозиции — делит её на несколько мелких.
Чтобы не запутаться в них, системный аналитик использует ещё одну технику — составления карты пользовательских историй (user story mapping). Она позволяет расположить истории в соответствии с последовательностью использования функций, а также показать команде, какие истории являются самыми важными на данный момент.
Как вы будете работать с гибкими техниками
В этом спринте вы научитесь:
- составлять пользовательские истории, критерии и сценарии их приёмки;
- декомпозировать истории;
- составлять карты пользовательских историй.
Также вы научитесь составлять другой тип историй — истории о работе (Job Story) — и оценивать их объём.
Чат поддержки