Size: a a a

Agile, Scrum, Lean, Kanban, XP

2020 October 12

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Marcooo
Понятно что никак не решает, вопрос в том, как поступают в данном случае с вопросом заказчика, будем честны, их интересуют в основном сроки, бюджет и содержание, каким образом отвечаете вы при таких обстоятельствах, вы не можете скинуть ему мем про скрам и сказать сорян братшика
Можете объяснить, как вне скрама решается указанный форс-мажор? И чем это лучшее скрама?

Видимо лучше тем, что как верно заметил Артем, вне скрама вы сразу нашли КРАЙНЕГО (он же ответственный) )))
источник

ОБ

Оксана Булаткина... in Agile, Scrum, Lean, Kanban, XP
Артем Летюшев
Сдвигом каких сроков? Вы еще не получили оценку, вы называете ее на глаз, а потом еще и сдвинуть хотите?)

Это не так работает)
Так и работает) Вы грумите задачи всей командой (до состояния "бери и делай") и оцениваете задачи всей командой как раз для того, чтобы у всей команды было одинаковое понимание сроков выолнения задачи. И если один человек, по каким-то причинам, уходит, оценка не меняется, просто задача достанется кому-то другому. Увеличится только общее время выполнения всех запланированных задач
источник

ТХ

Тимур Хайруллин... in Agile, Scrum, Lean, Kanban, XP
Артем Летюшев
Хосподе, опять пошли разговоры "как применять скрам в проектах". Кто-нибудь, сделайте уже FAQ. Добавьте туда также про сторипойнты в часы, как померить эффективность см и прочее
Реально. Хочется уже нецензурно выражаться. Эти набеги реально бесят.
Это как прийти в чат профессиональных механиков и требовать доказать, что "Ключ на 17 лучше ключа на 19"
Видимо, надо просто перестать реагировать
источник

АЛ

Артем Летюшев... in Agile, Scrum, Lean, Kanban, XP
Оксана Булаткина
Так и работает) Вы грумите задачи всей командой (до состояния "бери и делай") и оцениваете задачи всей командой как раз для того, чтобы у всей команды было одинаковое понимание сроков выолнения задачи. И если один человек, по каким-то причинам, уходит, оценка не меняется, просто задача достанется кому-то другому. Увеличится только общее время выполнения всех запланированных задач
Вы так пару проектов угробите...
источник

IA

Igor A in Agile, Scrum, Lean, Kanban, XP
Оксана Булаткина
Может и правда не скрам, конечно, но скрам же предполагает т-шейп команды, это сводит бас-фактор к минимуму. Вы потеряли тоих из семи, очевидно, их работа перераспределится на оставшихся четверых, значит, им понаобится в n больше времени для того, чтобы работу доделать
вы код писать умеете?) что такое Т шейп в реальном мире?)
источник

ОБ

Оксана Булаткина... in Agile, Scrum, Lean, Kanban, XP
Igor A
вы код писать умеете?) что такое Т шейп в реальном мире?)
Ахахах))) А вы забавный)
источник

M

Marcooo in Agile, Scrum, Lean, Kanban, XP
Тимур Хайруллин
Реально. Хочется уже нецензурно выражаться. Эти набеги реально бесят.
Это как прийти в чат профессиональных механиков и требовать доказать, что "Ключ на 17 лучше ключа на 19"
Видимо, надо просто перестать реагировать
Проблема только в том, что вы за всё это время, не дали нормального ответа, по сути проблема вашей компетенции
источник

M

Marcooo in Agile, Scrum, Lean, Kanban, XP
Igor A
вы код писать умеете?) что такое Т шейп в реальном мире?)
Что не так с T-shaped в менеджменте?

В двух словах T-shaped ("в форме Т") - это метафора, которая обозначает как у сотрудника развиты навыки.
Грубо говоря, специалист в какой-то сфере (программирование на java) со временем достиг больших высот - их символизирует вертикальная перекладина Т. А затем стал осваивать смежные области "справа и слева" от своей основной профессии - горизонтальная перекладина. Получается сотрудник в виде буквы "Т", разносторонне развитый.

Как и любая метафора - образ годится, чтобы пояснить мысль. Но крайне плох чтобы что-то доказать или придумать выход из сложной ситуации.

T-shaped заслуженно популярно в agile-сообществе, однако иногда приводит к конфузам.
Например: в Скрам есть "врожденное ограничение". Скрам-команды тяжело собрать из людей сильно отличающихся профессий. Это не невозможно, но придется преодолеть проблемы "простоев" внутри спринта.

Представьте, у вас команда 7 человек, в ней программисты, тестировщики, аналитик и дизайнер интерфейсов. Скрам. Обычно каждую задачу сперва обдумывает аналитик, подключает дизайнера, позже начинается разработка и тестирование. Спринт, скажем, длится 2 недели. Значит ли это, что сперва работает один лишь аналитик (остальные простаивают), а в конце спринта "пашут" в основном разработчики и тестировщики? Очевидно нет, зачем нам простой? Может, аналитику нужно брать в работу задачи заранее (с опережением на 1-2 спринта)? Ага, а тестировщика будем включать с запозданием (чтобы тоже никогда не простаивал)? А если кто-то в начале цепочки "сбойнет"? А если ролей в команде еще больше, как тогда? Какую бы громоздкую конструкцию из правил и уловок мы не построили - мы либо придем к тому что узаконим корневую причину ("простои - норма, мы их не боимся"), либо сильно начнем противоречить если не букве, то духу Скрам. Подход который делает ставку на легковесность, понятность команде, отсутствие долгосрочного планирования и взаимовыручку - так обрастает правилами, что превзойдет в PMBoK и часть обаяния Скрам для команды исчезнет.

T-shaped - иногда предлагают как решение. Профессии профессиями, но нам нужны Т-люди. Вопрос решен - в начале спринта аналитику помогут разработчики, а в конце те же разработчики помогут тестировщику закрыть задачи вовремя. Ведь все прокачали смежные навыки, отсюда и расширение кругозора, и определенная взаимозаменяемость.

Но важно вспомнить, T-shape лишь метафора. Которую к тому же здорово извратили в индустрии.

Во-первых сама форма буквы сбивает. Заставляет вас поверить, что Java-программист достигших высот в своем деле освоит и смежные области на такой же высоте. На самом деле - его познания в тестировании, бизнес-анализе будут чуть выше базовых (пока не пройдет путь профессионала). Так что правильно было бы букву Т перевернуть.

Во-вторых изначально горизонтальная перекладина отражала не то, что аналитик сможет программировать. Она лишь обозначала, что крутой специалист с широким кругозором легче _ коммуницирует _ , со смежными спецами. Общается, а не помогает / заменяет собой.
В общем случае ставка на T-shape разди взаимозаменяемости - утопия. Программист иногда может помочь тестировщику тестировать. А наоборот? Скажем дизайнер интерфейсов в последние два дня спринта решил помочь коллективу опытных java-программистов. Какой инопланетный скилл должен быть у него прокачан, чтобы  принести реальную пользу?

Ну и в третьих, помните, что T-shape достигается через освоение нового - учебу, отработку, закрепление. Во многом драйвер этой самой горизонтальной перекладины - любопытство. А значит он не сработает без запроса, по одной лишь воле руководства или увещеванию команды "прокачайся, надо". Талантливому программисту  смертельно НЕ интересен бизнес анализ (и тестирование вызывает зевоту)? Едва ли стоит ждать отрастания у него соответствующей "горизонтали".

T-shaped people это хорошая метафора о крутых не зашоренных спецах, познающих смежные профессии и за счет этого находящих общий язык в них. Но это не решение проблемы взаимозаменяемости.  К тому же T-shaped нельзя сделать по приказу, ими можно только стать по своей воле.
источник

JP

Jane Pavlova in Agile, Scrum, Lean, Kanban, XP
Тимур Хайруллин
Реально. Хочется уже нецензурно выражаться. Эти набеги реально бесят.
Это как прийти в чат профессиональных механиков и требовать доказать, что "Ключ на 17 лучше ключа на 19"
Видимо, надо просто перестать реагировать
Да, нужно ввести входной тест.
источник

АЛ

Артем Летюшев... in Agile, Scrum, Lean, Kanban, XP
Оксана Булаткина
Так и работает) Вы грумите задачи всей командой (до состояния "бери и делай") и оцениваете задачи всей командой как раз для того, чтобы у всей команды было одинаковое понимание сроков выолнения задачи. И если один человек, по каким-то причинам, уходит, оценка не меняется, просто задача достанется кому-то другому. Увеличится только общее время выполнения всех запланированных задач
Хорошо, быстро набросаю кейс.

Вы работаете по скраму в аутсорсинге. К вам пришел клиент с проектом. Просит оценить. У вас команда из 4 веб-разработчиков. Для проекта нужно 6 примерно. Вы добираете 2 (опустим откуда они взялись)
Вы бывший ПМ, а теперь скрам-мастер .Ваша организация близка по духу к сибириксу.

Вы ему, ща, давайте сделаем прогон оценим (Уговорили так сделать). Работаем 2 недельными спринтами. Прикинули, что для оценки надо 2 спринта, то бишь месяц.

После 1 спринта отвалилось (опустим причины) 3 разраба. Клиент через 2 недели хочет оценку бюджета и сроков. Собственник приходит к вам и хочет оценку каждый час.

Ваши действия?
источник

IA

Igor A in Agile, Scrum, Lean, Kanban, XP
Marcooo
Что не так с T-shaped в менеджменте?

В двух словах T-shaped ("в форме Т") - это метафора, которая обозначает как у сотрудника развиты навыки.
Грубо говоря, специалист в какой-то сфере (программирование на java) со временем достиг больших высот - их символизирует вертикальная перекладина Т. А затем стал осваивать смежные области "справа и слева" от своей основной профессии - горизонтальная перекладина. Получается сотрудник в виде буквы "Т", разносторонне развитый.

Как и любая метафора - образ годится, чтобы пояснить мысль. Но крайне плох чтобы что-то доказать или придумать выход из сложной ситуации.

T-shaped заслуженно популярно в agile-сообществе, однако иногда приводит к конфузам.
Например: в Скрам есть "врожденное ограничение". Скрам-команды тяжело собрать из людей сильно отличающихся профессий. Это не невозможно, но придется преодолеть проблемы "простоев" внутри спринта.

Представьте, у вас команда 7 человек, в ней программисты, тестировщики, аналитик и дизайнер интерфейсов. Скрам. Обычно каждую задачу сперва обдумывает аналитик, подключает дизайнера, позже начинается разработка и тестирование. Спринт, скажем, длится 2 недели. Значит ли это, что сперва работает один лишь аналитик (остальные простаивают), а в конце спринта "пашут" в основном разработчики и тестировщики? Очевидно нет, зачем нам простой? Может, аналитику нужно брать в работу задачи заранее (с опережением на 1-2 спринта)? Ага, а тестировщика будем включать с запозданием (чтобы тоже никогда не простаивал)? А если кто-то в начале цепочки "сбойнет"? А если ролей в команде еще больше, как тогда? Какую бы громоздкую конструкцию из правил и уловок мы не построили - мы либо придем к тому что узаконим корневую причину ("простои - норма, мы их не боимся"), либо сильно начнем противоречить если не букве, то духу Скрам. Подход который делает ставку на легковесность, понятность команде, отсутствие долгосрочного планирования и взаимовыручку - так обрастает правилами, что превзойдет в PMBoK и часть обаяния Скрам для команды исчезнет.

T-shaped - иногда предлагают как решение. Профессии профессиями, но нам нужны Т-люди. Вопрос решен - в начале спринта аналитику помогут разработчики, а в конце те же разработчики помогут тестировщику закрыть задачи вовремя. Ведь все прокачали смежные навыки, отсюда и расширение кругозора, и определенная взаимозаменяемость.

Но важно вспомнить, T-shape лишь метафора. Которую к тому же здорово извратили в индустрии.

Во-первых сама форма буквы сбивает. Заставляет вас поверить, что Java-программист достигших высот в своем деле освоит и смежные области на такой же высоте. На самом деле - его познания в тестировании, бизнес-анализе будут чуть выше базовых (пока не пройдет путь профессионала). Так что правильно было бы букву Т перевернуть.

Во-вторых изначально горизонтальная перекладина отражала не то, что аналитик сможет программировать. Она лишь обозначала, что крутой специалист с широким кругозором легче _ коммуницирует _ , со смежными спецами. Общается, а не помогает / заменяет собой.
В общем случае ставка на T-shape разди взаимозаменяемости - утопия. Программист иногда может помочь тестировщику тестировать. А наоборот? Скажем дизайнер интерфейсов в последние два дня спринта решил помочь коллективу опытных java-программистов. Какой инопланетный скилл должен быть у него прокачан, чтобы  принести реальную пользу?

Ну и в третьих, помните, что T-shape достигается через освоение нового - учебу, отработку, закрепление. Во многом драйвер этой самой горизонтальной перекладины - любопытство. А значит он не сработает без запроса, по одной лишь воле руководства или увещеванию команды "прокачайся, надо". Талантливому программисту  смертельно НЕ интересен бизнес анализ (и тестирование вызывает зевоту)? Едва ли стоит ждать отрастания у него соответствующей "горизонтали".

T-shaped people это хорошая метафора о крутых не зашоренных спецах, познающих смежные профессии и за счет этого находящих общий язык в них. Но это не решение проблемы взаимозаменяемости.  К тому же T-shaped нельзя сделать по приказу, ими можно только стать по своей воле.
Это я знаю. Мне интересно было что из этого понимает человек когда говорит "подумаешь фронтендер заболел" щаз мы его дружно заменим бэкэндерами..
источник

ОБ

Оксана Булаткина... in Agile, Scrum, Lean, Kanban, XP
Igor A
Это я знаю. Мне интересно было что из этого понимает человек когда говорит "подумаешь фронтендер заболел" щаз мы его дружно заменим бэкэндерами..
а это я так говорю?
источник

ОБ

Оксана Булаткина... in Agile, Scrum, Lean, Kanban, XP
Артем Летюшев
Хорошо, быстро набросаю кейс.

Вы работаете по скраму в аутсорсинге. К вам пришел клиент с проектом. Просит оценить. У вас команда из 4 веб-разработчиков. Для проекта нужно 6 примерно. Вы добираете 2 (опустим откуда они взялись)
Вы бывший ПМ, а теперь скрам-мастер .Ваша организация близка по духу к сибириксу.

Вы ему, ща, давайте сделаем прогон оценим (Уговорили так сделать). Работаем 2 недельными спринтами. Прикинули, что для оценки надо 2 спринта, то бишь месяц.

После 1 спринта отвалилось (опустим причины) 3 разраба. Клиент через 2 недели хочет оценку бюджета и сроков. Собственник приходит к вам и хочет оценку каждый час.

Ваши действия?
А я какую роль выполняю в этом всем? Скрам-мастера?
источник

ТХ

Тимур Хайруллин... in Agile, Scrum, Lean, Kanban, XP
Marcooo
Проблема только в том, что вы за всё это время, не дали нормального ответа, по сути проблема вашей компетенции
Я могу дать вам контакты моего руководителя и моей команды. Отпишите им, пусть уволят меня=)
А Вы в чате профессионалов набрасываете  субстанцию известно какого происхождения на вентилятор. Ваши вопросы уже тыщу раз за 30 лет существования скрама были пережеваны. Почему мы должны давать Вам ответы на вопросы без конкретики? Дайте конкретный вопрос. Дайте кейс. Тогда получится конструктив.
источник

АЛ

Артем Летюшев... in Agile, Scrum, Lean, Kanban, XP
Оксана Булаткина
А я какую роль выполняю в этом всем? Скрам-мастера?
Расширю сейчас описание
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Marcooo
Проблема только в том, что вы за всё это время, не дали нормального ответа, по сути проблема вашей компетенции
Что есть нормальный ответ с вашей точки зрения?

Серебряная пуля? Так её нет

И не мы в этом виноваты)
источник

ОБ

Оксана Булаткина... in Agile, Scrum, Lean, Kanban, XP
Так я СМ в команде, или я уговариваю клиента отдать нам проект вотпрямщас, а там посмотрим, как сложится? Или я СМ, который, по старой памяти, ПМ?
источник

АЛ

Артем Летюшев... in Agile, Scrum, Lean, Kanban, XP
Оксана Булаткина
Так я СМ в команде, или я уговариваю клиента отдать нам проект вотпрямщас, а там посмотрим, как сложится? Или я СМ, который, по старой памяти, ПМ?
Клиент уже дал вам тестовые спринты (судя по всему вам дико доверяют).

Спрос прямо сейчас с вас, нужна оценка сроков и бюджета.

Вы см в команде, который имеет бекграунд пмства
источник

IZ

Ivan Z in Agile, Scrum, Lean, Kanban, XP
Тимур Хайруллин
Реально. Хочется уже нецензурно выражаться. Эти набеги реально бесят.
Это как прийти в чат профессиональных механиков и требовать доказать, что "Ключ на 17 лучше ключа на 19"
Видимо, надо просто перестать реагировать
Это от недопонимания.

Приходит человек и говорит: хочу чтобы мне все было понятно. Ответьте мне простыми словами, чтобы мне было понятно.

Ему отвечают. А модель целиком в силу различных причин не помещается. Вот это непонимание вызывает стресс и волнение. Отсюда некоторая экспрессивная подача материала: что это за скрам, (он дурацкий), я его не понимаю (он не работает). То что в скобках - ошибочные суждения от стресса. Может ещё от страха, непонятное (скрам) пугает, и возникает выбор из двух реакций: бей или беги. Андрей выбрал бей )
источник

ОБ

Оксана Булаткина... in Agile, Scrum, Lean, Kanban, XP
Артем Летюшев
Клиент уже дал вам тестовые спринты (судя по всему вам дико доверяют).

Спрос прямо сейчас с вас, нужна оценка сроков и бюджета.

Вы см в команде, который имеет бекграунд пмства
Есть ощущение, что вы воспринимаете скрам-мастера, как менеджера. Что он приходит в команду, говорит, что и как делать, а команда покорно выполняет. Это не так, скрам-мастер - это сервис для команды, который обеспечивает комфортную работу разработчиков. За все остальное ответственность (как и инициативу) несет сама команда. Никто никого не тыкает в шею и не требует отчета за каждый час работы. Вы путаете подходы менеджмента 1.0 и гибких методологий
источник