Comments 12
Первым и обязательным шагом любой попытки применения автоматизации должна являться формализация процесса, который хотите автоматизировать.
Без этого шага начинается лирика и беллетристка на основе софтскилл. И классические душевные метания "что делать?" и "кто виноват?"
Да, пожалуй, самая распространённая проблема из всех, это попытка автоматизации хаоса.
Если к Аджайлу добавить Формализацию процессов, то это уже ГОСТ какой-то получается)))
ГОСТ Р 56715.2-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 2. Процессы и процессная модель
ГОСТ Р 56716-2015 Проектный менеджмент. Техника сетевого планирования. Общие положения и терминология
ГОСТ Р 56715.5-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 5. Термины и определения
ГОСТ Р 56715.4-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 4. Данные и модель данных
ГОСТ Р 56715.3-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 3. Методы
ГОСТ Р 56715.2-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 2. Процессы и процессная модель
ГОСТ Р 56715.1-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 1. Основные положения
ГОСТ Р МЭК 62198-2015 Проектный менеджмент. Руководство по применению менеджмента риска при проектировании
ГОСТ Р МЭК 61160-2015 Проектный менеджмент. Документальный анализ проекта
ГОСТ Р ИСО MEK_TO_16326-2002 РУКОВОДСТВО ПО ПРИМЕНЕНИЮ ГОСТ Р ИСОМЭК 12207 ПРИ УПРАВЛЕНИИ ПРОЕКТОМ
ГОСТ Р ИСО 21500-2014 "Руководство по проектному менеджменту";
ГОСТ Р 54869-2011 "Проектный менеджмент. Требования к управлению проектом";
ГОСТ Р 54871-2011 "Проектный менеджмент. Требования к управлению программой";
ГОСТ Р 54870-2011 "Проектный менеджмент. Требования к управлению портфелем проектов".
Можно конечно и формализм довести до абсурда, но без формализма ничего не получится.
Предметная область должна быть изложена формально именно теми, кто в ней понимает. Иначе этот формализм проведут программисты в силу своих религий и тогда
"Беда, коль пироги начнет печи сапожник, а сапоги тачать пирожник"
Если аджайл вот так прям приглянулся, то всё равно - формализацию должен регулярно корректировать понимающий и без этого будет бардак.
да, уж не ожидал от Ланита столько воды, как будто статью из студопедии прочитал
И главное - разработчик должен иметь профильное образование, что бы понимать нюансы отрасли, коих огромное количество. Заказчик не сможет все описать в ТЗ/БТ.
Это скорее задача аналитика раскопать все нюансы отрасли и задать заказчику правильные наводящие вопросы. А после того, как он в этом разберется, написать ТЗ разработчику так, чтобы разработчик мог выполнить задачу не имея профильного образования в отрасли. Всё-таки сфера ответственности разработчика это код, ему не обязательно знать бизнесовые нюансы отрасли.
Другой вопрос, конечно, когда проект маленький, и разработчик на проекте и чтец и жнец и на дуде игрец, но тут уже вопрос из другой плоскости.
О, да! Все это нужно рассказать внедрятелям САПа. Наверно много нового узнают.
Кроличья нора автоматизации бизнес-процессов