оно может и норм, но зависимости между такими системами это боль

Так я и говорю - зообординг.

у многих систем есть API

ничего нет сложно выгружать те же самые задачи в jira например если разработчкам удобнее

и забирать статусы по задачам

зачем забирать статусы по задачам?

Ох, жарко тут в пятницу вечером!) привет всем

ну зоопарк типа

если одим удобно в одной системе а другим в другой

то в принципе не сложно подружить

Не стои плодить сущности без необходимости 😄

Ну это все спрятано под капотом

Потом придется чинить двигатель через выхлопную трубу :)

Народ, может кто-нибудь обьяснить на примерах, что подразумевается в аджайл, когда говорят, что аналитика, разработка и тестирование должны работать в параллель над одной историей в спринте? ;)

Народ, может кто-нибудь обьяснить на примерах, что подразумевается в аджайл, когда говорят, что аналитика, разработка и тестирование должны работать в параллель над одной историей в спринте? ;)

Это значит, что по всем этим этапам команда идёт вместе.

Поясните

Что значит вместе? Аналитик и тестировщик сидят рядом с разработчиком когда он кодит? В чем цель такого действия? Профит?

Народ, может кто-нибудь обьяснить на примерах, что подразумевается в аджайл, когда говорят, что аналитика, разработка и тестирование должны работать в параллель над одной историей в спринте? ;)

Привет Нет длинных фаз, когда результаты одной фазы передаются в другую без возврата назад. К примеру, когда аналитики долго прорабатывают требования к системе. Скажем пару месяцев. Потом отдают в дизайн. Потом в разработку. Потом в тестирование. Потом в интеграцию. А есть так: есть предположение о необходимости функции. Небольшая функция полностью делается за короткий промежуток. Анализируется, проектируется, разрабатывается, тестируется и внедряется за один спринт (если про скрам)

В идеале, после анализа требований, проектирование, разработка, дизайн и тестриование работают параллельно.

Т.е. параллельности нет? Это все-таки последовательность, но в коротком промежутке времени?

Т.е. параллельности нет? Это все-таки последовательность, но в коротком промежутке времени?

Да в неидеальном случае последовательно. Но лучше параллельно, если уровень команды позволяет.

В идеале, после анализа требований, проектирование, разработка, дизайн и тестриование работают параллельно.

Приведите пример, на каком уровне систем и задач такое возможно и какие конкретно работы распараллеливаются?

И как это зависит от уровня команды? В части чего? Осознанность? Знание процесса?

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

Чтобы это осилить надо владеть DDD, автоматизацией тестирования и иметь хорошие коммуникации внутри команды

Что значит вместе? Аналитик и тестировщик сидят рядом с разработчиком когда он кодит? В чем цель такого действия? Профит?

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

Вот товарищь Default дело говорит. Только с организационной стороны, а не с технической )

T-Shaped skills, все дела. Да же @el_bazo ?

Этапы (анализ, кодинг, тестирование, етс) есть. Но это "этапы, через которые должна пройти задача, чтобы быть выполненной", а не "этапы, на которых работает только один участник команды". Задача общая. Достигать её надо вместе. Если забксует программист - тестировщик не должен сидеть и ждать пока программист там сам разрулит. Он подключается и помогает чем может, чтобы задача перешла на этап тестирования. Аналитик тоже не занимается тем, что "выполняет аналитику только вначале, а потом сидит". Так же делает все, чтобы задача двигалась дальше

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

T-Shaped skills, все дела. Да же @el_bazo ?

Все верно

T-Shaped skills, все дела. Да же @el_bazo ?

Ой, вот про это не нужно. Эта сказка только на тестировании работает и то плохо

Человек который знает по чуть-чуть везде, не профессионал ни в чем

T-shape, это по сути узкая специализация + общий кругозор позволяющий решать задачи в узкой специализации более эффективно

Но не то, что под этим пропагандируется

И как это зависит от уровня команды? В части чего? Осознанность? Знание процесса?

Уровень в том, насколько участники команды владеют экспертизой друг-друга. Если говорить о самом утопичном (ванильном) , где они на 100% кросс-функциональные - они просто втроем делают анализ, втроем кодят, втроем тестируют. Если уровень кросс-функциональности самый низкий - носят кофе тому, кто выполняет какой-то этап, чтобы он не отвлекался и быстрее делал свою работу.

Но не то, что под этим пропагандируется

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

Да, но не выполнять их работу, как указано выше с примером про высокий уровень кросс-функциональности

Да, но не выполнять их работу, как указано выше с примером про высокий уровень кросс-функциональности

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

Человек который знает по чуть-чуть везде, не профессионал ни в чем

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

На уровне узкого специалиста работу ты не выполнишь. Понимать, не значит уметь выполнять ;)

Да, но не выполнять их работу, как указано выше с примером про высокий уровень кросс-функциональности

Я дал два "крайних" положения. Они утрированы и нежизнеспособны. Но истина где-то в балансе между ними

В общем зачем теоретизировать. Есть пример из моей практики. ТЕстировщик умел проектировать предметку. Разработчик автоматизировал тесты. А системный аналитик мог заняться ручным тестированием в случае необходимости.

Вот это все примеры и их чаще всего и приводят.

Тестировщик хорошо аналитику не выполнит, т.к. навыки другие

Ну да, в общем вопрос - как распараллелить не остался без ответа. Верите ли вы в T-Shaped это вопрос отдельный. И, если честно, не вижу смысла говорить о ВЕРЕ

Так как распараллелить-то?

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

Что конкретно в параллель идёт? Нормальная команда и так всегда поддерживает смежные этапы

Уже писал. Задавайте конкретные вопросы если что-то непонятно.

Так как распараллелить-то?

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

Заодно поможет понять специфику тиммейта и начать в неё погружаться

Ок, ладно, судя по описанному выше - аналитика не параллелиться

9 утра, суббота... а тут холивар такой)

Ок, ладно, судя по описанному выше - аналитика не параллелиться

Параллелится всё.

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

По опыту, потом ты это переделываешь и затрачивает команда вдвоём больше ресурсов

Параллелится всё.

Пришла задача на аналитика - автоматизировать процесс. Что и как вы будете параллелить?

Я бы тоже послушал как параллелить аналитику с остальным.

Другое дело, что пока анализируется что-то одно, можно заняться чем-то другим ) Это не распараллеливание, но таки помогает уловиться в спринт

Я вот чаще встречал вынос аналитики из Dev Team

Вооот, но это не параллель

Ага

Еще встречал проработку аналитики на спринт вперед, тоже не параллель.

Но завто ux, дизайн, разработка и тестирование - параллелятся. Уже неплохо )

Многим командам этого и не снилось. (уровнеь не тот:))) )

Все равно не все одновременно работают над одной задачей. Их минимум несколько

Все равно не все одновременно работают над одной задачей. Их минимум несколько

Конечно. Могут работать != работают.

И говорить о том что в один момент времени команда работает только над одной задачей в параллель некорректно

А что вы хотите?

И говорить о том что в один момент времени команда работает только над одной задачей в параллель некорректно

Да, чаще всего так не получается. Да и не нужно.

Да у нас спор вышел с ВП, вот и хотела узнать мнение сообщества, вдруг мне опыта не хватает

Кто такой ВП?

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

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

Над одной целью скорее все таки

ВП-владелец продукта, но эту тему в таком описании и от коучей часто слышу

О, щас мэтр подключится

вот его слушайте внимательно

Динара, а вы кто?

Аналитик ;) Тим-лид, наставник. Ну и по возможности пытаюсь организовать работу нескольких команд над одной системой в рамках нескольких продуктов

Народ, может кто-нибудь обьяснить на примерах, что подразумевается в аджайл, когда говорят, что аналитика, разработка и тестирование должны работать в параллель над одной историей в спринте? ;)

На практике: часто аналитик и/или дизайнер в начале спринта могут вместе договориться о концепции. Разработчики с тестировщиками об основных апи для автоматизации. Аналитики с тестировщиками об основных сценариях. И дальше по ходу синхронизироваться по мере прояснения деталей. Иногда все же кому-то нужно проработать что-то заранее, но как правило не на 100%. Удавалось такое даже в банковских условиях такое проворачивали

На практике: часто аналитик и/или дизайнер в начале спринта могут вместе договориться о концепции. Разработчики с тестировщиками об основных апи для автоматизации. Аналитики с тестировщиками об основных сценариях. И дальше по ходу синхронизироваться по мере прояснения деталей. Иногда все же кому-то нужно проработать что-то заранее, но как правило не на 100%. Удавалось такое даже в банковских условиях такое проворачивали

Концепция может меняться в процессе и на прямо противоположную :)