Длины Sprint - 2-недельный по сравнению с 30 [закрытыми] днями
Возможно, попробуйте изменить один столбец за раз:
for i in main_data:
min_val = df[i].min()
max_val = df[i].max()
if 'C' in i:
#Applying normalization for C between [-40,+150]
new_value = normalize(df[i].values, min_val, max_val, -40, 150)
else:
#Applying normalization for A , B between [-1,+1]
new_value = normalize(df[i].values, min_val, max_val, -1, 1)
df_norm[i] = new_value
# df_norm = pd.df(new_value)
7 ответов
Я работал над командами, делающими 1, 2 и 4-недельные спринты. Это действительно зависит от Вашей организации. Я предпочитаю 1 или 2-недельные спринты. Текущая команда, которую я выполняю, в 4-недельных спринтах, потому что мы координируем усилия 12 различных продуктов. Я надеюсь перемещать их в 2-недельные повторения скоро.
Ключевая вещь к определению длины добирается до "сделанного, сделанного". Для некоторых команд это означает в производстве. Для других это может означать проверенный бизнесом удовлетворять их потребности с помощью внутреннего выпуска. Я запустил бы путем определения сделанный, сделанный, затем взгляда на то, как структурировать спринты вокруг этого. Идеально все истории добираются до сделанного в конце спринта - и Вы только делаете Scrummerfall.
Мне нравятся две недели. Это вызывает поле разумного срока на проблемах, все же позволяет Вам видеть результаты в темпе укрепления. 30 дней навсегда. Одна неделя могла легко быть правильным ритмом для быстро двигающегося продукта как веб-сайт.
У владельца продукта должна всегда быть возможность изменить prioritations и направления. Одна из целей с ТОЛПОЙ состоит в том, чтобы охватить изменения и позволить владельцу продукта быть ответственным за приоритет путем рассмотрения бизнес-потребностей и команды разработки, ответственной за доставку вовремя.
Таким образом, даже если у Вас есть 3-недельный спринт, не делает meen, что владелец продукта должен ожидать 3 недели, если он узнает что-то, что (возможно) собирается повредить спринт.
В некоторых редких случаях необходимо остановить спринт в середине и создать новое из-за новой информации или нового prioritations.
Я думал спринты приблизительно 1 недели, но это походит на Толпу Микро управление.
Да, но это заставит Вас делать больше Толпы: Вы будете делать планирование спринта, итеративную демонстрацию и ретроспективу каждую неделю. Оборотная сторона является издержками, однако, Вы проводите меньше времени, планируя, демонстрируя и "restrospecting" одно недельное повторение, чем повторение один месяц длиной.
Чем короче повторение, тем быстрее команда изучает процесс.
Теперь, в зависимости от вида проекта, это могло бы трудно, чтобы смочь достигнуть чего-то ценного в одной недельной задержке.
Прежде чем я забыл, я не делаю повторения трех недель: o)
Если Вы идете с повторениями четырех недель, у Вас также есть возможность заменить задачи, которые не были запущены с задач, оцененных для того же количества времени.
2 недели (10 стандартных рабочих дней, если Вы - комплект оборудования M-F или 12, если Вы - комплект оборудования M-S) являются половиной месяца (месяц обычно имеет примерно 20 рабочих дней в нем, плюс-минус). Кроме того, неделя более неопределенна, чем день, но менее неопределенна, чем месяц, таким образом, она делает единицу измерения в течение многих недель лучше для более гибкого (больше дает/берет), проекты разработки.
Однако в прошлый раз, когда я сделал что-либо как толпа, это было на школьном проекте, и это не была действительно толпа. Таким образом, это были 7-дневные недели в 10-недельной четверти. Мне действительно понравился 2-недельный блок за ту ситуацию. Я чувствовал, что мог стать много сделанным, но мы могли часто корректировать временные шкалы и планы.
Прямо сейчас мы делаем 30-дневные спринты и получаем выполненные груды. Одна причина, что 30-дневные спринты работают хорошо на нас, состоит в том, что наше планирование и оценка обычно занимают 2 дня (сбор и решение который высокоуровневые задачи взять от отставания, беря высокоуровневые задачи и анализируя их, помещая оценки на анализируемые задачи, и затем присваивая им). Мы также откладываем 2-3 дня для устранения ошибки и тестирования.
Мы уже в 5 дней там, так выполнение 2-недельных спринтов только оставило бы нас с 5 днями R&D. 30 дней были большим балансом для нас до сих пор.
Длины Sprint могут варьироваться от проекта до проекта, но должны остаться постоянными в течение того же проекта. Лучшая вещь сделать пытается найти самую удобную длину спринта для Вашей команды, я использовал Толпу в течение двух лет, и теперь мы согласились на спринты двадцати рабочих дней.
Мой опыт говорит мне, что в проектах, для которых нужны быстрые результаты и относительно простое программирование (операции CRUD, простые сетки и формы, и т.д.) более мудро пойти для более коротких спринтов, как две недели. Для вещей с более высокой сложностью (как платформы), вероятно, вероятно, лучше пойти для более длинных спринтов, таких как спринты четырех недель. Мой текущий проект склоняется к последней опции.
Но важное выбирает длину, удобную и для команды и для владельца продукта.