Ну вот оно и тестирование, которое я имел ввиду (автотесты конечно тоже тестирование, но все же это только нижняя часть пирамиды). Получается, что остальное тестирование проводится вне рамках спринта.
Нет! :-) Отдельное тестирование release candidate -- важная, но все же небольшая часть тестирования. Это дополнительная линия защиты. Каждый случай бага, требующего фикса в релизной ветке -- это экстренная ситуация. Почти всегда делаем Root Cause Analysis и улучшаем основное тестирование.
Но я последний десяток лет работаю в data storage и с чрезвычайно сильным фокусов на качестве и тестировании. Потому что терять данные пользователей -- нехорошо :-) Возможно, в других областях сложнее достичь высокий уровень тестирования.
Отсюда вопрос. Что если нашли косяк? Что тогда с релизом и как косяк попадает обратно в спринт?
Сначала решаем, насколько серьезный косяк. Иногда можно все же выпустить релиз, а чинить потом. Идет в бэклог команды, ответственной за область продукта, где нашли косяк. Ведь скорей всего эта команда косяк и произвела :-) Команда со своим стейкхолдером решает, когда делать.
Если чинить нужно обязательно в этом релизе, то это release blocker. Ответственная команда все бросает (не обязательно вся команда, конечно, может быть, что только один-два человека) и фокусируется на починке косяка в основной ветке и бэкпорт в релизную ветку (или откат функционала из релизной ветки, если быстро починить нельзя -- потом идет в обычный бэклог). Это, конечно, влияет на текущий спринт, а то и два. Что-то будет не сделано и пойдет в следующий спринт. Это нормально. Если PO не понимает, что происходит, и требует выполнения целей спринта, ну, это плохой PO :-)
Тут хочу отметить, что я фундаментально не согласен вот с этим утверждением из исходной статьи ("команда обязана выполнить все запланированные задачи"). Скрам нигде это не требует. Это идеальная цель, но не жесткое требование.
И смежный вопрос - в компании есть саппорт? Там обычно делают уровни L1 / 2 / 3, и программисты - одни из последних. И вот если есть - то кто решает саппорт тикеты на уровне программистов? Есть отдельная команда / дежурства? Или они тоже попадают в бэклог и спринты? И туда же баги, которые обнаружили уже на проде?
Могу рассказать, как у нас устроено, это не секрет. Так как продукт -- data storage, то "пользователи" обычно люди типа сис-админов. Первый уровень саппорта -- технические специалисты поддержки, которые хорошо разбираются в продукте и разных предметных областях применения (есть специализация, конечно). Дальше есть выделенная команда программистов с ротацией в полгода примерно (кто-то сидит дольше, потому что нравится). Их работа -- разбираться со сложными проблемами непосредственно у пользователей и чинить баги, на которые они могут найти время. У этой команда, естественно никакого скрама, потому что работа часто меняется. Канбан в чистом виде. Но иногда они могут делать вполне себе фичи. Например, улучшить телеметрию или запилить улучшение производительности.
Если нужна экспертиза в какой-то специальной части продукта, то привлекают нужных людей из других команда для консультации и код ревью. Если фикс слишком большой, то стейкхолдеры между собой договариваются, в какую обычную команду надо отправить, и какое место в их бэклоге. Тут уже вопрос приоритетов. Если нужно починить Б быстрее, то работа над А замедлится. Нет волшебного решения.
Эта специальная команда дежурит в обычное рабочее время. В остальное время дежурят программисты из обычных команд. Получается 2-3 дежурства в год по неделе. За прошедший год у меня бы один вызов ночью :-) и то не в мое дежурство, а так получилось по цепочке специалистов в конкретной предметной области. В общем, мне кажется, не на что жаловаться.
Конкретно в моих успешных проектах про agile - стейкхолдер был одновременно и экспертной предметной области. И как итог - если такого человека нет, значит продукт может работать неправильно и его регулярно переделывают.
Это обязательно! Стейкхолдер/PO обязан быть экспертом в предметной области для успешной работы команды. В целом, agile подразумевает, что программисты в команде понимают предметную область. Это значит, что в начале всегда будет этап обучения и разбирательства. Но у программиста команды всегда должна быть возможность позвать PO и сказать, что "X -- это не технический вопрос, а продуктовый. Разберись и реши, как должно быть". Причем, один-два программиста из команды вполне могут принимать участие в разбирательстве.
У меня есть конкретные примеры задач (лично моих и коллег), которые не уложились бы в недельный спринт
Примеры очень жизненные! Конечно, полно задач, которые занимают месяц, два, три, дольше. Но это очень высокоуровневые задачи. Опять же, с колокольни Trunk-Based Development это решается с помощью feature flags. Например, если нужно переехать с асинхронного пересчета на блокирующий, то начинаем с крохотной подсистемы, которая выключена по умолчанию в продукте. Но! Мы постоянно гоняем тесты в новом режиме для той функциональности, которая уже работает. Каждый спринт что-то улучшается и можно продемонстрировать новый результат. Даже если он еще недоступен в основном продукте, это все равно инкремент. В какой-то момент можно делать пробные переключения на новую подсистему, смотреть, что сломалось и планировать работу дальше.
Может показаться, что тут много работы на выброс. Имхо, это не так. Уверенность в том, что все работает так, как задумано, стоит затрат.
банковской сфере. Но там архитектура делалась по ватерфоллу.
Банковская сфера очень сильно зарегулирована, как я понимаю. Многие решения и требования определяются законами и правилами.
начали с кукурузника из говна и палок, а оказывается надо было стратегический бомбардировщик с ядерными ракетами.
Да, бывает такое. я не знаю общего решения, но по опыту выходит, что какой именно бомбардировщик нужен -- точно неизвестно пока не попробовать. Часто кукурузник через три месяца лучше, чем авиалайнер через два года.
Да, много вопросов :-) это хорошо, наверное. Попробую ответить на все.
Отсюда еще вопрос - получается какие-то спринты могут содержать только например анализ и дизайн (без кодинга и тестирования) - это норм? Ведь тогда нет никакого инкрементного полезного изменения в продукте.
В теории, да, могут. Тут есть несколько наблюдений.
Во-первых, на практике никто не может дизайнить 8 часов в день, нужны отвлечения на утрясти мысли.
Во-вторых, даже в новом проекте всегда есть понятная работа, которую все равно нужно делать. Плюс разобраться с багами из Continuous Integration. Или код ревью для соседней команды. Или наконец-то уговорить PO протащить в верх бэклога задачу (штуковину, юзер стори) по улучшению какой-нибудь внутренней утилиты, которую долго откладывали. Всегда есть, чем заняться.
В-третьих, в agile в целом не принято big design upfront. Если три месяца что-то анализировать и дизайнить, а потом год делать, то может оказаться, что задизайненное и не нужно. :-) Понятно, что решения, которые потом сложно изменить, стоит продумывать хорошо. Но в целом, если у вас хорошее тестирование, не слишком страшная организация кода, то важный agile принцип -- дизайнить минимальную вещь, а кодовая база должна быть в состоянии, когда можно относительно легко делать большие изменения.
В четвертых, инкременты. В сферическом вакууме, да, каждая юзер стори и каждый спринт должны приносить пользу некоторому пользователю, который в конечном итоге приносит деньги. На практике, выгодополучать юзер стори (иногда, называют персона) может быть не конечный пользователь продукта, а сисадмин, сотрудник тех поддержки, ваш тестировщик, ваш аналитик телеметрии, даже вы как разработчик. Например, инкремент вполне может быть "Мы разобрались с неведомой хней Х и теперь знаем, что делать в фиче Y".
Тут хотелось бы пояснений - выходит, что релиз никак не связан со спринтами и идет с запозданием. Я такого не припомню в каноничном скраме. Да и в целом в голове не укладывается (спринт должен всегда заканчиваться релизом последних задач). Почему так сделано?
Честно говоря, не припомню, чтобы скрам предписывал механизм релиза продукта. Сейчас мельком глянул https://scrumguides.org/scrum-guide.html -- тоже не вижу, но может не заметил. Да, спринт заканчивается релизом последних задач в том смысле, что код влит в основную ветку, все работает, вы можете продемонстрировать улучшение. А вот когда это улучшение попадет к пользователям, вы не контролируете.
И что с продуктом происходит эти две недели?
Конкретно у нас на release candidate ветке команда тестирования/сертификации гоняет особенные долгие тесты, выкатывает на тестовые серверы и серверы внутреннего пользования (dogfood, не знаю, есть ли устоявший русский термин), гоняет стресс тесты, делает некоторое ручное тестирование по чеклистам. Это чтобы поймать баги, которые пролезли через обычный continuous integration/testing.
Я почитал про TBD - я так понимаю в trunk у вас всегда рабочая версия с зелеными тестами. То есть стараются не сливать в trunk без тестов, а если это произошло, то в первую очередь исправляют, чтобы тесты стали зелеными. Следовательно от нее в любой момент времени можно сделать релиз-кандидат.
Да, именно так. За попытку залить в транк без тестов будет ай-ай-ай на код ревью.
Какой состав команды у вас по ролям и кол-ву людей?
Сейчас команда 8 разработчиков (два принципал, три сеньора, два мидл, один джуниор -- но звания между конторами и странами сложно сравнивать). я выше (https://habr.com/ru/articles/869164/comments/#comment_27731170) писал, что 8 -- это максимум. Роли примерно все одинаковые из-за особенностей проекта (не могу деталей).
Стейкхолдер очень занят, гарантированно бывает только на планировании и на демо, на демо приходит и говорит - "немного не так" или "все не так, переделывайте, надо вот так". Сталкивались ли с такими ситуациями? Какие действия предпринимали? И в целом ваше мнение?
Ну, стейкхолдер и должен быть только на планировании, демо, ну и backlog review. Работа стейкхолдера -- быть в курсе, что команда делает и зачем. Вот прямо, чтобы "все не так, переделывайте, надо вот так" не припомню.
Худшая ситуация - только один программист и на несколько продуктов параллельно (и он везде должен успеть и в анализ, дизайн, кодинг, тестирование).
"только один программист и на несколько продуктов параллельно" -- это не скрам :-) Это что-то другое. Хорошо или плохо -- отдельный вопрос. Но скрам это про то, когда команда работает над одной общей целью в течение некоторого времени. Если нужно все везде успеть, то канбан будет лучше.
Стейкхолдер/PM/PO/тестировщики - занимаются параллельно несколькими продуктами.
Это как раз нормальное. PO часто курирует несколько команд, иногда по несвязанным проектам. Тяжелая доля :-)
Разработка длительных "штуковин". Например какая-то долгая задача по переделке архитектуры (так как изначально было сделано MVP на коленке) или долгие задачи, которые нельзя выложить частично или просто долгие задачи.
Декомпозиция и инкрементальное исполнение. Долгая переделка и потом мучительное вливание в основную ветку -- это зло, имхо. И против идей trunk-based development, используемой у нас в конторе.
Да и в целом смущает 5 рабочих дней на спринт. Одна обычная небольшая задача может занять больше времени - 1-2 дня на анализ, 1-2 дня на дизайн, 1-2 на кодинг, 1-2 на написание тестов. То есть по хорошему скорость будет 1 полная задача в спринт на одного программиста.
Если коротко, то это нормально. Большие задача бьют на части, которые предположительно можно сделать за один спринт.
Почему нельзя? Можно и даже может быть нужно! Если у вас основная ветка всегда в хорошем состоянии, то вы легко каждые 2-3 недели можете делать релиз с тем, что работает.
"Суета" она не про релизы, а про то, чтобы все в команде точно знали, что они делают, зачем они это делают, и куда проект в целом двигается. Границы спринтов это точки корректировки направления работы.
Конкретно у меня сейчас спринт одна неделя, но не суть. Одна-две почти без разницы, вопрос предпочтений команд и других процессов в конторе. Больше двух недель -- имхо, плохо, слишком долго между моментами синхронизации "а в правильную сторону ли я иду" :-)
Вторник -- backlog review это час плюс какое-то время на подготовку для тех, у кого была "домашняя работа" с прошлого раза приготовить содержательно новые задачи. В остальном это обычный рабочий день.
Среда -- тоже обычный рабочий день, но может быть с неким фокусом на чистку хвостов, которые отложили в начале спринта.
Про четверг я выше в другом ответе написал, но повторю для контекста. Demo/review -- 30 минут. Retro -- 45 минут. Planning -- 30 минут.
В какой день релиз?
У нас то, что можно описать Trunk-Based Development (на хабре была статья про это https://habr.com/ru/articles/794246/ со ссылками на доп материал). Сейчас релиз раз в две недели. Утром во вторник выбирается билд, в котором за ночь ничего страшного не сломалось и делается release candidate branch, из которой через две недели идет релиз.
День внешнего релиза по идее не должен быть никак связан с границами ваших спринтов.
Каждая "штуковина" (я их буду так называть, потому что они у всех по-разному называются - стори, юз кейсы, задачи) в backlog, которая попадает в спринт - внутри спринта она пройдет через все этапы (анализ, кодинг, функциональное тестирование) или у нее уже готов, например, анализ и тест кейсы (например в рамках TDD и то есть останется только кодинг)?
Штуковина, идущая в спринт должна быть размера, который хотя бы теоретически можно сделать за спринт. Если нужен анализ и дизайн, то это отдельная штуковина, делается раньше (как часть спринта) и производит новые штуковины в бэклог. Понятно, что анализ и дизайн не всегда можно вместить в рамки спринта (может, надо время на подумать и утрясти идеи), такие штуковины могут длиться дольше.
Имхо, важный момент, что это ошибка считать, что все штуковины должны быть выполнены в спринт или ужас-ужас-ужас :-) Спринты -- это про организацию работы и точки корректировки, а не про обещания сделать что-то к определенному дню.
Куда вы впихиваете регрессионное тестирование?
В agile почти все тестирование -- это часть обычной работы, и почти все тестирование автоматическое. Вы пишите и тесты и код. Continuous Integration гоняет тесты на ваших изменениях и на основной ветке постоянно.
Если говорить совсем категорично: например, если вы делаете задачу, а потом неделю ждете, пока человеческие тестеры ее проверят и вернут на доработку (баги или недочеты), то это не agile, а что-то другое.
Бывали ситуации когда на демо выясняется, что сделали что-то не то или не так (все мы люди и все мы ошибаемся)? И какие действия предпринимались?
Если косяк выясняется на демо, это значит, что на нескольких более ранних этапах его не выявили (например, во время проверки Acceptance Criteria). Бывает, конечно, тогда это тема для ретро -- обсудить, почему не выявили раньше. Но так как спринт короткий, то цена ошибки не очень велика. Если косяк небольшой и делать все равно нужно, штуковина остается открытой и переходит в следующий спринт. Если косяк существенный, но можно выделить в новую штуковину.
И если в этом случае принималось решение о новой "штуковине" (типа доработка/исправление) - куда она шла? В бэклог или вы ее впихивали в будущий спринт? [хотя тут пожалуй ответ очевиден - в зависимости от приоритета/критичности]
В бэклог по умолчанию. На следующем backlog review разбираться с приоритетом. Если важно и срочно, то естественно можно на месте со stakeholder разобраться, когда делать. Вполне нормально, что новая вещь идет в верх бэклога и берется сразу в следующий спринт.
Demo/review -- 30 минут. Retro -- 45 минут. Planning -- 30 минут. Если у вас существенно дольше, то что-то делается не так :-) Это если вы разработчик. Если вы -- заинтересованное лицо (stakeholder, не уверен, какой устоявшийся русский термин), то календарь, конечно, может быть забит сильно. Но у stakeholders всегда так независимо от методологии.
Давайте отвечу на простой вопрос из абзаца в конце.
Например, граница спринта в четверг, в который идут demo/review и retro закончившегося спринта, а потом planning начинающегося. А во вторник за два дня -- backlog review, чтобы были готовы актуальные задачи для выбора в четверг.
Спасибо. А то я, не разобравшись, почему-то подумал, что это закрытые платформы, хотя очевидно, такой подход не взлетит, если только это не Switch, например.
Что интересно, ссылка на ZeroVer описывает состояние, но не объясняет, почему это хорошо 😀
Например, если все версии начинаются с 0, то этот ноль уже ничего не значит и просто мусор.
Возможно, нужно считать, что первый 0 значит, что нет никаких гарантий обратной совместимости между версиями. Но на практике вроде какая-то совместимость есть же?
Думаю, что работать над чем-то на чистом Rust в крупных существующих продуктах -- это редкость и роскошь.
Обычно будет куча уже присутствующего кода, и нужно будет усиленно воевать с ffi, потому что идеально отсечь интерфейсы и структуры данных -- очень сложно, даже если это совсем новая фича.
Примеров не знаю, но сейчас рекордно низкий уровень безработицы. Как вы написали, это не значит, что у конторы все плохо и на грани банкротства. Однако это значит, что очень сложно найти замену ушедшему сотруднику или набрать людей на новые проекты.
Имхо, самый важный вопрос от комментатора выше (и вопрос, который возник у меня) это зачем нужно самому реализовывать install/start/stop/uninstall? Ведь есть уже встроенные утилиты, которые это делают. Для понимая устройства сервисов новичком этот код ничего не даёт, а только отвлекает от собственно тела сервиса.
Статья на этот вопрос не отвечает, запутывая читателей. Для новичков слишком много информации сразу. Для не новичков -- непонятно, зачем.
В крайнем случае, эти примеры можно было бы вынести в приложение в конце.
Новости ещё и способ быстро узнать что-то новое. Взять на заметку, мол, вдруг пригодиться. Если новость не содержит достаточно контекста для такой заметки и требует дополнительного исследования, то теряется быстрота.
И вроде бы должно быть пофигу, но остаётся ощущение, что автор не заботится о читателях.
Skype for Business не имеет с обычным Skype ничего общего (кроме названия) и произрастает из прошлых продуктов: Lync и ранее Communicator. Lync вовсю использовался внутри самой Майкрософт.
Teams снова вырос совершенно отдельно и вытеснил Skype for Business. Как так вышло внутри -- я не знаю.
Нет! :-) Отдельное тестирование release candidate -- важная, но все же небольшая часть тестирования. Это дополнительная линия защиты. Каждый случай бага, требующего фикса в релизной ветке -- это экстренная ситуация. Почти всегда делаем Root Cause Analysis и улучшаем основное тестирование.
Но я последний десяток лет работаю в data storage и с чрезвычайно сильным фокусов на качестве и тестировании. Потому что терять данные пользователей -- нехорошо :-) Возможно, в других областях сложнее достичь высокий уровень тестирования.
Сначала решаем, насколько серьезный косяк. Иногда можно все же выпустить релиз, а чинить потом. Идет в бэклог команды, ответственной за область продукта, где нашли косяк. Ведь скорей всего эта команда косяк и произвела :-) Команда со своим стейкхолдером решает, когда делать.
Если чинить нужно обязательно в этом релизе, то это release blocker. Ответственная команда все бросает (не обязательно вся команда, конечно, может быть, что только один-два человека) и фокусируется на починке косяка в основной ветке и бэкпорт в релизную ветку (или откат функционала из релизной ветки, если быстро починить нельзя -- потом идет в обычный бэклог). Это, конечно, влияет на текущий спринт, а то и два. Что-то будет не сделано и пойдет в следующий спринт. Это нормально. Если PO не понимает, что происходит, и требует выполнения целей спринта, ну, это плохой PO :-)
Тут хочу отметить, что я фундаментально не согласен вот с этим утверждением из исходной статьи ("команда обязана выполнить все запланированные задачи"). Скрам нигде это не требует. Это идеальная цель, но не жесткое требование.
Могу рассказать, как у нас устроено, это не секрет. Так как продукт -- data storage, то "пользователи" обычно люди типа сис-админов. Первый уровень саппорта -- технические специалисты поддержки, которые хорошо разбираются в продукте и разных предметных областях применения (есть специализация, конечно). Дальше есть выделенная команда программистов с ротацией в полгода примерно (кто-то сидит дольше, потому что нравится). Их работа -- разбираться со сложными проблемами непосредственно у пользователей и чинить баги, на которые они могут найти время. У этой команда, естественно никакого скрама, потому что работа часто меняется. Канбан в чистом виде. Но иногда они могут делать вполне себе фичи. Например, улучшить телеметрию или запилить улучшение производительности.
Если нужна экспертиза в какой-то специальной части продукта, то привлекают нужных людей из других команда для консультации и код ревью. Если фикс слишком большой, то стейкхолдеры между собой договариваются, в какую обычную команду надо отправить, и какое место в их бэклоге. Тут уже вопрос приоритетов. Если нужно починить Б быстрее, то работа над А замедлится. Нет волшебного решения.
Эта специальная команда дежурит в обычное рабочее время. В остальное время дежурят программисты из обычных команд. Получается 2-3 дежурства в год по неделе. За прошедший год у меня бы один вызов ночью :-) и то не в мое дежурство, а так получилось по цепочке специалистов в конкретной предметной области. В общем, мне кажется, не на что жаловаться.
Это обязательно! Стейкхолдер/PO обязан быть экспертом в предметной области для успешной работы команды. В целом, agile подразумевает, что программисты в команде понимают предметную область. Это значит, что в начале всегда будет этап обучения и разбирательства. Но у программиста команды всегда должна быть возможность позвать PO и сказать, что "X -- это не технический вопрос, а продуктовый. Разберись и реши, как должно быть". Причем, один-два программиста из команды вполне могут принимать участие в разбирательстве.
Примеры очень жизненные! Конечно, полно задач, которые занимают месяц, два, три, дольше. Но это очень высокоуровневые задачи. Опять же, с колокольни Trunk-Based Development это решается с помощью feature flags. Например, если нужно переехать с асинхронного пересчета на блокирующий, то начинаем с крохотной подсистемы, которая выключена по умолчанию в продукте. Но! Мы постоянно гоняем тесты в новом режиме для той функциональности, которая уже работает. Каждый спринт что-то улучшается и можно продемонстрировать новый результат. Даже если он еще недоступен в основном продукте, это все равно инкремент. В какой-то момент можно делать пробные переключения на новую подсистему, смотреть, что сломалось и планировать работу дальше.
Может показаться, что тут много работы на выброс. Имхо, это не так. Уверенность в том, что все работает так, как задумано, стоит затрат.
Банковская сфера очень сильно зарегулирована, как я понимаю. Многие решения и требования определяются законами и правилами.
Да, бывает такое. я не знаю общего решения, но по опыту выходит, что какой именно бомбардировщик нужен -- точно неизвестно пока не попробовать. Часто кукурузник через три месяца лучше, чем авиалайнер через два года.
Cheers!
Да, много вопросов :-) это хорошо, наверное. Попробую ответить на все.
В теории, да, могут. Тут есть несколько наблюдений.
Во-первых, на практике никто не может дизайнить 8 часов в день, нужны отвлечения на утрясти мысли.
Во-вторых, даже в новом проекте всегда есть понятная работа, которую все равно нужно делать. Плюс разобраться с багами из Continuous Integration. Или код ревью для соседней команды. Или наконец-то уговорить PO протащить в верх бэклога задачу (штуковину, юзер стори) по улучшению какой-нибудь внутренней утилиты, которую долго откладывали. Всегда есть, чем заняться.
В-третьих, в agile в целом не принято big design upfront. Если три месяца что-то анализировать и дизайнить, а потом год делать, то может оказаться, что задизайненное и не нужно. :-) Понятно, что решения, которые потом сложно изменить, стоит продумывать хорошо. Но в целом, если у вас хорошее тестирование, не слишком страшная организация кода, то важный agile принцип -- дизайнить минимальную вещь, а кодовая база должна быть в состоянии, когда можно относительно легко делать большие изменения.
В четвертых, инкременты. В сферическом вакууме, да, каждая юзер стори и каждый спринт должны приносить пользу некоторому пользователю, который в конечном итоге приносит деньги. На практике, выгодополучать юзер стори (иногда, называют персона) может быть не конечный пользователь продукта, а сисадмин, сотрудник тех поддержки, ваш тестировщик, ваш аналитик телеметрии, даже вы как разработчик. Например, инкремент вполне может быть "Мы разобрались с неведомой хней Х и теперь знаем, что делать в фиче Y".
Честно говоря, не припомню, чтобы скрам предписывал механизм релиза продукта. Сейчас мельком глянул https://scrumguides.org/scrum-guide.html -- тоже не вижу, но может не заметил. Да, спринт заканчивается релизом последних задач в том смысле, что код влит в основную ветку, все работает, вы можете продемонстрировать улучшение. А вот когда это улучшение попадет к пользователям, вы не контролируете.
Конкретно у нас на release candidate ветке команда тестирования/сертификации гоняет особенные долгие тесты, выкатывает на тестовые серверы и серверы внутреннего пользования (dogfood, не знаю, есть ли устоявший русский термин), гоняет стресс тесты, делает некоторое ручное тестирование по чеклистам. Это чтобы поймать баги, которые пролезли через обычный continuous integration/testing.
Да, именно так. За попытку залить в транк без тестов будет ай-ай-ай на код ревью.
Сейчас команда 8 разработчиков (два принципал, три сеньора, два мидл, один джуниор -- но звания между конторами и странами сложно сравнивать). я выше (https://habr.com/ru/articles/869164/comments/#comment_27731170) писал, что 8 -- это максимум. Роли примерно все одинаковые из-за особенностей проекта (не могу деталей).
Ну, стейкхолдер и должен быть только на планировании, демо, ну и backlog review. Работа стейкхолдера -- быть в курсе, что команда делает и зачем. Вот прямо, чтобы "все не так, переделывайте, надо вот так" не припомню.
"только один программист и на несколько продуктов параллельно" -- это не скрам :-) Это что-то другое. Хорошо или плохо -- отдельный вопрос. Но скрам это про то, когда команда работает над одной общей целью в течение некоторого времени. Если нужно все везде успеть, то канбан будет лучше.
Это как раз нормальное. PO часто курирует несколько команд, иногда по несвязанным проектам. Тяжелая доля :-)
Декомпозиция и инкрементальное исполнение. Долгая переделка и потом мучительное вливание в основную ветку -- это зло, имхо. И против идей trunk-based development, используемой у нас в конторе.
Если коротко, то это нормально. Большие задача бьют на части, которые предположительно можно сделать за один спринт.
Daily 15 минут. Если нужно что-то более подробно пообсуждать, то те, кому надо, отдельными группами собираются после daily.
Максимальный размер скрам команды 6-8 человек. Причем 7-8 только если все очень организованные и сработанные. Реально 4-6 человек макс.
То, что вы описали, скрам на 22 человека -- это вообще ужас-ужас-ужас бессмысленно и беспощадно. Такая игра в agile без понимания 🙁
Почему нельзя? Можно и даже может быть нужно! Если у вас основная ветка всегда в хорошем состоянии, то вы легко каждые 2-3 недели можете делать релиз с тем, что работает.
"Суета" она не про релизы, а про то, чтобы все в команде точно знали, что они делают, зачем они это делают, и куда проект в целом двигается. Границы спринтов это точки корректировки направления работы.
Конкретно у меня сейчас спринт одна неделя, но не суть. Одна-две почти без разницы, вопрос предпочтений команд и других процессов в конторе. Больше двух недель -- имхо, плохо, слишком долго между моментами синхронизации "а в правильную сторону ли я иду" :-)
Вторник -- backlog review это час плюс какое-то время на подготовку для тех, у кого была "домашняя работа" с прошлого раза приготовить содержательно новые задачи. В остальном это обычный рабочий день.
Среда -- тоже обычный рабочий день, но может быть с неким фокусом на чистку хвостов, которые отложили в начале спринта.
Про четверг я выше в другом ответе написал, но повторю для контекста. Demo/review -- 30 минут. Retro -- 45 минут. Planning -- 30 минут.
У нас то, что можно описать Trunk-Based Development (на хабре была статья про это https://habr.com/ru/articles/794246/ со ссылками на доп материал). Сейчас релиз раз в две недели. Утром во вторник выбирается билд, в котором за ночь ничего страшного не сломалось и делается release candidate branch, из которой через две недели идет релиз.
День внешнего релиза по идее не должен быть никак связан с границами ваших спринтов.
Штуковина, идущая в спринт должна быть размера, который хотя бы теоретически можно сделать за спринт. Если нужен анализ и дизайн, то это отдельная штуковина, делается раньше (как часть спринта) и производит новые штуковины в бэклог. Понятно, что анализ и дизайн не всегда можно вместить в рамки спринта (может, надо время на подумать и утрясти идеи), такие штуковины могут длиться дольше.
Имхо, важный момент, что это ошибка считать, что все штуковины должны быть выполнены в спринт или ужас-ужас-ужас :-) Спринты -- это про организацию работы и точки корректировки, а не про обещания сделать что-то к определенному дню.
В agile почти все тестирование -- это часть обычной работы, и почти все тестирование автоматическое. Вы пишите и тесты и код. Continuous Integration гоняет тесты на ваших изменениях и на основной ветке постоянно.
Если говорить совсем категорично: например, если вы делаете задачу, а потом неделю ждете, пока человеческие тестеры ее проверят и вернут на доработку (баги или недочеты), то это не agile, а что-то другое.
Если косяк выясняется на демо, это значит, что на нескольких более ранних этапах его не выявили (например, во время проверки Acceptance Criteria). Бывает, конечно, тогда это тема для ретро -- обсудить, почему не выявили раньше. Но так как спринт короткий, то цена ошибки не очень велика. Если косяк небольшой и делать все равно нужно, штуковина остается открытой и переходит в следующий спринт. Если косяк существенный, но можно выделить в новую штуковину.
В бэклог по умолчанию. На следующем backlog review разбираться с приоритетом. Если важно и срочно, то естественно можно на месте со stakeholder разобраться, когда делать. Вполне нормально, что новая вещь идет в верх бэклога и берется сразу в следующий спринт.
Demo/review -- 30 минут. Retro -- 45 минут. Planning -- 30 минут. Если у вас существенно дольше, то что-то делается не так :-) Это если вы разработчик. Если вы -- заинтересованное лицо (stakeholder, не уверен, какой устоявшийся русский термин), то календарь, конечно, может быть забит сильно. Но у stakeholders всегда так независимо от методологии.
Давайте отвечу на простой вопрос из абзаца в конце.
Например, граница спринта в четверг, в который идут demo/review и retro закончившегося спринта, а потом planning начинающегося. А во вторник за два дня -- backlog review, чтобы были готовы актуальные задачи для выбора в четверг.
Спасибо. А то я, не разобравшись, почему-то подумал, что это закрытые платформы, хотя очевидно, такой подход не взлетит, если только это не Switch, например.
Не раскрыт такой важный, как мне кажется, аспект -- где брать игры на каждую из этих консолей.
Хотя с GPD Win 4, вроде, понятно. Если Windows 11, то можно Steam, например.
О как! Тогда это прекрасно же. А я не домотал до конца страницы.
Что интересно, ссылка на ZeroVer описывает состояние, но не объясняет, почему это хорошо 😀
Например, если все версии начинаются с 0, то этот ноль уже ничего не значит и просто мусор.
Возможно, нужно считать, что первый 0 значит, что нет никаких гарантий обратной совместимости между версиями. Но на практике вроде какая-то совместимость есть же?
Думаю, что работать над чем-то на чистом Rust в крупных существующих продуктах -- это редкость и роскошь.
Обычно будет куча уже присутствующего кода, и нужно будет усиленно воевать с ffi, потому что идеально отсечь интерфейсы и структуры данных -- очень сложно, даже если это совсем новая фича.
я видел только общие данные. Есть ли причины, почему разработчики могут очень сильно отличаться?
Например, уехал в другую страну с концами или ушел в армию.
Про проекты, да, согласен. Но ведь не всегда сотню новых людей надо.
Примеров не знаю, но сейчас рекордно низкий уровень безработицы. Как вы написали, это не значит, что у конторы все плохо и на грани банкротства. Однако это значит, что очень сложно найти замену ушедшему сотруднику или набрать людей на новые проекты.
Имхо, самый важный вопрос от комментатора выше (и вопрос, который возник у меня) это зачем нужно самому реализовывать install/start/stop/uninstall? Ведь есть уже встроенные утилиты, которые это делают. Для понимая устройства сервисов новичком этот код ничего не даёт, а только отвлекает от собственно тела сервиса.
Статья на этот вопрос не отвечает, запутывая читателей. Для новичков слишком много информации сразу. Для не новичков -- непонятно, зачем.
В крайнем случае, эти примеры можно было бы вынести в приложение в конце.
Эх, да, был, но уже несколько лет как BitBucket убрал поддержку Mercurial репозиториев.
В планетарном масштабе -- пофиг, конечно. 🙂
Новости ещё и способ быстро узнать что-то новое. Взять на заметку, мол, вдруг пригодиться. Если новость не содержит достаточно контекста для такой заметки и требует дополнительного исследования, то теряется быстрота.
И вроде бы должно быть пофигу, но остаётся ощущение, что автор не заботится о читателях.
Это все разные продукты.
Skype for Business не имеет с обычным Skype ничего общего (кроме названия) и произрастает из прошлых продуктов: Lync и ранее Communicator. Lync вовсю использовался внутри самой Майкрософт.
Teams снова вырос совершенно отдельно и вытеснил Skype for Business. Как так вышло внутри -- я не знаю.
Предположу, что людей раздражает, когда для минутной статьи нужно пять минут что-то искать и читать в интернете, чтобы понять о чем речь.