Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2017

Команда vs. Методология

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

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

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

Провальная команда провалит проект с практически любой методологией. Даже наилучшая методология врядли способна на большее, чем просто растянуть агонию или смягчить провал. Неподходящая методология ещё быстрее выявит провальные тенденции и станет впоследствии "козлом отпущения", на которого и свалят вину от провала.

Успешность или провальность команды формируется из множества факторов, большинство из которых относится к социальной, а не технической сфере, что невероятно затрудняет их анализ и коррекцию. Это и мотивация, и межличностные отношения и коммуникации, и успешность формирования лидерства в команде, и наличие в команде всех необходимых для успеха ролей, и стадия формирования самой команды, и многое другое. Для "нейтрализации" всех этих факторов (или по крайней мере большинства) были разработаны так называемые "тяжёлые" методологии. Например, большинство требований к сертификации процесса по ISO 9001:2000 как раз сводится к нейтрализации "человеческих" факторов и подмены их тем, что принято называть бюрократией. Для провальных команд использование подобных процессов и методологий - единственных путь привести проект к успешному завершению пусть даже ценой десятикратных затрат времени и ресурсов. Для успешных команд использование подобных методологий - существенная потеря времени и ресурсов, устранение которой (переход на более "лёгкие" методологии) способно многократно повысить общую производительность и результирующую успешность.

Именно применение в успешных командах и оптимизация с их помощью успешных команд является основным сектором использования гибких методологий. К сожалению, большинство авторов не делают на этом никакого акцента, в скорее наоборот, стараются "притянуть" свою методологию "за уши" в сторону всеобщей применимости. Последствия такой интерпретации - желание всё большего числа менеджеров внедрить гибкую методологию в своей не очень успешной команде, и решить тем самым проблемы её неуспешности. Только вот результат обычно обратный и не заставляет себя долго ждать: проблемы становятся ещё более явными, провал приближается ещё более стремительно, неудача в итоге "списывается" на методологию.

В связи со всем вышесказанным, хочу посоветовать всем менеджерам, задумавшим переход/внедрение гибкой методологии:

1. Постарайтесь ответить себе честно - успешна ли ваша команда? Есть ли в её работе "провальные" тенденции? Если команда с трудом приводит к успеху половину проектов - задумайтесь об утяжелении процесса или о новой команде. Если успешность команды близка к 100% - это то что надо, пора становиться гибче.

2. Никогда не переходите на методологию в середине проекта, особенно если в нём назревают серьёзные проблемы. Идеальное время перехода - между проектами или в самом начале проекта. Лучше всего "обкатать" методологию на небольшом проекте и маленькой команде, потом уже запусткать на серьёзные проекты и всю компанию. Если переход в середине проектного цикла неизбежен, делайте это только во время относительного  спокойствия, решив сначала основные проблемы и уведя проект от кризисных тенденций.

Ну и конечно же, всё вышесказанное никак не отменяет других советов по переходу, если решение о переходе всё-таки принято и процесс запущен.


Categories: Agile | Management
Posted by Vitalii Tsybulnyk on Wednesday, November 3, 2010 7:56 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Add comment




  Country flag

b i u quote
Loading