Must have артефакты для разработки ПО | DOU

Must have артефакты для разработки ПО | DOU Аналитика

Что такое артефакт в разработке по?

Артефакт — это любой созданный искусственно элемент программной системы.
К элементам программной системы, а, следовательно, и к артефактам, могут относиться исполняемые файлы, исходные тексты, веб страницы, справочные файлы, сопроводительные документы, файлы с данными, модели и многое другое, являющееся физическим носителем информации. Другими словами, артефактами являются те информационные элементы, которые тем или иным способом используются при работе программной системы и входят в ее состав.

С понятием «компонент» часто ассоциируют компонентное или сборочного программирование, однако это не верно с точки зрения UML. В терминах UML компонентное или сборочное программирование манипулирует артефактами!

Компонент (в UML) — это частью модели, описывающая логическую сущность, которая существует только во время проектирования (design time), хотя в дальнейшем ее можно связать с физической реализацией (артефактом) времени исполнения (run time).

15 ноя 2021

Это шестая статья из серии «Введение в Agile». В ней мы расскажем о ролях и артефактах Скрам, а также о практиках, которые дополняют Скрам.

До этого мы разбирались в отличиях гибких и классических подходов к управлению, области применения Agile-подходов, характеристиках Agile-команды и способах перехода на Agile, а также познакомились с основами Scrum:

Scrum (Скрам) был разработан в 1995 году Джеффом Сазерлендом и Кеном Швабером. Перед Сазерлендом была поставлена задача: менее чем за 6 месяцев разработать замену основному программному продукту компании, в которой он тогда работал. Прочитав все, что смог найти о повышении производительности команд, Джефф предложил свой подход. Он объединился со своим коллегой Кеном Швабером для формализации подхода и в 1995 году Scrum был представлен всему миру.

Роли в Скрам

В Скрам выделяют три роли: Владелец продукта, Скрам-мастер и Команда разработки. Все вместе они составляют Скрам-команду.

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

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

Поскольку Владелец продукта отвечает за успех своего продукта, он занимает роль лидера в команде, в то же время тесно сотрудничая с другими участниками и не имея формальной власти над ними. Роман Пихлер в книге «Управление продуктом в Scrum. Agile методы для вашего бизнеса» описывает Владельца продукта как «первого среди равных» в команде.

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

При этом важно, чтобы Владелец продукта не выступал «передаточным звеном» между заказчиком и командой, а мог самостоятельно защищать продукт и принимать по нему решения. Для этого ему нужно быть достаточно квалифицированным в предметной области проекта (разработка ПО, создание банковских продуктов или верстка веб-страницы).

Скрам-мастер – это эксперт в области Agile-практик, который помогает Команде разработки выстроить правильные процессы. На начальных этапах Скрам-мастер проводит встречи (Планирование спринта, Ежедневные летучки, Обзор спринта, Ретроспективу), поддерживает в актуальном состоянии артефакты процесса, защищает команду от внешних вмешательств: срочных поручений, не относящихся к разрабатываемому продукту, попыток изменить требования в ходе спринта и т.п.

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

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

Команда разработки – это те самые мотивированные профессионалы, которые заведомо мотивированы на создание результата. В Команде разработки должно быть не более 9 человек, все участники взаимозаменяемы, то есть могут помочь друг другу в выполнении задач. Кросс-функциональность позволяет Команде нести коллективную ответственность за результат.

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

Чтобы сплотить команду, рекомендуют разместить всех участников в одном помещении. По мнению Филиппа Мисслера, CTO немецкой компании «mobile.de», это влияет не только на эффективность выполнения задач, но и на боевой дух команды. Для создания атмосферы в рабочем помещении повесьте на видном месте плакаты с ключевой информацией о продукте: формулировку концепции, наиболее приоритетные элементы Бэклога продукта, задачи текущего спринта.

Артефакты в Скрам

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

Бэклог продукта есть практически в любом Agile-проекте: это удобное средство для фиксации требований, задач и элементов продукта. Для оценки качества Бэклога применяется инструмент DEEP (от англ. detailed, estimated, emergent, prioritized): хороший Бэклог должен содержать детализированные, оцененные, независимые и приоритизированные элементы.

Дополнительный анализ:  Аналитик данных и data scientist: в чем отличие? – Новости – Факультет компьютерных наук – Национальный исследовательский университет «Высшая школа экономики»

Максимальную степень детализации должны иметь наиболее приоритетные элементы. Оценка элементов Бэклога помогает спланировать, что мы запланируем на следующий спринт, а что сделать не успеем. По мере создания продукта в Бэклог могут добавляться новые требования.

Для оценки элементов Бэклога применяются относительные величины, которые показывают совокупную величину элемента по сложности, трудоемкости или размеру. Распространены техники оценки в стори-поинтах (от англ. «story points», очки, баллы) – 0, 1, 2, 3, 5, 8, 13 или 20 стори-поинтов, или в размерах футболок – S – маленький элемент, M – средний, L – большой.

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

Бэклог спринта – это набор элементов Бэклога продукта, который Команда принимает в разработку на ближайший спринт. В Бэклоге спринта также формулируется Цель спринта (Зачем мы работаем в этом спринте? Чего хотим достичь именно за эту итерацию?) и план по достижению этой цели.

Роман Пихлер в уже упоминавшейся книге «Управление продуктом в Scrum» приводит пример цели спринта, сформулированной как: «У высоких деревьев глубокие корни». Эта фраза отлично описывала цель спринта: закладку основания для всего последующего проекта.

В Бэклог спринта должны попадать только такие элементы, которые удовлетворяют трем параметрам: они являются четкими, проверяемыми и осуществимыми. Четкость означает одинаковое понимание участниками команды сути задачи. Проверяемость означает наличие эффективного способа проверить, выполнена ли задача. Осуществимость означает возможность полностью выполнить эту задачу за один спринт.

Инкремент продукта – это сумма завершенных во время спринта Элементов Бэклога продукта и всех инкрементов предыдущих спринтов. То есть, это текущее состояние разрабатываемого продукта, включая доработки последнего спринта.

Процессы в Скрам

Планирование спринта проходит перед началом каждого спринта. Цель этого процесса – определить объем работ, который Команда возьмет в ближайший спринт. В ходе Планирования спринта Команда выбирает из Бэклога продукта самые приоритетные элементы (требования к продукту), детализирует их до уровня задач, оценивает трудоемкость и взаимосвязи между задачами.

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

Ежедневная летучка проводится каждый день в ходе Разработки, в одно и то же время. На этой встрече Команда обсуждает, что каждый из участников сделал за прошлый день, что планирует делать в следующий и в чем нужна помощь. Летучка длится не более 15 минут.

Design

Зачем. Если вы делаете программное обеспечение, которое предназначено для использования человеком посредством визуальных интерфейсов, тогда вам не обойтись без дизайна вашего ПО. Дополнительное объяснение, зачем необходим дизайн на проекте, считаю лишним.

Как. Развернутый ответ о том, как может быть построена коммуникация с дизайнером, вы можете посмотреть в этом видео.

Когда. Обновляйте каждый раз, когда вам приходит новая информация или понимание того, как пользователь будет взаимодействовать с системой. Старайтесь держать мокапы обновленными.

Личное мнение. Все дизайны должны отображать основные сценарии работы с приложением. Должны быть отображены реальные примеры данных, имен, фотографий и так далее. Всегда делайте интерактивные прототипы. Это сократит вам время на согласование требований и даст команде понимание того, как это все должно работать, с первого раза.

Entity relationship model

Зачем. ERM позволяет показать взаимоотношения бизнес-сущностей между собой. Если вы сможете это сделать в самом начале разработки своего продукта, тогда это упросит техническим специалистам понимание того, как правильно строить архитектуру самого приложения и базы данных. Используя такие диаграммы в процессе разработки ПО, вы снижаете риск того, что нужно будет переделать приложение.

P. S. Даже если разработчики говорят: «Мы используем NoSQL базы данных и мы можем меняться на ходу», — не верьте им 🙂 Этот трюк работает только вначале, пока продукт молодой и зеленый, и нет ни нагрузок, ни сложной бизнес-логики… Так что пускай не ленятся и задумываются над архитектурой.

Как. Чтобы понять, как использовать эти диаграммы, я рекомендую почитать о реляционных базах данных. На каких принципах они построены, какие связи есть и зачем все это необходимо.

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

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

Meeting notes

Зачем. После проведенной встречи хорошим тоном считается зафиксировать договоренности и план дальнейших действий. Я рекомендую использовать этот артефакт только как инструмент самоконтроля, а не документ строгой отчетности. Структура документа достаточно проста.

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

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

Как. Если встреча была не запланированной и быстрой, тогда ручка и бумага — мои лучшие друзья. Если я контролирую ситуацию, тогда, конечно же, OneNote. Неважно, каким способом я зафиксировал информацию, я всегда ее оцифровываю. Дальше в электронном виде я могу ее расшарить кому и когда это необходимо.

Когда. Я пишу заметки во время встречи и после нее. На каждую встречу я обязательно готовлю тему и список вопросов, на которые мне нужно получить ответы, чтобы работа по проекту двигалась вперед по плану. Конечно же, я уведомляю клиента о своих намерениях, чтобы мы не тратили время впустую.

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

Дополнительный анализ:  5 лучших плагинов для отслеживания заказов в магазинах WooCommerce — WordPressify

Mock data (тестовые данные)

Зачем. Это тщательно подготовленные данные, которые должны использоваться разработчиками во время проектирования/разработки системы. QA специалисты должны использовать их как эталонные данные при тестировании.

Process flow diagram

Зачем. Чтобы упростить согласование бизнес-логики между всеми участниками процесса разработки ПО. В своей практике я использую «Activity Diagrams» или «Cross functional flow charts» для решения 99% задач. Мне не нужны сложные и комплексные нотации типа BPMN / IDF0 и прочие.

Как. Прежде всего, вам необходимо понять, как работают процессы в данный момент, если это уже существующий бизнес. Если же это что-то новое, тогда вам необходимо подумать, как будет выглядеть тот или иной процесс. Используя паттерн AS IS / TO BE, я всегда делаю зарисовки процессов AS IS на бумаге в виде схем / слов / кракозябликов, а вот процессы TO BE я уже отрисовываю в программном комплексе, используя определенную нотацию и тип диаграммы.

Когда. Итеративно, по мере поступления новой информации. Процессы могут зависеть друг от друга.

Личное мнение. Ваша задача — не рисовать красивые диаграммы по всем канонам определенной нотации, а делать классный работающий продукт быстро, в сроки и качественно. Пытайтесь декомпозировать процессы на более мелкие. Это позволит улучшить читабельность диаграмм.

State machine

Зачем. Чтобы понять, какие существуют состояния/статусы и какие триггеры на это влияют. У каждой сущности есть свой life cycle. У некоторых из них он достаточно короткий и состоит из 2-3 статусов. Но также бывают и сложные сущности, где уйма разных состояний и факторов, которые влияют на их изменение.

Хороший пример сущности со сложной структурой — это заявка в службу поддержки, где есть несколько уровней служб, и заявке иногда приходится пройти 3-4 уровня, с рассмотрением и переадресацией этой заявки в другие службы. О том, как определять статусы и состояния сущностей, вы можете посмотреть в моем видео. Такого типа диаграммы помогают backend разработчикам в реализации бизнес-логики.

Как. Я использую диаграмму «state machine» в нотации UML. Вам необходимо понять, в какой момент сущность создается, какие сущности влияют на состояние текущей сущности. Это все вам поможет более детально продумать ваше приложение.

Когда. Обновляйте каждый раз, когда вам приходит новая информация или понимание о том, какие сущности/состояния/триггеры появились.

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

Use cases

Зачем. Использование use cases позволяет осознать и показать максимальную картину того, что будет входить в разрабатываемую фичу или целый продукт. Используя эту технику, вы легко можете отображать и прослеживать зависимости взаимодействия между пользователем и системой.

Как. Эта диаграмма создается итеративно, по мере поступления новой информации. Большая часть изменений в диаграмме приходится на начало выяснения требований. Именно вначале вы пытаетесь понять, какие кейсы использования ПО будут именно у вас.

Когда. Поскольку информация по кейсам меняется достаточно редко, я ее рисую в самом начале разбора продукта/фичи. Это не занимает много времени — 2-3 часа от силы.

Личное мнение. Использование use cases очень помогает в структурировании информации. Я практически всегда использую этот тип диаграмм в проектах, где много ролей и сценариев.

Артефакты, необходимые для тестирования

Дисклаймер. Данная статья не является претензией на объективность, а отражает только мое сугубо личное мнение. Также прошу обратить внимание на то, что мое мнение не является статичным и может меняться. Статья написана только для того, чтобы не отвечать много раз на одни и те же вопросы, а просто дать ссылку.

Итак попробую ответить на вопрос: какие артефакты необходимы для обеспечения процесса тестирования (имеется ввиду разрабатываемые самим тестировщиком).

Я выделяю несколько артефактов:

1. План тестирования (Test plan)
2. Тестовый сценарий (Test-case)
3. Наборы тестовых сценариев (Test script or Test suite)
* Набор тестовых сценариев для Smoke-test
* План приёмосдаточных испытаний (ПСИ)
4. Описание дефектов
5. Отчет о тестировании

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

План тестирования

Есть как минимум два общепринятых понимания этого документа:

1. Документ описывающий кто, что, когда и как будет тестироваться
2. Документ описывающий все необходимые для проверки приложения тесты.

Говоря план тестирования, я подразумеваю именно первый вариант толкования.
Для того чтобы посмотреть пример плана тестирования можно:

* Взять книгу Роберт Калбертсон, Крис Браун, Гэри Кобб. Быстрое тестирование
* Взять RUP
* Погуглить
* Дождаться когда я изложу пример в одной из следующих статей

Тестовый сценарий(тест)

Тестовый сценарий — это описание начальных условий, входных данных, действий пользователя и ожидаемого результата.
Хорошая практика — написание тестовых сценариев на основании вариантов использования (Use cases).

Тестовый сценарий является как атом мельчайшей частичкой для ниже описанных документов (но его как и атом можно разбить на условия, входные данные, шаги, результаты)

Варианты названий:

* Атомарный тест
* Тестовый вариант
* Вариант тестирования
* Тестовый случай

Наборы тестовых сценариев

Это тестовые сценарии сгруппированные по некоему признаку (например тестируемой функциональности). Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего (Test script)), так и независимыми (Test suite).
Наиболее часто выделяемыми наборами являются: Набор тестовых сценариев для Smoke-test и План приёмо-сдаточных испытаний.

Набор тестовых сценариев для Smoke-test

Если честно, то я не знаю адекватного перевода на русский данного термина. Иногда используется перевод “Дымчатое тестирование”, но он вызывает у меня стойкое отвращение.

Набор тестовых сценариев для Smoke-test — это документ, включающий в себя набор определенных тестовых сценариев, покрывающих основную функциональность объекта или системы. Цель проведения Smoke-test — убедиться в том, что ключевые функции программы работают, не вникая в подробности.

Хорошая практика — прием билда в тестирование на основании прохождения Smoke-test. Также зачастую в качестве такого теста используют ежедневную сборку с обязательным прохождением unit тестов.

Комментарий: Ежедневная сборка без unit тестов не может считаться как Smoke test. Это называется: “Ух ты компилицо”

План приёмо-сдаточных испытаний (ПСИ)

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

В общем случае подмножества тестов выглядят так как на рисунке.
Must have артефакты для разработки ПО | DOU
Выше я перечислил те артефакты, которые считаю важными для проведения тестирования. Но это не значит что при любом тестировании необходимо использовать все из них. Да и детализация каждого из артефактов в каждом конкретном случае может различаться.
Кросспост с личного блога

Дополнительный анализ:  Доклады / Analyst Days

Важно понимать

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

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

На мой взгляд, сейчас идеальное время для вхождения в профессию и развития в ней. Рынок предлагает огромное число вакансий для аналитиков с очень достойной оплатой труда и возможностью удаленной работы (к слову, для тех, кто находится в поиске – у нас в компании вакансий тоже много).

А какие из вопросов встречались на собеседовании у вас? Возможно какие-то вопросы вам кажутся неуместными для СА?

Иллюстрации:Михаил Голев

Возможные вопросы:

Для компаний, где роль СА объединена с БА (бизнес-аналитиком).Сюда же могут попасть вопросы про выявление требований: основные техники сбора требований, управление стейкхолдерами (заинтересованными сторонами), выбор стратегии работы со стейкхолдерами и тп.

Документация к системе и другие артефакты деятельности аналитика

Опять же, как и в предыдущем блоке в основном вопросы про ваш опыт, чтобы оценить насколько он релевантен тому, что вам предстоит делать.

Интеграции

С этой темой надо быть аккуратнее. Есть ситуации, когда лучше сказать хоть что-то чем не сказать ничего, но здесь работает ровно противоположное. Если вы не уверены в том, что достаточно разбираетесь в теме, лучше не утверждать ничего, что вызовет дополнительные вопросы на понимание.

Кто такой системный аналитик

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

Чаще всего требования к кандидатам следующие (помимо опыта работы в определенном домене):

  • Основная деятельность: сбор, анализ и документирование требований к ПО на техническом языке. Сопутствующее общение с заказчиками и проектной командой, изучение предметной области, участие в проектировании решений, проверка реализованного функционала на соответствие требованиям, участие в показах.

  • Требуемые hard skills: навыки разработки технической документации (BRD, SRS), опыт работы с различными СУБД, уверенные знания SQL, проектирование модели данных, знание нотаций UML, BPMN, знание различных методов интеграции систем, понимание принципов проектирования REST API, опыт работы с SOAP, понимание особенностей форматов обмена данными JSON/XML.

  • Требуемые soft skills: коммуникабельность, способность находить общий язык и с разработкой, и с бизнесом, аналитическое мышление, умение работать в условиях недостатка информации, адаптивность к изменениям, проактивность и ответственность за конечный результат.

Откуда вопросы?

За последний год на позиции тимлида группы системных аналитиков я провела немало собеседований. Но не менее ценным опытом считаю личные собеседования на позицию СА в других компаниях, в ходе которых я выявила для себя ТОП-5 тем с возможными вопросами, которые повторялись практически на каждом интервью.

Сразу уточню, что далеко не все вопросы встретятся у вас на собеседовании одновременно. Но если вы претендуете на высокую позицию и пройдете N собеседований, то с большой долей вероятности встретите все эти вопросы на своем пути. Также хочу отметить, что для аналитиков разного уровня требуется разная детализация ответов. Если вы junior/pre-middle, то обычно достаточно поверхностного ответа на приведенные примеры вопросов, чтобы интервьюер понял, что вы сталкивались с темой или хоть чуть-чуть в этом разбирались.

Практика

Я решил взять за основу общий сценарий, чтобы было более понятно. Если у вас будут конкретные вопросы по вашим кейсам, пишите их в комментариях или мне лично.

Epic: Account management

Features: log in / log out / password recovery

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

В это перечень входят:

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

Проектирование решения

Как показывает практика, далеко не каждый СА участвует в проектировании решения. Это связано с различиями в понимании роли СА в разных компаниях, а также с уровнем компетенции СА (достаточно ли у аналитика знаний и опыта, для влияния на выбор реализации решения или нет).

Процесс разработки по

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

Ресурсы для изучения:

Ответы на все вопросы есть в замечательной книге К. Вигерса и Д. Битти «Разработка требований к ПО». Книга, на мой взгляд, обязательна к прочтению каждому СА. Но если вам все-таки лень читать 716 страниц достаточно сложного к восприятию текста, то вот список ресурсов, где хорошо описаны ответы на вопросы выше:

Требования к по

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

Выводы

Некоторые из вас сразу скажут, что подход к работе на ваших проектах совершенно другой: заказчик хочет видеть что-то другое или привык к ТЗ (техническому заданию) на 100 500 страниц в формате *.docx. Мой ответ прост: если вы хотите меняться и расти, вам придется найти способы изменить подходы к работе с клиентами и дать им четкое понимание плюсов и минусов разных подходов.

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

Оцените статью
Аналитик-эксперт
Добавить комментарий