Waterfall или Agile: как выбрать методологию управления проектом? — Azoft на

Что такое agile?

Гибкая разработка впервые упоминается в опубликованной в 1970 г. статье Уильяма Ройса о создании больших программных систем. Четыре ее фундаментальных ценности и 12 принципов были сформулированы позднее в «Манифесте Agile». Agile — это методология управления проектами, состоящая из коротких циклов инкрементальной разработки, называемых спринтами. Каждый цикл нацелен на непрерывное улучшение разработки продукта или сервиса.

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

Вторая стадия — проектирование, в ходе которой заинтересованные стороны определяют, как должен выглядеть продукт и какие необходимые элементы он должен содержать. Далее идет собственно разработка, в ходе которой команда разработки создает продукты короткими итерациями, называемые «спринтами».

Тестирование призвано выяснить, соответствует ли продукт требованиям. При выявлении недостатков он возвращается на стадию разработки для устранения проблем перед повторным тестированием. Этот цикл продолжается пока продукт не станет соответствовать спецификациям.

Основные модели разработки по

• Code and fix — модель кодирования и устранения ошибок;
• Waterfall Model — каскадная модель, или «водопад»;
• V-model — V-образная модель, разработка через тестирование;
• Incremental Model — инкрементная модель;
• Iterative Model — итеративная (или итерационная) модель;
• Spiral Model — спиральная модель;
• Chaos model — модель хаоса;
• Prototype Model — прототипная модель.

Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.

Agile – гибкое управление проектом

Agile
  – это система ценностей, помогающая создавать новые продукты. 

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

Сам по себе Agile – это не модель управления, а философия, помогающая сформировать отношение к работе. Философия состоит из четырех ценностей и 12 принципов. Они закреплены в
Agile-манифесте разработки программного обеспечения:

«Люди и взаимодействия важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

Создатели воспринимали Agile  как философию, которую можно адаптировать под конкретные задачи. Современные модели проектного менеджмента, например, Scrum и Kanban, основаны на философии Agile.

Рассмотрим преимущества и недостатки Agile.

Agile или «водопад»: за и против

Оба метода разработки имеют свои достоинства и недостатки. Основные из них Мойра Александер свела в таблицу.

Достоинства и недостатки «гибкого» и «традиционного» подходов к разработке

Iterative model (итеративная модель)

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

Рассмотрим на примере создания мессенджера, как эта модель работает.

1. Заказчик решил, что хочет создать мессенджер. Разработчики сделали приложение, в котором можно добавить друга и запустить чат на двоих.
2. Мессенджер «выкатили» в магазин приложений, пользователи начали его скачивать и активно использовать. Заказчик понял, что продукт пользуется популярностью, и решил его доработать.
3. Программисты добавили в мессенджер возможность просмотра видео, загрузки фотографий, записи аудиосообщений. Они постепенно улучшают функциональность приложения, адаптируют его к требованиям рынка.

Преимущества итеративной модели

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

Недостатки итеративной модели

• Использование на начальном этапе баз данных или серверов— первые сложно масштабировать, а вторые не выдерживают нагрузку. Возможно, придётся переписывать большую часть приложения.
• Отсутствие фиксированного бюджета и сроков. Заказчик не знает, как выглядит конечная цель и когда закончится разработка.

Итеративная модель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате. 

Kanban

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

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

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

Kanban – инструменты для улучшения рабочих процессов

Kanban
 – это метод для построения внутренних процессов в компании. Он тоже входит в семейство гибких методологий.

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

Доска может быть как физической, так и виртуальной, например,
Trello. Важно, чтобы задачи не были слишком маленькими – так их будет много и учет будет отнимать время. Также важно, чтобы задачи не были слишком большими, чтобы карточки не застревали на доске.

Важный момент – это точка принятия обязательств. Если задача правее этой точки, команда еще решает, делать или не делать эту задачу. Но когда задача перемещается левее, это значит, что задачу решили сделать. С момента, как задачу решили сделать, имеет смысл отслеживать прогресс по ней.

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

Поэтому в канбане есть принцип «перестаньте начинать [новые задачи], начните завершать [задачи, которые уже в работе]»

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

Доска – это лишь один из инструментов, который помогает увидеть проблемы. Чтобы оптимизировать работу, существуют другие инструменты: ограничение количества задач в работе, управление потоком, 
каденции
 и так далее.

Lean startup – бережливый стартап

Бережливый стартап – это способ разработать и вывести на рынок новый продукт. Концепция сочетает исследование пользователей и итеративный подход.

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

Базовые этапы Lean Startup:

1. Построить минимально жизнеспособную версию продукта;

2. Выпустить ее и оценить метрики;

3. Сделать выводы и собрать идеи для улучшения продукта.

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

Например, так разрабатывали облачное хранилище Dropbox. Создатели сделали простую программу, в которой пользователи Windows могли обмениваться любыми файлами. Они побоялись выпустить программу сразу для реальных пользователей и записали видео о работе программы.

Видео выложили на форум разработчиков и получили от них пожелания, что они хотели бы видеть в программе. И также наняли тестировщиков, чтобы те проверили программу. Затем на основе обратной связи доработали и выпустили программу. Следующие обновления они тоже тестировали и прислушивались к реакции пользователей. Сейчас Dropbox используют больше 500 миллионов людей во всем мире.

Бережливый стартап подойдет для:

• снижения рисков при запуске стартапа. Основатель Zappos не знал , готовы ли люди покупать обувь по интернету. Чтобы проверить гипотезу, он сфотографировал обувь в местных магазинах и загрузил фото на сайт. Если обувь заказывали, он покупал ее в магазине и отправлял. Теперь Zappos – большой онлайн-ретейлер обуви.

• оценки жизнеспособности нового продукта, модели, версии. Например, General Electric разработали новую модель холодильника при помощи бережливого стартапа. Они прошли 18 итераций разработки и обратной связи от пользователей перед выпуском финального продукта. 

Компании, которые используют Lean Startup: Dropbox, Zappos, General Electric, Slack, «Модульбанк».

Подробнее о применении бережливого стартапа читайте в статье «Бережливый стартап».

Microsoft solutions framework

“Частная” методология управления проектами, MSF, была придумана и введена в работу в 1994 году майкрософтом. Она особенна тем, что разрабатывалась непосредственно под разработку программного обеспечения, а не адаптировалась, что можно сказать о том же PMBoK.

Внешне похожа на список внутренних рекомендаций (типа как у вас в интре) для менеджеров проектов. В чистом виде не используется даже Microsoft – добавляют тот же эджайл, например. В википедии есть познавательная статья об этом фреймворке, прошу пройти туда – там больше, чем могу рассказать я.

Scrum – инструкция по запуску нового продукта

Scrum
 – это способ организации рабочего процесса. Скрам помогает проверять идеи, тестировать новые решения, выпускать инновационные продукты.

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

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

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

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

Подробнее об организации работы по Scrum читайте в статье «Agile по правилам Scrum».

Spiral model (спиральная модель)

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

Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом». 

1. Заказчик решил, что хочет сделать такую систему, и заказал программистам реализовать управление чайником с телефона. Они начали действовать по модели «водопад»: выслушали идею, провели анализ предложений на рынке, обсудили с заказчиком архитектуру системы, решили, как будут её реализовывать, разработали, протестировали и «выкатили» конечный продукт.
2. Заказчик оценил результат и риски: насколько нужна пользователям следующая версия продукта — уже с управлением телевизором. Рассчитал сроки, бюджет и заказал разработку. Программисты действовали по каскадной модели и представили заказчику более сложный продукт, разработанный на базе первого.
3. Заказчик подумал, что пора создать функциональность для управления холодильником с телефона. Но, анализируя риски, понял, что в холодильник сложно встроить Wi-Fi-модуль, да и производители не заинтересованы в сотрудничестве по этому вопросу. Следовательно, риски превышают потенциальную выгоду. На основе полученных данных заказчик решил прекратить разработку и совершенствовать имеющуюся функциональность, чтобы со временем понять, как развивать систему «Умный дом».

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

Преимущества спиральной модели

• Большое внимание уделяется проработке рисков.

Недостатки спиральной модели

• Есть риск застрять на начальном этапе— бесконечно совершенствовать первую версию продукта и не продвинуться к следующим.
• Разработка длится долго и стоит дорого.

На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке.

V-образная модель (разработка через тестирование)

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

Преимущества V-образной модели

• Количество ошибок в архитектуре ПО сводится к минимуму.

Недостатки V-образной модели

• Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».

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

Waterfall

Водопад, каскадная методология – традиционная, самая популярная и логичная методология управления проектами. В чистом виде может сработать совсем в простых проектах. Допустим, тебе потребовалось посадить дерево. “По водопаду” выполнение проекта выглядит так:

Каждый этап в таком проекте идет следом за предыдущим и не может быть выполнен раньше предыдущего – это и есть “водопад”. Еще это пересекается с “методом критического пути”, но о нем расскажу в отдельной статье – напомни мне.

Я работаю с проектами в сфере разработки сайтов и мобильных приложений. Этапы разработки таких проектов по водопаду примерно одинаковы:

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

Waterfall – каскадная модель

Каскадная модель или модель «водопад», – это вариант классического поэтапного планирования. 

Проект состоит из последовательных этапов: инициация, планирование, разработка, реализация и тестирование, мониторинг и завершение. 

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

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

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

Реализация и тестирование. На этой фазе происходит основная работа – строители закладывают фундамент, возводят стены и крышу, проводят коммуникации. 

Мониторинг и завершение проекта. Руководитель передает проект клиенту, оценивает результат и составляет план по улучшению на будущее.

Разным проектам нужны различные этапы реализации – некоторым достаточно и трех фаз, другим нужно больше пяти. Но суть waterfall-модели одна – проект разбит на этапы, которые заранее запланированы и выполняются один за другим.

Waterfall или agile?

Никакая методология не панацея. Ближайшую аналогию могу провести с чеклистами – это такая классная штука (читай статью на моем медиуме @salakhmir), которая люто помогает в работе, но, почему-то, работает не у всех. Любой инструмент – всего лишь инструмент, и сам по себе работать не будет.

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

Часто отклонения уходят в отдельные проекта, но чаще остаются внутри текущего и тянут за собой увеличение времени (бюджета) проекта. Кажется, это плохо, но момент политики в работе с людьми (мы же работаем с людьми, а не с сайтами, помнишь?) исключать нельзя.

Классическое управление проектами

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

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

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

Краткий ликбез по waterfall

Waterfall (каскадная) – это методология ведения проекта, когда фазы работ идут последовательно. Следующая фаза начинается только после завершения предыдущей. Наглядно это выглядит так:

Получается, план такой: 

1. Установили и прояснили требования заказчика и согласовали их с командой;
2. Подготовили весь дизайн проекта; 
3. Разработали программное обеспечение целиком по заданным технологиям;
4. Протестировали проект на наличие багов;
5. И только после всех предыдущих, последовательных этапов — запустили в эксплуатацию.

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

Методология

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

Методологий управления проектами великое множество – они бывают используемыми только в одной компании, бывают глобальными. Методологии бывают в виде инструментов (типа Agile), бывают в виде большой книги с набором этих инструментов (PMBoK, тоже методология).

В жизни я использовал и использую две, самые популярные методологии – Waterfall (“водопад”/“каскадная”) и Agile (и его ответвление – Scrum), о них и пойдет речь. Ради расширения кругозора читателя расскажу и о других известных мне вещах. Если читатель работает с диджитал, то “водопада” и “эджайла” хватит за глаза – можно будет использовать их в работе, жизни, рассказывать знакомым и незнакомым людям, на митапах, с умным видом попивая смузи.

Ограничения agile

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

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

Многое зависит от клиента. Принципы аджайла требуют сотрудничества и участия клиента. Клиенту нужно пройти обучение и перестроить свои процессы, чтобы помогать в разработке продукта. Если клиент не разделяет ценности Agile, работать с ним не получится.

Легко сбиться с пути. Суть аджайла – в гибкости и возможности подстраиваться под постоянно меняющиеся условия. Иногда если обратная связь заказчика не ясна, разработчик может сфокусироваться на работе в неправильном направлении. Есть опасность впустую тратить деньги, постоянно меняя продукт.

Гибкий подход подойдет, если:

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

• вы делаете продукт, который можно выпускать частями: блог, программное обеспечение, стриминговый сервис;

• запросы пользователей и ситуация на рынке постоянно меняются.

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

Компании, которые работают по Agile: Spotify, Microsoft, Google, Netflix, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis, General Electric, John Deere.

Подробно о том, что такое аджайл и как он появился, читайте в нашей статье «Agile – новый Lean?».

Ограничения scrum

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

Меньше предсказуемости. В каскадной методологии работа начинается с разработки подробного ТЗ, в Scrum такого нет. Клиенту бывает сложно решиться на проект с большим количеством неизвестных. 

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

Скрам подойдет, если:

• вы разрабатываете новый продукт, аналогов которого нет на рынке;

• у вас есть возможность собрать команду сотрудников, которые будут заниматься только этим проектом. 

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

Артемий Анцупов 

agile-coach, партнер «Скрамтрэк» 

Ограничения канбана

У канбана широкая область применения. Можно сравнить его с ящиком инструментов. Для каждой задачи можно что-то подобрать. При этом каждый будет пользоваться инструментами по-своему. Поэтому канбан можно применить везде, где у вас есть поток задач. Однако, метод будет неэффективен, если нужно разработать новый сложный продукт, для этого лучше подойдет скрам.

Канбан подойдет:

• если у команды много задач и заказов: канбан поможет выявить проблемы и оптимизировать работу;

• для отделов, которые поддерживают операционную деятельность: бухгалтерия, финансовый отдел;

• для визуализации процессов и выявления проблем: доску по канбан-методу можно вести даже для личных дел – чтобы видеть приоритетные задачи и заметить дело, которое уже давно висит. 

О том, может ли проектное управление уживаться с процессным и что противопоказано при переходе на проектный менеджмент, читайте в статье «Ликбез для проектного менеджера» на портале ProКачество. 

Компании, которые используют канбан: «Альфа-Банк», «Хоум Кредит Банк», «Почта Банк», «Додо Пицца», HeadHunter, Wargaming, Microsoft, Siemens и другие.

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

Артемий Анцупов 

agile-coach, партнер «Скрамтрэк» 

Особенности agile

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

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

За один такой интервал времени разрабатывают новую версию продукта или перерабатывают уже существующий. В итоге после итерации получается новый продукт или новая версия, готовая к выпуску. Продукт выпускают, собирают обратную связь и в следующую итерацию улучшают и дорабатывают. Иногда итерации называют agile-спринтами, но это не совсем верно. Спринт – термин из Scrum-подхода.

Можно менять проект в процессе. И заказчик, и команда оценивают результат по ходу проекта и решают, как действовать дальше.

Результат важнее документации. От плана можно отступать, если это принесет пользу проекту. 

Особенности канбана

• Канбан предлагает оценивать эффективность с точки зрения сервиса: насколько заказчик остался доволен, с какими задачами обычно обращаются клиенты, сколько они готовы ждать.

• Главный показатель эффективности в Kanban – это среднее время прохождения задачи по доске. Если задача прошла быстро – все хорошо. Если время выполнения затянулось, нужно думать, где и почему возникли проблемы.

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

• Вся команда едина – нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Сделать», «В процессе», «Тестирование», «Согласование» и др.

Откуда взялись методологии?

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

Отличия scrum и kanban

Скрам и канбан часто сравнивают, но сравнение не всегда имеет смысл – они не конкурируют и не исключают друг друга. Скрам поможет решить большую сложную задачу, а канбан – оптимизировать работу с потоком задач.

Артемий Анцупов: «Скрам помогает решить конкретную задачу – разработать новый продукт, как можно быстрее и так, чтобы он был нужен пользователям. Для этой задачи скрам эффективен. Если у вас есть внутренний или внешний сервис – вам пригодится канбан.

Проверка — тестирование

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

И это главный минус Waterfall: если бы использовали гибкие методологии, критические ошибки нашли бы сильно раньше. Это сократило бы время разработки и ресурсы команды, продукт обошелся бы дешевле, а проблемы не были бы столь существенными. А так получается, что бОльшая часть проекта уже пройдена, но к этому моменту работоспособного продукта моет и не быть.

Проектирование

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

1. Обсуждают и согласуют с клиентом логику работы системы, детали готового продукта
2. Создают описание функционала — что и как должно работать
3. Готовят прототип и макеты дизайна, привлекают разработчиков
4. Согласуют бюджет, определяют объем человеко-часов, планируют штат команды разработки

Вопрос реализации по прежнему пока не затрагивается. Но подготовительный этап в самом разгаре.

Резюме

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

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

Этапы жизненного цикла по

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

Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.

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

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

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

Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.

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

А методология включает в себя набор методов по управлению разработкой: это правила, техники и принципы, которые делают её более эффективной.