Предлагаем вашему вниманию запись беседы за одним из экспертных столов на встрече сообщества Analyst.by осенью 2018 года. Данный стол был посвящён особенностям бизнес-анализа на Agile-проектах. Экспертом, отвечающим на вопросы, выступил Флор Бабицкий из HQSoftware.
Тем, кто не был на встречах Analyst.by, эта беседа даст представление о том, как проходят наши экспертные столы.
Если у вас есть свои ответы на вопросы, поднятые в этом обсуждении, приглашаем делиться ими в комментариях.
Флор Бабицкий отвечает на вопросы
Борис Щуко (Targetprocess):
Как я понимаю, Ваши представления о хорошем Agile отличаются от того, что звучало в сегодняшних докладах. Верно?
Флор Бабицкий (HQSoftware):
У двух из трёх сегодняшних докладчиков подход к организации проектов заявлен как Agile, но, судя по описаниям, таковым не является. У них смешиваются подходы Waterfall и Agile: сначала делается elaboration и пишутся большие артефакты требований, а уже потом пускают разработку в виде Scrum.
В Scrum есть краеугольные компоненты, которые нельзя выбрасывать. Очень часто методология заявляется как Scrum, но на деле:
-
Product Owner отсутствует,
-
стейкхолдеры клиента малодоступны для общения,
-
ежедневные встречи не проводятся,
-
демо и ретроспективы также отсутствуют.
Люди думают, что выражение “гибкая методология” означает, что её можно изменить под себя.
Любую методологию можно сравнить с мясорубкой, которой на вход подаётся нечто аморфное, а на выходе появляется нечто ровное, упорядоченное. Если из механизма убрать “неудобные” элементы (но задающие смысл его работы!), то он и не будет выравнивать исходный материал. На выходе будет та же аморфная масса, которая подаётся на вход. Т. е. если методология взята, то её нужно придерживаться. Если произвольно выбрасывать или смешивать методы, то это по существу будет отсутствие методологии.
Борис:
Проблема, которая стояла перед сегодняшними докладчиками ― что у них большие, сложные, многолетние проекты. Если систему не документировать, то не выйдет ли она из-под контроля разработчиков?
Флор:
Может, и не выйдет. Каждая story живёт, пока не закончился спринт. Её написали, поместили в бэклог. Перед спринтом поставили в бэклог спринта. Потом согласовали бэклог спринта с клиентом, приоритизировали, устроили planning poker… Разработали, протестировали. В конце спринта показываем демо. Все stories спринта закрываем и никогда, вообще никогда к ним не возвращаемся.
Зачем к ним возвращаться? Если нужны улучшения системы (improvements), то вы создадите новую story, с нуля.
Александр Войтехович (ISsoft):
По моим наблюдениям чистый Scrum хорошо подходит для проектов, отвечающих ряду условий:
-
проектная команда небольшая, чтобы все члены могли присутствовать на митингах с заказчиком;
-
состав команды не должен меняться, чтобы не терялись знания о проекте;
-
проект короткий, чтобы мог выполняться п. 2).
Флор:
По моему опыту проект может быть сколь угодно длинным. Если мы всегда действуем по схеме Scrum, то мне не надо помнить, что было в начале проекта. Клиент может сказать, что какая-то функция должна работать иначе ― но мне не нужно искать старую story, относившуюся к этой функции. Мне проще написать новую story и отдать в разработку. Нет нужды поддерживать большую целостную документацию.
Если нужно выяснить, как функция была сделана раньше, но посмотреть негде, то я попрошу программиста посмотреть в коде. Но возможно, что это не лучший опыт передачи знаний.
Светлана Лемешевская (ISsoft):
А что если программист не имеет возможности понять по коду? Что если функциональность писалась несколько лет назад другими людьми и разбираться в коде очень сложно? В нашем случае программисту пришлось писать компонент с нуля.
Флор:
В Scrum это приемлемо. Если требования поменялись, то нормальным является делать компонент заново.
И надо понимать, что скорость работы программистов и QA-специалистов в Agile и Waterfall одинаковая. Agile выигрывает за счёт сокращения количества коммуникации и времени ожидания встреч и согласований, времени работы с документацией.
Ещё один экспертный стол на встрече Analyst.by
Борис:
Так как быть в ситуации, когда у вас большая сложная система, в которой разные части сильно взаимосвязаны? Проект существует десяток лет, люди сменились. При изменении какой-то части системы у вас иногда будет “ломаться” другая часть. Как этого избежать? Может, здесь нужны не документы аналитиков (требования), а документация программистов, например?
Флор:
Такая проблема есть и всегда будет. Возможно, появление сильного ИИ её решит.
Если требования ведутся в виде user stories, то единственное спасение, которое я вижу ― бизнес-аналитику быть неравнодушным и знать весь функционал. User stories для такого человека ― как лилии на болоте, и если он плюхнет камень в воду (большую доработку), то знает, до каких stories круги доползут и что нужно проверить.
В своих проектах я организую полное описание системы в виде иерархического раскрывающегося списка требований в wiki. Уровни в списке такие: вся система -> подсистемы -> Epics -> User Stories. Когда нужно понять, на что повлияет новая фича, эта иерархия помогает быстро сориентироваться во всём составе функциональности.
Чтобы было легче ориентироваться, делайте в этой иерархии большее число слоёв или делите систему на большее число подсистем. Тогда плоские списки внутри каждой раскрытой сущности (например, список эпиков внутри подсистемы) будут короче и можно будет более “вертикально” искать нужные части системы.
Также анализ влияния нововведений делается через тесты. Кроме тестирования непосредственно новой функциональности нужно применять регрессионное тестирование, smoke-тестирование. Для них нужно иметь test cases.
Александр:
Мне кажется, для длительного, многолетнего проекта Scrum просто не подходит.
Флор:
Методологии, отличные от Agile, пригодны в медленно меняющихся бизнесах ― например, в банковской сфере. Но времени на требования всё равно будет уходить много.
Мне непонятно, как большая SRS поможет в случае сложного проекта, в котором доработки делать страшно из-за непредсказуемых последствий. Вы же не будете каждый раз перечитывать том требований?
“Стена” обратной связи на встрече Analyst.by
Борис:
Так может, нужно для этого писать не объёмные требования, а некие документы о зависимостях?
Для больших проектов или предприятий (от 70 человек) есть масштабированный Agile, в частности SAFe. Но в его описаниях я пока не видел каких-либо указаний о ведении “верхней” документации, которая бы объединяла знания о всей большой разрабатываемой системе.
Флор:
Я думаю, это всё должно решаться тестами. Среди прочего, человек с хорошим знанием проекта должен в acceptance criteria указывать, какие существующие элементы системы нужно проверить после введения новой функциональности.
А проводить какую-то трассировку зависимостей между user stories я не представляю возможным на больших проектах. На одном большом проекте может быть несколько тысяч stories.
Борис:
Покрывать всё тестами ― это большая нагрузка на команды разработки. Когда в сложную систему вводятся новые компоненты, то 80% всего времени команд может идти на написание тестов. И в таком случае компании (Facebook, например) применяют crowd testing ― т.е. выкатывание новой версии системы на часть пользователей, чтобы те могли найти баги во время её использования. Тогда команды их правят, а потом выкатывают новую версию на всех пользователей. Но crowd testing не особо применишь на ответственном проекте, от которого зависят бизнесы и в котором цена ошибки из-за бага может быть очень высока.
Флор:
Если цена ошибки высока, то, возможно, действительно стоит попробовать более Waterfall’ный подход, в том числе более подробно и системно документировать требования изначально.
Текст подготовил Борис Щуко
