Comments 23
TL;DR
Тут завуалированное требование «будь послушным».
Команда должна стать средой исполнения – гибкой, адаптивной, не возражающей.
Тут завуалированное требование «будь послушным».
А представьте, если бы возражал? Как изменилась бы скорость вашей работы?Скорость бы уменьшилась. Однако люди возражают по разным причинам. Выяснение причины может увеличить качество работы. Или вопрос качества тут не интересен?
всё вроде бы здорово, не пойму как членов команды премировать или наказывать. Как отслеживать работу отдельного члена команды. Мне кажется, что метод будет работать только для тех кому интересно и кто сам себя приучил.
Мои поздравления. Вам удалось собрать команду.
LOL, хотите чтобы люди и коллективы были как Crome, как программы, будете их запускать, останавливать, подвешивать в отладчике
Это, батенька, профдеформация
Это, батенька, профдеформация
были как Crome, как программы, будете их запускать, останавливать, подвешивать в отладчике
нет, люди — это люди. Объяснение в таких терминах, из моей практики, понятнее программистам. Менеджерам по-другому понятнее, чернокнижникам — в терминах цикла Деминга, и т.д.
Это просто форма подачи одной и той же информации.
но тогда это ничего не значит
Я просто расскажу вам, как это делали мы.
Извиняюсь за назойливость, но опять повторю свой вопрос — на командах какого размера, каких проектах и за какое время было достигнуто 4x?
Команда должна стать средой исполнения – гибкой, адаптивной, не возражающей.
Я бы сказал, что это несколько противоречит «самоорганизующейся команде» и «доверительным отношениям» из Agile. Я правильно понимаю, что залог успеха — всесилие скрам-мастера?
Раньше была добротная статья про измерения, есть критерии успеха для этого базового принципа?
Если я начну отвечать на все вопросы, то придется написать в комментариях все планируемые публикации. Потому что простые ответы вас не удовлетворят, нужны объяснения.
Я обязательно все расскажу.
А полезные вопросы, вроде ваших, буду учитывать в процессе изложения.
Прошу понять меня правильно.
У меня 3 вопроса, признаю, что 2 последних могут быть отражены в последующих статьях. А что с первым про контекст организации?
Вот придет СберТеч с командой в 6 тыс. человек. Им тоже будет 4x?
Вот придет СберТеч с командой в 6 тыс. человек. Им тоже будет 4x?
У нас была команда 5 человек. Скрам рекомендует до 9 человек, насколько я помню.
Если придет сбер с 6 тыс.человек, то они поделятся на небольшие команды, и получат суммарное ускорение БОЛЬШЕ, чем в 4 раза, по сравнению с тем, что есть у них сейчас. Потенциал ускорения взаимодействующих команд в разы выше, чем одной команды, и тем более одного человека.
Опять забегаю вперед, но значительная, а порой невероятная доля потерь находится на границах команд, отделов, организаций и т.д. И это крайне малоизученная область. Чтобы убедиться, попробуйте найти полезную информацию по теме boundary management.
Наберитесь терпения, дружище.
Без обид, но именно про такие расспросы написано в начале статьи: «Просто нас задолбали с вопросами по почте и на конференциях, поэтому решили рассказать централизованно, в самом подходящем для этого месте — Хабре».
Это не про то, что мы чего-то там про себя думаем. Мы — программисты, и не любим делать одну работу много раз.
Если придет сбер с 6 тыс.человек, то они поделятся на небольшие команды, и получат суммарное ускорение БОЛЬШЕ, чем в 4 раза, по сравнению с тем, что есть у них сейчас. Потенциал ускорения взаимодействующих команд в разы выше, чем одной команды, и тем более одного человека.
Опять забегаю вперед, но значительная, а порой невероятная доля потерь находится на границах команд, отделов, организаций и т.д. И это крайне малоизученная область. Чтобы убедиться, попробуйте найти полезную информацию по теме boundary management.
Наберитесь терпения, дружище.
Без обид, но именно про такие расспросы написано в начале статьи: «Просто нас задолбали с вопросами по почте и на конференциях, поэтому решили рассказать централизованно, в самом подходящем для этого месте — Хабре».
Это не про то, что мы чего-то там про себя думаем. Мы — программисты, и не любим делать одну работу много раз.
Спасибо!
Не сочтите за придирки, но до 9-ти человек — это все-таки рекомендуемый размер скрам-команд, а не скрама вообще. При больших командах уже требуются какие-то методики масштабирования скрама (тот же nexus, хоть я его и не люблю), но это офф-топик.
По поводу мало-изученности agile/scrum для больших команд не соглашусь, есть же целое направление agile for enterprise со своей спецификой, но это опять же офф-топик.
Запасусь терпением и буду ждать дальнейших статей :-)
Не сочтите за придирки, но до 9-ти человек — это все-таки рекомендуемый размер скрам-команд, а не скрама вообще. При больших командах уже требуются какие-то методики масштабирования скрама (тот же nexus, хоть я его и не люблю), но это офф-топик.
По поводу мало-изученности agile/scrum для больших команд не соглашусь, есть же целое направление agile for enterprise со своей спецификой, но это опять же офф-топик.
Запасусь терпением и буду ждать дальнейших статей :-)
Отладчик хрома ведь не возражает против кода, который вы в нем дебажите? А представьте, если бы возражал?
Написали вы кусок, запустили, увидели ошибку, исправили в исходнике, запустили снова, а хром вам говорит – "эээ, неее, мы так не договаривались"
Отладчик Хрома написан и работает в соотвествии со строгими правилами. Как минимум спецификация JavaScript и спецификация V8. Если вы попробуете выполнить код на C++ или подсунете неверный байт-код, он, представьте себе, так и скажет — "мы так не договаривались".
так и скажет — «мы так не договаривались».
наверное, все-таки, скажет что-то типа «Uncaught SyntaxError: Unexpected identifier» или «Uncaught SyntaxError: Unexpected token :».
Это не «мы так не договаривались», а «я не понимаю, чего ты хочешь от меня». Я в публикации говорил об отказе от исполнения изменений, о сопротивлении.
Да и вообще не важно это, вроде. Вы же поняли, о чем абзац. Пусть и не идеальная аналогия подобрана.
Судя по описанию, у вас получилось тяп-ляп и в продакшн. Быстрая разработка, отсутствие документации, постоянно меняющиеся правила.
Спасибо, это мой любимый вопрос, все программисты его задают.
Постоянно меняющиеся правила — да, об этом и публикация. Постоянно меняющиеся до определенного момента. В этом весь смысл.
Отсутствие документации было и до, и во время, и после. Т.е. тут ничего не менялось.
Быстрая разработка — это вы про экстремальное программирование? Не могу уловить коннотацию.
Постоянно меняющиеся правила — да, об этом и публикация. Постоянно меняющиеся до определенного момента. В этом весь смысл.
Отсутствие документации было и до, и во время, и после. Т.е. тут ничего не менялось.
Быстрая разработка — это вы про экстремальное программирование? Не могу уловить коннотацию.
Это я про резко сократившиеся сроки. Либо у вас раньше было все неоптимально организовано, а сейчас стало нормально как у всех, либо раньше было нормально, а сейчас стало хуже качество, за счет того, что вы убрали часть нужных мероприятий. Причем возможно вы еще не дошли до момента когда появятся последствия, а возможно вам это не грозит потому что у вас приложения маленькие. В любом случае ваш кейс для большинства неприемлем.
Sign up to leave a comment.
#Ускорение4X. Принцип № 0/1. Изменяемая среда