Денис
Да, частично, но не только
Nik
Не, у него не гибкий скрам
Yuriy
Уважаемые коллеги. А кто какие минусы видит в выборе QA Engineer в качестве скрам мастера в IT проект?
Nik
Вовлеченность
Андрей
А что у нас проектное управление сводится к Best practics?
Нет, но моё мнение - в области высокой неопределённости лучше использовать другие процессы. Проект тут имеет много шансов завалиться, и мы имеем много шансов узнать об этом поздно. Аджайл/Скрам не обещают успеха, но они повышают шансы на 1. Успех, 2. Раннее закрытие неудачного продукта.
Yuriy
А он этого хочет? :)
Вот как раз собирается команда
Vasilii
Процедуры скрама позволят еще раз подсветить те проблемы, которые существуют. Но это не серебреная пуля. Без личного участия и изменения своих подходов к работе ничего не поменяется. Все будет точно также только со стендапами и ретроспективами.
Алекс
Вот как раз собирается команда
Для старта лучше взять опытного скрам мастера.
Алекс
+1, и подсветка эта очень яркая
Вплоть до увольнений :)
Андрей
Вот как раз собирается команда
На мой взгляд, для Скрам-мастера критично хотеть им быть. И совмещать эту роль с любой другой нехорошо :), но если иначе не выходит... Если у Вас больше одной команды, я обычно советую, чтобы один из челнов Dev Team 1 был скрам-мастером в Scrum Team 2, и наоборот :) иначе иногда будет возникать конфликт интересов
Андрей
а можно подробнее, какие могут быть конфликты интересов ?
В случае конфликта PO и команды (например, «я хочу чтобы вы взяли в спринт больше» или «давайте возьмём вот это в середине спринта») сложно, будучи членом команды, помочь решить этот конфликт совершенно беспристрастно
Nikolay
Отличнейший ХолиВарчик
Alexey
это первое свойство определения development team тащем то
РЭ:: Они самоорганизующиеся: никто (даже Скрам-мастер) не может указывать Команде Разработки как превратить Бэклог Продукта в готовые к релизу Инкременты. Тут указана изоляция от внешних воздействий. Но не указываются внутренние правила. Таким образом, из этого не следует, что каждый внутри команды должен "сам" принимать решения. И это дает возможность тимлиду планировать работу на исполнителей. ибо если нарушается правило "Команда Разработки состоит из профессионалов, " то никакой самостоятельности не может быть начальном этапе. В обычной ситуации, менеджер занят работой со всеми заинтересованными сторонами и обеспечивает комаду всеми нужными ресурсами.. Поэтому вполне логично что он не будет влезать в принятие решений по реализации. Если поставка идет по плану то достаточно только ставить приоритеты. Но это, также не запрещает запросить защиту выбранного технического решения. С друой стороны Scrum определят Роли. А это значит, что один и тот же сотрудник может иметь несколько ролей.
Алекс
или какой контекст ?
Андрей
В смысле больше ? Цели поставленные командой более не актуальны?
«Больше» в смысле того, что не все команды (особенно начинающие) умеют хорошо ставить цель спринта :) и даже если ставят, то потом «под цель» собирают бэклог спринта из тасков. В общем, конфликты между РО и командой возможны, и SM «из команды» может либо тяготеть занять сторону команды, либо - что даже хуже - сторону РО. В общем, не зря в Скраме SM - это отдельная роль, и уж если мы не можем себе позволить бюджет на выделенных SM а берём на эту роль членов команд, пусть они хоть не в своей команде эту роль играют. Если, конечно, команд больше одной
Igor
РЭ:: Они самоорганизующиеся: никто (даже Скрам-мастер) не может указывать Команде Разработки как превратить Бэклог Продукта в готовые к релизу Инкременты. Тут указана изоляция от внешних воздействий. Но не указываются внутренние правила. Таким образом, из этого не следует, что каждый внутри команды должен "сам" принимать решения. И это дает возможность тимлиду планировать работу на исполнителей. ибо если нарушается правило "Команда Разработки состоит из профессионалов, " то никакой самостоятельности не может быть начальном этапе. В обычной ситуации, менеджер занят работой со всеми заинтересованными сторонами и обеспечивает комаду всеми нужными ресурсами.. Поэтому вполне логично что он не будет влезать в принятие решений по реализации. Если поставка идет по плану то достаточно только ставить приоритеты. Но это, также не запрещает запросить защиту выбранного технического решения. С друой стороны Scrum определят Роли. А это значит, что один и тот же сотрудник может иметь несколько ролей.
там вообще то указано что каждый член команды разработки несет ответственность за продукт. это подразумевает равенство. так же равенство устанавливается через единый титул - разработчик. у вас в команде разрабов не может быть тимлидов 😄 ибо это противоречит тому что все имеют один титул. о том какой должна быть команда хорошо описано у Сазерленда в красной книжке.
Igor
PO и DT вполне могут находится в конфликте интересов. SM как раз нужен для того чтобы создать все условия чтобы команда смогла найти общий язык с PO
Алекс
В этом случае команда должна быть достаточно мотивированной, что бы понимать преграды и устранять их.
+ скорее всего команды откажется от ретро, т.к. эта встреча будет бесполезной, а если мы исключаем какое то мероприятие то это уже называть скамом нельзя :)
Андрей
+ скорее всего команды откажется от ретро, т.к. эта встреча будет бесполезной, а если мы исключаем какое то мероприятие то это уже называть скамом нельзя :)
Должна быть, но станет такой не сразу. И задача SM им помогать туда расти, преодолевая проблемы. Про «откажется от ретро» я не понял, почему :), но и тут «внешний» SM лучше, чем один из девелоперов - он может таки настаивать, что ретро нужно.
Алекс
Должна быть, но станет такой не сразу. И задача SM им помогать туда расти, преодолевая проблемы. Про «откажется от ретро» я не понял, почему :), но и тут «внешний» SM лучше, чем один из девелоперов - он может таки настаивать, что ретро нужно.
Такая ситуация возможна если SM - разработчик из другой команды, т.к. у разработчика есть свои задачи которые как участник команды он должен решать в рамках другой команды и целей которые стоят перед командой.
Алекс
Все таки лучше взять на время опытного скарам мастера, что бы он выступал как ментор для одного из участников команды, который со временем останется разработчиком и станет SM для команды
Igor
Такая ситуация возможна если SM - разработчик из другой команды, т.к. у разработчика есть свои задачи которые как участник команды он должен решать в рамках другой команды и целей которые стоят перед командой.
как SM в такой ситуации сможет вытаскивать проблемы другой команды? если он работает в одной команде разрабом у него не будет времени подготовится к ретро - это почти всегда значит что ретро будет безполезное.
Андрей
Все таки лучше взять на время опытного скарам мастера, что бы он выступал как ментор для одного из участников команды, который со временем останется разработчиком и станет SM для команды
Это идеальный вариант. Я о том случае, когда вообще "нет денег на вашего скрам-мастера, пусть один из девелоперов им будет"
Андрей
как SM в такой ситуации сможет вытаскивать проблемы другой команды? если он работает в одной команде разрабом у него не будет времени подготовится к ретро - это почти всегда значит что ретро будет безполезное.
Задача скрам-мастера - применяя "хитрые штучки", тащить информацию для ретро и на ретро из членов комады, а не самому её приносить. Да, приходится и самому, но на самом деле участия в остальных встречах - планирования, демо и стенд-апах - бывает достаточно чтобы диагностировать основные проблемы и принести их на ретро.
Андрей
ИМХО В этом случае, лучше не использовать Scrum а попробовать Канбан
Да нет, выбор между скрамом и канбаном всё-таки по другим критериям 🙂
Алекс
Да нет, выбор между скрамом и канбаном всё-таки по другим критериям 🙂
По каким ? по неопределенности поставленной задачи?
Андрей
Скорее по продуктовым и средовым. Новый незнакомый продукт в условиях высокой неопределённости - лучше Скрам, продукт уже взрослый и нужно оптимизировать поддержку/малые изменения - лучше Канбан. Опять же, если продукт новый, но типовой - я за Канбан, потому что гипотезы уже проверены и нужен скорее поток доставки.
Андрей
Так что да, по неопределённости в конечном итоге
Андрей
Люди - важны, ОЧЕНЬ важны, но если в компании до того не было ни скрама ни канбана, переход что на первый что на второй будет революцией ) Особенно когда в Канбане начнут чёткие WIPы расставлять и правила перехода по стадиям ))) ой-ой-ой, тут подгорает ярче чем от скрамовского "мы в середине спринта новых задач не берём" 🙂
Nikolay
Иначе бяда
Андрей
Андрей, все так, по этому , wip лимиты вводят сильно погодя.
Но вводят же ))) а сначала продаём Канбан как "менее революционный чем Скрам" )))
Nikolay
Ну Девид он же Девид ;)
Андрей
Чтобы так хитро вытащить на ретро штуки надо быть на фуллтайме в команде
Нет. Чтобы их принести самому - надо быть фуллтайм. чтобы их вытащить - нужен опыт проведения ретро и знание, как людей раскочегарить
Вадим
А кто то из группы работал (работает) в Избенке-Вкусвилл?
Вадим
Интересен опыт и карьерное развитие, если было
Андрей
все таки - главное в Scrum это цель спринта а не колчество задач в спринте. тут главное что dev команда совместно с PO решает какие задачи они делают для достижения целей спринта
Да, всё верно, но на практике я пока что мало видел команд (особенно в корпоративном мире, не в стартапах), которые грамотно умеют работать с целью спринта. Особенно с самого начала 🙂
Igor
Чтобы готовится надо быть с командой и видеть что у них творится
Андрей
Без подготовки вы только на срач их раскочегарите :D
Ну смотрите - пока команда молодая/новая, она косячит везде. То есть на встречах (а скрам-мастер парт-тайм скорее всего на встречи-то ходит) это лезет. И ему хватает чего принести. Дальше - команда зреет, но и скрам-мастер зреет тоже и начинает уже не столько приносить, сколько помогать команде самой проявлять. Ну а дальше - если всё хорошо - то у команды появляются аргументы, а у компании - уверенность в том, что нужны выделенные скрам-мастера на фуллтайм.
Андрей
Может быть, слишком идеалистично, но ситуация когда скрам-мастер = член той же команды обычно кончается хуже. Ещё раз: ситуация с выделенным фулл-тайм скрам-мастером ИДЕАЛЬНА, но я сейчас о том сетапе, когда это невозможно. Не надо меня убеждать в том, что он нужен - я в этом сам убеждён )))
Igor
Что значит косячат? У меня новые команды исправляли непонимание скрама за 2-3 недельных спринта. Потому как с новыми командами работать проще у них нет сломанного понимания.
Алекс
Да, всё верно, но на практике я пока что мало видел команд (особенно в корпоративном мире, не в стартапах), которые грамотно умеют работать с целью спринта. Особенно с самого начала 🙂
Зачастую в коорпоративном мире есть РП, со старыми привычками - РП оценивает, РП ставь задачу, РП конролирует, РП проверяет выполнение. А Scrum Фреймворке подругому, исполнитель + PO ставим цель, исполниетель оценивает, исполнитель берет задачу, исполнитель демонстрирует результат РО + заинтересованным
Андрей
Что значит косячат? У меня новые команды исправляли непонимание скрама за 2-3 недельных спринта. Потому как с новыми командами работать проще у них нет сломанного понимания.
Зависит от предыстории компании и сложившейся культуры. Корпорация 20 лет от роду - о, да, там конечно за 2-3 недели всё исправится, как по волшебству ))) 2-3 года не хотите только на то, чтобы продакт овнеры получили продуктовые KPI вместо проектных? )))
Андрей
И до хрена сил вложить. И не сдаться. И не "перестоять в позе отказа" тоже.
Igor
Зависит от предыстории компании и сложившейся культуры. Корпорация 20 лет от роду - о, да, там конечно за 2-3 недели всё исправится, как по волшебству ))) 2-3 года не хотите только на то, чтобы продакт овнеры получили продуктовые KPI вместо проектных? )))
Все зависит от того как вы в эту новую команду людей набираете. Если набирать людей которые до мозга костей пропитаны этой корпоративной культурой - никакого скрама не будет.
Андрей
А "других людей у меня для вас нет" 🙂 и пропитаны там все, в разной степени, и даже при желании жить по-новому навыков и привычек этой новой жизни нет, их надо создавать, и 2-3 спринта здесь - это адски оптимистичный срок, ну или вам круто везло )
Андрей
Да я тоже ищу, но и у них есть "груз прошлого", и за пределами этих команд он тоже довлеет. Понятно, как сказал Ионов в пятницу, "чтобы быть успешным коучем, нужно коучить успешных клиентов" 🙂 И здорово работать со стартапом - мотивация, вовлечённость, корпоратского дерьма не лежит за каждым углом, бюрократии минимум... но сейчас ведь корпорации бодрой стаей идут в светлое будущее. И с ними тоже приходится работать. И, как ни странно, именно у них есть деньги на скрам-мастеров, коучей и т.д. 🙂
Dmitry
Андрей
Пятничный срачик имеет право быть и во вторник! 🙂
Igor
У нас было большое удивление когда нашли опытного разраба из большой команды для перехода в новую. Суть была в том что он косячил и команда была недовольна им. Никто не ждал что он изменится. Но что забавно он изменился.
Алекс
Dmitry
Пятничный срачик имеет право быть и во вторник! 🙂
Я только пришел, пока не уловил в чем срач)
Андрей
Да нет срачика как такового, беседуем 🙂 Я себя странно чувствую, как будто мои коллеги святее меня в стремлении к идеальному скраму, а я отстаиваю право корпоратской реальности на неидеальность ))) оччччень для меня странная поза, ну да ладно 🙂
Dmitry
У меня вот практический вопрос, господа ковучи, какая обувь для тренеров самая удобная? А то у меня после трех дней тренингов, есть непреодолимое желание нанять персонального массажиста )))
Андрей
Ecco 🙂
Андрей
Подерёмся, ой подерёмся )))
Dmitry
Эх
Андрей
Эх
И я не успел, мне его предложили первому, пришлось отбиваться. Иначе-то, конечно, предложил бы
Алекс
Все таки вопрос, применимы ли Scrum Kanban фреймворки для компаний с бирюзовыми парадигмами ?
Андрей
А почему бы и нет? Есть конкретные сомнения?