Javenue logo

Javenue

Программирование на Java

Информационные технологии

Scrum митинг во всей красе

Существует 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-мастеры могут обсудить между собой возникшие проблемы и решить их с участием заинтересованных лиц.
  • Бывают ситуации, когда человека лучше освободить от участия в митинге: если он очень сконцентрирован на решении некоторой задачи, на митинге он будет менее внимателен, да и после митинга ему будет труднее заново вникнуть в суть проблемы.

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


Комментариев: 0

  Выйти

  * для публикации комментариев нужно