https://www.youtube.com/watch?v=GN5KI4pxwFg на тему фасилитатор ментор тренер

Надо посмотреть. Хотя само название содержит в себе методологический анти-паттерн :)

Главное - содержание

Надо посмотреть. Хотя само название содержит в себе методологический анти-паттерн :)

coach, master <> boss?

Есть большая проблема нелепости переводов, потому что термин Servant Leadership на русском звучит как-то странно :)

Поэтому как правило приходится приземлять на то, что есть.

Вот вам из последнего pink cards -> розовый талон :)

Руководитель это вообще не про другое. Менеджеры по своему определению нужны для того, чтобы придавать организации устойчивость и не давать изменениям слишком сильно раскачать лодку.

То есть не для проведения изменения, а для контроля за ними.

Эту и другую точку зрения вы всегда можете услышать на канале Agile

Всем пятницы, котаны :) Agile вам, и чтобы без срама

:)))

😁😁

Я про менеджеров если что. Скрам-мастера и коучи это не менеджеры соответственно

😄 где-то в Славиной биографии явно есть пятно, связанное со скрамом...))

Менеджер = иерархический менеджер

Я про менеджеров если что. Скрам-мастера и коучи это не менеджеры соответственно

+1

но они также и не проджект-менеджеры в классическом понимании

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

Короче да - нужны фасилитаторы, а не менеджеры. Менеджеры только для контроля, хотя не факт, что он вообще нужен

фальсификаторы

коллеги, кому интересно поговорить про кастомер девелопмент + скрам процесс , приглашаю на митап 02 ноября в Москве. Я писал про него, но может быть кто то еще не прочел и не записался. https://infoshell-ev-org.timepad.ru/event/389115/

Как теперь идти?

Тьфу!

Кстати, утверждение неверное

я тоже немного... "удивился" от этого высказывания

может потому что скрам <> продакт-менеджмент?

скрам как раз позволяет создать успешный продукт, в книже это на первых страницах (например Кона)

но вот для стартапа... :)

он позволяет создать работающий продукт, но не успешный

@neemah не вырывай высказывание из контекста. Полное высказывание было с продолжением.

есть разница между успешным продуктом и работающим

и причина очень простая - Скрам не дает методов создания стратегии или видения продукта . По сути это конвеер, который позволяет создать работающий продукт.

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

кое-как работающий

а в сочетании с такими вещами как кастомер девелопмент или дизайн мышление можно получить хороший эффект

кое-как работающий

ну как сделать так и будет-) хорошо делай хорошо будет

Скрам не конвеер и контекста там мало :) Дмитрий, я беру то что вы пишите, если ставите enter посередине мысли - не вините окружающих

к ранее поднимавшемуся вопросу об "agile-комнате")) (из книги "Scrum и XP: заметки с передовой" - www.pmoffice.by/wp-content/uploads/2016/07/Scrum-XP-zapiski-s-peredovoy.pdf )

Всем привет, а подскажите, как в agile, фиксировать задачи, которые на прямую команда не делает, но зависит от них. кроме туду и ексельки отделной?

А что будет если не фиксировать?

может забыться

и другие дела появиться

Вы написали "зависит"

Зависит в моем понимании "мы не можем доделать эту задачу, потому что зависим от ..."

Если это ситуация может забыться - может оно нафиг и не надо? :)

А так вообще зависимости блокирующие как правило, прямо в задаче указываются в списке задач команды.

наверное, для начала еще нужно разделить условия, необходимые для выполнения задачи на: - чисто ожидающие - нужно просто дождаться готовности X - требующие инициирования: нужно инициировать Y для возможности выполнять задач A, B, C... т.к. это ведь требует разного подхода

и, наверное, эти зависимости д.б. обработаны до попадания в sprint backlog для Scrum, и в ToDo/Planned для Kanban

Agile это не набор правил, лучше бы проблему описали ;)

тем не менее, правила же в нем есть?)

линки в issue tracker системе между задачами-то можно проставить, вопрос похоже был в том, как потом все эти dependencies выгрузить в виде представления

ситуация: проект идет фоном, работы выполняют люди из разных agile команд и тимлид, который вне команд, я контролю это дело, в мою команду текущие работы не попадают и соответсвенно фиксируются только у меня в эксельке) скрам мастер не хочет добавлять эти задачи в спринт, мол не положено) а хотелось бы не бегать по людям и не спрашивать кто, что делает и не напоминать)

так заведите отдельное пространство для таких задач, и там попросите людей фиксирвать

тот же excel на google drive

а не локально

Привет всем! А вы тут уже обсуждали ситуацию, когда тестировщики в начале спринта "простаивают", так как разработчики еще ничего не сделали, а в конце спринта наоборот? Ответ, вроде очевиден - кросс-функциональные команды, но не каждый разработчик захочет тестировать...

Причем, не хватает буквально 10% времени спринта чтобы догнать тестирование

Простой это хорошо, время чтобы заняться процессными вещами, например учиться автотестам

кросс-функциональная - это не то что я выполняю несколько ролей, а то что внутри команды есть ВСЕ роли

у нас в команде юнит тесты внедрили, вроде норм, всё успевают. Тестировщик учиться программировать)

В этом и суть простоев

slack-time называется

УЧИТЬСЯ*

Тогда интересно , как разрешить такое, что если тестирование -узкое место, то при планировании спринта нужно брать меньше разработки. Так? И мы приходим к некоторому соотношению, например 1 тестировщик на 3 разработчиков

вы не берете разработку при планировании спринта, вы берете обязательность по релизу ЦЕЛИ

думайте целью, а потом думайте как там решать уже внутри вопросы аля кто тестирует, а кто программирует

ну как, вы даже не берете обязательства, вы говорите "мы очень постараемся" :)

программизм - это способ достижения цели

не всегда единственный

Интересная мысль про путь решения проблем :))

единственный способ сократить ошибки в коде - не писать код

е д и н с т в е н н ы й действенный (IMHO)

:p

тестировщики так себе

О, да :)

КМК тестировщики хороши с точки зрения требований. потому что они пытаются взглянуть на продукт с точки зрения пользователей

если на этапе требований уже подключаются, то хорошо, а если код какой-то не успели протестировать -ну... :)

Да, мы тестировщиков привлекаем на стадии разбора требований (без них не проводим вообще)