Это — дополненный модифицированный перевод https://stackify.com/what-is-sdlc/

Жизненный цикл разработки программного обеспечения (SDLC, software development lifecycle) — это как надо нормально делать программные продукты чтобы было подешевле и покачественнее и в срок.

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

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

Общий смысл SDLC — делать по порядку и не пропускать такие этапы:

  • Анализ потребностей
  • Планирование
  • Дизайн (тут больше про проработку архитектуры)
  • Разработка — тут наконец пишут код 😉
  • Тестирование
  • Запуск (деплой)
  • …. получаем результат/данные, а значит новые проблемы/задачи, и переходим в начало.

SDLC имеет несколько подвидов, см. в конце статьи.

Пробежимся по жизненному циклу

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

Потом, надо разработать требования.

Потом надо получить результат (используемый пользователями продукт) через анализ, планирование, дизайн, разработку, тестирование и выведение результата работы в мир.

… вот и все 🙂

Методология SDLC помогает избежать дорогостоящих ошибок (по ресурсам и репутации), типа неспрашивания фидбека у клиента и пользователей.

SDLC поддерживает тестирование и итерирование. Больше тестирования — меньше переделываний, затрат времени/денег/репутации.

Подробнее по каждому этапу

Анализ потребностей — Requirement analysis

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

Детальнее про анализ потребностей
(казалось бы, какое это имеет отношение к программисту?…)

Три больших вопроса

  1. Какие потребности у пользователей?
  2. Как лучше удовлетворить эти потребности?
  3. Как улучшить техническую производительность?

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

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

Вопросы юзерам:

  • чего ты хочешь достичь с помощью продукта? — критичный вопрос, чтобы понимать причины важности продукта для пользователя
  • какой твой любимый аспект продукта? — чтобы сфокусироваться на самом важном
  • какой менее любимый аспект? — будь готов слушать
  • каких хочешь улучшений? — полезно, но юзеры не всегда знают чего хотят
  • насколько посоветуешь продукт друзьям/коллегам? — мощный метод для получения NPS — понимания реального довольства пользователей и нахождения фанатов. Баллы 9-10 означают что юзер есть «промоутером», всем о продукте рассказывают. 7-8 пассивны, вряд ли что-то рассказывают. 1-6 — недовольны и могут даже отговаривать других от продукта. Не забывайте задавать вопрос «Почему?» чтобы понимать контекст оценки

Вопросы девелоперам:

  • Какие самые популярные запросы на фичи? — если какая-то фича запрашивается чаще чем другая значит возможно она нужнее
  • Какие сейчас баги? — были ли серьезные решения? Можно ли что-то изменить чтобы каких-то категорий ошибок стало меньше?
  • Есть возможность порефакторить? — первая версия продукта всегда внутри выглядит ужасно. Все может работать, но это не будет длиться вечно. Гуглите «технический долг». Так что надо вкладывать силы в шлифовку и переписывание кода и даже процессов.
  • Какие фичи принесут наибольшую пользу? — фич всегда много, надо выставлять приоритеты.

Вопросы менеджерам:

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

Вопросы продающим людям:

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

Вопросы экспертам индустрии:

  • Что будет трендовым в следующем году? — для высокоуровневых стратегий
  • Есть ли сейчас какие-то ниши в индустрии незанятые? — редкая ценная инфа

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

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

Планирование — Planning

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

Иными словами, команде надо определить осуществимость проекта, и как им успешно его закрыть с минимальными рисками и тратами.

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

Дизайн

"Как мы получим то что хотим?" — превращаем спецификации из предыдущего шага в план разработки (design plan, Design specification). Потом все стороны изучают план, дают отзывы и советы. Важно иметь такой план, чтобы собрать больше вводных данных от всех, в этот же документ. Фейл на этом шаге вылезет в большие траты или возможно даже коллапс проекта.

Разработка — Development

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

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

Бывает и так, что задокументированных гайдлайнов нет, четко прописанных структур нет, но все как-то привыкли и синхронизируются в личном общении 😇, бардак в общем.

Чтобы разработка шла чьотко, используют всякие системы управления задачами типа Jira / redmine / Trello (вот пример доски). Разрабам понятно что делать, менеджеры контролируют процесс.

У более или менее организованных команд весь код оседает в GIT (что это?), а фичи и багофиксы от разрабов объединяются через pull(merge) requests (читайте про них первые пару разделов тут). Кстати, у Ш++ есть отдельный мини-курс по гиту.

Тестирование

"Мы получили то, что хотели?" — тут мы тестим на дефекты и недостатки. Исправляем их, пока продукт не соответствует оригинальным спецификациям.

Грубо говоря, мы хотим добиться того, чтобы код соответствовал требованиям.

Тестить можно вручную, можно писать разные виды автотестов (загуглите про юнит-тесты, интеграционные тесты, т.д.). Иногда на фирме есть целые QA отделы (с тестировщиками разного уровня).

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

А иногда пользователей продукта «заставляют быть тестировщиками» (т.е. выкатывают недострой в прод, скрещивают пальцы, и ждут криков. Если воя не наблюдается значит критических ошибок нет, ага).

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

Деплой (Запуск, разворачивание) — Deployment

"Тем, что мы сделали, должны начать пользоваться" — надо запустить разработанный продукт, чтобы реальные пользователи начали пользоваться. Обычно это установка на серверах, или в kubernetes кластерах (не гуглите), или заливка приложухи в app store. Для того чтобы разворачивать инфраструктуры, существуют даже специальные проекты типа terraform (тут описываются все ресурсы, от серверов до доменных имен, и терраформ это все поднимает в облаках автоматически и связывает друг с другом)

Многие организации вдобавок выбирают поэтапный деплой — сначала разворачивают продукт в тестовых средах, но где можно его полностью испытать с пользовательской точки зрения (testing / staging среда).

Хорошо когда любой разработчик получает возможность легко развернуть часть инфраструктуры у себя на машине. Сейчас очень любят docker для этого. Не шарить докер для веб-разработчика (бекендщика) — это значит быть неспособным к более или менее организованной/взрослой разработке в команде.

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

Дополнительно — Поддержка разработанного продукта

"Давайте доводить продукт ближе к тому что мы реально хотим" — продукт сталкивается с реальным миром, находятся баги и запрашиваются фичи. Некоторые команды предпочитают делать продукт в режиме: сделаю все как договорились, ты (заказчик) одобришь, и тогда отдаю код/документацию/доступы и пока-пока 🖖. В других случаях договариваются, что разработчик не исчезнет, и будет поддерживать продукт. Даже часы наперед резервируют и оплачивают, чтобы у разработчиков было время.

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

Примеры/типы SDLC

Основные:

  • Waterfall (водопад) — старейшая и прямейшая модель. Заканчиваем одну фазу, и начинаем следующую. Каждая фаза имеет «мини-план» и впадает в другую.
    Проблема в том что мелкие детали могут задерживать весь процесс.
    Все ругают waterfall.
  • Agile (читается Эджайл) — разбивает продукт на циклы и доставляет продукт быстро. На каждом цикле что-то релизиться (release, релиз конечного продукта), собираются отзывы которые влияют на следующие версии продукта. Возможный минус — что зависимость от пользовательского фидбека может привести к тому что продукт уйдет не в ту степь.
    ☝️ Весь мир за Agile, стыдно не знать что такое Agile.
  • Big Bang (Большой взрыв) — высокорисковая модель, когда все ресурсы кидаются на разработку, без анализа потребностей. Хорошо для маленьких команд.
    … 😈 потому что мы хотим блин код писать, а не это вот всё!

Ещё немного для теоретиков:

  • Iterative — эта модель настаивает на быстрых циклах. Быстро и дешево создаем версии, быстро тестируем, быстро исправляем и постоянно делаем лучшие и лучшие версии продукта. Такие темпы могут быстро съесть ресурсы, если не следить за этим.
  • V-Shaped (в-форме-буквы-V) — похож на Waterfall, но тестирование происходит на каждом шаге. Проблема опять-таки в возможности возникновения блокировок.
  • Spiral (спиральная модель) — самая гибкая из всех, похожая на итеративную модель. Идет через планирование-дизайн-разработку-тестирование опять и опять, с постепенными улучшениями на каждом витке.

Вот еще одна рандомная статья по этому поводу, там упоминается важное слово «Scrum».

Преимущества SDLC

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

Что можно сделать неправильно и сделать себе лишь хуже с помощью SDLC? Не слушать потребности заказчиков, пользователей и вообще любых заинтересованных сторон — приведет к плохому пониманию требований к результату.

SDLC будет работать если следовать тому что было описано 🙂
и всем этапам.
(интересно, как часто следуют всем этапам?)

Итоги

Умные люди поняли, что если хочешь сделать норм продукт, то надо подходить к этому основательно, постепенно и прислушиваясь ко всем участникам на всех этапах, а не сразу кодить и не сразу всё кодить и не сразу идеально кодить.

Если программист/менеджер не воспринимает эти этапы и не общается на таком языке, то его ориентированность на общий для всех результат — сомнительна.