Yurii
Продакт овнер не входит
Yurii
в сркаме 7+-2 состав
Алекс
😂
Dmitriy M.
(one of DEV or QA is the SM) -- что значит SM в данном контексте, Senior Manager?
Yurii
я не прав?
Dmitriy M.
или скрам мастер?
Алекс
😂
Мария
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.
Mikhail
В скраме sm - скрам мастер
D.
Дмитрий, просто прочитайте Scrum Guide - уверен, он снимет все Ваши вопросы
Мария
лучше читать в оригинале скрам гайд https://www.scrumguides.org/scrum-guide.html
Yurii
D.
Юрий, читайте Скрам Гайд, а не непонятные источники
Yurii
спасибо
D.
3 роли в Scrum это Dev Team, Scrum Master и Product Owner. Все они вместе - Scrum Team
Yurii
под скрам тим понимал получается девов
D.
на самом деле это дев тим
Mikhail
D.
а скрам тим это дев тим + СМ + РО
D.
и 3-9 это оптимальный размер именно для дев тим, а не скрам тим
Dmitriy M.
спасибо, почитаю, и еще вопросик, термины Theme, Epic, Story, Implementation Task непосредственно к чему относятся в контексте Agile?
Yurii
спасибо за информацию
Yurii
пока учусь только)
D.
всегда пожалуйста! ;)
Mikhail
К разработке
Dmitriy M.
Требования?
Dmitriy M.
привязка есть ли к фреймворкам каким
Mikhail
Лучше воспользоваться Гуглом
Mikhail
По определениям
D.
не факт - то, что обсуждалось выше, тоже наверняка результат пользования Гуглом)
Mikhail
Епик - это
Стори - это
И т.д.
Dmitriy M.
мне не нужны определения, мне нужен факт в чем конкретно используется и к чему относится, как правильно сказать
D.
User Stories корнями из XP идут, если в контексте фреймворков говорить
D.
что использовать, что нет - в идеале должна решать команда
D.
Epic, Stories, Task вообще исключительно из-за повсеместного распространения Jira стали такими популярными
Dmitriy M.
спасибо
D.
но в идеале это как с DoD - команда сама для себя должна определить какие сущности использовать, естесственно принимая во внимание стандарты организации
D.
Коллеги, напомните плиз - как запостить объявление в @agile_jobs ?
А в чем у вас проблема?
Вадим
D.
А, все, извиняюсь - увидел кнопку Join и подумал что значит постить может только админ. Мой недосмотр))
============ FALCON ============
Всем привет!
Как считаете SM важно иметь опыт в разработке? Его наличие мешает или помогает?
Ruslan
Насколько я знаю, в свободное время скрам мастер должен присоединяться к команде разработке. Поэтому теоритечески - помогает
============ FALCON ============
А практически?)
Anton
Anton
Ruslan
Тестировать можно, как минимум)
Anton
Тестировать можно, как минимум)
А тренер футбольной команды иногда на поле выходить на чемпионате?
Ruslan
Пример выше никак не относится к скрам.
Если отвечать на поставленный вопрос Амана, то сложно вспомнить кейс, где дополнительный опыт мешает
Anton
Andrey
спасибо
А после него Джефа сазерленда, скрам гайд немного сух, а вот книга даст понять не только что нужно делать, но и почему, и как правильнее) Читается легко
Grigory
В свободное время sm занимается саморазвитием и подготовкой новых игр для команды...
Yurii
Сазерленда уже прочитал)
Pavel
#whois
Всем привет!
Меня зовут Павел. Я из Таганрога. Работаю в продуктовой компании, занимающейся фул стек разработкой. Следуем принципам agile.. насколько получается 🙂 Я специализируюсь на iOS разработке, но сейчас также являюсь скрам мастером. Параллельно с практикой подтягиваю теорию. Имею знания в самых различных областях. Могу быть полезен нестандартными мыслями (хотя и звучит как шаблон).
Ищу новые знания 🙂 в частности практики и методы улучшения процесса.
Перешел в группу по личной рекомендации
Pavel
В немалой степени набрел на канал потому, что у меня возникла некоторая проблема, с которой пока не знаю как поступить
Сейчас у нас в компании две команды, работающие над одним продуктом. Я явлюясь скрам мастером в первой команде и фасилитатором во второй.
Вторая команда состоит из пяти фул тайм разработчиков (один из них скрам мастер) и двух удаленных.
Также есть продуктовая команда.
Изначально оба скрам мастера проводили ретро каждый в своей команде, но у второй команды не было прогресса по улучшению рабочего процесса, поэтому решили произвести такой обмен.
Основная проблема заключается в том, что, несмотря на очевидные показатели - постоянно низкая (и падающая) велосити, большой объем тех долга, команда отрицает, что что-то не в порядке с процессом, на ретро инициативы для обсуждения "что, почему, как" нет. Более того, когда я сам поднимаю эти вопросы (не уверен, корректно ли это в моей роли), почти никто не высказывается. Проблемы, хотя и повторяются из спринта в спринт уже на протяжении нескольких месяцев, объясняются сиюминутными причинами. Желания решать проблемы тоже не высказывают, решений не предлагают
Существует ощущение, что одну часть команды не волнует происходящее. Другая же часть под влиянием общей атмосферы и того, что ничего не меняется/не происходит, тоже не хочет активно участвовать. Как пример, на одном из ретро была фраза, описывающая настроение "Много закрылось юзер стори - ок. Мало - тоже ок."
В первой команде таких проблем нет. Хотя ретро, как инструмент, бывает вызывает недовольство, обсуждения там всегда бурные и результативные с последующим изменением процессов
Может кто-то с таким сталкивался? Или есть идеи, как изменить сложившуюся ситуацию во второй команде? В какую сторону копать?
Dmitry
В немалой степени набрел на канал потому, что у меня возникла некоторая проблема, с которой пока не знаю как поступить
Сейчас у нас в компании две команды, работающие над одним продуктом. Я явлюясь скрам мастером в первой команде и фасилитатором во второй.
Вторая команда состоит из пяти фул тайм разработчиков (один из них скрам мастер) и двух удаленных.
Также есть продуктовая команда.
Изначально оба скрам мастера проводили ретро каждый в своей команде, но у второй команды не было прогресса по улучшению рабочего процесса, поэтому решили произвести такой обмен.
Основная проблема заключается в том, что, несмотря на очевидные показатели - постоянно низкая (и падающая) велосити, большой объем тех долга, команда отрицает, что что-то не в порядке с процессом, на ретро инициативы для обсуждения "что, почему, как" нет. Более того, когда я сам поднимаю эти вопросы (не уверен, корректно ли это в моей роли), почти никто не высказывается. Проблемы, хотя и повторяются из спринта в спринт уже на протяжении нескольких месяцев, объясняются сиюминутными причинами. Желания решать проблемы тоже не высказывают, решений не предлагают
Существует ощущение, что одну часть команды не волнует происходящее. Другая же часть под влиянием общей атмосферы и того, что ничего не меняется/не происходит, тоже не хочет активно участвовать. Как пример, на одном из ретро была фраза, описывающая настроение "Много закрылось юзер стори - ок. Мало - тоже ок."
В первой команде таких проблем нет. Хотя ретро, как инструмент, бывает вызывает недовольство, обсуждения там всегда бурные и результативные с последующим изменением процессов
Может кто-то с таким сталкивался? Или есть идеи, как изменить сложившуюся ситуацию во второй команде? В какую сторону копать?
Пробовал поговорить с разработчикам один на один?
Ну а в целом мотивировать. Например попробуйте провести более расширенное демо по итогам спринта у обеих команд. Пригласить, помимо разработчиков, стекхолдеров, представителей маркетинга и т.д. Так команда будет получать больше обратной связи от компании, увидит что есть интерес к тому что они делают. Но тут главное чтобы это не воспринималось как "отчетно" мероприятие - начнут резать беклог спринта.
Dmitry
А еще очень помогает фокусировке ставить на каждый спринт цель. И делать фокус не на количество сгоревших стори поинтов, а на достижение цели спринта.
Pavel
В немалой степени набрел на канал потому, что у меня возникла некоторая проблема, с которой пока не знаю как поступить
Сейчас у нас в компании две команды, работающие над одним продуктом. Я явлюясь скрам мастером в первой команде и фасилитатором во второй.
Вторая команда состоит из пяти фул тайм разработчиков (один из них скрам мастер) и двух удаленных.
Также есть продуктовая команда.
Изначально оба скрам мастера проводили ретро каждый в своей команде, но у второй команды не было прогресса по улучшению рабочего процесса, поэтому решили произвести такой обмен.
Основная проблема заключается в том, что, несмотря на очевидные показатели - постоянно низкая (и падающая) велосити, большой объем тех долга, команда отрицает, что что-то не в порядке с процессом, на ретро инициативы для обсуждения "что, почему, как" нет. Более того, когда я сам поднимаю эти вопросы (не уверен, корректно ли это в моей роли), почти никто не высказывается. Проблемы, хотя и повторяются из спринта в спринт уже на протяжении нескольких месяцев, объясняются сиюминутными причинами. Желания решать проблемы тоже не высказывают, решений не предлагают
Существует ощущение, что одну часть команды не волнует происходящее. Другая же часть под влиянием общей атмосферы и того, что ничего не меняется/не происходит, тоже не хочет активно участвовать. Как пример, на одном из ретро была фраза, описывающая настроение "Много закрылось юзер стори - ок. Мало - тоже ок."
В первой команде таких проблем нет. Хотя ретро, как инструмент, бывает вызывает недовольство, обсуждения там всегда бурные и результативные с последующим изменением процессов
Может кто-то с таким сталкивался? Или есть идеи, как изменить сложившуюся ситуацию во второй команде? В какую сторону копать?
Павел, мне кажется вы пытаетесь решать не ту проблему. Команда не хочет брать на себя ответственность за результат - почему? Они точно «команда» или их просто согнали насильно работать вместе? Или им обещали другой проект и обманули? Или культура внутри компании токсична и не поощряет инициативу?
Pavel
Попробуйте в почему поиграть с командой и понаблюдать динамику их общения (планирование, дейли, груминг, демо)
Pavel
По поводу разговоров один на один - сейчас этим занимается мой непосредственный начальник, он раньше был скрам мастером для всех команд. Я также попробовал узнать у некоторых разработчиков, что им не нравится, чтобы собрать хоть какой нибудь фидбэк. В общем да, узнал довольно много, наверное, будет иметь смысл углубиться в эту практику, спасибо за совет :)
Pavel
Пробовал поговорить с разработчикам один на один?
Ну а в целом мотивировать. Например попробуйте провести более расширенное демо по итогам спринта у обеих команд. Пригласить, помимо разработчиков, стекхолдеров, представителей маркетинга и т.д. Так команда будет получать больше обратной связи от компании, увидит что есть интерес к тому что они делают. Но тут главное чтобы это не воспринималось как "отчетно" мероприятие - начнут резать беклог спринта.
Вот с этим проблема, по моему и демо, и ретро считаются своего рода повинностью. Представители заказчика всегда присутствуют, но у меня складывается ощущение, что это никак не мотивирует. Вероятно, очень мало обратной связи.
Стас Щетинников
если выучить и вытянуть сложнее, чем нанять, зачем мучить всех?
Pavel
Павел, мне кажется вы пытаетесь решать не ту проблему. Команда не хочет брать на себя ответственность за результат - почему? Они точно «команда» или их просто согнали насильно работать вместе? Или им обещали другой проект и обманули? Или культура внутри компании токсична и не поощряет инициативу?
Команда набиралась под этот проект, он идет уже больше, чем полтора года, но по-прежнему практически никто им не пользуется, его не хотят выводить на рынок. Также случаются такие вещи, как сделали что-то быстро, а потом через месяц другой этот функционал переделывается, перекрашивается или и вовсе отправляется чуть ли не в корзину, думаю, это сильно демотивирует. То есть возникает ощущение, что у представителя заказчика нет четкого видения/оно меняется. Я и за собой заметил, что после некоторых резких поворотов мотивация падает
============ FALCON ============
Хотя они может действительно не знают)) 😁
Pavel
Попробуйте в почему поиграть с командой и понаблюдать динамику их общения (планирование, дейли, груминг, демо)
Вот здесь интересно. Есть один член команды, который почти все воспринимает в штыки. Вероятно, на остальных сказывается и его влияние. Но, когда скажем ретро проходило без него (я не проводил, просто со стороны видел), вроде тоже особой вовлеченности не было
Стас Щетинников
Команда набиралась под этот проект, он идет уже больше, чем полтора года, но по-прежнему практически никто им не пользуется, его не хотят выводить на рынок. Также случаются такие вещи, как сделали что-то быстро, а потом через месяц другой этот функционал переделывается, перекрашивается или и вовсе отправляется чуть ли не в корзину, думаю, это сильно демотивирует. То есть возникает ощущение, что у представителя заказчика нет четкого видения/оно меняется. Я и за собой заметил, что после некоторых резких поворотов мотивация падает
нуууу, согласен, под такие условия даже новую команду собирать не поможет. Не хотите «покоучить» продуктовиков и заказчика?
Стас Щетинников
коучить команду разработки тут не сильно поможет.
Alex
Команда набиралась под этот проект, он идет уже больше, чем полтора года, но по-прежнему практически никто им не пользуется, его не хотят выводить на рынок. Также случаются такие вещи, как сделали что-то быстро, а потом через месяц другой этот функционал переделывается, перекрашивается или и вовсе отправляется чуть ли не в корзину, думаю, это сильно демотивирует. То есть возникает ощущение, что у представителя заказчика нет четкого видения/оно меняется. Я и за собой заметил, что после некоторых резких поворотов мотивация падает
Это у вас не ощущение, это правда. Все признаки отсутствия видения на лицо. Тут 2 момента: 1) а помогает ли команда заказчику обрести это видение? 2) И как заказчик к этому относится? Мол, "делайте так как вас просят - покормите собак и ничего не трогайте" или все же готовы прислушиваться?
Pavel
Хотя они может действительно не знают)) 😁
Почему у них постоянно падает продуктивность, судя по разговорам, они не знают.. про scrum/agile знают, но это их не особо вдохновляет
Pavel
нуууу, согласен, под такие условия даже новую команду собирать не поможет. Не хотите «покоучить» продуктовиков и заказчика?
Я к заказчику доступа не имею, поэтому пытаюсь сделать лучше хотя бы в своем небольшом углу.. но вообще да, обсуждения, связанные с этими проблемами видения, возникают в обеих командах почти каждый раз
Pavel
Ну и, наверное, меня смутило, что одна команда в таких условиях работает хорошо, а вторая не очень. Хотя все же люди разные
============ FALCON ============
А в чем заключается отличие в процессах между двумя командами?