Так все-таки, для ускорения первична команда или скрам-мастер?
Допустим, цель ускориться (как и любую другую) ставит «бизнес», он ее озвучивает команде или скрам-мастеру?
Почему во главу процесса поставлен скрам-мастер, а не продакт-овнер, например? Ведь ускорение разработки — это долговременная цель. А за стратегическое развитие продукта или сервиса отвечает именно продакт-овнер. Откуда у скрам-мастера берется понимание, что сейчас удачный момент (с точки зрения «бизнеса») для экспериментов с процессами, которые могут сказаться негативно?
BTW
По поводу прожект-менеджеров и ресурсов — модель уж очень упрощенная, по крайней мере в сферах с интеллектуальной деятельностью. Но не вижу смысла вдаваться в дискуссию.
А как все-таки формулируется второй принцип?
Ускорением должен заниматься скрам-мастер?
Если цель ставится не команде, а скрам-мастеру, чем он отличается от прожект-менеджера?
Т.е. если в данной статье заменить скрам-мастер на прожект-менеджер, какие утверждения станут неверными?
Спасибо!
Не сочтите за придирки, но до 9-ти человек — это все-таки рекомендуемый размер скрам-команд, а не скрама вообще. При больших командах уже требуются какие-то методики масштабирования скрама (тот же nexus, хоть я его и не люблю), но это офф-топик.
По поводу мало-изученности agile/scrum для больших команд не соглашусь, есть же целое направление agile for enterprise со своей спецификой, но это опять же офф-топик.
Запасусь терпением и буду ждать дальнейших статей :-)
У меня 3 вопроса, признаю, что 2 последних могут быть отражены в последующих статьях. А что с первым про контекст организации?
Вот придет СберТеч с командой в 6 тыс. человек. Им тоже будет 4x?
Извиняюсь за назойливость, но опять повторю свой вопрос — на командах какого размера, каких проектах и за какое время было достигнуто 4x?
Команда должна стать средой исполнения – гибкой, адаптивной, не возражающей.
Я бы сказал, что это несколько противоречит «самоорганизующейся команде» и «доверительным отношениям» из Agile. Я правильно понимаю, что залог успеха — всесилие скрам-мастера?
Раньше была добротная статья про измерения, есть критерии успеха для этого базового принципа?
А можно подробнее, как именно эти 4x были получены? Это сокращение time to market или увеличение velocity команды? Если последнее, то насколько это объективно? Может просто гиперинфляция store points?
Спасибо!
С точки зрения хранения, git все равно, файл текстовый или нет. Я так понимаю, что вопрос про компактное хранение изменений в картинках? Я бы сказал, что для этого в первую очередь нужны тулзы, а не scm. Например, никто не мешает складывать в репозиторий транзакционные логи для базы данных. И потом ресторить актуальное состояние.
Можно посмотреть в сторону файловых систем с де-дубликацией для эффективного хранения повторяющихся блоков данных (если они есть).
Стесняюсь спросить, а чем новых сотрудников не устраивают существующие учебники по git? Например, на git-scm (не сочтите за рекламу) есть версия на русском языке, доходчиво, с картинками.
Почему-то этот момент упущен в мотивировочной части.
У файла есть не только содержимое, но и атрибуты (мета-данные), которые могут наследоваться от папок, файловых систем, протоколов доступа и носителей.
Например, read-only доступ к файлу на CD.
Вопрос как раз и возник потому, что в статье не встретил упоминания канонизации (url) и поиска дубликатов. Если уникальных страниц все-равно получается много больше, чем в google или yandex, я бы попытался понять причину.
google индексирует «примерно 1 330 000» страниц на habrahabr.ru, yandex готов выдать «932 тыс. результатов», т.е. в 4-6 раз меньше, чем выкачано страниц краулером из статьи. Есть какое-то объяснение этому факту? Может было достаточно вытащить ~170 GB?
Критиковать всегда проще, но я не очень понимаю, зачем для объяснения ООП пытаться брать примеры из физического мира? Почему бы не взять документ (электронный) или файл, например? По-моему, гораздо ближе к идеологии ООП.
Допустим, цель ускориться (как и любую другую) ставит «бизнес», он ее озвучивает команде или скрам-мастеру?
Почему во главу процесса поставлен скрам-мастер, а не продакт-овнер, например? Ведь ускорение разработки — это долговременная цель. А за стратегическое развитие продукта или сервиса отвечает именно продакт-овнер. Откуда у скрам-мастера берется понимание, что сейчас удачный момент (с точки зрения «бизнеса») для экспериментов с процессами, которые могут сказаться негативно?
BTW
По поводу прожект-менеджеров и ресурсов — модель уж очень упрощенная, по крайней мере в сферах с интеллектуальной деятельностью. Но не вижу смысла вдаваться в дискуссию.
Ускорением должен заниматься скрам-мастер?
Если цель ставится не команде, а скрам-мастеру, чем он отличается от прожект-менеджера?
Т.е. если в данной статье заменить скрам-мастер на прожект-менеджер, какие утверждения станут неверными?
Не сочтите за придирки, но до 9-ти человек — это все-таки рекомендуемый размер скрам-команд, а не скрама вообще. При больших командах уже требуются какие-то методики масштабирования скрама (тот же nexus, хоть я его и не люблю), но это офф-топик.
По поводу мало-изученности agile/scrum для больших команд не соглашусь, есть же целое направление agile for enterprise со своей спецификой, но это опять же офф-топик.
Запасусь терпением и буду ждать дальнейших статей :-)
Вот придет СберТеч с командой в 6 тыс. человек. Им тоже будет 4x?
Извиняюсь за назойливость, но опять повторю свой вопрос — на командах какого размера, каких проектах и за какое время было достигнуто 4x?
Я бы сказал, что это несколько противоречит «самоорганизующейся команде» и «доверительным отношениям» из Agile. Я правильно понимаю, что залог успеха — всесилие скрам-мастера?
Раньше была добротная статья про измерения, есть критерии успеха для этого базового принципа?
Выдающийся результат! На Agile конференциях больше полутора редко заявляют.
За какое время достигается? На команде какого размера? Например, во втором проекте:
фактически один контрибьютер (если отбросить 5 коммитов из 1170).
Индивидуальный скрам?
Спасибо!
Можно посмотреть в сторону файловых систем с де-дубликацией для эффективного хранения повторяющихся блоков данных (если они есть).
Почему-то этот момент упущен в мотивировочной части.
Например, read-only доступ к файлу на CD.