Спасибо!
Не сочтите за придирки, но до 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?
Критиковать всегда проще, но я не очень понимаю, зачем для объяснения ООП пытаться брать примеры из физического мира? Почему бы не взять документ (электронный) или файл, например? По-моему, гораздо ближе к идеологии ООП.
Не сочтите за придирки, но до 9-ти человек — это все-таки рекомендуемый размер скрам-команд, а не скрама вообще. При больших командах уже требуются какие-то методики масштабирования скрама (тот же nexus, хоть я его и не люблю), но это офф-топик.
По поводу мало-изученности agile/scrum для больших команд не соглашусь, есть же целое направление agile for enterprise со своей спецификой, но это опять же офф-топик.
Запасусь терпением и буду ждать дальнейших статей :-)
Вот придет СберТеч с командой в 6 тыс. человек. Им тоже будет 4x?
Извиняюсь за назойливость, но опять повторю свой вопрос — на командах какого размера, каких проектах и за какое время было достигнуто 4x?
Я бы сказал, что это несколько противоречит «самоорганизующейся команде» и «доверительным отношениям» из Agile. Я правильно понимаю, что залог успеха — всесилие скрам-мастера?
Раньше была добротная статья про измерения, есть критерии успеха для этого базового принципа?
Выдающийся результат! На Agile конференциях больше полутора редко заявляют.
За какое время достигается? На команде какого размера? Например, во втором проекте:
фактически один контрибьютер (если отбросить 5 коммитов из 1170).
Индивидуальный скрам?
Спасибо!
Можно посмотреть в сторону файловых систем с де-дубликацией для эффективного хранения повторяющихся блоков данных (если они есть).
Почему-то этот момент упущен в мотивировочной части.
Например, read-only доступ к файлу на CD.