Scrum это всего лишь инструмент. Как, скажем, молоток он не может быть плохим или хорошим. Вопрос уместно ли его применяют. И скрам при желании можно применять так, что он будет противоречить agile манифесту.
В качестве эксперимента я довольно продолжительное время старался избегать scrum в управлении проектами и искал его изъяны. Но всегда в моем профессиональном окружении было больше тех, кто доказывал его пользу. За неимением лучшего варианта пока придерживаюсь гибрида, часто включающего скрам (доску и церемонии). Разница только в балансировке между waterfall и agile.
Из моих наблюдений хейт в сторону agile происходит в 3 случаях:
Философию применяет не тот человек (не понимающий/не разделяющий принципы "молотка").
Философию применяют не так (либо частично, либо вообще всё - так называемый карго-культ). Причина вытекает из 1.
Философию применяют не там (например, в классическом капитальном строительстве - в той части процессов, где все понятно и последовательно и % неопределенности стремится к нулю). Результат все равно будет, но доля хаоса сместит сроки и бюджет вправо.
Есть и другие способы управления совершенно не относящиеся к agile или скрам, и благодаря им можно также добиться результатов. Во всем есть свои плюсы и минусы. Это лишь вопрос выбора.
Сопровождение на уровне - Восстановить, если источники данных отвалятся. За два года не отвалились.
Была идея считать расход через пробег по GPS, но сразу отказались. Он правильно считается при выполнении нормативов. По факту же внешних факторов уйма: температура воздуха, перегруз/недогруз, техсостояние ТС и далее по списку.
Несколько раз GPS программно отправлял ТС в Австралию. Почему - непонятно. Но средняя скорость у БелАЗа вырастала до 400 км/ч.
Ненадёжно. Поэтому данные забирали именно с ДУТ.
Смартфоны для GPS тоже нормальная история. Но их не было и это были бы разовые затраты. Тут было бы больше проблем с их обслуживанием, когда они начали бы ломаться. Это уже проходили. Конкретно в этом кейсе надежнее встроенные системы.
Наверное, хороший анекдот. Но в этом кейсе неприменим. В решении использовалось то, что уже было. С точки зрения экономики - затраты уже учтены в другой задаче несколько лет назад, повторно их учитывать некорректно. Но если взять за базу некую условную ситуацию, что ДУТ и GPS не было бы, то мы бы их купили и установили. И даже на 200 ТС в условиях такого крупного предприятия это в рамках погрешности месяца.
Поэтому да, бюджет 0, и семечками торговать не пришлось. Особенности учёта больших компаний.
В предпоследнем абзаце стоимость указана. Если погуглить - от 20 тыс. за ТС. В компании из кейса платили больше, т.к. ставили несколько лет назад, под другие задачи, и предложений на рынке было меньше. Это за ТМЦ, работы, настройку и сопровождение. Хранение на стороне облачного решения. Им платили разово, немного, и опять же под другие задачи.
Больше всего - лин-менеджер. Плюс эксперты и разработчик 1с. Если выделить время чисто под задачу - часов 100 суммарно. С учётом того, что задача в третьем приоритете, делалась несколько месяцев без отвлечения от основных, поэтому считать затраты на ЗП некорректно.
Связь с 1с уже была. Тащили пробеги с GPS. Остальные 99% информации вежливо игнорировали.
Дополнительных затрат, которые хоть как-то бы отразились на capex и opex, не было. С учётом размера компании и приоритета задачи, все было реализовано в пределах итак заложенных переменных затрат.
Scrum это всего лишь инструмент. Как, скажем, молоток он не может быть плохим или хорошим. Вопрос уместно ли его применяют. И скрам при желании можно применять так, что он будет противоречить agile манифесту.
В качестве эксперимента я довольно продолжительное время старался избегать scrum в управлении проектами и искал его изъяны. Но всегда в моем профессиональном окружении было больше тех, кто доказывал его пользу. За неимением лучшего варианта пока придерживаюсь гибрида, часто включающего скрам (доску и церемонии). Разница только в балансировке между waterfall и agile.
Из моих наблюдений хейт в сторону agile происходит в 3 случаях:
Философию применяет не тот человек (не понимающий/не разделяющий принципы "молотка").
Философию применяют не так (либо частично, либо вообще всё - так называемый карго-культ). Причина вытекает из 1.
Философию применяют не там (например, в классическом капитальном строительстве - в той части процессов, где все понятно и последовательно и % неопределенности стремится к нулю). Результат все равно будет, но доля хаоса сместит сроки и бюджет вправо.
Есть и другие способы управления совершенно не относящиеся к agile или скрам, и благодаря им можно также добиться результатов. Во всем есть свои плюсы и минусы. Это лишь вопрос выбора.
Планировалась серия кейсов по авто и ж/д логистике в условиях крупных промышленных предприятий.
С курьерами не работал, но отдельно пофилософствовать можно. Решений много и некоторые хорошо адаптируются.
Сопровождение на уровне - Восстановить, если источники данных отвалятся. За два года не отвалились.
Была идея считать расход через пробег по GPS, но сразу отказались. Он правильно считается при выполнении нормативов. По факту же внешних факторов уйма: температура воздуха, перегруз/недогруз, техсостояние ТС и далее по списку.
Несколько раз GPS программно отправлял ТС в Австралию. Почему - непонятно. Но средняя скорость у БелАЗа вырастала до 400 км/ч.
Ненадёжно. Поэтому данные забирали именно с ДУТ.
Смартфоны для GPS тоже нормальная история. Но их не было и это были бы разовые затраты. Тут было бы больше проблем с их обслуживанием, когда они начали бы ломаться. Это уже проходили. Конкретно в этом кейсе надежнее встроенные системы.
Наверное, хороший анекдот. Но в этом кейсе неприменим. В решении использовалось то, что уже было. С точки зрения экономики - затраты уже учтены в другой задаче несколько лет назад, повторно их учитывать некорректно. Но если взять за базу некую условную ситуацию, что ДУТ и GPS не было бы, то мы бы их купили и установили. И даже на 200 ТС в условиях такого крупного предприятия это в рамках погрешности месяца.
Поэтому да, бюджет 0, и семечками торговать не пришлось. Особенности учёта больших компаний.
В предпоследнем абзаце стоимость указана. Если погуглить - от 20 тыс. за ТС. В компании из кейса платили больше, т.к. ставили несколько лет назад, под другие задачи, и предложений на рынке было меньше. Это за ТМЦ, работы, настройку и сопровождение. Хранение на стороне облачного решения. Им платили разово, немного, и опять же под другие задачи.
Больше всего - лин-менеджер. Плюс эксперты и разработчик 1с. Если выделить время чисто под задачу - часов 100 суммарно. С учётом того, что задача в третьем приоритете, делалась несколько месяцев без отвлечения от основных, поэтому считать затраты на ЗП некорректно.
Связь с 1с уже была. Тащили пробеги с GPS. Остальные 99% информации вежливо игнорировали.
Дополнительных затрат, которые хоть как-то бы отразились на capex и opex, не было. С учётом размера компании и приоритета задачи, все было реализовано в пределах итак заложенных переменных затрат.
Расскажите, как выстроен Agile у вас?