Комментарии 9
В компании Haulmont используется Agile или классический waterfall? Если и то и то, в каких пропорциях и на каких проектах?
staskin1, правильным ответом будет «и то и то».
И agile, и waterfall — это концепции, реализация которых может сильно отличаться на практике. Если говорить упрощенно, для небольших проектов — например простое внедрение ТЕЗИС — мы используем waterfall модель. Требования понятны, можно легко написать спецификацию и рассчитать конечную цену внедрения. Очевидно, что это максимально комфортный вариант для заказчика. Необходимость изменений в таком случае обычно невелика, и формальный процесс управления ими (change requests) не слишком трудоемок.
Для крупных проектов — в основном это сложное корпоративное ПО, или масштабные внедрения продуктов ТЕЗИС или Sherlock — такой подход уже плохо работает. В большинстве случаев (скажу больше — во всех) на начальном этапе заказчик может сформировать лишь высокоуровневые требования к решению. Понимание деталей приходит по мере развития проекта, когда становятся понятными возможности системы и то, как они используются на практике. В таких проектах мы используем agile методологию. Детальное планирование и анализ требований осуществляются лишь на короткий горизонт ближайшей итерации — спринта (в нашей практике 1-2 месяца). Параллельно с разработкой ведется планирование следующего и т.д. Это дает гибкость в управлении изменениями и позволяет минимизировать ненужную работу. Например, детальное планирование всего проекта, когда мы наверняка знаем, что большая часть требований изменится. Или формальную реализацию функциональности по спецификации (она ведь подписана!), когда уже очевидно несоответствие спецификации реальным потребностям. В итоге мы экономим время и деньги заказчика.
С другой стороны, мы не можем применять «экстремальные» варианты agile процессов, в которых долгосрочное планирование отсутствует в принципе (хотя я думаю они хорошо подходят например для разработки компактных, но массовых продуктов на рынке b2c). И заказчик, и мы должны понимать конечную цель проекта, его архитектуру, основные принципы работы и взаимодействия компонентов. Поэтому обычно мы создаем roadmap, а также функциональную спецификацию на весь проект, покрывающую основные требования без деталей реализации. Это дает нам возможность примерно оценить общие сроки и бюджет проекта (с некоторой вилкой), и таким образом управлять ожиданиями заказчика.
И agile, и waterfall — это концепции, реализация которых может сильно отличаться на практике. Если говорить упрощенно, для небольших проектов — например простое внедрение ТЕЗИС — мы используем waterfall модель. Требования понятны, можно легко написать спецификацию и рассчитать конечную цену внедрения. Очевидно, что это максимально комфортный вариант для заказчика. Необходимость изменений в таком случае обычно невелика, и формальный процесс управления ими (change requests) не слишком трудоемок.
Для крупных проектов — в основном это сложное корпоративное ПО, или масштабные внедрения продуктов ТЕЗИС или Sherlock — такой подход уже плохо работает. В большинстве случаев (скажу больше — во всех) на начальном этапе заказчик может сформировать лишь высокоуровневые требования к решению. Понимание деталей приходит по мере развития проекта, когда становятся понятными возможности системы и то, как они используются на практике. В таких проектах мы используем agile методологию. Детальное планирование и анализ требований осуществляются лишь на короткий горизонт ближайшей итерации — спринта (в нашей практике 1-2 месяца). Параллельно с разработкой ведется планирование следующего и т.д. Это дает гибкость в управлении изменениями и позволяет минимизировать ненужную работу. Например, детальное планирование всего проекта, когда мы наверняка знаем, что большая часть требований изменится. Или формальную реализацию функциональности по спецификации (она ведь подписана!), когда уже очевидно несоответствие спецификации реальным потребностям. В итоге мы экономим время и деньги заказчика.
С другой стороны, мы не можем применять «экстремальные» варианты agile процессов, в которых долгосрочное планирование отсутствует в принципе (хотя я думаю они хорошо подходят например для разработки компактных, но массовых продуктов на рынке b2c). И заказчик, и мы должны понимать конечную цель проекта, его архитектуру, основные принципы работы и взаимодействия компонентов. Поэтому обычно мы создаем roadmap, а также функциональную спецификацию на весь проект, покрывающую основные требования без деталей реализации. Это дает нам возможность примерно оценить общие сроки и бюджет проекта (с некоторой вилкой), и таким образом управлять ожиданиями заказчика.
На каких крупных проектах вы обкатывали те тезисы, которые заявляете в статье?! Честно пытался понять, дважды перечитывал, но в голове получилась каша, хотя я хорошо знаю что такое СЭД, ERP, управление проектами и немного знаю про agile.
zhavoronok, статья в первую очередь о том, что стандартные agile практики ИТ могут также хорошо подходить не-ИТ бизнесу. И если вы внедряете у себя ECM систему, нужно в первую очередь смотреть не на стандарты, а на то, что реально происходит в вашей организации, автоматизировать то, что даст наибольший эффект, и так, чтобы людям стало работать проще, чтобы взаимодействия на всех уровнях были максимально простыми и эффективными, а не «по стандарту» или «по вертикали». Кроме того, и люди и софт должны быть готовы к изменениям процессов вместе с развитием бизнеса (что не отменяет необходимость их формализации).
Мы помогаем заказчикам выявить первоочередные задачи, и сформировать наилучшее решение. В результате мы часто внедряем систему итеративно (agile), так, чтобы решить наиболее насущные задачи в максимально короткий срок. При этом далеко не всегда при внедрении ТЕЗИС классический модуль канцелярии (входящие-исходящие, ОРД и прочее) является наиболее востребованным. Для бизнеса формальный документооборот редко является действительно критичной задачей. Например для Российского Регистра Морского Судоходства мы в первую очередь реализовали процедуры прохождения заявок на освидетельствование судов, освидетельствования в промышленности и флоте и только потом стандартное согласование договоров и канцелярию.
Мы помогаем заказчикам выявить первоочередные задачи, и сформировать наилучшее решение. В результате мы часто внедряем систему итеративно (agile), так, чтобы решить наиболее насущные задачи в максимально короткий срок. При этом далеко не всегда при внедрении ТЕЗИС классический модуль канцелярии (входящие-исходящие, ОРД и прочее) является наиболее востребованным. Для бизнеса формальный документооборот редко является действительно критичной задачей. Например для Российского Регистра Морского Судоходства мы в первую очередь реализовали процедуры прохождения заявок на освидетельствование судов, освидетельствования в промышленности и флоте и только потом стандартное согласование договоров и канцелярию.
К сожалению из статьи не смог понять что предлагает автор.
Использовать AGILE при разработке СЭД? Но такое решение принимается компанией в зависимости от продукта, требований клиентов и предметной области.
Использовать AGILE как идеологию в работе самой СЭД? Тогда компании со сложной структурой\сложными маршрутами документов просто загнутся под количеством уведомлений при соголасовании каждого пункта очередного документа.
Пясните, что же автор имел ввиду. Замена 4 слов в «манифесте» это конечно хорошо, но этого мало.
Использовать AGILE при разработке СЭД? Но такое решение принимается компанией в зависимости от продукта, требований клиентов и предметной области.
Использовать AGILE как идеологию в работе самой СЭД? Тогда компании со сложной структурой\сложными маршрутами документов просто загнутся под количеством уведомлений при соголасовании каждого пункта очередного документа.
Пясните, что же автор имел ввиду. Замена 4 слов в «манифесте» это конечно хорошо, но этого мало.
REvseev, я думаю, что частично ответил в комментарии выше. Конечно, процессы должны быть формализованы, Станислав не предлагает заменить процессы свободным общением. Но желательно, чтобы они отражали реальные эффективные рабочие процессы, сохраняя возможность изменений с минимальными трудозатратами — как с организационной, так и с технической точки зрения.
Главная мысль статьи, что методики коллективной работы и управления проектами в ИТ гораздо прогрессивнее и эффективнее всех прочих традиционных методов управления, чтобы там бюрократы всех мастей не говорили вам о традиционных ценностях.
По-крупному, у СЭД две задачи — документирование деятельности и поддержка коллективной работы. Часто (почти всегда) происходит подмена одного другим — во главу угла ставится дотошное документирование, часто не обусловленное никакими нормативными требованиями и реальной оценкой рисков. Просто чтобы кому-то задницу прикрыть. И потом выдается за лучшую практику — дескать, мы так работаем.
Об этом много пишет Стив Деннинг на Форбс, этот пост написан отчасти под впечатлением от его идей.
www.forbes.com/sites/stevedenning/2012/04/09/the-best-kept-management-secret-on-the-planet-agile/
Мой манифест — это прежде всего попытка изменить видение СЭД.
У айтишников есть свой вполне здравый и проверенной практикой подход к управлению бизнесом, которому заказчики не из ИТ-сферы могли бы поучиться. Управленцы, а тем более документоведы, не лучшие советчики в этом деле.
Как-то так.
По-крупному, у СЭД две задачи — документирование деятельности и поддержка коллективной работы. Часто (почти всегда) происходит подмена одного другим — во главу угла ставится дотошное документирование, часто не обусловленное никакими нормативными требованиями и реальной оценкой рисков. Просто чтобы кому-то задницу прикрыть. И потом выдается за лучшую практику — дескать, мы так работаем.
Об этом много пишет Стив Деннинг на Форбс, этот пост написан отчасти под впечатлением от его идей.
www.forbes.com/sites/stevedenning/2012/04/09/the-best-kept-management-secret-on-the-planet-agile/
Мой манифест — это прежде всего попытка изменить видение СЭД.
У айтишников есть свой вполне здравый и проверенной практикой подход к управлению бизнесом, которому заказчики не из ИТ-сферы могли бы поучиться. Управленцы, а тем более документоведы, не лучшие советчики в этом деле.
Как-то так.
Коллеги, спасибо за статью!
Применяем этот подход на практике и убеждаемся, что лед действительно тронулся: перемены и в умах Заказчиков, и в собственных позитивных результатах (в частности, скорости сдачи проектов).
Успехов!
Применяем этот подход на практике и убеждаемся, что лед действительно тронулся: перемены и в умах Заказчиков, и в собственных позитивных результатах (в частности, скорости сдачи проектов).
Успехов!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Agile в документообороте