Size: a a a

Agile, Scrum, Lean, Kanban, XP

2020 February 04

AT

Anton Tikhomirov in Agile, Scrum, Lean, Kanban, XP
Annie мысли (сорри за лонгрид), как обещал, живость встречи и созданная ценность зависит целиком и полностью от навыка фасилитации ведущего, его прямая задача работать с ПО и командой, от первого добиваться понятности изложения своих мыслей и их трансформацию в задачи, готовность слышать и слушать команду, от вторых готовность принимать задачи (комититься за их реализацию),работать командой и участвовать в диалоге, который а) построен на принципах взаимного уважения (никто не любит когда его перебивают и все любят когда их лично/их труд уважают и слушают), б) созидания общего продукта/результатата (те кто любят перебивать или не хотят слушать ничего полезного не создают, таких надо гнать в шею, не стесняясь (кто говорил что нельзя в нужное время быть строгим?)), в) проходит по общим правилам которым все должны следовать.
Так же, на мой взгляд, одна из самых главных задач модератора - не допускать софистики и полемики не относящейся ко встрече (есть офтопик? запиши, потом обсудим), излишняя вольность в этом уводит всю команду от цели и ведет к просеру времени/денег/проекта.
Что касается инструментария - правило #1 единое, удобное, доступное для всех, рабочее пространство (discord, teams, slack технических решений много). В вашем случае доска электронная мастхэв, все записи там же, комитменты там же, комментарии и вопросы на ходу решаются в 90% случаев прямо в карточках. Но, самая большая опасность в том, что команде нужно прививать желание работать с электронными инструментами, сложно многим заставить себя зайти куда-то, кликнуть что-то, напечатать где-то, проще все отложить до встречи и там все что вспомнится вывалить. Если уж прям ооочень необходимо совместить офлайн и онлайн ресурсы в одной команде, то описанного выше сложно (никак) избежать, и правила ведения встречи должны быть 100% выдержаны, даже если веселье на встрече будет низким/никаким, вы за результатом идете, так ведь? Веселье можно сделать в отдельной комнате, куда кидайте гифки/мемы/хоть что. При этом до офлайн команды важно донести мысль о том, что некачественное участие онлайн команды приводит к их некачественной работе и результату качество которого, они в какой то момент, не смогут гарантировать и в итоге будут только пытаться делать, а не делать. Но как мы помним do or do not, there is no try) this is the way)
Из вопросов-советов, можно ли разделить команду на несколько (фиче-команды?) в которых отдельно онлайн и офлайн будут?
Есть ли возможность провести отдельную встречу не про проект и задачи, а про коммуникации и проблемы?
источник

AT

Anton Tikhomirov in Agile, Scrum, Lean, Kanban, XP
Yuriy Smirnov
Лучше электронная)
чем лучше?)
источник

JP

Jane Pavlova in Agile, Scrum, Lean, Kanban, XP
Чем электронная 😁 #ТАМ
источник

AT

Anton Tikhomirov in Agile, Scrum, Lean, Kanban, XP
Jane Pavlova
Чем электронная 😁 #ТАМ
😉u know it)
источник

YS

Yuriy Smirnov in Agile, Scrum, Lean, Kanban, XP
Anton Tikhomirov
чем лучше?)
В контексте распределеных команд поддерживать две доски сложно)
источник

AT

Anton Tikhomirov in Agile, Scrum, Lean, Kanban, XP
Yuriy Smirnov
В контексте распределеных команд поддерживать две доски сложно)
да не реально даже, хотя можно наверное придумать вебкамеру с трансляцией офлайн доски)) цифровизация2020)
источник

AS

Annie Shevchenko in Agile, Scrum, Lean, Kanban, XP
Anton Tikhomirov
Annie мысли (сорри за лонгрид), как обещал, живость встречи и созданная ценность зависит целиком и полностью от навыка фасилитации ведущего, его прямая задача работать с ПО и командой, от первого добиваться понятности изложения своих мыслей и их трансформацию в задачи, готовность слышать и слушать команду, от вторых готовность принимать задачи (комититься за их реализацию),работать командой и участвовать в диалоге, который а) построен на принципах взаимного уважения (никто не любит когда его перебивают и все любят когда их лично/их труд уважают и слушают), б) созидания общего продукта/результатата (те кто любят перебивать или не хотят слушать ничего полезного не создают, таких надо гнать в шею, не стесняясь (кто говорил что нельзя в нужное время быть строгим?)), в) проходит по общим правилам которым все должны следовать.
Так же, на мой взгляд, одна из самых главных задач модератора - не допускать софистики и полемики не относящейся ко встрече (есть офтопик? запиши, потом обсудим), излишняя вольность в этом уводит всю команду от цели и ведет к просеру времени/денег/проекта.
Что касается инструментария - правило #1 единое, удобное, доступное для всех, рабочее пространство (discord, teams, slack технических решений много). В вашем случае доска электронная мастхэв, все записи там же, комитменты там же, комментарии и вопросы на ходу решаются в 90% случаев прямо в карточках. Но, самая большая опасность в том, что команде нужно прививать желание работать с электронными инструментами, сложно многим заставить себя зайти куда-то, кликнуть что-то, напечатать где-то, проще все отложить до встречи и там все что вспомнится вывалить. Если уж прям ооочень необходимо совместить офлайн и онлайн ресурсы в одной команде, то описанного выше сложно (никак) избежать, и правила ведения встречи должны быть 100% выдержаны, даже если веселье на встрече будет низким/никаким, вы за результатом идете, так ведь? Веселье можно сделать в отдельной комнате, куда кидайте гифки/мемы/хоть что. При этом до офлайн команды важно донести мысль о том, что некачественное участие онлайн команды приводит к их некачественной работе и результату качество которого, они в какой то момент, не смогут гарантировать и в итоге будут только пытаться делать, а не делать. Но как мы помним do or do not, there is no try) this is the way)
Из вопросов-советов, можно ли разделить команду на несколько (фиче-команды?) в которых отдельно онлайн и офлайн будут?
Есть ли возможность провести отдельную встречу не про проект и задачи, а про коммуникации и проблемы?
спасибо за такой развернутый ответ)
источник
2020 February 05

AK

Artem Kulikov in Agile, Scrum, Lean, Kanban, XP
Эх, Сергей Сергей, ключ пишется без мягкого знака, маркетолог вы наш
источник

V

Vitaly in Agile, Scrum, Lean, Kanban, XP
#яумамымаркетолог
источник

EM

Ekaterina Maksimova in Agile, Scrum, Lean, Kanban, XP
Сергей, привет!
Это в EdMarket Club чат информация)
источник

N

Nikita in Agile, Scrum, Lean, Kanban, XP
Привет!
подскажите как лучше планировать спринты с дизайнером

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

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

как быть?
источник

М

Маришка in Agile, Scrum, Lean, Kanban, XP
совместно с ПО расставить приоритеты на задачи, которые реализовывает команда. И работать на опережение, чтобы ресурс был полностью готов и согласован.
у дизайнера может быть собственный спринт
источник

SG

Sergey Gospodchikov in Agile, Scrum, Lean, Kanban, XP
Nikita
Привет!
подскажите как лучше планировать спринты с дизайнером

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

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

как быть?
Дизайнера в команду
источник

SG

Sergey Gospodchikov in Agile, Scrum, Lean, Kanban, XP
Иначе он так и будет выпадать из процесса
источник

N

Nikita in Agile, Scrum, Lean, Kanban, XP
спасибо
источник

NP

Nikita Poselyanov in Agile, Scrum, Lean, Kanban, XP
Nikita
Привет!
подскажите как лучше планировать спринты с дизайнером

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

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

как быть?
Никак, UX \ UI всегда или отстаёт или опережает т.к. даже с фидбэк лупом в 2е недели всё равно пройдёт время пока изменения зайдут в PBI, пока случится PBR оттягивает вперед или назад. Готовых OOB что бы это починить на моей практике нет, можно состряпать "песочницу" + \ - её утвердить, но когда её закончат всё равно начнутся расслоения.
источник

N

Nikita in Agile, Scrum, Lean, Kanban, XP
Nikita Poselyanov
Никак, UX \ UI всегда или отстаёт или опережает т.к. даже с фидбэк лупом в 2е недели всё равно пройдёт время пока изменения зайдут в PBI, пока случится PBR оттягивает вперед или назад. Готовых OOB что бы это починить на моей практике нет, можно состряпать "песочницу" + \ - её утвердить, но когда её закончат всё равно начнутся расслоения.
👍👍тоже так думал
источник

N

Natasha Segnitz in Agile, Scrum, Lean, Kanban, XP
Мы запирали текущую версию фигмы, чтобы не было чехарды в работе, к следующему рефайнмент новый файл был готов к разбору
источник

N

Natasha Segnitz in Agile, Scrum, Lean, Kanban, XP
Дизайнер был в команде, работал и параллельно в режиме текущего дизайн-фидбека и на опережение
источник

N

Natasha Segnitz in Agile, Scrum, Lean, Kanban, XP
У нас сейчас начинается построение дизайн отдела и системы, поделюсь решениями и контекстом, если уцелею. Коллеги пока онбордятся
источник