Ответ
Почему модель Agile SDLC подходит для стартапов? Опции темы
Старый 20.06.2018, 16:47
  #1
Nataly
 
Регистрация: 29.07.2014
Сообщений: 474

Почему модель Agile SDLC подходит для стартапов?
Чаще всего хорошее планирование – это лишь половина успеха. В сфере IT качество продукции во многом зависит от качества планирования, поэтому жизненный цикл разработки программного обеспечения (Software Development Life Cycle, SDLC) так важен. SDLC - это термин, который относится к способу построения процесса разработки, макету разработки и определению задач для каждого члена команды. SDLC является основой планирования, контроля, создания, тестирования и доставки программного обеспечения, которая помогает узнать, где команда находится в любой момент времени и какие необходимы ресурсы для работы команды на каждом этапе.

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

Наиболее эффективной для стартапов является методология под названием Agile SDLC model. Быть гибким (agile) в основном означает быть способным адаптироваться к изменениям, когда это необходимо. Благодаря этой методологии, команды могут адаптироваться к изменениям на рынке и обходиться любыми ограниченными ресурсами, доступными им в конкретный период времени. Будучи бережливой методологией, она помогает уменьшить или полностью исключить расточительную и бессмысленную деятельность.





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

Модель Agile SDLC основана на двух подходах – итеративном и инкрементном (Iterative & Incremental). Инкрементная разработка означает, что вы создаете что-то по частям. Программное обеспечение разрабатывается небольшими кусками, причем на каждом шаге добавляется функционал. Такой подход позволяет получить минимальный жизнеспособный продукт (minimum viable product, MVP) довольно рано. Однако есть одна проблема - продукт не будет готов до тех пор, пока не будет добавлена последняя часть рабочего функционала.

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

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

Мы уже упоминали итеративный подход, но он в одиночку может втянуть вас в бесконечный цикл повторных уточнений, которые истощают ограниченные ресурсы стартапа. Спиральная модель (Spiral model) сочетает в себе структуру модели водопада и повторяемость итеративного подхода, что также означает, что существует опасность потери времени и денег, если разрабатываемый продукт является новым и имеет много неизвестных характеристик. Все это указывает на самую гибкую и ориентированную на результат модель для стартапов - Agile SDLC.

Манифест гибкой разработки программного обеспечения (Agile Manifesto)

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





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








Однако есть и различия. Scrum фокусируется на четком планировании и имеет разные роли для каждого проекта - Владелец продукта (Product Owner), Скрам-мастер (Scrum Master) и Команда разработки (Development Team). Если вы хотите изменить методологию компании на Agile, Scrum может стать вашим предпочитаемым оружием, так как им довольно легко управлять, и он не будет радикально реорганизовывать всю систему.

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





Рассмотрим основные принципы Agile Manifesto.

Люди и взаимодействие важнее процессов и инструментов

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

Работающий продукт важнее исчерпывающей документации

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

Сотрудничество с заказчиком важнее согласования условий контракта

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

Готовность к изменениям важнее следования первоначальному плану

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

Agile vs Waterfall

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

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

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

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

Как и Waterfall, модель Agile SDLC также имеет плюсы и минусы. Разработчики нуждались в методологии, которая бы учитывала изменения и потребность в более быстрой разработке программного обеспечения, и из этой потребности возник Манифест, как упоминалось выше.

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





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

После принятия изменений вторым по значимости достоинством Agile является принятие неопределенности. Это совершенно нормально не знать все о продукте в самом начале. Agile признает, что команда будет обнаруживать больше информации по мере развития процесса разработки. Функция больше не отвечает потребностям клиентов? Нет проблем - с Agile SDLC легко изменить направление.

Для того чтобы быть в состоянии принять изменения и неопределенность, Agile SDLC использует циклы пересмотра проекта (review cycles). Большинство Agile практик используют либо временные рамки, либо контролируют объем проделанной работы (Scrum и Kanban, как мы упоминали выше). После этого, проделанная работа рассматривается с клиентами или доверенными лицами клиентов.

Тем не менее, в рамках Agile проекты могут занимать больше времени и требовать более высокого уровня затрат, так как нет заранее установленного количества этапов, которые нужно будет пройти. Это может быть вызвано отсутствием понимания философии Agile, изложенной в манифесте. Большинство организаций хотят быть гибкими, но не инвестируют время, деньги и усилия, чтобы изменить, обучить менеджмент необходимым для этого навыкам. Иногда попытка реализовать «гибкие» идеи, вырванные из контекста, имеет плохие и разрушительные последствия.

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

К сожалению, не каждая организация и не каждая корпоративная культура готова стать гибкой. Если компания полагается на 12-24-месячные планы действий, будущие обещания, которые она дает клиентам, чтобы ручаться за текущую деятельность, или требует строгого утверждения бюджета, прежде чем сможет начать новый проект, ей будет трудно переключиться на Agile, так как этот SDLC основан на определенном уровне неопределенности. Если компания планирует прогнозировать операции в течение следующих 6 месяцев или дольше, она не сможет использовать Agile.

Несмотря на свои недостатки, Agile становится модным словом среди стартапов. Почему? Небольшие стартапы не могут превзойти по расходам или вытеснить большие корпорации, но у них есть то, чего нет у «большой рыбы» - гибкость. Стартапы превосходят конкурентов, используя ограниченные ресурсы умнее, и Agile является одним из лучших фреймворков для достижения этого. В Agile-стартапах работают небольшие команды, каждая из которых работает над одной частью проекта, и когда они собирают результаты, у них есть минимальный жизнеспособный проект, который они постепенно улучшают, включая обратную связь от пользователей и рынка.

Как заставить Agile SDLC работать для стартапов

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

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

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

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

Шаг 5. Найдите свой собственный путь. Многие стартапы пытаются копировать процессы других масштабирующихся компаний. Например, Spotify стал образцом для подражания для других растущих гибких организаций. Но правда в том, что не существует единого способа разработки программного обеспечения в Spotify. Spotify поощряет своих сотрудников постоянно привносить новые идеи и адаптировать свой способ работы. Как основатель стартапа, вы должны принять уникальность компании и помочь команде найти свой собственный путь к росту.

Шаг 6. Откажитесь от позиции командного управления. Гибким компаниям не нужен отдел руководства проектом или посредник между ними и заинтересованными сторонами и клиентами.





Если углубиться в то, как работают гибкие организации, то можно отметить Lean Startup. Lean - это набор принципов, которые помогают компании достичь качества, скорости и ориентации на клиентов. Lean - это практика, которая устраняет все возможные «убытки» - бесполезные собрания, документацию и неэффективные способы работы, такие как многозадачность. Таким образом, в основном, Lean - это метод управления проектами, который работает для всех отраслей, а Agile - его вариант для IT.

Как включить общие принципы Lean в методологию Agile?

Вот несколько шагов:

1. Определите продукт. Четко установите, в чем состоит продукт, как он будет работать, кто будет его использовать, как он поддерживает стратегию компании.

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

3. Составьте план работы. Это будет график выпуска каждой итерации.

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

5. Организуйте обзоры. Покажите рабочий продукт заинтересованным сторонам.

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

Как вы видите, построение Lean и Agile так же эффективно, как и динамично, поэтому многие компании по всему миру выбирают эту методологию. Она позволяет группам разработчиков сосредоточиться на дорожной карте продукта и максимизировать эффективность, устраняя трудоемкие и зачастую бесполезные документы и встречи. Однако выбирая Agile SDLC, вы должны иметь в виду, что важно объединить этот ориентированный на цели рабочий процесс с верификацией клиентов, чтобы обеспечить создание первоклассного продукта.
Нравится 0   Не нравится 0
Пожаловаться на это сообщение 0  
Ответить с цитированием

Ответ
 
 

Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Секрет успеха домашних страниц 20 ведущих стартапов Tallulah Аналитика 0 11.08.2014 21:05
10 необходимых инструментов для стартапов Tallulah Сервисы 0 02.08.2014 22:19
Схематическое изображение подходит не всем сайтам Viper Статьи 0 23.04.2014 15:59
Круг DASEMRA, или что такое Agile SEO Viper Статьи 0 14.04.2014 10:09
Помогите идентифицировать модель stomatolog Оффтоп 4 16.04.2013 19:17

Метки
agile, kanban, lean, scrum, sdlc, разработка по, стартап


Здесь присутствуют: 1 (пользователей: 0, гостей: 1)
 
Опции темы

Быстрый переход


Текущее время: 16:50. Часовой пояс GMT +3.