Дорогие читатели, я видела, что на Хабр уже есть статья посвященная SDLC (и не одна), однако, этой статьей я хочу привлечь внимание ИТ-менеджеров, ничего об этом не знающих или знающих поверхностно. Напишу немного по-своему, так как я объясняла джунам, админам проекта и нетехническим специалистам, работающим непосредственно с разработкой программных продуктов. Было, что и на весь проектный офис рассказывала…

Да, такое встречается и нередко, что менеджер проекта, именно посвященного разработке ПО, не знает, что такое цикл разработки программного продукта (=SDLC), не понимает, зачем это знать, как с этим работать и к чему применять. К сожалению, это не только Джуны, мне встречались менеджеры уровнем и повыше, которые работают в командах разработки и не понимают их процессов. «Зачем, от этого же ничего не зависит» – говорили мне они…да ещё как зависит вообще-то.

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

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

SDLC (software development lifecycle)

SDLC (software development lifecycle) – это набор шагов, которые вся команда разработки проходит от идеи до выпуска продукта на рынок и передачи в сопровождение. 

Как оно в жизни бывает? Вот от бизнеса поступила какая-то инициатива. Допустим, нужно доработать API по процессу возобновления договоров партнерами со своей стороны. Я знаю, что это очень маленькая задачка, не проект, взяла её как пример специально. 

Что дальше делать?

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

Но добьется ли менеджер неупорядоченными действиями «от балды» итоговой цели – рабочий продукт, отвечающий требованиям заказчика и переданный в сопровод (=рабочий и поддерживаемый процесс пролонгации в существующем апи: методы работают, мы получаем/отправляем нужную инфо, партнер тоже её получает/отправляет)? Возможно, добьется. Но, что называется, сделав кучу ненужных, лишних, а может быть даже и вообще неправильных действий и потратив зря неоправданно много времени. 

Чтобы такое не сотворить, есть, например, SDLC. Имея о нем представление, мы можем заложить работы безошибочно так, чтобы итоговая цель была выполнена. Для этого он и придуман).

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

Важно, что каждая стадия ЖЦ разработки опирается на артефакт предыдущей стадии.

Этапность SDLC можно использовать и в рамках всевозможных проектных методологий: Waterfall, Agile (Scrum, Kanban, Lean, ….). 

В Waterfall SDLC завершается в точке «Сопровождение», процесс линейный. В Agile – SDLC идет по кругу до тех пор, пока не будет собран весь продукт: после разработки 1ой готовой части продукта и передачи её в сопровод, снова начинается планирование (следующей части) и тд по процессу. Всевозможные методологии и фреймворки в рамках SDLC расписывать не буду, их >50 вроде бы, можно самостоятельно погуглить.

Как можно улучшить доску Jira с помощью SDLC

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

Под каждый свой проект я адаптирую SDLC.

Раньше доска в Jira у моих команд делилась только на TO DO-IN PROGRESS-DONE. Но от этого не было никакой прозрачности, тяжело было понять, на каком этапе тикет, кто должен его брать следующий по процессу и постоянно приходилось управлять этим на планерках, следить, чтоб все как надо пошло.

Я решила поменять доску Jira и сформулировать её столбцы по этапам SDLC (добавив бэклог в 1 столбец, перед планирование). А to do-in progress-done выведя как метки к тикетам. Также в данном БП Jira по SDLC я заложила 2 точки входа непосредственно для заказчиков: отжатие кнопочки «согласование» на этапе проектирования (значит, что все доки прочитал, со всем согласен, отпираться не буду), без него тикеты не уходили в разработку; отжатие кнопочки «протестировано заказчиком» на этапе тестирования (значит, что мне все ок, жду в проде) – без нее тикеты не уходили на внедрение. 

Что мы получили от этого? 

• Избавились от километровых эксель-отчетов и долгих статус-собраний перед бизнесом, чтоб отчитаться: что? Где? В каком статусе? Почему так долго? Кто это делает?

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

• Увеличили лояльность заказчиков, потому как наладили прозрачность и заказчику понравилось участвовать самому в процессе, отжимая кнопочки и оставляя комменты там, где мы ему позволили)

Может быть я, конечно, не изобрела ноу-хау и вы давно все так и делаете) но, глядя на доски коллег, никто такое не сделал почему-то до меня в рамках 1 большой организации…

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