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