#EnciclopediATIC | Эпизод 1: Методологиях Agile и Waterfall

Приветствую и приглашаю Вас на первую серию #EnciclopediATIC – проекта под маркой career.ict.md. Сегодня мы поговорим о «Методологиях Agile и Waterfall». Возьмем их по порядку,
чтобы всё было вам понятно.

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

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

А теперь, прояснив эти два понятия, пойдем дальше. Сейчас поговорим о видах Agile: Scrum и Kanban.

Scrum – это рамки, используемые в командах, которые управляют сложными проектами. Другими словами, Scrum – это методология Agile, которая ставит своей целью представление ценных результатов за короткие периоды. Впрочем, первое применение данного метода было описано Takeuchi и Nonaka в «The New Product Development Game» в 1986 году в журнале «Harvard Business Review». По мнению авторов, проекты, использующие небольшие команды и имеющие возможность передавать задачи друг другу, производят наилучшие результаты. Также они сравнили эти эффективные команды со схваткой вокруг мяча в регби, по-английски «scrum», говоря о таком методе организации проектов как Scrum.

Метод Kanban, так, как он был определен Дэвидом Дж. Андерсоном – это метод инкрементального, эволюционного изменения процессов и организационных систем. Вкратце, Kanban – это способ организации хаоса, который сопровождает деятельность многочисленных команд по внедрению, путем осознания необходимости расставить приоритеты и привести в соответствие усилия. Его описывают еще и как способ выявления проблем, связанных с рабочими процессами и потоками, который позволяет их решать и предоставлять больше содержательности клиентам и покупателям.

Рассмотрим теперь и роли, которые встречаются во всех этих сложных проектах. Их много и все они очень важны, такие как development team, product owner, scrum master и stakeholder.

  • Development team означает в переводе команду по разработке, которая состоит из специалистов, создающих из деятельности по поставке потенциальный Инкремент, с которым можно выйти на рынок, «Готового» продукта, в конце каждого Спринта. Команды по разработке самоорганизуются. Никто, даже Scrum Master, не может сказать, как можно превратить элементы Product Backlog в потенциальные Инкременты функций, с которыми можно выйти на рынок. Кроме того, такие команды межфункциональные и обладают всеми компетенциями в отношении конечного продукта. Если говорить о том, сколько участников должна насчитывать development team, то вам следует знать, что она должна быть достаточно небольшой, чтобы оставаться быстрой, но и достаточно большой, чтобы суметь завершить существенную работу в составе Спринта.
  • Что такое product owner? Это функция, которой обладает определенное лицо. Product owner — это член команды Agile, ответственный за максимальное увеличение ценности продукта за счет труда команды по развитию. Product Owner сосредотачивается на невыполненных задачах (backlog), обеспечивая, чтобы все было ясно, оптимизировано, а команда программистов понимала все вопросы. Product Owner должен сосредоточиться на внутренней организации, чтобы обеспечить соответствие потребностей клиента техническим чертам продукта. Он же, Product Owner, берет feedback у клиента, убеждаясь в том, что конечный результат проекта соответствует ожидаемому.
  • Другая встречающаяся роль — это Scrum Master. Он является инструктором команды по разработке в системе Agile. Scrum master отвечает за управление процессом и только процессом. Они не участвуют в принятии решений, а действуют для направления команды разработчиков. Этот человек всегда в курсе состояния проекта, и его работу модно приравнять к работе менеджера проекта. Его называют также Lord Scrum. Таким образом, Scrum Master не является архитектором или каким-либо техническим экспертом, а скорее, тренером. Без этого человека в команде, управляющего процессом от А до Я, проект может потерпеть провал.
  • Не стоит забывать и о Stakeholder-е (заинтересованной стороне). Это тот, кто дает feedback собственнику продукта и команде Scrum, а также часто способствует Sprint Review. Часто stakeholder-ы даже входят в состав организации, которая разрабатывает соответствующий продукт. На самом деле, stakeholder-ом может быть лицо или группа лиц, или даже организация, которые заинтересованы либо на определенном этапе, либо при всем процессе, чтобы он осуществлялся определенным образом и давал определенный результат.

Статья написана в сотрудничестве с Сабиной Паулеску, менеджером по персоналу Амдарис, и Алиной Мальбаш, менеджером по персоналу Technosoft.