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-компаний

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

IT-СловарьITHR & IT-РекрутингТехнологии IT-сорсинга
4 января, 2022

Golang. Где искать разработчиков и сколько они стоят?

В ноябре 2021 года, языку программирования GO исполнилось 12 лет. Название GO, язык получил как производное от материнской компании Google, но позднее, чтобы не пересекаться с еще одним языком программирования “Go!”,…
IT-ПродажиСобес IT-Sales FAQ
4 января, 2022

ТОП-9 вопросов на собеседовании IT-Продавца | Отвечает Юрий Сорокин

Что сложного в том, чтобы пройти собеседование на должность IT-Продавца? - Не скажите. К сожалению, те товарищи, которые должны продавать лучше других: it-рекрутеры и it-продавцы, постоянно допускают грубейшие ошибки, как…
IT-ПродажиIT-СловарьITHR & IT-РекрутингЛикбез для IT-SalesТехнологии IT-сорсинга
4 января, 2022

Embedded system. Что это? Почему так востребовано?

АМбЭдет или ЭМбэдед. Только не скажите - эмбед, как это делает большинство.  Встраиваемая, или встроенная, система (Embedded System) ― это микропроцессорная вычислительная система, являющаяся модулем какого-либо устройства и предназначенная для…
IT-МаркетингIT-ПродажиOutbound MarketingКопирайтинг в ITЛидогенерация в ITЛикбез для IT-SalesТехнологии IT-продаж
17 декабря, 2021

Onepager. Коммерческое предложение-одностраничник для IT. Что в нем?

Коммерческое предложение в IT нередко нужно еще на этапе до квалификации клиента, когда клиент делает запрос на продукт или услугу, но мы решение о сотрудничестве еще не приняли и нам…