Ну вообще мне кажется, что инспекция и адаптация как раз и есть про непрерывное совершенствование.
В том и разница. В книге непрерывное совершенствование называлось «непрерывным совершенствованием». С циклом Деминга, отсылкой к японским итерационным же практикам совершенствования процессов, и красной нитью через всю книгу — «надо совершенствоваться, в этом смысл».
А теперь, в гайдах, такую информацию только выискивать и вычленять можно, иногда притягивая за уши. Изначальная главная цель методики стала двумя-тремя короткими фразами инструкции, которые без болта не заметишь.
Ладно, чего-то разнылся я. Если у вас получается ускорить разработку в разы, используя скрам гайд — ок, рад за вас. Пишите опыт, с удовольствием почитаю, ибо такого опыта в публичном пространстве практически нет. Одни гайды :)
Корень проблемы кроется в упрощении методики. Кто это упрощение сделал – не знаю. Вероятно, консультанты, которые изучили методику и должны были ее продавать. Продать скрам с ускорением до 4X за короткое время – нельзя, потому что для получения высокого результата невозможно использовать только инструкции из книги – нужно искать пути оптимизации для конкретной команды… Намного проще, с точки зрения бизнеса консультанта, продать инструкцию, научить выполнять эту инструкцию и получить свои деньги
Честно, не знал, что и авторы скрама пошли по этому пути.
Это и ужасная, и прекрасная новость.
Ужас в том, что скоро никто не вспомнит, зачем был создан скрам и в чем его смысл.
Прелесть в том, что у нас не осталось конкурентов.
мне не очень понятна Ваша неприязнь к Скрам Гайду
попробуйте найти в нем раздел про непрерывное совершенствование.
Гайд делает самое поганое, что можно сделать — выключает мозг, включает только ноги и руки.
Я, честно, не думал, что все так плохо. Несколько раз в комментариях, в социальных сетях, встречал отсылки к этому гайду. Но не думал, что люди это всерьез.
Это все равно, что пытаться понять медицину по методичке оказания первой помощи, которую в институте давали. Не помню, как предмет назывался, там еще надо было искусственное дыхание делать манекену.
Скрам-гайд — очень неудачный выбор для тех, кто хочет внедрить скрам. Это поделка, которую авторам скрама пришлось сделать — для тех, кто не хочет думать, а хочет лишь исполнять инструкции. Там прямо так и написано — запрещено менять, убирать и добавлять.
В книге про скрам, того же автора, написано прямо противоположное.
Книга — первоисточник, оригинал. Скрам гайд — производная, причем низкого качества.
Увы. #Ускорение4X соотносится со скрам гайдом так же, как скрам соотносится со скрам гайдом — никак. Слова похожи, но не более того.
О тотальном контроле речи нет, нужен контроль изменений. Осуществляет скрам-мастер — тот, кто отвечает за процесс. Но это я вперед забегаю, обо всем напишу в свое время.
Я правильно понимаю, что Вы отказываетесь от такой базовой вещи в скраме, как самоорганизация команд
Неправильно. Как только вы перестанете считать скрам-мастера внешним по отношению к команде, все встанет на свои места. Выбор скрам-мастера, как ответственного за процесс, делает команда — ровно для того, чтобы не париться всем сразу. Это и есть самоорганизация.
Но если предлагается некая авторская методология, зачем вообще использовать терминологию и роли из скрама?
Об этом говорилось в прошлой публикации. Авторская методика — это fork scrum, ровно как и написано в оригинальной методике. Часть терминов, ролей, процессов и фишек от скрама остались. Если их переобзывать по-своему, то придется вести таблицу соответствий.
Почему во главу процесса поставлен скрам-мастер, а не продакт-овнер, например?
Потому что владелец продукта не работает с командой каждый день, не присутствует в процессе.
Ведь ускорение разработки — это долговременная цель
скорее — постоянная, как непрерывное совершенствование.
А за стратегическое развитие продукта или сервиса отвечает именно продакт-овнер
пусть отвечает, только это разные зоны ответственности — развитие команды и развитие продукта. И нет правильного ответа, что важнее — зависит от ситуации. Я исхожу из ситуации, что команда более постоянна, чем продукты.
Откуда у скрам-мастера берется понимание, что сейчас удачный момент (с точки зрения «бизнеса») для экспериментов с процессами, которые могут сказаться негативно?
Если скрам-мастер работает правильно, то он создаст ситуации с явными негативными последствиями своих экспериментов. А момент для совершенствования почти всегда подходящий.
В обратном порядке мне больше нравится: скрам-мастер должен заниматься ускорением.
Если цель ставится не команде, а скрам-мастеру, чем он отличается от прожект-менеджера?
Если определить не только кому ставится цель, а еще и кем ставится цель, то скрам-мастер вполне может остаться скрам-мастером. Например, если цель «ускорять» ставится командой, избранному командой скрам-мастеру.
Проект-менеджер — принципиально другая роль. Его цель — выполненный проект, т.е. результат, а команда — ресурс проекта.
У скрам-мастера цель — команда и процесс, его улучшение. В моей системе объектом улучшения является скорость.
Спасибо, это мой любимый вопрос, все программисты его задают.
Постоянно меняющиеся правила — да, об этом и публикация. Постоянно меняющиеся до определенного момента. В этом весь смысл.
Отсутствие документации было и до, и во время, и после. Т.е. тут ничего не менялось.
Быстрая разработка — это вы про экстремальное программирование? Не могу уловить коннотацию.
наверное, все-таки, скажет что-то типа «Uncaught SyntaxError: Unexpected identifier» или «Uncaught SyntaxError: Unexpected token :».
Это не «мы так не договаривались», а «я не понимаю, чего ты хочешь от меня». Я в публикации говорил об отказе от исполнения изменений, о сопротивлении.
Да и вообще не важно это, вроде. Вы же поняли, о чем абзац. Пусть и не идеальная аналогия подобрана.
По поводу мало-изученности agile/scrum для больших команд не соглашусь
не для больших команд, а для большого количества команд. Если точнее, то — для управления границами, будь то команды, отделы, функции, бизнес-процессы, цели и т.д. Но это тоже оффтоп.
У нас была команда 5 человек. Скрам рекомендует до 9 человек, насколько я помню.
Если придет сбер с 6 тыс.человек, то они поделятся на небольшие команды, и получат суммарное ускорение БОЛЬШЕ, чем в 4 раза, по сравнению с тем, что есть у них сейчас. Потенциал ускорения взаимодействующих команд в разы выше, чем одной команды, и тем более одного человека.
Опять забегаю вперед, но значительная, а порой невероятная доля потерь находится на границах команд, отделов, организаций и т.д. И это крайне малоизученная область. Чтобы убедиться, попробуйте найти полезную информацию по теме boundary management.
Наберитесь терпения, дружище.
Без обид, но именно про такие расспросы написано в начале статьи: «Просто нас задолбали с вопросами по почте и на конференциях, поэтому решили рассказать централизованно, в самом подходящем для этого месте — Хабре».
Это не про то, что мы чего-то там про себя думаем. Мы — программисты, и не любим делать одну работу много раз.
Если я начну отвечать на все вопросы, то придется написать в комментариях все планируемые публикации. Потому что простые ответы вас не удовлетворят, нужны объяснения.
Я обязательно все расскажу.
А полезные вопросы, вроде ваших, буду учитывать в процессе изложения.
Прошу понять меня правильно.
были как Crome, как программы, будете их запускать, останавливать, подвешивать в отладчике
нет, люди — это люди. Объяснение в таких терминах, из моей практики, понятнее программистам. Менеджерам по-другому понятнее, чернокнижникам — в терминах цикла Деминга, и т.д.
Это просто форма подачи одной и той же информации.
В том и разница. В книге непрерывное совершенствование называлось «непрерывным совершенствованием». С циклом Деминга, отсылкой к японским итерационным же практикам совершенствования процессов, и красной нитью через всю книгу — «надо совершенствоваться, в этом смысл».
А теперь, в гайдах, такую информацию только выискивать и вычленять можно, иногда притягивая за уши. Изначальная главная цель методики стала двумя-тремя короткими фразами инструкции, которые без болта не заметишь.
Ладно, чего-то разнылся я. Если у вас получается ускорить разработку в разы, используя скрам гайд — ок, рад за вас. Пишите опыт, с удовольствием почитаю, ибо такого опыта в публичном пространстве практически нет. Одни гайды :)
Значит, в предыдущей статье я был прав наполовину:
Честно, не знал, что и авторы скрама пошли по этому пути.
Это и ужасная, и прекрасная новость.
Ужас в том, что скоро никто не вспомнит, зачем был создан скрам и в чем его смысл.
Прелесть в том, что у нас не осталось конкурентов.
попробуйте найти в нем раздел про непрерывное совершенствование.
Я, честно, не думал, что все так плохо. Несколько раз в комментариях, в социальных сетях, встречал отсылки к этому гайду. Но не думал, что люди это всерьез.
Это все равно, что пытаться понять медицину по методичке оказания первой помощи, которую в институте давали. Не помню, как предмет назывался, там еще надо было искусственное дыхание делать манекену.
Скрам-гайд — очень неудачный выбор для тех, кто хочет внедрить скрам. Это поделка, которую авторам скрама пришлось сделать — для тех, кто не хочет думать, а хочет лишь исполнять инструкции. Там прямо так и написано — запрещено менять, убирать и добавлять.
В книге про скрам, того же автора, написано прямо противоположное.
Книга — первоисточник, оригинал. Скрам гайд — производная, причем низкого качества.
Увы. #Ускорение4X соотносится со скрам гайдом так же, как скрам соотносится со скрам гайдом — никак. Слова похожи, но не более того.
О тотальном контроле речи нет, нужен контроль изменений. Осуществляет скрам-мастер — тот, кто отвечает за процесс. Но это я вперед забегаю, обо всем напишу в свое время.
Неправильно. Как только вы перестанете считать скрам-мастера внешним по отношению к команде, все встанет на свои места. Выбор скрам-мастера, как ответственного за процесс, делает команда — ровно для того, чтобы не париться всем сразу. Это и есть самоорганизация.
Об этом говорилось в прошлой публикации. Авторская методика — это fork scrum, ровно как и написано в оригинальной методике. Часть терминов, ролей, процессов и фишек от скрама остались. Если их переобзывать по-своему, то придется вести таблицу соответствий.
как курица и яйцо. Нужно и то, и другое.
Потому что владелец продукта не работает с командой каждый день, не присутствует в процессе.
скорее — постоянная, как непрерывное совершенствование.
пусть отвечает, только это разные зоны ответственности — развитие команды и развитие продукта. И нет правильного ответа, что важнее — зависит от ситуации. Я исхожу из ситуации, что команда более постоянна, чем продукты.
Если скрам-мастер работает правильно, то он создаст ситуации с явными негативными последствиями своих экспериментов. А момент для совершенствования почти всегда подходящий.
В обратном порядке мне больше нравится: скрам-мастер должен заниматься ускорением.
Если определить не только кому ставится цель, а еще и кем ставится цель, то скрам-мастер вполне может остаться скрам-мастером. Например, если цель «ускорять» ставится командой, избранному командой скрам-мастеру.
Проект-менеджер — принципиально другая роль. Его цель — выполненный проект, т.е. результат, а команда — ресурс проекта.
У скрам-мастера цель — команда и процесс, его улучшение. В моей системе объектом улучшения является скорость.
Хм, ладно.
На высшую истину и полное раскрытие темы не претендуем, спорить ни с кем не собираемся, мы этот путь прошли. Хотите – тоже проходите.
Постоянно меняющиеся правила — да, об этом и публикация. Постоянно меняющиеся до определенного момента. В этом весь смысл.
Отсутствие документации было и до, и во время, и после. Т.е. тут ничего не менялось.
Быстрая разработка — это вы про экстремальное программирование? Не могу уловить коннотацию.
наверное, все-таки, скажет что-то типа «Uncaught SyntaxError: Unexpected identifier» или «Uncaught SyntaxError: Unexpected token :».
Это не «мы так не договаривались», а «я не понимаю, чего ты хочешь от меня». Я в публикации говорил об отказе от исполнения изменений, о сопротивлении.
Да и вообще не важно это, вроде. Вы же поняли, о чем абзац. Пусть и не идеальная аналогия подобрана.
не для больших команд, а для большого количества команд. Если точнее, то — для управления границами, будь то команды, отделы, функции, бизнес-процессы, цели и т.д. Но это тоже оффтоп.
Если придет сбер с 6 тыс.человек, то они поделятся на небольшие команды, и получат суммарное ускорение БОЛЬШЕ, чем в 4 раза, по сравнению с тем, что есть у них сейчас. Потенциал ускорения взаимодействующих команд в разы выше, чем одной команды, и тем более одного человека.
Опять забегаю вперед, но значительная, а порой невероятная доля потерь находится на границах команд, отделов, организаций и т.д. И это крайне малоизученная область. Чтобы убедиться, попробуйте найти полезную информацию по теме boundary management.
Наберитесь терпения, дружище.
Без обид, но именно про такие расспросы написано в начале статьи: «Просто нас задолбали с вопросами по почте и на конференциях, поэтому решили рассказать централизованно, в самом подходящем для этого месте — Хабре».
Это не про то, что мы чего-то там про себя думаем. Мы — программисты, и не любим делать одну работу много раз.
Если я начну отвечать на все вопросы, то придется написать в комментариях все планируемые публикации. Потому что простые ответы вас не удовлетворят, нужны объяснения.
Я обязательно все расскажу.
А полезные вопросы, вроде ваших, буду учитывать в процессе изложения.
Прошу понять меня правильно.
нет, люди — это люди. Объяснение в таких терминах, из моей практики, понятнее программистам. Менеджерам по-другому понятнее, чернокнижникам — в терминах цикла Деминга, и т.д.
Это просто форма подачи одной и той же информации.
Об этом будет отдельная публикация.