Опыт внедрения гибкой методологии разработки в деятельность розничного и IT-блоков банка

Размещено на сайте 25.09.2017

Agile-методологию, изначально реализованную в IT-области, сегодня рассматривают как особый подход к проектной деятельности в любой организации. В какой-то мере уже можно говорить об «agile-империализме», связанном с продвижением agile-методологии сначала в смежные, связанные с IT, затем в более отдаленные области. Какими критериями руководствоваться при принятии решения о применении agile в деятельности организации? Как обеспечить каскадирование целей от руководства организации, которое представлено ролями кураторов, к непосредственным исполнителям в командах?

Руслан ДОЛЖЕНКО, Уральский государственный экономический университет, профессор кафедры экономики труда и управления персоналом, д.э.н.

Приводятся извлечения из статьи. Полную версию материала читайте в журнале. Подписаться

Процесс должен одинаково пониматься всеми его участниками. Все участники процесса должны пользоваться общей терминологией. Те, кто выполняет работу и принимает итоговый результат, должны иметь общее представление о критериях готовности продукта.

Несмотря на кажущуюся эффективность, интерес бизнеса к agile, который во многом перегрет вниманием массовой общности практиков, внедрение данной методологии должно быть крайне продуманным, учитывающим все системные последствия коренного изменения подходов к организации деятельности проектных команд.

Ограничение размера трайба/кластера построено на «Числе Данбара»: количество постоянных социальных связей, которые чело- век может поддерживать, составляет 125–150 человек.

Ключевым условием успешности agile являются не методы, не технологии и даже не опыт, который банк в силу наличия значительных финансовых ресурсов всегда может купить, а организационная культура.

Постановка всех задач в agile ведется по принципу «что/как». Вышестоящий уровень ставит задачу в форме «что сделать» или «какой цели нужно достичь», а нижестоящий уровень сам определяет, «как» делать. При этом вышестоящий уровень не должен вмешиваться в то, «как» нижестоящий уровень будет выполнять задачу.

Качественная пользовательская история — это история, которую можно целиком записать на одной карточке, а критерии приемки — на ее обратной стороне.

Выбрать	Риски	Бухучет и налоги	Кредитный департамент	Управление банком
направление:	Розница	Внутренний контроль	Операционный департамент	Юридическая работа

О компании	Контакты	Авторам		Для клиентов (Как скачать закрывающие документы)
Помощь	Реклама	Подписным агентствам