Comments 12
2. Протестировано на проде
4. Выложено на прод
как так то?
девтим не может приступать к дальнейшим действиям (pull requests и тд), пока DOT не будет выполнен полностью
Чем они будут заняты в это время — можно договориться
А можно и не договориться? Ваш srum напоминает мне чем-то странную смесь srum-а и сломанного waterfall-а.
А проблемы с синхронизацией у вас, похоже, из-за неверного планирования спринтов.
У нас появились правила по шагам тестирования и докатке задачи до боя. И это правда похоже на вотерфол, никто не спорит!) Но только в рамках одной маленькой стори.
А вот с неверным планированием готова подискутировать. Не получится так, что все идеально одинаково заняты над одной задачей, и дружно ровно переключаются на другую.
Если получится — приглашай в гости, я так точно готова поучиться у вас)
— наиболее полную загрузку народа (чтобы увеличить velocity)
— с другой стороны, выбираются истории — если, конечно, есть выбор — так, чтобы не тормозить друг друга. Например, реализуется новая фича, зависящая и от backend, и от контроллеров, и от frontend. Для текущего спринта можно реализовать либо сначала backend часть, а потом пилить контроллеры и front (да, фронтенд тоже может быть не один и очень разный), либо сначала контроллеры, за ними фронт, а бэкенд можно запилить и в следующем спринте — если фича не горящая. На каждом retrospective обсуждаем, где и в чем были задержки, смотрим статистику, улучшаем планирование.
При этом никто никогда никого не ждет.
Кстати, для этого в dev team полезно иметь full stack-ов, чем больше, тем лучше (если бабки позволяют). Всегда можно перебросить на «провисающую» story.
Если получится — приглашай в гости, я так точно готова поучиться у васЯ бы с удовольствием пригласил, но, во-первых, немного далековато (у нас — это в Бостоне), во-вторых, я, к сожалению, эти вопросы не решаю.
P.S. Еще немного не понял сентенцию про pull request-ы — они ведь специально для того и были выдуманы (и спецом предназначены), чтобы не ждать, когда кто-то запилит свою часть. Вы там как, с git-ом — на короткой ноге, или в процессе освоения? ;)
Уловила ваш подход)
Мы с вами с разными целями заполняем спринт. Цель нашего спринта — доставить ценность до прода. То есть фича должна быть готова полностью. И ни фронт, ни бэк, ни что-то ещё на другие спринты не съезжают.
И спринт планируется при этом таким образом, чтобы выполнить бизнес-цель. Равномерная загрузка разработчиков при этом достигается редко, и такое распределение, которое у вас делает архитектор/тимлид, у нас не практикуется.
Мы можем предлагать Продакту выбрать определенный набор фич, чтобы все компетенции успели выполнить задачи за спринт. То есть если фронт перегружен и точно не успеет сделать третью стори, то Продакту самому это не очень интересно.
Девтим может предложить взять третью строи поменьше, или добавить техтасок, если есть техдолг или задачи по девопсу.
Главная цель — полностью готовые фичи на проде.
А в Бостон было бы классно скататься, да...
Видимо, ваши проблемы происходят еще и от того, что у вас нет хорошего архитектора, и full stack devs.
А статистику скрама вы ведете? Что у вас с velocity и health? Правильная статистика в scrum — это must have, запросто вскрывает проблемы.
P.S. Да, забыл написать по поводу «фича должна быть готова полностью». Есть такой термин, MVP, вы с ним знакомы? Специально для таких случаев и придуман :D
Простоев собственно и нет) Люди переключаются на другие задачи, пока фича полностью тестируется и готовится к релизу. Таким образом с velocity все в порядке.
MVP, разумеется, есть. Наши Продакты достаточно в теме) Разработка тоже знает что это, и помогает Продакту найти этот минимальный жизнеспособный продукт.
В целом, не вижу жестких противоречий скраму в нашем подходе. Сказать, что Фича не мерджится в мастер, пока не прошла функциональное тестирование — это скорее здравый смысл, нежели догма, по моему скромному мнению.
Однако спасибо за ваши мысли, очень интересно!
Простоев собственно и нетНу и чудесно! Значит, я вас неправильно понял, либо вы не совсем верно выразились в тексте статьи
Наш опыт показал, что при таком подходе кто-то из разработчиков всегда скучает, а кто-то вынужден задерживаться на работе и доделывать свою “половинку”.
У нас таких проблем и обид не возникает, и никто не задерживается на работе больше, чем он хочет сам. Вот приведу «пример на пальцах»: делаем user story, в которую вовлечены почти все софтверные компоненты (а у нас scrum применяется еще не только для софта), я запилил, например, фронт по быстрому, а человек, у которого карта (мы пользуемся Trello) с беком/мидлом, не успевает (ну, мало ли что — заболел, куча интервью, форс-мажор). Ничего страшного — я перекинул на себя его карту (с частью user story — кстати, разбитие больших задач на мелкие подзадачи — очень важная часть правильного скрама) и запилил контроллер. Не успеваю сделать бэк (или там есть тонкости, которые я не знаю, а время тратить не охота) — воткнул стаб в контроллер и обозвал MVP. Счастливому кастомеру ушел новый релиз «на обкатку», в бэклог пошла новая story — все happy, включая скрам-мастера и PO :)
Притом, помимо user stories, у нас есть и house stories — над развитием продукта нужно думать (для чего важен хороший архитект). Вот сейчас, в бэкграунде, переезжаем потихоньку на serverless (рекомендую покопать, любопытная штука), попиливая потихоньку house stories в спринтах. И, глядишь, незаметно так и мигрируем себе ;)
В общем, скрам прикольная, забавная и полезная штука, главное — применять его гибко, с умом и без догматики.
Синхронизация команды со SCRUM