Igor
как раз таки связано с тем что люди склонны идти по пути наименьшего сопротивления.
Igor
а теперь прикинь сколько на пути коуча который работает в типичном агиль консалтинге "красных" организаций и где надо внедрять агиль потому что клиент уже заплатил :)
Igor
а еще кулстори ты вроде бы внедрил какие то процессы и назвал это скрамом(то что это на самом деле срам), потом вдруг уходишь из компании и твои выстроенные процессы разваливаются сразу же :D но ты себе ставишь ачивку в резюме что ты збс компанию закоучил
Pavel
чтобы не пойти по легкому пути и изменить фреймворк это как раз вопрос стержня
Так нет же, в том то и дело. Если ты понимаешь, как та или иная часть системы работает, и почему она работает именно так, тебе не покажется, что изменить ее - путь наименьшего сопротивления.
Igor
Так нет же, в том то и дело. Если ты понимаешь, как та или иная часть системы работает, и почему она работает именно так, тебе не покажется, что изменить ее - путь наименьшего сопротивления.
вот у меня такое впечатление сложилось о моем бывшем коллеге с которым мы скрам внедряли. но сейчас я что то задумался и понимаю что скорее всего фрейворк он до конца не понимает.
Igor
у него есть канал на ютубе где он делится своими изысканиями на тему, я пару видосов посмотрел и у меня в отрыве от их окружения возникают сильные вопросы :D
Pavel
Всякое может быть. Если посмотреть, что я года четыре назад творил... тоже много вопросов вызывает :)
Igor
Всякое может быть. Если посмотреть, что я года четыре назад творил... тоже много вопросов вызывает :)
это нормально тип развиватся :D мне за то что я творил в той компании малех даже стыдно. но я понимаю что по другому было никак.
Igor
https://www.youtube.com/watch?v=DEZi1wBhPB4&feature=share - вот этот видос у меня вызвал вопросы
Pavel
это нормально тип развиватся :D мне за то что я творил в той компании малех даже стыдно. но я понимаю что по другому было никак.
Стыдно мне в основном за то, что я игнорировал замечания о неадекватности творимого :)
Igor
важно только то что сейчас происходит :)
Pavel
Ретроспективу надо проводить, оглядываться назад и спрашивать себя "а не ...уйню ли я творю" :)
Igor
я в жизни сейчас ее провожу постоянно после того как я сделал что то значимое. типо поехал куда то потом ретроспективу провел что можно было сделать лучше в поездке)
Pavel
https://www.youtube.com/watch?v=DEZi1wBhPB4&feature=share - вот этот видос у меня вызвал вопросы
Ну немного ересь на мой взгляд, но имеет право на жизнь.
Igor
Ну немного ересь на мой взгляд, но имеет право на жизнь.
если начать задавать вопросы то скорее всего ересь полная получится. например больше всего вопросов у меня вызвала связь удаленности PO и дележки ответственности в DT.
Igor
+ опять же история про слабый и сильный маневр :D когда ты не можешь изменить процесс сразу он предлагает делать это постепенно внедряя по кусочкам. однако этот вариант не работает почти никогда ибо при дроблении теряется ценность внедряемых элементов.
Pavel
Ну я тоже внедряю по кусочкам. Кусочки, правда, из скрам-гайда беру :)
Igor
ну смотри внедряешь ты например daily scrum - без цели спринта это будет отчетный митинг где разрабы будут просто отчитываться по задачам. какой профит от этого митинга будет?
Pavel
Просто практика показала, что у многих команд есть две паралельные проблемы:
1. У команд уже есть негативный опыт, когда внедряли скрам, а внедрили не то и не туда
2. У команд нет понимания, как это все работает.
Pavel
Pavel
Дейли вообще последним идет :)
Igor
ну хорошо внедряем ретро - разрабы не могут начать говорить с PO потому что не считают его частью команды, а еще потому что он влияет на зп :D и какой толк у нас от ретроспективы?) ну свои процессы какие то они пофиксят, скорее всего еще придумают новых костылей.
Pavel
ну хорошо внедряем ретро - разрабы не могут начать говорить с PO потому что не считают его частью команды, а еще потому что он влияет на зп :D и какой толк у нас от ретроспективы?) ну свои процессы какие то они пофиксят, скорее всего еще придумают новых костылей.
Ооо, огромный толк. Я теперь знаю, что команда не считает ПО частью команды и не готова что-то открыто с ним обсуждать, потому что он влияет на зарплату.
Pavel
Аж две дисфункции, с которыми можно работать
Igor
Igor
и им тоже процессы в командах как то же работают
Pavel
Им понятно, что это дисфункции?:)
Igor
скорее всего нет. но нужно ли чтобы они это понимали?)
Pavel
Разумеется.
Igor
а что они смогут сделать с этой информацией?
Pavel
а что они смогут сделать с этой информацией?
осознать, понять, что это проблема и согласиться с этой проблемой работать :)
Igor
и у нас получается бремя осознаной проблемы :) если таких проблем куча начинается медленная демотивация.
Igor
PO к сожалению должен сделать первый шаг на исправлении этой дисфункции.
Pavel
и у нас получается бремя осознаной проблемы :) если таких проблем куча начинается медленная демотивация.
А ты, как коуч, там зачем? Направляй в сторону поиска конструктивного решения.
Pavel
PO к сожалению должен сделать первый шаг на исправлении этой дисфункции.
С ПО тоже надо работать.
Igor
на самом деле в большей степени только с ним и надо. от команды мало что зависит ибо там зачастую процессы достаточно гибкие чтобы обеспечить хотелки бизнеса :D
Pavel
Опять же, в реальности у тебя не бдует команды, у которой совсем нет никаких следов scrum, но есть именно что кроссфункциональность и подходящий размер :)
Igor
не всегда он подходящий :D было дело 15 человек в одной команде
Igor
но одно точно всегда есть - следы внедрения чего то похожего на scrum
Igor
например вокрфлоу еще на 10 статусов в жире
Pavel
например вокрфлоу еще на 10 статусов в жире
Это вообще на старте обычно не проблема. В смысле - не надо ее решать, надо root cause искать :)
Pavel
15 человек в команде, безумный воркфлоу, отсутствие релизов фиг знает сколько месяцев - оно часто все в какие-то общие проблемы упираются. command and Control культура, blame game, авторирарный, но очень ветренный ПО, вот это вот все.
Pavel
Если это сверху обмазать очень правильным скрамом - все равно не взлетит.
Igor
так я знаю да
Igor
проблема там была в другом. я обмотал это супер правильным скрамом. оно взлетело чуть пролетело и упало :D
Pavel
Просто если, например, ПО считет себя бигбоссом и склонен к микроменеджменту, то пока ты с ним не отработаешь по полной, нормального планирования и ревью - не будет.
Igor
то что творилось за пределами команды в результате тормозило все :D
Pavel
Ну либо ты станешь сам в авторитарную позу и с воплем "низззя" будешь защищать команду от него... пока не уволят :)
Igor
как Глебка то?)
Pavel
Нет, у меня и без глебки такого в карьере хватало :)
Pavel
Я думаю, что все скрам-мастера проходили стадию скрамдоментализма :)
Igor
у меня была проблема похлесче :D реальный владелец бизнеса не отпускал права PO но и в тоже время давай права но не все. в итоге PO не был полноценным, там даже получился комитет по принятию продуктовых решений. который не мог договорится.
Igor
в итоге многие вещи не решались потому что нет ответственного. владелец бизнеса говорит разбирайтесь сами, назначенный PO говорит я не могу на себя взять такую ответственность.
Pavel
Вот потому и хорошо начать с ретро, найти root cause и попутно найти какие-то проблемы, которые команда может решить сама и быстро.
Pavel
(обычно это что-то, связанное либо с тестами, либо с конфликтами при мердже)
Igor
у меня на поиск этого ушло полгода
Pavel
Т.е. ты начинаешь долгую и муторную работу с проблемой через серию предположений, а команда получает опыт позитивных изменений :)
Igor
лан я кароч спать :D
Anonymous
Всем привет!
Представлюсь 🙂 Работаю в LoyaltyPlant, управляю развитием crm-системы для маркетологов.
Год назад мы ещё были компанией с функциональными отделами - шло туго 🙂 тогда я собрала команду из дизайнеров, разработчиков и тестировщиков и внедрила в скрам со всеми ритуалами и с разговорами, нацеленными на глубокое понимание agile. Получилось здорово. Уже год делаем стабильные релизы каждые 2 недели или чаще. Удовлетворённость пользователей растет, сама команда супер-довольна.
Пожалуй, могу делиться опытом, как внедрять скрам на основе нескольких статей и одной книжки - scrum и XP.
В то же время я выполняю функции PO, и сейчас скорее двигаюсь в эту область.
👋
#whois
Sergey
Sergey
Как то просил меня кто-то скинуть Скрам доску в наших командах. Ловите. В разных командах они разные, но различаются несильно.
Sergey
Sergey
Sergey
Маленькая доска дополнительная для готовых задач и задач для однокомандного PBR.
Sergey
На большой доске снизу справа - цель Спринта. Снизу по всей доске полоса красная для багов с WIP=1. Снизу где нет плавательных дорожек - решения Ретроспективы для выполнения. Все фичи (User Story) оценены в SP и имеют оценку важности от РО (красным) и оценку сложности от команды. Они стоят в плавательных дорожках (светленькие). Остальное на дорожке - техтаски, рождаемые командой на второй части Планирования. Они двигаются по дорожке, пока не будут все сделаны. Исходный листок после этого перемещается в Done, на отдельную доску.
Anonymous
Такие примеры достойны уважения! А какие практики из ХР используете?
Хороший вопрос) Скажу честно, мне как-то сложно назвать "Заказчик всегда рядом" практикой XP, так как это просто у нас по струтуре бизнеса так вышло)
Еще частые релизы (между функциональными раз в 2 недели делаем еще 2-3 маленьких с багфиксами и мелочами).
Planning poker практикуем. Это сюда же?)
В целом, не делали большой акцент на XP.
Sergey
Anonymous
Кстати, раз уж я внезапно тут оказалась.. Подскажите, есть кто работает в джире?) Какой мы только велосипед не изобрели, чтобы с дефектами работать в рамках спринта. Кто может поделиться успешным процессом?)
Sergey
Я тут как раз перевожу очередную статью для https://less.works. Она про Бэклог. Там есть маленький абзац про Инструменты. В переводе он звучит так: "Совет относительно использования инструмента в Scrum и в LeSS. Организации часто ищут инструменты для решения своих проблем, даже несмотря на то, что сами инструменты нередко являются причиной проблемы. Избегайте решения проблем с помощью инструментов, пока вы действительно глубоко не поймете проблему и решите, что инструмент это правильное решение для этой конкретной проблемы." Это я к тому, что сначала я бы описал процесс работы с дефекатми, а затем уже искал под него инструмент. Попытка впихнуть процессы в Инструмент - бессмысленная затея, имхо.
Chyngyz
Кстати, раз уж я внезапно тут оказалась.. Подскажите, есть кто работает в джире?) Какой мы только велосипед не изобрели, чтобы с дефектами работать в рамках спринта. Кто может поделиться успешным процессом?)
Работаем в жире. По процессу рассказать к сожалению не смогу. Но все работает отлично
Anonymous
Я тут как раз перевожу очередную статью для https://less.works. Она про Бэклог. Там есть маленький абзац про Инструменты. В переводе он звучит так: "Совет относительно использования инструмента в Scrum и в LeSS. Организации часто ищут инструменты для решения своих проблем, даже несмотря на то, что сами инструменты нередко являются причиной проблемы. Избегайте решения проблем с помощью инструментов, пока вы действительно глубоко не поймете проблему и решите, что инструмент это правильное решение для этой конкретной проблемы." Это я к тому, что сначала я бы описал процесс работы с дефекатми, а затем уже искал под него инструмент. Попытка впихнуть процессы в Инструмент - бессмысленная затея, имхо.
Не могу не согласиться -) Только вся компания на джире. И хоть процессы важнее инструмента, но работать как-то надо))))