Интересно. Но есть вопрос - в статье упомянут остаток на складе. Как можно было бы решить следующую задачу в рамках представленного подхода:
Есть остатки на складах, есть входящий поток заказов в несколько параллельных потоков на n физических серверах, БД одна. Для каждого резервируется товар на складе. Получается такой конкурентный доступ к остаткам, и очередному заказу может не хватить.
В рамках анемичной модели с подгрузкой состояния склада в память сервера и блокировками на уровне приложения - более менее стабильно это работало только на одном сервере. На двух и более серверах остатки и резервы в конце не совпадали.
Внедрение распределенной блокировки особо не помогло. Заметное увеличение времени обработки и хоть какая-то стабильность только в рамках периода блокировки. Малейшая случайная задержка в любом месте по любой причине на большой массе заказов - выдавало расхождение остатков и резервов.
И только перенос бизнес логики в хранимую процедуру с использованием специфики БД + короткая транзакция в рамках хранимки + без перегона массива данных между сервером БД и сервером приложений по сети - дало стабильный результат - быстро и без расхождений остатков.
Но бизнес логика в хранимке - ну никак не натягивается на глобус DDD. Может вы уже решали подобную задачу в рамках DDD и есть чем поделиться?
Я не согласен с высшим образованием. Оно нужно. Хотя бы любое техническое / инженерное. Есть отдельные специальности типа «прикладная информатика в …»
Джун с вышкой по прикладной информатике - мидл по сравнению человеком с курсов без инженерной вышки. Да от вуза зависит. Но регионального вуза будет достаточно. Из тех с кем общался на собеседованиях - больше понравился иннополис. Но мне не попадались люди из МГУ/бауманки.
Встречавшиеся мне сениоры программисты с матаном в качестве вышки - еще круче. Они решают и исследуют задачи на каком-то недоступном мне уровне. Рассматривают через призму «все есть функция», с параметрами, пределам, ограничениями. Причем любую задачу, не только программирование.
Насчет походов в базу в цикле - я тут у себя недавно натолкнулся - была пакетная обработка (кешим данные из бд, запускаем цикл по массиву и выполняем какую либо работу для каждого документа). То есть экономия на запросах доп данных из базы. Нагрузочные тесты что то там показали.
Потом сменил пакетную обработку на обработку по одному документу (для каждого доп данные грузились соотвественно каждый раз) - я ожидал что будет хуже, а оказалось лучше. Тот же объем документов мало того, что обработался быстрее, так и система еще стала более отзывчива. 🤔
Там конечно очень много всего наверчено - и орм и асинк/авайты. Без пол-литра не разберешься, что именно так влияет. Но по факту - вот как есть.
и уж точно дают крышу над головой для наших семей и наполняют животы едой
На 175к в год в их городе за вменяемое время жилье не купить. Только не надо про ренту. Это временное решение. Когда дело дойдет до пенсии - окажешься на улице. Поэтому к пенсии ипотека должна быть выплачена.
У человека с 20 (когда он закончил вуз) до 65 (пенсия) - примерно 45 лет. За это время в среднем по больнице надо успеть - купить жилье, поднять детей и накопить на пенсию. Примерно и в среднем по 15 лет на каждый пункт. Дальше уже кому как - кто-то не заводит детей, а кто-то не надеется дожить до пенсии.
175 в год это примерно 10 в месяц после налогов, это примерно 3 тыс на ипотеку. Это дает максимальную стоимость жилья в 380 тыс на 15 лет. Осталось глянуть в каком городе находится компания и сколько там стоит жилье
Ага, через дорогу от Сан Франциско 😅. Кондо стоят от 550-670 тыс, таунхаусы 800-900, дома лям.
Ну вот и все ясно с ними. Почти работа за доширак, а пафосу-то сколько…
Насколько я понимаю микросервисы - это хостинг независимых (ограниченных) модулей.
То есть если монолит модульный - то переход на микросервисы - это разнести модули по серверам и наладить между ними взаимодействие через различные протоколы синхронного и асинхронного взаимодействия. Плюс подложить соломку в виде рейтрай полиси, циркуль-брейкеров, саг и тп. В конце наслаждаться тоннами денег на девопс, увеличенными задержками в обработке данных и «когда-нибудь оно будет в согласованном состоянии»
А вот если монолит не модульный. То сначала из него надо сделать модульный. Нарезать ограниченные контексты, разрезать единую бд на схемы, и тп.
В свежих мерседесах навигация с дополненной реальностью - рисует синие стрелки куда поворачивать перед перекрестками.
Но это рисуется внизу на относительно маленьком экране, что не удобно. Вот таким должно быть все лобовое стекло и стрелки должны рисовался прям перед глазами.
Остальное можно распределить по физическим и сенсорным кнопкам. Но лично я предпочитаю физические, особенно когда они необычно или круто тактильно сделаны.
Оо, воспоминание разблокировано. Я ж работал эникеем в компании по продаже компов в 2004-2007. Тоже так ездил.
Однажды попросили глянуть офисный вай-фай. Диковинка тогда была. Тормозила и прерывалась связь. Я хз что ответить. Как-то уболтал их заменить на обычные провода. Только в 2011 году я натолкнулся на аналогичное поведение у простенького роутера d link. Он не держал больше 5 коннекшенов.
А еще как-то попались бритоголовые бизнесмены из казино. Комп им нужен был. В багажнике не катался, но однажды босс попросил посмотреть домашний комп. Я немного напрягся в тот момент.
Конкретно у нас на release candidate ветке команда тестирования/сертификации гоняет особенные долгие тесты, выкатывает на тестовые серверы и серверы внутреннего пользования
Ну вот оно и тестирование, которое я имел ввиду (автотесты конечно тоже тестирование, но все же это только нижняя часть пирамиды). Получается, что остальное тестирование проводится вне рамках спринта. Отсюда вопрос. Что если нашли косяк? Что тогда с релизом и как косяк попадает обратно в спринт?
И смежный вопрос - в компании есть саппорт? Там обычно делают уровни L1 / 2 / 3, и программисты - одни из последних. И вот если есть - то кто решает саппорт тикеты на уровне программистов? Есть отдельная команда / дежурства? Или они тоже попадают в бэклог и спринты? И туда же баги, которые обнаружили уже на проде?
Ну, стейкхолдер и должен быть только на планировании, демо, ну и backlog review. Работа стейкхолдера -- быть в курсе, что команда делает и зачем. Вот прямо, чтобы "все не так, переделывайте, надо вот так" не припомню
Пожалуй, я не совсем точно задал вопрос. Поясню. Чтобы сделать нормальный продукт - надо знать что и как должно работать. В продуктах с простой предметной областью - программисты могут и сами разобраться. Но в продуктах со сложной предметной областью (финансы, логистика) - нужен бизнес-аналитик. В agile - это эксперт предметной области. Конкретно в моих успешных проектах про agile - стейкхолдер был одновременно и экспертной предметной области. И как итог - если такого человека нет, значит продукт может работать неправильно и его регулярно переделывают.
Декомпозиция и инкрементальное исполнение. Долгая переделка и потом мучительное вливание в основную ветку -- это зло, имхо. И против идей trunk-based development, используемой у нас в конторе
Тут на самом деле отдельная глубокая тема. Разве только скажу, что вот среди моих знакомых и с кем я общался в личке на хабре (кто писал крутые статьи по архитектуре и разработке) - все мы видим примерно одинаковые проблемы и предлагаем похожие идеи и решения. Нет каких-то действительно прорывных идей или серебряной пули. То есть в среднем по больнице мы все как-то пытаемся с этим справится, но вот конкретно в моем случае - этого не хватает, чтобы быстро внедрять изменения.
Можно конечно каждую секунду думать с позиции "что это все будет переделано" как на уровне архитектуры, так и кодинга. Но порой проще и быстрее тупо написать код, чем подстилать соломку везде где только можно, превращая это в fizzbuzz enterprise edition.
У меня есть конкретные примеры задач (лично моих и коллег), которые не уложились бы в недельный спринт (особенно если на продукте один программист):
БД Oracle, пришел клиент и хочет MS SQL. Если продукт находится на ранней стадии и там используется ORM - это 2-3 часа, переключить диалект, поправить строку подключения и сделать smoke тест. Но если уже были оптимизации запросов на нативном SQL - это надо все провалидировать и исправить. В зависимости от проекта это может быть десятки и сотни мест / хранимок. Плюс дефолтные уровни транзакций могут работать немного по-разному в разных СУБД. Плюс спец средства разные в разных СУБД. Плюс если до этого не выделяли время на автотесты - еще и тестирование.
Со сменой версии БД перестали работать оптимизации для нативных запросов и пришлось это все изучать и переписывать.
Замена некоторых этапов бизнес-процессов с синхронной обработки на работу через очередь.
В системе, которая работает со складскими запасам - смена парадигмы. Вместо асинхронного перерасчета после всех действий и событий - на работу в реальном времени с блокировками. Так как было несколько действий, которые влияли на состояние склада (списание, оприходование, инвентаризация) - поправить например только списание нельзя. Остальные действия будут в этот момент ломать склад или не получать актуальную информацию. А переписать все три блока - это точно не неделя.
В целом по моему личному мнению - все это из-за agile и mvp.
У меня есть пример удачного проекта в сложной предметной области - банковской сфере. Но там архитектура делалась по ватерфоллу. Oт банка даже был специальный документ по их стандартам архитектуры и встройке сторонних продуктов в их существующую инфраструктуру. И в рамках этой архитектуры, которая была сделана с запасом - реализация бизнес-логики по agile. Вот там все взлетело на ура.
В последнее время у меня соответственно неудачный пример - начали с кукурузника из говна и палок, а оказывается надо было стратегический бомбардировщик с ядерными ракетами.
Конкретно у меня сейчас спринт одна неделя, но не суть
Допустим, это выходит пятница > четверг - 5 рабочих дней, за вычетом времени на backlog review / demo-review / retro.
Если нужен анализ и дизайн, то это отдельная штуковина, делается раньше (как часть спринта) и производит новые штуковины в бэклог
Ок, выходит, что каждая штуковина проходит через все этапы в рамках скрама и спринтов, может длиться дольше чем один спринт и это воспринимается нормально. Отсюда еще вопрос - получается какие-то спринты могут содержать только например анализ и дизайн (без кодинга и тестирования) - это норм? Ведь тогда нет никакого инкрементного полезного изменения в продукте.
Если косяк небольшой и делать все равно нужно, штуковина остается открытой и переходит в следующий спринт. Если косяк существенный, но можно выделить в новую штуковину
Ок, понял.
Сейчас релиз раз в две недели. Утром во вторник выбирается билд, в котором за ночь ничего страшного не сломалось и делается release candidate branch, из которой через две недели идет релиз
Тут хотелось бы пояснений - выходит, что релиз никак не связан со спринтами и идет с запозданием. Я такого не припомню в каноничном скраме. Да и в целом в голове не укладывается (спринт должен всегда заканчиваться релизом последних задач). Почему так сделано? И что с продуктом происходит эти две недели? Я почитал про TBD - я так понимаю в trunk у вас всегда рабочая версия с зелеными тестами. То есть стараются не сливать в trunk без тестов, а если это произошло, то в первую очередь исправляют, чтобы тесты стали зелеными. Следовательно от нее в любой момент времени можно сделать релиз-кандидат.
И у меня еще есть вопросы, если позволите.
Какой состав команды у вас по ролям и кол-ву людей?
Стейкхолдер очень занят, гарантированно бывает только на планировании и на демо, на демо приходит и говорит - "немного не так" или "все не так, переделывайте, надо вот так". Сталкивались ли с такими ситуациями? Какие действия предпринимали? И в целом ваше мнение?
Работа в условиях ограниченных ресурсов. Там разные варианты могут быть. Идеальный конечно - одна полноценная команда со всеми ролями на один продукт. Худшая ситуация - только один программист и на несколько продуктов параллельно (и он везде должен успеть и в анализ, дизайн, кодинг, тестирование). Средние ситуации типа - программист занимается только одним продуктом, но Стейкхолдер/PM/PO/тестировщики - занимаются параллельно несколькими продуктами. Сталкивались ли с такими ситуациями? Какие действия предпринимали? И в целом ваше мнение?
Разработка длительных "штуковин". Например какая-то долгая задача по переделке архитектуры (так как изначально было сделано MVP на коленке) или долгие задачи, которые нельзя выложить частично или просто долгие задачи. Сталкивались ли с такими ситуациями? Какие действия предпринимали? И в целом ваше мнение?
Да и в целом смущает 5 рабочих дней на спринт. Одна обычная небольшая задача может занять больше времени - 1-2 дня на анализ, 1-2 дня на дизайн, 1-2 на кодинг, 1-2 на написание тестов. То есть по хорошему скорость будет 1 полная задача в спринт на одного программиста.
Так, у вас выходит спринт с четверга по четверг, две недели?
Пока я понял вот так
Непосредственная работа в спринте с пятницы до понедельника, при двух неделях - это 7 рабочих дней
Вторник - backlog review
Среда - ?
Четверг - demo/review + retro + planning следующего спринта
И еще несколько вопросов, мне правда интересно без всякой токсикологии
В какой день релиз?
Каждая "штуковина" (я их буду так называть, потому что они у всех по-разному называются - стори, юз кейсы, задачи) в backlog, которая попадает в спринт - внутри спринта она пройдет через все этапы (анализ, кодинг, функциональное тестирование) или у нее уже готов, например, анализ и тест кейсы (например в рамках TDD и то есть останется только кодинг)?
Куда вы впихиваете регрессионное тестирование?
Бывали ситуации когда на демо выясняется, что сделали что-то не то или не так (все мы люди и все мы ошибаемся)? И какие действия предпринимались?
И если в этом случае принималось решение о новой "штуковине" (типа доработка/исправление) - куда она шла? В бэклог или вы ее впихивали в будущий спринт? [хотя тут пожалуй ответ очевиден - в зависимости от приоритета/критичности]
А как это выглядит в коде? Отдельный метод в интерфейсе репозитория?
Интересно. Но есть вопрос - в статье упомянут остаток на складе. Как можно было бы решить следующую задачу в рамках представленного подхода:
Есть остатки на складах, есть входящий поток заказов в несколько параллельных потоков на n физических серверах, БД одна. Для каждого резервируется товар на складе. Получается такой конкурентный доступ к остаткам, и очередному заказу может не хватить.
В рамках анемичной модели с подгрузкой состояния склада в память сервера и блокировками на уровне приложения - более менее стабильно это работало только на одном сервере. На двух и более серверах остатки и резервы в конце не совпадали.
Внедрение распределенной блокировки особо не помогло. Заметное увеличение времени обработки и хоть какая-то стабильность только в рамках периода блокировки. Малейшая случайная задержка в любом месте по любой причине на большой массе заказов - выдавало расхождение остатков и резервов.
И только перенос бизнес логики в хранимую процедуру с использованием специфики БД + короткая транзакция в рамках хранимки + без перегона массива данных между сервером БД и сервером приложений по сети - дало стабильный результат - быстро и без расхождений остатков.
Но бизнес логика в хранимке - ну никак не натягивается на глобус DDD. Может вы уже решали подобную задачу в рамках DDD и есть чем поделиться?
Ого! Вот я и узнал почему был диксит и имаджинариум.
Я не согласен с высшим образованием. Оно нужно. Хотя бы любое техническое / инженерное. Есть отдельные специальности типа «прикладная информатика в …»
Джун с вышкой по прикладной информатике - мидл по сравнению человеком с курсов без инженерной вышки. Да от вуза зависит. Но регионального вуза будет достаточно. Из тех с кем общался на собеседованиях - больше понравился иннополис. Но мне не попадались люди из МГУ/бауманки.
Встречавшиеся мне сениоры программисты с матаном в качестве вышки - еще круче. Они решают и исследуют задачи на каком-то недоступном мне уровне. Рассматривают через призму «все есть функция», с параметрами, пределам, ограничениями. Причем любую задачу, не только программирование.
42 😅
Насчет походов в базу в цикле - я тут у себя недавно натолкнулся - была пакетная обработка (кешим данные из бд, запускаем цикл по массиву и выполняем какую либо работу для каждого документа). То есть экономия на запросах доп данных из базы. Нагрузочные тесты что то там показали.
Потом сменил пакетную обработку на обработку по одному документу (для каждого доп данные грузились соотвественно каждый раз) - я ожидал что будет хуже, а оказалось лучше. Тот же объем документов мало того, что обработался быстрее, так и система еще стала более отзывчива. 🤔
Там конечно очень много всего наверчено - и орм и асинк/авайты. Без пол-литра не разберешься, что именно так влияет. Но по факту - вот как есть.
А еще там написано
На 175к в год в их городе за вменяемое время жилье не купить. Только не надо про ренту. Это временное решение. Когда дело дойдет до пенсии - окажешься на улице. Поэтому к пенсии ипотека должна быть выплачена.
У человека с 20 (когда он закончил вуз) до 65 (пенсия) - примерно 45 лет. За это время в среднем по больнице надо успеть - купить жилье, поднять детей и накопить на пенсию. Примерно и в среднем по 15 лет на каждый пункт. Дальше уже кому как - кто-то не заводит детей, а кто-то не надеется дожить до пенсии.
175 в год это примерно 10 в месяц после налогов, это примерно 3 тыс на ипотеку. Это дает максимальную стоимость жилья в 380 тыс на 15 лет. Осталось глянуть в каком городе находится компания и сколько там стоит жилье
Ага, через дорогу от Сан Франциско 😅. Кондо стоят от 550-670 тыс, таунхаусы 800-900, дома лям.
Ну вот и все ясно с ними. Почти работа за доширак, а пафосу-то сколько…
В интернетах один еще одна теория - лос анджелес смарт сити, даже карты накладывают и они совпадают с картами пожаров
Насколько я понимаю микросервисы - это хостинг независимых (ограниченных) модулей.
То есть если монолит модульный - то переход на микросервисы - это разнести модули по серверам и наладить между ними взаимодействие через различные протоколы синхронного и асинхронного взаимодействия. Плюс подложить соломку в виде рейтрай полиси, циркуль-брейкеров, саг и тп. В конце наслаждаться тоннами денег на девопс, увеличенными задержками в обработке данных и «когда-нибудь оно будет в согласованном состоянии»
А вот если монолит не модульный. То сначала из него надо сделать модульный. Нарезать ограниченные контексты, разрезать единую бд на схемы, и тп.
В свежих мерседесах навигация с дополненной реальностью - рисует синие стрелки куда поворачивать перед перекрестками.
Но это рисуется внизу на относительно маленьком экране, что не удобно. Вот таким должно быть все лобовое стекло и стрелки должны рисовался прям перед глазами.
Остальное можно распределить по физическим и сенсорным кнопкам. Но лично я предпочитаю физические, особенно когда они необычно или круто тактильно сделаны.
😅😅😅 и что же чат гпт будет делать без стэк оверфлоу? На нем же, поди, и обучался
Оо, воспоминание разблокировано. Я ж работал эникеем в компании по продаже компов в 2004-2007. Тоже так ездил.
Однажды попросили глянуть офисный вай-фай. Диковинка тогда была. Тормозила и прерывалась связь. Я хз что ответить. Как-то уболтал их заменить на обычные провода. Только в 2011 году я натолкнулся на аналогичное поведение у простенького роутера d link. Он не держал больше 5 коннекшенов.
А еще как-то попались бритоголовые бизнесмены из казино. Комп им нужен был. В багажнике не катался, но однажды босс попросил посмотреть домашний комп. Я немного напрягся в тот момент.
Спасибо за ответы
А как же топ 5 окупаемых бизнесов? Помнится когтеточки были, вендинги и чеснок
Ну вот оно и тестирование, которое я имел ввиду (автотесты конечно тоже тестирование, но все же это только нижняя часть пирамиды). Получается, что остальное тестирование проводится вне рамках спринта. Отсюда вопрос. Что если нашли косяк? Что тогда с релизом и как косяк попадает обратно в спринт?
И смежный вопрос - в компании есть саппорт? Там обычно делают уровни L1 / 2 / 3, и программисты - одни из последних. И вот если есть - то кто решает саппорт тикеты на уровне программистов? Есть отдельная команда / дежурства? Или они тоже попадают в бэклог и спринты? И туда же баги, которые обнаружили уже на проде?
Пожалуй, я не совсем точно задал вопрос. Поясню. Чтобы сделать нормальный продукт - надо знать что и как должно работать. В продуктах с простой предметной областью - программисты могут и сами разобраться. Но в продуктах со сложной предметной областью (финансы, логистика) - нужен бизнес-аналитик. В agile - это эксперт предметной области. Конкретно в моих успешных проектах про agile - стейкхолдер был одновременно и экспертной предметной области. И как итог - если такого человека нет, значит продукт может работать неправильно и его регулярно переделывают.
Тут на самом деле отдельная глубокая тема. Разве только скажу, что вот среди моих знакомых и с кем я общался в личке на хабре (кто писал крутые статьи по архитектуре и разработке) - все мы видим примерно одинаковые проблемы и предлагаем похожие идеи и решения. Нет каких-то действительно прорывных идей или серебряной пули. То есть в среднем по больнице мы все как-то пытаемся с этим справится, но вот конкретно в моем случае - этого не хватает, чтобы быстро внедрять изменения.
Можно конечно каждую секунду думать с позиции "что это все будет переделано" как на уровне архитектуры, так и кодинга. Но порой проще и быстрее тупо написать код, чем подстилать соломку везде где только можно, превращая это в fizzbuzz enterprise edition.
У меня есть конкретные примеры задач (лично моих и коллег), которые не уложились бы в недельный спринт (особенно если на продукте один программист):
БД Oracle, пришел клиент и хочет MS SQL. Если продукт находится на ранней стадии и там используется ORM - это 2-3 часа, переключить диалект, поправить строку подключения и сделать smoke тест. Но если уже были оптимизации запросов на нативном SQL - это надо все провалидировать и исправить. В зависимости от проекта это может быть десятки и сотни мест / хранимок. Плюс дефолтные уровни транзакций могут работать немного по-разному в разных СУБД. Плюс спец средства разные в разных СУБД. Плюс если до этого не выделяли время на автотесты - еще и тестирование.
Со сменой версии БД перестали работать оптимизации для нативных запросов и пришлось это все изучать и переписывать.
Замена некоторых этапов бизнес-процессов с синхронной обработки на работу через очередь.
В системе, которая работает со складскими запасам - смена парадигмы. Вместо асинхронного перерасчета после всех действий и событий - на работу в реальном времени с блокировками. Так как было несколько действий, которые влияли на состояние склада (списание, оприходование, инвентаризация) - поправить например только списание нельзя. Остальные действия будут в этот момент ломать склад или не получать актуальную информацию. А переписать все три блока - это точно не неделя.
В целом по моему личному мнению - все это из-за agile и mvp.
У меня есть пример удачного проекта в сложной предметной области - банковской сфере. Но там архитектура делалась по ватерфоллу. Oт банка даже был специальный документ по их стандартам архитектуры и встройке сторонних продуктов в их существующую инфраструктуру. И в рамках этой архитектуры, которая была сделана с запасом - реализация бизнес-логики по agile. Вот там все взлетело на ура.
В последнее время у меня соответственно неудачный пример - начали с кукурузника из говна и палок, а оказывается надо было стратегический бомбардировщик с ядерными ракетами.
С наступающим.
Допустим, это выходит пятница > четверг - 5 рабочих дней, за вычетом времени на backlog review / demo-review / retro.
Ок, выходит, что каждая штуковина проходит через все этапы в рамках скрама и спринтов, может длиться дольше чем один спринт и это воспринимается нормально. Отсюда еще вопрос - получается какие-то спринты могут содержать только например анализ и дизайн (без кодинга и тестирования) - это норм? Ведь тогда нет никакого инкрементного полезного изменения в продукте.
Ок, понял.
Тут хотелось бы пояснений - выходит, что релиз никак не связан со спринтами и идет с запозданием. Я такого не припомню в каноничном скраме. Да и в целом в голове не укладывается (спринт должен всегда заканчиваться релизом последних задач). Почему так сделано? И что с продуктом происходит эти две недели? Я почитал про TBD - я так понимаю в trunk у вас всегда рабочая версия с зелеными тестами. То есть стараются не сливать в trunk без тестов, а если это произошло, то в первую очередь исправляют, чтобы тесты стали зелеными. Следовательно от нее в любой момент времени можно сделать релиз-кандидат.
И у меня еще есть вопросы, если позволите.
Какой состав команды у вас по ролям и кол-ву людей?
Стейкхолдер очень занят, гарантированно бывает только на планировании и на демо, на демо приходит и говорит - "немного не так" или "все не так, переделывайте, надо вот так". Сталкивались ли с такими ситуациями? Какие действия предпринимали? И в целом ваше мнение?
Работа в условиях ограниченных ресурсов. Там разные варианты могут быть. Идеальный конечно - одна полноценная команда со всеми ролями на один продукт. Худшая ситуация - только один программист и на несколько продуктов параллельно (и он везде должен успеть и в анализ, дизайн, кодинг, тестирование). Средние ситуации типа - программист занимается только одним продуктом, но Стейкхолдер/PM/PO/тестировщики - занимаются параллельно несколькими продуктами. Сталкивались ли с такими ситуациями? Какие действия предпринимали? И в целом ваше мнение?
Разработка длительных "штуковин". Например какая-то долгая задача по переделке архитектуры (так как изначально было сделано MVP на коленке) или долгие задачи, которые нельзя выложить частично или просто долгие задачи. Сталкивались ли с такими ситуациями? Какие действия предпринимали? И в целом ваше мнение?
Да и в целом смущает 5 рабочих дней на спринт. Одна обычная небольшая задача может занять больше времени - 1-2 дня на анализ, 1-2 дня на дизайн, 1-2 на кодинг, 1-2 на написание тестов. То есть по хорошему скорость будет 1 полная задача в спринт на одного программиста.
Позвольте задать примерно те же вопросы...
У вас двух недельные спринты?
Как вы его тратите по дням? И когда у вас релиз?
Почему демо после спринта, если по канонам (вроде как) - демо это составной элемент спринта?
Бывали ситуации когда на демо выясняется, что сделали что-то не то или не так (все мы люди и все мы ошибаемся)? И какие действия предпринимались?
Так, у вас выходит спринт с четверга по четверг, две недели?
Пока я понял вот так
Непосредственная работа в спринте с пятницы до понедельника, при двух неделях - это 7 рабочих дней
Вторник - backlog review
Среда - ?
Четверг - demo/review + retro + planning следующего спринта
И еще несколько вопросов, мне правда интересно без всякой токсикологии
В какой день релиз?
Каждая "штуковина" (я их буду так называть, потому что они у всех по-разному называются - стори, юз кейсы, задачи) в backlog, которая попадает в спринт - внутри спринта она пройдет через все этапы (анализ, кодинг, функциональное тестирование) или у нее уже готов, например, анализ и тест кейсы (например в рамках TDD и то есть останется только кодинг)?
Куда вы впихиваете регрессионное тестирование?
Бывали ситуации когда на демо выясняется, что сделали что-то не то или не так (все мы люди и все мы ошибаемся)? И какие действия предпринимались?
И если в этом случае принималось решение о новой "штуковине" (типа доработка/исправление) - куда она шла? В бэклог или вы ее впихивали в будущий спринт? [хотя тут пожалуй ответ очевиден - в зависимости от приоритета/критичности]
Охтыж, на ностальгию пробило - Полководец у меня была.