Ситуация следующая, есть бизнес процесс: бизнес аналитики пишут бизнес требования и передают их дизайнерам, которые в свою очередь определяют структуру базы данных и пишут задания программистам, далее программисты реализуют все это и передают тестерам. Далее цикл повторяется.
В принципе это работает, но при этом есть следующие минусы:
— дизайнеры не оставляют свободы программистам, т.к. в их заданиях прописано все вплоть до имен классов, методов, имен локальных переменных и скл запросов, т.е. они пишут логику в ворде на неком самопальном языке похожем на бейсик.
— т.к. система развита то уже никто не может охватить всю архитектуру и провести рефакторинг для, например, улучшения производительности.
— существует несколько вариаций этой системы, которые живут параллельно но при этом делают в принципе одно и тоже, различаются параметрами и фичами. Процесс переноса фичи из одной ветки в другую затягивается на недели для команды. Взять и все слить в одно не получится, по причине выше (надо сказать что без системы бизнес встанет).
Как мне видится, здесь нужно вводить некоторый формальный процесс разработки (от сбора бизнес требований до реализации) с инструментальной поддержкой.
Поделитесь опытом, что вы используете (плюсы минусы)?
Здравствуйте, Driver, Вы писали:
D>Ситуация следующая, есть бизнес процесс: бизнес аналитики пишут бизнес требования и передают их дизайнерам, которые в свою очередь определяют структуру базы данных и пишут задания программистам, далее программисты реализуют все это и передают тестерам. Далее цикл повторяется.
Классический "водопад", в общем.
D>В принципе это работает, но при этом есть следующие минусы: D>- дизайнеры не оставляют свободы программистам, т.к. в их заданиях прописано все вплоть до имен классов, методов, имен локальных переменных и скл запросов, т.е. они пишут логику в ворде на неком самопальном языке похожем на бейсик.
Нормальное разделение ролей. На то они и разработчики архитектуры, чтобы на верхнем уровне думать.
D>- т.к. система развита то уже никто не может охватить всю архитектуру и провести рефакторинг для, например, улучшения производительности.
Архитектура как раз, судя по описанию, хорошо охвачена спецификациями. И как раз провести рефакторинг, при наличии всех спеков, вполне посильная задача — сначала на бумаге, потом в спеках, а потом и в коде. Это значительно проще, чем в случае, когда спеков нет и есть тонны кода — вот тогда реально геморой понять что к чему на верхнем уровне и отрефакторить эффективно.
D>- существует несколько вариаций этой системы, которые живут параллельно но при этом делают в принципе одно и тоже, различаются параметрами и фичами. Процесс переноса фичи из одной ветки в другую затягивается на недели для команды. Взять и все слить в одно не получится, по причине выше (надо сказать что без системы бизнес встанет).
Это уже вопрос управления конфигурациями (SCM) — того, как организовано ветвление всего продукта, его компонентов, развертывание на стороне клиента, сохранение настроек окружения и т.п. Возможно, вам нужен спец из числа архитекторов, который возьмет на себя труд в этом методично разобраться и — как следуюет отрефакторить + наладить правильный SCM (возможно, с привлечением стороннего спеца).
D>Как мне видится, здесь нужно вводить некоторый формальный процесс разработки (от сбора бизнес требований до реализации) с инструментальной поддержкой.
Формализации у вас, судя по описанию, и так через край
Здравствуйте, Driver, Вы писали:
D>ага, причем визио почти не используется, все в ворде включая структуры базы, задания программистам и настроечные данные.
Черт, тогда да, всё запущено. Рекомендация про SCM остается в силе плюс сошлюсь на CASE средства на базе UML — в первую очередь Together, он и реверс-инжиниринг делает, и по диаграмам UML код умеет строить. По крайней мере, лет 5 надаз умел Ещё смотрел Rational Rose, но как с ним сейчас обстоят дела — не знаю.
Здравствуйте, Driver, Вы писали:
D>Ситуация следующая, есть бизнес процесс: бизнес аналитики пишут бизнес требования и передают их дизайнерам, которые в свою очередь определяют структуру базы данных и пишут задания программистам, далее программисты реализуют все это и передают тестерам. Далее цикл повторяется.
D>В принципе это работает, но при этом есть следующие минусы: D>- дизайнеры не оставляют свободы программистам, т.к. в их заданиях прописано все вплоть до имен классов, методов, имен локальных переменных и скл запросов, т.е. они пишут логику в ворде на неком самопальном языке похожем на бейсик.
Никто не заставляет вас поступать именно так.
Пересмотрите уровень детализации, который вы ожидаете от дизайнеров.
D>- т.к. система развита то уже никто не может охватить всю архитектуру и провести рефакторинг для, например, улучшения производительности.
Вы пробовали?
D>- существует несколько вариаций этой системы, которые живут параллельно но при этом делают в принципе одно и тоже, различаются параметрами и фичами. Процесс переноса фичи из одной ветки в другую затягивается на недели для команды. Взять и все слить в одно не получится, по причине выше (надо сказать что без системы бизнес встанет).
Опять же, вы пробовали?
D>Как мне видится, здесь нужно вводить некоторый формальный процесс разработки (от сбора бизнес требований до реализации) с инструментальной поддержкой.
D>Поделитесь опытом, что вы используете (плюсы минусы)?
Не думаю, что процессы и тулы вам сильно помогут.
SCM у вас похоже не очень. Его можно поправить.
Но дополнительные формализации вам скорей всего не помогут.
Предположу что основная проблема у вас в том, что у вас настолько все заформализовано,
что люди, которые способны решить ваши проблемы,
просто не хотят у вас работать. Эту проблему никакой тул вам не решит.
Здравствуйте, Aquary, Вы писали:
A>Черт, тогда да, всё запущено. Рекомендация про SCM остается в силе плюс сошлюсь на CASE средства на базе UML — в первую очередь Together, он и реверс-инжиниринг делает, и по диаграмам UML код умеет строить. По крайней мере, лет 5 надаз умел Ещё смотрел Rational Rose, но как с ним сейчас обстоят дела — не знаю.
Не сильно поможет это.
Ну сгенерят они сотни диаграмм с миллионом никому не нужных деталей.
А дальше что?
Диаграммы конечно же нужны, но только те, которые рисует человек,
имея четкое представление, что конкретно он хочет показать.
... B>Никто не заставляет вас поступать именно так. B>Пересмотрите уровень детализации, который вы ожидаете от дизайнеров.
проблема в том что процесс так налажен. Собственно я и спрашиваю здесь про технику которая, в частности, оставляет большую свободу программистам, но при этом последним не придется общаться с бизнес аналитиками. Если у вас этот процесс налажен, не могли бы вы поделитеся деталями.
... B>Вы пробовали?
нет, хотя в принципе это возможно, но здесь я преследую цель улучшения процесса.
... B>Опять же, вы пробовали?
да
... B>Не думаю, что процессы и тулы вам сильно помогут. B>SCM у вас похоже не очень. Его можно поправить. B>Но дополнительные формализации вам скорей всего не помогут.
B>Предположу что основная проблема у вас в том, что у вас настолько все заформализовано, B>что люди, которые способны решить ваши проблемы, B>просто не хотят у вас работать. Эту проблему никакой тул вам не решит.
насчет SCM согласен, что касается остального — да заформализовано, но зато работает, вопрос как улучшить этот процесс?
Здравствуйте, Driver, Вы писали:
D>насчет SCM согласен, что касается остального — да заформализовано, но зато работает, вопрос как улучшить этот процесс?
Ну например, найти человека, который вам поможет
Или ты в самом деле надеешься, что кто-то по сообщениям в форуме сможет
понять суть вашей проблемы и в двух словах описать решение?
Всем привет!
D>Ситуация следующая, есть бизнес процесс: бизнес аналитики пишут бизнес требования и передают их дизайнерам, которые в свою очередь определяют структуру базы данных и пишут задания программистам, далее программисты реализуют все это и передают тестерам. Далее цикл повторяется.
D>В принципе это работает, но при этом есть следующие минусы: D>- дизайнеры не оставляют свободы программистам, т.к. в их заданиях прописано все вплоть до имен классов, методов, имен локальных переменных и скл запросов, т.е. они пишут логику в ворде на неком самопальном языке похожем на бейсик.
Включите шаг на утверждение/согласование дизайна с разработчиками на реализуемость и оптимальность.
D>- т.к. система развита то уже никто не может охватить всю архитектуру и провести рефакторинг для, например, улучшения производительности.
Тут скорее всего кропотливая работа по восстановлению требований, архитектуры....
D>- существует несколько вариаций этой системы, которые живут параллельно но при этом делают в принципе одно и тоже, различаются параметрами и фичами. Процесс переноса фичи из одной ветки в другую затягивается на недели для команды. Взять и все слить в одно не получится, по причине выше (надо сказать что без системы бизнес встанет).
Попробовать оптимизировать сорс контрол, связать изменения кода с задачами и требованиями.
D>Как мне видится, здесь нужно вводить некоторый формальный процесс разработки (от сбора бизнес требований до реализации) с инструментальной поддержкой.
D>Поделитесь опытом, что вы используете (плюсы минусы)?
На сегодняшний день их много, желательно конечно комплексное и сильно интегрированное решение: IBM Rational Jazz, IBM Rational, Microsoft TFS
... B>Ну например, найти человека, который вам поможет
таких и искать поди днем с огнем
B>Или ты в самом деле надеешься, что кто-то по сообщениям в форуме сможет B>понять суть вашей проблемы и в двух словах описать решение?
Здравствуйте, Driver, Вы писали:
D>Здравствуйте, bkat, Вы писали:
D>... B>>Ну например, найти человека, который вам поможет
D>таких и искать поди днем с огнем
Да, не просто.
B>>Или ты в самом деле надеешься, что кто-то по сообщениям в форуме сможет B>>понять суть вашей проблемы и в двух словах описать решение?
D>Это было бы здорово
Быстрые и понятные серебрянные пули — это Agile и прочие SCRUM'ы
В жизни увы все сложнее и успех не гарантирован
