какого рода требования они пишут

и почему им для этого надо знать «потроха системы»?

Аналитики пока что вне команды

Пишут функциональные требования, но зачастую чтобы написать, надо понять, как есть

И получается так что кроме разработчиков никто толком не знает ничего

ну, тут, конечно, надо больше контекста, но в моем понимании, либо они должны быть частью команды, либо все-таки они должны писать user-story, и описывать все-таки со стороны пользователя продукта

Даже если они часть команды - что это изменит?

Ведь им надо будет сформировать истории на следующие спринты, а не текущий

На текущий спринт истории уже написаны, оценены и разрабатываются

А вот на следующий они как раз и готовят новые

как у вас выглядят истории? можете какой-нибудь пример привести?

Да, чуть позже, на телефоне неудобно в джиру лезть :)

окей)

в личку скинул

У меня есть книга норма керта.

мы уже тоже заказали))

но почему девочка, а зовут Даня?

Даня - производная от Дарьи)

в личку скинул

Кейс простой - если мы хотим организовать работу с legasy

Значит мы признаем что вся система есть технический долг

один большой технический долг

Соответственно в таком случае у тебя должны возникнуть истории типа "Я как разработчик хочу понять как этот блок работает"

и "Я как разработчик хочу эту хрень отрефакторить"

критерий успешности таких историй будет таким чтобы тот кто берет такую историю в работу - смог команде продемонстрировать результат свое работы

в книге http://www.ozon.ru/context/detail/id/135326154/ в главе 8 рассказано как с техдолгом жить и работать

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

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

Превращение legacy в новое legacy должно быть обосновано с точки зрения бизнеса.

Конечно

Потому вся система и не переписывается

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

Мы в техдолг уходим а вопрос не в нем :)

Обоснование может быть таким: "вот у нас такие-то истории занимают столько-то времени, и вот эти ошибки возникли из-за высокой complexity нашего монолита, МЫ ПОТЕРЯЛИ НА ЭТОМ время/деньги/..., предлагаю A,B,C"

Да, так и делаем

Не надо решать за бизнес

это старая история

а я про то что если система непонятна команде

значит нужно запускать "Изучение системы"

Денег в изучении системы нет :)

да прям...

это же вопрос обязательств

Монстр который разрабатывался около 10 лет

команда берет на себя обязательства - изучить систему и повысить скорость разработки функционала для бизнеса

Серёг - вспомни старые свои проекты: да пофигу

это тоже самое что "семеркой" 1С сейчас владеть

савокупная стоиомсть владения legasy системой огромная

для особых бизнесменов - можно даже подсчитать

еще и Грефа приплести

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

про time to market

time to market не цель

это цель у продуктовых компаний, и к этому надо дописать fit for purpose

программисты :)

тут давеча люди ввели понятие Continious Product Learning

собственно оттуда все кейсы и берутся

Погуглю, как обычно наверное что-то очевидное за красивым названием :)

в книге http://www.ozon.ru/context/detail/id/135326154/ в главе 8 рассказано как с техдолгом жить и работать

Только не читайте книгу на русском, там адовый перевод. А сама книга - очень хорошая ;)

Мы её читаем вот так

😂

😀

Оч знакомая ситуация, что описана выше. В прошлой компании была 1 в 1

Задел спринта это сильно. Заделать задел спринта.

Боже мой, переводчики извращенцы 😭

И спринт состоит из средств :)

"ежедневное стояние" - мое любимое ;)

Чувствую неправильную локализацию мы сделали...

Вдруг кому нужно... https://drive.google.com/open?id=0B0RtsuDjIW5BS2pKbHlfY2ZhREk (Революционный метод управления проектами, Д. Сазерленд)

тег book

Чувствую неправильную локализацию мы сделали...

Это иконка?

ассоциации с фильмом "звонок" 😄 а вообще какой-то оффтоп пошел вроде бы, а?.. 😉

Я через минут 10 удалю, сорян

а может ли ИИ обучить команду Agile подходам?

а может ли ИИ обучить команду Agile подходам?

Почему нет

Это иконка?

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

ИИ - искусственный интеллект?

Илексей Ильичев

@alexandronov есть бот-скраммастер для слака

Marina о, а можно ссылочку?

https://www.scrumbot.co/