Все же это должно было случиться и вот на сферу промышленной автоматизации пытаются натянуть гибкие методологии. Тут немного моих размышлений, основываясь на статье
И тут вроде все хорошо. Действительно итерационный подход весьма удобная вещь, которая позволяет очень гибко изменять проект, то того как он максимально закостенел.
В статье нам представляют фреймворк scrum.
Scrum — минимально необходимый набор мероприятий, артефактов, ролей, на которых строится процесс Scrum -разработки, позволяющий за фиксированные небольшие промежутки времени, называемые спринтами, предоставлять конечному пользователю работающий продукт с новыми бизнес-возможностями, для которых определён наибольший приоритет.
Считается, что он способен повысить качество и производство, а также помочь в развитии новых “талантов”
Для интеграторов, которые хорошо справляются с agile, клиенты получают выгоду от более быстрой доставки с меньшими общими затратами. Также повышается вероятность того, что клиенты получат то, что им больше всего нужно, даже если это не было точно указано на этапе расчета стоимости проекта. Agile обеспечивает гораздо более совместную среду.Agile не выплавляет железный треугольник фиксированной стоимости, объема и графика, но дает интеграторам и клиентам гибкость для осознанного компромисса. В проектах с фиксированной ценой и фиксированным графиком новые и лучшие идеи могут легко заменить менее ценный объем.
Какие проблемы в наших широтах существуют? Однозначно у нас очень не любят итерационные подходы, а именно их непонимание. Да, документация и проекты могут выдаваться по частям.
Сила графиков. Понятно, что сроки проекта очень важная часть в нашем ремесле, но святая приверженность графику очень удручает. Сложно спрогнозировать точные сроки, когда нет точных объемов работа. Качественное ТЗ, которое бы не изменялось ни разу за время реализации проектов - единорог. Я пока такое еще не встречал.
Большие проблемы в асинхронной коммуникации. Не знаю почему, но последние пол года мне показали, что у нас не хотят писать письма и все документировать. Да это немного долгий процесс - расписать все изменения и корректировки, избегая двойной трактовки, но стоит учиться это делать. Так как это уменьшает проблемы в дальнейшем.
Сложности в установке приоритетов. Самое распространенное что я слышал при постановке задач, когда просишь расставить приоритеты и сроки: “Все срочно и еще вчера”, а когда перед тобой лежит много задач с такой формулировкой, то очень много времени тратиться на их приоритезацию.
Гибкие методологии весьма удобны, если их правильно адаптировать под ваши задачи, но это тоже занимает время и стоит каких-то денег.
Возможно у вас есть опыт подобного внедрения в свою рабочую среду, если не сложно, то поделитесь им.
"Темы" для разговора об АСУТП в Телеграм: https://t.me/wtfplc_topics
