Существует 2 основных типа, на которые делятся методологии разработки програмного обеспечения (software development methodology). Это структурные и гибкие методологии. Структурные методологии предполагают высокоформализованный подход к разработке ПО (каскадная модель). Гибкие методологии (Agile) ориентированы в основном на итеративную разработку с минимально допустимой формализацией процесса.
Об основных принципах гибких методологий я расскажу в другой статье. А обратить ваше внимание хочу вот на что. Agile методологии очень хорошо себя зарекомендовали и сейчас даже самый высокоформализованный процесс трудно себе представить без “гибких” элементов, в частности митингов.
Итак, SCRUM-meeting.

SCRUM - одна из гибких методологий разработки ПО. Впервые была использована в 1993 с целью улучшить продуктивность команды разработчиков, сделав упор не на качественно определенный, а на качественно контролируемый процесс разработки.
Важной частью этой методологии являются SCRUM-митинги, которые должен курировать компетентный человек - SCRUM-Master (чаще всего project manager или team lead). Такие митинги для большего эффекта нужно проводить каждый день в одно и то же время. Длительность митинга лучше ограничивать 15-30 минутами. Каждый участник проектной команды должен ответить на 3 простых вопроса:
1. Что было сделано с момента предыдущего SCRUM-митинга?
2. Какие возникли проблемы во время работы?
3. Какими задачами буду заниматься после митинга?
После ответа на любой из этих вопросов, другие члены команды могут прокомментировать слова своего сотрудника. SCRUM-Master следит за тем, чтобы такие комментарии не затягивались и не переходили в споры. В таких случаях обсуждение некоторого вопроса SCRUM-Master откладывает на удобное для заинтересованных лиц время.

Если вы еще не проводите SCRUM-митинги внутри своей команды, вот очевидный список преимуществ этого подхода:
1. За очень короткий промежуток времени project manager и все члены команды могут оценить статус проекта.
2. Все возникшие проблемы решаются очень быстро так как доносятся до всех участников проекта (среди которых потенциально есть компетентные в данном вопросе люди).
3. Сотрудники учатся слушать других, понимать их, а также четко выражать свои собственные мысли.
4. Участники проекта учатся ставить перед собой реальные задачи и отвечать за статус их выполнения.

Мне, конечно, еще далековато до SCRUM-мастера и тем более до Project-менеджера, тем не менее, хочу поделиться некоторыми своими наблюдениями:

• Существуют проблемы, требующие немедленного решения. Такие проблемы нужно решать сразу, даже если митинг из-за этого может немного затянуться.
• Не смотря на это, SCRUM-мастер должен понимать, что длительные конфликтные обсуждения чаще всего заканчиваются компромиссом (а не консенсусом, как должно быть в идеале).
• Команды больше 7-9 человек желательно разбивать на группы, у каждой из которых есть свой SCRUM-Master. Пример: проведя параллельно совещания для тестировщиков и разработчиков можно сэкономить время и силы членов команды. После этого SCRUM-мастеры могут обсудить между собой возникшие проблемы и решить их с участием заинтересованных лиц.
• Бывают ситуации, когда человека лучше освободить от участия в митинге: если он очень сконцентрирован на решении некоторой задачи, на митинге он будет менее внимателен, да и после митинга ему будет труднее заново вникнуть в суть проблемы.

Очень надеюсь, что данная статья была вам интересна. Комментарии приветствуются.