fbpx

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

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

Сегодня поговорим о некоторых из них. Это может здорово пригодиться вам на собеседовании.

Присоединяйся к школе HRPR в Telegram-сообществе IT-рекрутеров и в соцсетях

Допустим такую грубую классификацию в подходах к разработке:

  • классические (пришел менеджер, раздал всем задачи, каждый отвечает за свою задачу, пилим, допиливаем, идем за новой);
  • гибкие (пилим командой, обсуждаем, эффективность команды зависит от эффективности каждого игрока).

Гибкие методологии можно разделить на:

  • бережливые (избавляемся от «мусора» — все, что не добавляет ценности продукту) и
  • экстремальные (плотно взаимодействуем с клиентом на каждом этапе).

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

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

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

Преимущества парного подхода:

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

Недостатки парного подхода:

  • подходит не для всех задач, например, рефакторинг проще делать все же одному. Ну и сложные задачи, требующие глубокого погружения в контекст, тоже не подходят для парного программирования;
  • не всегда психологически комфортен для разработчиков, бывает тяжело убедить хотя бы попробовать. А если согласились, то в процессе могут даже подраться. И это не шутка;
  • утомляет, в таком интенсивном режиме невозможно проработать 6 часов, часа 2, ну 3 максимум;
  • успех зависит от уровня сплоченности команды и дружелюбности атмосферы в команде.

Парный подход применяется, если команда столкнулась с трудностями при решении задачи. Здесь очень хорошо подходит поговорка: «Одна голова хорошо, а две — лучше». Это вид мозгового штурма для программистов. Также парное программирование часто применяют на собеседованиях.

FDD (Feature driven development) — также один из гибких подходов к разработке ПО, который настроен на решение конкретной, уже известной задачи бизнеса, поставки реального рабочего функционала в заранее оговоренные сроки.

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

5 основных процессов FDD:

  1. Разработка общей модели.
  2. Создание списка функций на основе общей модели, разбиение на конкретные feature.
  3. Планирование (как будут решаться конкретные задачи, с помощью каких технологий).
  4. Непосредственно дизайн и разработка функций.
  5. Реализация разработанных функций.

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

Чтобы рассмотреть следующий подход — TDD (test-driven development), давайте пару слов скажем, что такое тестирование. Это одна из техник контроля качества кода. Тестировщики или разработчики пишут специальные тесты, эти тесты запрашивают выполнение определенной команды программой, команда выполняется (или не выполняется — тест не пройден), и если это выполнение соответствует желаемому результату, то тест считается пройденным.

TDD (test-driven development) — еще один гибкий подход создания ПО, при котором сразу пишутся тесты под определенный функционал, а потом уже пишется код, который способен пройти этот тест. Постоянно проводится рефакторинг (улучшение, причесывание кода для простоты внесения последующих изменений).

Основные процессы по TDD:

  1.  Написать тест для нового функционала.
  2.  Удостовериться, что этот тест не проходит.
  3.  Написать код, который способен пройти тест.
  4. Запустить тест, убедиться, что тест пройдет. Если нет, поправить код, повторить, пока тест не будет пройден.
  5. Рефакторинг.
  6. Перезапустить тест и убедиться, что рефакторинг ничего не сломал.

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

На занятиях в школе HRPR мы расскажем про методологии ведения проектов

Это не всегда нужно понимать досконально, но «узнавать на слух» не помешает. 🙂

01

ШАГ

Приходите на курс HRPR для IT-рекрутеров. Скоро старт новой группы. 125+ часов, 40+ занятий, 10+ спикеров из ведущих IT-компаний

Последнее из блога

Как правильно продавать проекты с Искусственным Интеллектом. Примеры и кейсы от SKademy и SalesolutionIT-ПродажиТехнологии IT-продаж
15.10.2024

Как подготовиться к продажам AI-решений. Зачем здесь OSINT?

В этой статье рассмотрим ключевые аспекты продажи AI-решений, принимая во внимание использование OSINT для исследования лидов
Примеры как правильно оформить свой профиль в LinkedIN и начать с него продаватьIT-МаркетингIT-ПродажиТехнологии IT-продаж
26.06.2024

Как упаковать свой профиль в LinkedIn и запустить с него первые продажи

Как новичку правильно оформить свой профиль в LinkedIN, сформировать клиентскую базу, настроить автоматизацию и запустить продажи на международный рынок
IT-МаркетингIT-ПродажиТехнологии IT-продаж
03.03.2024

SSI: карго-культ от LinkedIn или хоть на что-то влияет? Исследование + гайд в приложении

Говорят, что чем выше SSI, тем чаще посты пользователя показываются в ленте и тем выше его профиль оказывается в выдаче поиска LinkedIn, что важно при поиске работы, клиентов и соискателей.…
IT-МаркетингIT-ПродажиТехнологии IT-продаж
29.02.2024

Как продавать ИИ-решения? Практика построения системы продаж проектов с ИИ

Как продавать проекты, включающие в себя Искусственный Интеллект и Машинное Зрение. Практика и кейсы построения структуры AI Sales POD

Где вам удобнее общаться?

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

Телефон: +375 29 706 35 79, почта: hi@skademy.by

Или выберите удобный мессенджер: