Всем привет! 👋

Продолжаем нашу рубрику #студентыGetAnalyst.
И сегодня хотим похвастаться отзывом Александры – студентки пятого потока программы «Дизайн REST API»🥳💥

⬇️⬇️⬇️

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

У меня была необходимость систематизировать и упорядочить знания по базам данных, API и Интеграциям. Знания были, но очень разобщённые 👀

💥 Курс помог собрать и упорядочить знания в целостную систему. Появилась экспертная уверенность и понимание работы с интеграциями.
Очень понравилась подача Екатерины. У неё есть талант преподавания: все четко и по делу.

В результате:
1️⃣ стала легко работать с базами данных на любом уровне (логическом, физическом),
2️⃣ поняла, как работать ЕR-диаграммами и связями (один ко многим — один к одному).
3️⃣ теперь могу прочитать и даже грамотно написать JSON.

Я уверенно приступаю к задаче, вижу, в какую сторону «копать» в рамках задачи и как взаимодействовать с разработчиками.

Планирую менять работу на более интересную. Уверенно чувствую себя на собеседованиях после курса.

🔥🔥🔥

P. S. Александра поделилась, что заинтересовалась программами GetAnalyst после просмотра обучающих видео на youtube-канале проекта.

Если тоже хотите углубиться в системный анализ, то подписывайтесь на наш yt-канал 👌

Как насчёт завершить рабочую неделю темой, про которую спрашивают на собеседованиях у аналитиков? 👀

Наверняка вы не раз натыкались на формулировки «методология разработки продукта», «гибкая разработка», «в рамках итерации» или «работаем по Agile» и так далее.
Причём эти фразы можно слышать не только в сфере IT – выстроенный флоу работы проник во многие сферы нашей жизни, начиная от маркетинга и заканчивая управлением операционной работой на заводах. А ещё про методологии разработки ПО часто спрашивают на собеседованиях и, что удивительно, не все верно называют отличия этих методологий. Короче, рассказываем!😎 #hardGetAnalyst


Любой продукт (не обязательно из сферы IT) разрабатывается путём прохождения определённых этапов от создания идеи и до конечной «продажи» продукта клиенту.

🥷: Пути – это различные успешные практики или методологии, следование которым позволяет предугадать качество конечного продукта.

Самыми популярными методологиями разработки ПО на текущий момент принято считать:
1️⃣ Водопадную модель
2️⃣ Инкрементальную модель
3️⃣ Итерационную модель
4️⃣ Гибкую модель.

Разберём каждую из методологий немного подробнее.

1️⃣ Водопадная модель (с англ. waterfall model)

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

🥷: Это значит, что пока не будет завершён этап аналитики, задача не может перейти на этап разработки, а пока она не будет разработана – невозможен переход на этап тестирования.

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

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

Если конечные требования к решению известны и точно не будут изменяться, водопадная методология разработки действительно сэкономит ресурсы компании на разработку. Но в реальной жизни риск изменения требований чаще всего есть всегда: аналитик не учёл некоторые моменты, заказчик «передумал» или приоритет задачи изменился и спустя время предыдущие требования становятся неактуальными.

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



2️⃣ Инкрементальная модель (с англ. incremental model)

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

На первом этапе полностью проектируется основная часть системы с базовой функциональностью. Затем система обрастает дополнительными полноценными возможностями или по-другому «инкрементами».

🥷: Отсюда и название методологии — инкрементальная.

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

🥷: Конечный продукт станет доступен пользователю только после реализации всех необходимых инкрементов в решении.

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


Продолжим с двумя другими методологиями в субботу, а в понедельник запустим КВИЗ! Ставьте 🔥, если ждёте!

А вот и суббота! 🥳

А значит продолжаем разбираться с популярными методологиями разработки ПО 🥷

И сегодня на очереди итерационная и гибкая модель.

⬇️⬇️⬇️

3️⃣ Итерационная (или итеративная) модель (с англ. Iterative Model)

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

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

🥷: Но есть ещё отличия.

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

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



4️⃣ Гибкая модель (с англ. Agile model)

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

🥷: Чаще всего это массивные проекты с большим набором возможностей и высокой неопределённостью в требованиях.

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

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

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

Самыми популярными направлениями в гибкой модели принято считать: Scrum, Kanban и Lean. Если хотите узнать о них подробнее – ставьте 👍, напишем пост про разницу этих направлений. Кстати, про это тоже спрашивают на собеседованиях! 👀

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


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

А ВОТ И КВИЗ 🥳 #quizGetAnalyst

Друзья, всем привет! 👋

В конце прошлой недели мы с вами изучили основные методологии разработки ПО. Пришло время закрепить полученные знания небольшим тестом (вы точно справитесь!) 🥷

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

Всем привет! 🙃

💻 Если хотите почувствовать себя немножко разработчиком и даже самостоятельно написать код под чутким руководством Екатерины — это ваш шанс! 💥

Уже в эти выходные собираемся и пробуем писать код на Java или Python (🥷: честно говоря, я за Python, потому что его у аналитиков спрашивают чаще).

А если не захотите писать, то в конце встречи научитесь его немного читать (а это тоже важный скилл!).

О дате и времени встречи сообщим дополнительно, поэтому ставьте реакции, кто пойдёт 👍

ПОБЕДИЛ PYTHON 🥳🥳🥳

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