Kaizen и ретроспектива
Alex Yakima
под вопрос что и как вы делаете, а считаете, что все ОК - значит вам
нужно что-то менять.
Интересно, сколько проходит совершенно безрезультатных ретроспектив
каждую минуту в мире, резюие которых: вобщем у нас все ОК? Более того,
сколько команд их вобще не проводит...
СанЁк Баглай
> Вспомнилась цитата Таичи Оно (передаю по памяти): Если вы не ставите
> под вопрос что и как вы делаете, а считаете, что все ОК - значит вам
> нужно что-то менять.
Я когда-то на общем собрании в компании попытался протолкнуть идею,
когда каждый второй-третий-четвертый-.. раз, делая что-то однотипное,
придумывать все более новые способы реализации. Пускай они будут
уступать предыдущим способам в чем-то - не это ценное. Ценна та
привычка, которая прививается: привычка меняться и искать новые (чаще
креативные) пути решения обычных проблем. Как результат, в казалось бы
безвыходной (для команды) ситуации, твой натренированный мозг находит
куда больше 2х реальных путей решения.
На общем собрании меня забанили, сказав "зачем менять то, что
работает?" Конечно, я могу понять мотивацию - поиск чего-то нового в
краткосрочной перспективе отнимает дополнительных денег. Но это только
поначалу так. Видение у каждого свое - кто-то считает рабочим то, что
изнутри загнивает.
У меня есть вопрос, как сделать так, чтобы каждый участник команды
желал меняться каждый день, а на ретроспективу приносил бы идеи
которые хотел бы реализовать в команде?
Alex Yakima
самокритичны и всегда в поиске, некоторые - нет. Что касается новых
углов - это классно, но это делает только команда, которая ИЩЕТ.
Вопрос теперь в том, как создать команду, которая привыкла находиться
в режиме поиска новых путей. Ответ прост на первый взгляд - нужна к
этому мотивация. Сложно ее развить правильно в рамках команды. Но
возможно... своим же опытом. Короткие итерации плюс несколько удачных
ретроспектив по результатам чьих-то нововведений, или критичного
взляда, - дуть во все трубы о виновниках командного счастья...
Разработчик - существо амбициозное, это факт, мало в ком это не
разбудит желания "и самому так сделать".
Мне, правда, было легче всегда, у меня была стопроцентная поддержка
менеджера - потому что я им и был :)))
СанЁк Баглай
>
> Мне, правда, было легче всегда, у меня была стопроцентная поддержка
> менеджера - потому что я им и был :)))
Еще я заметил, что меняться надо локально начиная с себя. Хочешь,
допустим привить парное программирование? Не стоит идти за этим к
менеджеру и предлагать ему эту идею. Так же не стоит продавать ее
команде на очередной ретроспективе. Так же не стоит предлагать
напарнику парно по-программировать пару дней в неделю или даже пол дня
в неделю. Не стоит вообще говорить никому, что ты делаешь а делать
это. Как? Тебе задали вопрос? Прививай привычку не говорить "не, не
знаю я с этим не работал" а идем попробуем что-то сделать вместе (то
есть парно, только тссс, ни слова об этом). Можно так же попросить
кого-то тебе помочь. Ну или на очередном планировании сказать что эта
фича очень сложная, и надо еще новенького прокачать, а значит взять
себе его в напарники.
Ой! Как-то больше про парное программирование получилось, чем про
перемены :)
В общем менеджер не помощник - у него с каждым твоим нововведением
риски повышаются. Его за это будут ругать. Вот если поделить с ним
ответственность пополам или снизить риски, вот тогда он будет
содействовать. Но стулья вперед!
Alex Yakima
Но иногда, кстати, собственной инициативы может не хватить. Зависит от
менеджера тоже, конечно. Разные личности бывают.
не все практики можно так внедрять. Парное программирование, ТДД - да.
А вот с постоянной интеграцией уже будет посложнее, потому что если
один-два человека стараются так работать, а остальные работаю
старообрядчески (при том, что code base один и тот же), то у новаторов
будет инсульт и очень скоро.
-Саша
СанЁк Баглай
у новаторов будет инсульт и очень скоро.
О! Есть идея - дай долю от прибыли и будет тебе счастье. Что скажешь? Опыта в этом у меня не очень, но идея такая есть.
Так же можно привить вначале парное программирование, а потом через него все остальное...
И вообще зачем что либо прививать? Заметил, что игроки команды по своей природе люди креативные и сами многое уже придумали для себя, просто не делятся этим с командой. А зачем выносить на всеобщее, если вероятно критика польется?
Alex Yakima
иную технику, процедуру и т д. Пару успешных применений - друг другу
возрастает доверие, позволяющее рассчитывать на то, что тебя не будут
пытаться моментально раскритиковать. Просто полная партизанщина тоже
не выход. В конце концов у команд тоже есть свои амбиции - например,
четко знать, что они применяют ТДД, что это их командная практика и
даже можно этим похвастаться за пивом с экс-коллегами из предыдущей
конторы.
On Oct 13, 2:02 pm, СанЁк Баглай <apo...@gmail.com> wrote:
> 13 октября 2010 г. 13:57 пользователь Alex Yakima
> <alex.yak...@gmail.com>написал:
СанЁк Баглай
http://groups.google.com/group/enter-agile/browse_thread/thread/1a7d7309cf0d1e70
), который поможет партизанщине опопсеть и помочь команде порадоваться
за результат совместно.
Philipp Dzyuba
внедрения в команде. Ну, по крайней мере, для меня.
Проблема номер раз. Формальный митинг. Команда воспринимает
ретроспективу как формальное действие, которое все равно некому не
нужно и ни к чему не приводит. У нас есть скрам мастер, пусть он и
разбирается, как улучшать процесс.
Проблема номер два. Максимализм. Очень часто команда предлагает экшены
которые невозможно выполнить даже за год. К примеру <<Разобраться во
всей системе и во всей бизнес логике, и только тогда будет счастье>>
Проблема номер три. Склероз. Команда очень часто забывает про экшены
которые сама и предложила, на следующий же день. В конечном итоге она
Снова приходить к проблеме номер раз.
С текущей командой действительно правильные ретроспективы начались
только со спринте No. 9. Команда самостоятельно озвучила все проблемы,
самостоятельно выписала экшены и в следующем спринте все их применила.
Я все это время сидел тихонько и радовался :)