fbpx

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

Присоединяйся к HRPR в сетях

Допустим такую грубую классификацию в подходах к разработке:
– классические (пришел менеджер раздал всем задач, каждый отвечает за свою задачу, пилим, допиливаем, идем за новой);
– гибкие (пилим командой, обсуждаем, эффективность команды зависит от эффективности каждого игрока).
Гибкие методологии можно разделить на бережливые (избавляемся от “мусора” – все, что не добавляет ценности продукту) и экстремальные (плотно взаимодействуем с клиентом на каждом этапе).
Все подходы, заявленные в названии статье, относятся к условным гибким методологиям. То есть, они еще не являются подробно разработанными и описанными методиками, скорее, это профессиональные приемы разработчиков для решения конкретных, насущных задач. Давайте рассмотрим каждый из этих подходов подробнее.

Парное программирование – это вариант или одна из форм экстремального программирования (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 мы расскажем про методологии ведения проектов.

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

07

СЕНТЯБРЯ 2021

Старт группы HRPR. 125 часов занятий и подготовка вашего резюме для скорейшего входа в профессию.

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

hrpr school blogITHR & IT-Рекрутингвопросы на зачет
24 июня, 2021

SWIFT vs Objective-C: кто востребованнее?

Спрос на разработчиков iOS увеличивается с ростом количества пользователей мобильных устройств. Игры, приложения и другое программное обеспечение для Apple пишется на языках Swift и Objective-C. Рекрутер должен понимать, какой язык…
IT-МенеджментITHR & IT-Рекрутингвопросы на зачет
23 июня, 2021

Почему OKR удается внедрить не всем IT-компаниям?

Метод OKR (Objective and Key Results) — это один из способов управления IT-компанией, разработанный Джоном Дорром. В отличие от реалистичных метрик KPI, определяемых менеджментом, метод OKR предполагает постановку амбициозных целей,…
hrpr school blogITHR & IT-Рекрутингвопросы на зачет
17 июня, 2021

Xamarin для рекрутеров

Xamarin — это фреймворк платформы .Net, принадлежащий компании Microsoft. Он используется для разработки мобильных приложений на языках программирования C# и Xaml. Популярность получил благодаря своим кроссплатформенным возможностям, т.е. разработчик может…
hrpr school blogITHR & IT-Рекрутингвопросы на зачет
17 июня, 2021

Stack Overflow. Давайте поищем разработчиков там

В нашем блоге были статьи о том, как искать всех разработчиков на GitHub, как искать специалистов по машинному обучению на Kaggle, как искать дизайнеров на Dribbble и Behance, а сейчас…