Комментарии 12
А если функциональность требует нетривиального алгоритма (далеко выходящего за рамки повседневного опыта разработчика), то на каком этапе происходит его выбор или разработка? Кто ей занимается? Если это не сам программист — то как обеспечивается, с одной стороны, реализуемость того, что напридумано, и с другой — корректность реализации?
В случае сложной функциональности, из описания которой есть только идея сформулированная в общих чертах и совершенно непонятно как ее реализовывать, в первую очередь делается исследование + прототипирование + разработчик советуется с архитекторами и экспертами. При чем это делается еще до формализации требований. Другими словами выясняется «а что мы вообще можем сделать в этой области». Если прототип подтверждает работоспособность выбранного подхода, то требования финализуются и разработка продолжается в основных бранчах.
Понятно. А кто пишет прототип? И насколько глубоко разработчик должен понимать алгоритм? Или достаточно того, что эксперты и архитекторы распишут все структуры и формулы до последней буквы?
Первоначальное прототипирование всегда выполняется опытным разработчиком (лидом), которому не нужно разжевывать структуры и формулы. Естественно такие задачи не ставятся новичкам. Участие архитекторов и экспертов заключается в указании направления, в котором «копать».
Пример из нашей практики:
Была поставлена задача реализовать возможность резервного копирования из открытого виртуального диска (во включенной виртуальной машине) без использования нативных снапшотов (для платформы VMware ESXi). Для этого разработчик создал драйвер работающий на уровне vSCSI фильтров (через которые осуществляется работа с виртуальными SCSI устройствами), который мог перехватывать все I/O выполняемые с виртуальным диском. Затем этот драйвер расширялся до уровня, на котором он мог хранить список секторов, в которых происходили изменения (аналог Changed Block Tracking). Всю эту работу выполнял один и тот же опытный разработчик (знакомый как с архитектурой самого продукта, так и c платформой ESXi), то есть он выяснял в какое место можно встроить драйвер, исследовал платформу ESXi, и т.д.
Пример из нашей практики:
Была поставлена задача реализовать возможность резервного копирования из открытого виртуального диска (во включенной виртуальной машине) без использования нативных снапшотов (для платформы VMware ESXi). Для этого разработчик создал драйвер работающий на уровне vSCSI фильтров (через которые осуществляется работа с виртуальными SCSI устройствами), который мог перехватывать все I/O выполняемые с виртуальным диском. Затем этот драйвер расширялся до уровня, на котором он мог хранить список секторов, в которых происходили изменения (аналог Changed Block Tracking). Всю эту работу выполнял один и тот же опытный разработчик (знакомый как с архитектурой самого продукта, так и c платформой ESXi), то есть он выяснял в какое место можно встроить драйвер, исследовал платформу ESXi, и т.д.
Спасибо. Эта схема выглядит более реалистичной, чем вертикаль, в которой специалист по предметной области, алгоритмист и разработчик — совершенно разные люди. Я никак не могу понять, как вертикаль вообще может работать без специалиста, описанного в вашем примере.
Я тоже не могу представить себе ситуацию, когда разработчик пишет код для платформы, в которой не имеет экспертизы :)
Роли архитектора, алгоритмиста и разработчика в той или иной мере накладываются на любого конечного исполнителя. Если в какой-то из ролей не хватает экспертизы — то идет обращение к соответствующим экспертам (через прямое общение, письма или через ревью кода например).
Роли архитектора, алгоритмиста и разработчика в той или иной мере накладываются на любого конечного исполнителя. Если в какой-то из ролей не хватает экспертизы — то идет обращение к соответствующим экспертам (через прямое общение, письма или через ревью кода например).
Как вы документируете изменения в существующей функциональности (например, изменились некоторые требования фичи) и, соответственно, связываете изменения с задачами на разработку (т.е. между Confluence и JIRA)?
Вся документация по требованиям ведется в Confluence. Изменения требований могут происходить на разных стадиях:
1) В процессе разработки фичи, но до ее выпуска в паблик. Подтверждение/одобрение изменения может выполняться на разных уровнях. В нашем случае подобные решения принимаются аналитиком и в отдельных случаях привлекается вышестоящее начальство (product manager) если изменение спорное, но чаще это все-таки один человек.
Допустим запрос на изменение был подтвержден. В этом случае редактируется оригинальная статья на Confluence, о чем сообщается разработчику(-ам) и тестировщику(-ам). Разработчик корректирует оценки в существующих dev-tasks, либо, если того требуют изменения, заводит новые таски, которые линкуются к оригинальному тикету (типа «epic») в JIRA, в котором редактируется описание, либо оставляется комментарий. Об этих изменениях сообщается начальству т.к. любые изменения в функциональности приводят к изменению оценок и соответственно — к изменению сроков.
2) После того как функциональность ушла в «народ». Такая ситуация тоже не редкость — в этом случае в JIRA заводится тикет типа «Change request» с указанием milestone, куда мы хотим внести это изменение и со ссылкой на оригинальное описание в Confluence (привязка к фиче, которую хотим менять). Затем проводится процедура одобрения (Approve) изменения и если изменение принято, то разработчик (как правило это dev lead, который распределяет задачи между остальными разработчиками) ставит оценку задачи в человеко-днях, а тестировщик вносит изменения в тестовые сценарии. После этого вносятся изменения в оригинальное описание на Confluence с указанием нового поведения, с пометками в какой сборке было старое поведение.
Основная сложность в отслеживании именно ситуаций вида 2) — мы пробовали множество различных процессов и выше я описал один из них (наиболее актуальный). Одна и та же фича может меняться кардинально и бывает трудно понять чего ожидать от конкретной сборки (билда), если не вести подробную документацию. Confluence помогает в этом благодаря встроенной версионности всех статей и залитых документов.
1) В процессе разработки фичи, но до ее выпуска в паблик. Подтверждение/одобрение изменения может выполняться на разных уровнях. В нашем случае подобные решения принимаются аналитиком и в отдельных случаях привлекается вышестоящее начальство (product manager) если изменение спорное, но чаще это все-таки один человек.
Допустим запрос на изменение был подтвержден. В этом случае редактируется оригинальная статья на Confluence, о чем сообщается разработчику(-ам) и тестировщику(-ам). Разработчик корректирует оценки в существующих dev-tasks, либо, если того требуют изменения, заводит новые таски, которые линкуются к оригинальному тикету (типа «epic») в JIRA, в котором редактируется описание, либо оставляется комментарий. Об этих изменениях сообщается начальству т.к. любые изменения в функциональности приводят к изменению оценок и соответственно — к изменению сроков.
2) После того как функциональность ушла в «народ». Такая ситуация тоже не редкость — в этом случае в JIRA заводится тикет типа «Change request» с указанием milestone, куда мы хотим внести это изменение и со ссылкой на оригинальное описание в Confluence (привязка к фиче, которую хотим менять). Затем проводится процедура одобрения (Approve) изменения и если изменение принято, то разработчик (как правило это dev lead, который распределяет задачи между остальными разработчиками) ставит оценку задачи в человеко-днях, а тестировщик вносит изменения в тестовые сценарии. После этого вносятся изменения в оригинальное описание на Confluence с указанием нового поведения, с пометками в какой сборке было старое поведение.
Основная сложность в отслеживании именно ситуаций вида 2) — мы пробовали множество различных процессов и выше я описал один из них (наиболее актуальный). Одна и та же фича может меняться кардинально и бывает трудно понять чего ожидать от конкретной сборки (билда), если не вести подробную документацию. Confluence помогает в этом благодаря встроенной версионности всех статей и залитых документов.
Касаемо п. 2, как я понял из статьи, для управления требованиями по «фиче» вы используете Epic — задача проходит схожий с CR процесс? И как в случае с CR фиксируются те изменения, которые нужно внести (не процесс обновления требований по «фиче», а сами изменения)?
В общем да — процессы очень похожи. Внесение изменения всегда согласовывается с разработчиками (тестировщиками/начальством) перед финализацией.
Не очень понял к сожалению в чем принципиальное отличие «обновления требований по «фиче»» от «самих изменений» в вашей интерпретации. Можете пояснить? (ниже описал процесс поподробнее, но, возможно, не так понял)
Любые изменения фиксируются в первую очередь в оригинальной статье в Confluence, в которой было изначальное описание «фичи» и которая связана с JIRA через линк на «Epic». В самом «Epic» мы стараемся избегать описания требований — такое возможно только если «фича» очевидная и небольшая. В Confluence в случае переработки требований (в том числе в результате CR) добавляется запись в раздел «history», например:
Version 0.0 Первоначальная версия.
Version 0.1 Изменено описание поддерживаемых локаций
Version 0.2 Изменено описание алгоритма (секции 2.1 и 2.2)
Version 0.3 ....
Затем редактируется исходный текст статьи.
Не очень понял к сожалению в чем принципиальное отличие «обновления требований по «фиче»» от «самих изменений» в вашей интерпретации. Можете пояснить? (ниже описал процесс поподробнее, но, возможно, не так понял)
Любые изменения фиксируются в первую очередь в оригинальной статье в Confluence, в которой было изначальное описание «фичи» и которая связана с JIRA через линк на «Epic». В самом «Epic» мы стараемся избегать описания требований — такое возможно только если «фича» очевидная и небольшая. В Confluence в случае переработки требований (в том числе в результате CR) добавляется запись в раздел «history», например:
Version 0.0 Первоначальная версия.
Version 0.1 Изменено описание поддерживаемых локаций
Version 0.2 Изменено описание алгоритма (секции 2.1 и 2.2)
Version 0.3 ....
Затем редактируется исходный текст статьи.
В общем, вы правильно поняли мой вопрос. Получается, что на странице с требованиями вы фиксируете историю изменений (не пользуетесь стандартной функциональностью Confluence — Page History), на основе чего команда и понимает, что именно поменялось (версия, полагаю, указывается в Epic).
Ещё меня интересует, как вы структурируете весь набор требований. Раз вы используете фичи, то, быть может, их взаимосвязь отображаете в виде Feature Tree?
Ещё меня интересует, как вы структурируете весь набор требований. Раз вы используете фичи, то, быть может, их взаимосвязь отображаете в виде Feature Tree?
Да, функциональность Confluence — Page History нами используется только для отката к предыдущей версии в случае необходимости. Для трекинга изменений удобнее все-таки смотреть в шапку страницы, чем шерстить все её предыдущие версии.
В структурировании зависимостей между фичами какого-то особого утвержденного процесса нет. Если есть зависимости между фичами, то они оформляются в JIRA в виде зависимостей между тикетами типа Epic (отношения типа «Depends On», «Executed In», и т.д). В Confluence в таких случаях обычно ставятся ссылки на соответствующие страницы зависимой фичи.
В нашем случае зависимости между фичами, которые необходимо как-то особо обрабатывать, встречаются достаточно редко благодаря тому, что при реализации функциональности всегда учитывается возможность её расширения (для этого и существуют архитекторы). Например, добавление опции e-mail оповещений к операции бэкапа не требует изменений в самой функциональности бэкапа, а пристраивается «сбоку». Конечно, бывают исключения, но они слишком редки, чтобы ради них придумывать отдельный процесс.
При этом изменения в существующем функционале, например, добавление в бэкап поддержки новых файловых систем, тоже оформляются в виде Epic-ов как новые фичи. Но даже такие, казалось бы, большие изменения не требуют больших переделок в корневом функционале бэкапа — вся поддержка файловых систем вынесена в отдельный расширяемый модуль.
В структурировании зависимостей между фичами какого-то особого утвержденного процесса нет. Если есть зависимости между фичами, то они оформляются в JIRA в виде зависимостей между тикетами типа Epic (отношения типа «Depends On», «Executed In», и т.д). В Confluence в таких случаях обычно ставятся ссылки на соответствующие страницы зависимой фичи.
В нашем случае зависимости между фичами, которые необходимо как-то особо обрабатывать, встречаются достаточно редко благодаря тому, что при реализации функциональности всегда учитывается возможность её расширения (для этого и существуют архитекторы). Например, добавление опции e-mail оповещений к операции бэкапа не требует изменений в самой функциональности бэкапа, а пристраивается «сбоку». Конечно, бывают исключения, но они слишком редки, чтобы ради них придумывать отдельный процесс.
При этом изменения в существующем функционале, например, добавление в бэкап поддержки новых файловых систем, тоже оформляются в виде Epic-ов как новые фичи. Но даже такие, казалось бы, большие изменения не требуют больших переделок в корневом функционале бэкапа — вся поддержка файловых систем вынесена в отдельный расширяемый модуль.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стадии рождения новой функциональности в программном продукте