Бггг. Яркие и неординарные личности тоскуют - их опять не поняла толпа леммингов ))

На серьёзной ноте: если тебе категорически не нравятся дэйлики, и ты смог построить себе жизнь так, чтобы дейликов в ней не было - ты молодец, однозначно.

категорически не нравится карго культ )

дэйлики у меня есть в 2х командах

скоро отменят

раньше были во всех

С точки зрения потока работ: дэйли — это точка синхронизации. Вопрос бизнесовый тут ровно один: будет от такой точки синхронизации польза или нет?

Соответственно, если мы оптимизируем throughput команды, то задача в том, чтобы организовать поток работ (передачу информации, артефактов и пр) максимально асинхронно. Чтобы точек синхронизации было меньше.

Если же мы оптимизируем что-то другое — например latency на каких-то релизах или этапах проекта или минимизируем нервное напряжение заказчика или ещё что-то, то дэйли — это совершенно нормальная и полезная практика.

И на сладкое: в одном и том же проекте при разных вводных и разных этапах дэйли могут полезны или вредны. И иногда полезно то вводить, но убирать.

Шах и мат всем в этом треде.

ну так а я о чем говорил? с головой надо подходить к любой практике
Леша ворвался и решил раскрыть вопрос =)

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

но мысль верная

Да, конечно. Но суть ухода от дэйли — это устранение синхронных точек коммуникации. Или есть другие причины уходить от митингов?

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

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

Чем плохи разные часовые пояса? Ровно тем, что сложно выбрать точку синхронизации, удобную всем членам команды, — так?

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

Реальность в том, что обычно куски сами по себе никому не нужны. Нужен какой-то работающий продукт. Так что стыковаться с другими кусками всё равно как-то придётся. И надо какой-то порядок состыковки определить.

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

Ну и так далее и так далее.

«Здравый смысл» - плохой сигнал. Когда аргументируют что-то «здравым смыслом» - значит метрик нету :(

так погоди
вот тебе команда в 10 человек с дизайнерами, фронтами, бэками, продуктами

и вот тебе разработка поделившаяся на бэк+фронт - они хавают ценность одну с доски и синкаться им не надо - точка синхронизации - Git, раз в 15 минут коммит в мастер и все видят что ты сделал

закон гудхарта вашим метрикам )

Короче, нету никакой серебряной пули. Надо:
1. понимать структуру проекта
2. Уметь разбивать проект на этапы
3. Выстраивать для этапов потоки работ
4. Понять, какие метрики являются ключевыми на каждом этапе
5. Понять органичения как проекта в целом, так и каждого этапа. Как проектные, так и организационные (включая время, людей, часовые пояса команды и пр.)
6. По результатам — адаптировать рабочий процесс на каждом этапе, чтобы лучше достигать целевых метрик. Включая добавление или отмену дэйли, регулярные демо, методологию работы (организационные фреймворки) и многое другое

Загуглил. Спасибо.