Рубрика «гибкая методология разработки»

Все оценки сроков разработки ПО — ложь - 1

▍ Разработка ПО — это исследование

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

В разработке ПО мы не тратим время на задачи, решения которых знаем. Если решения уже существуют, мы добавляем в качестве зависимости пакет или библиотеку с этим решением, или копируем старый код, или делаем что-то ещё, на что требуются секунды, а затем можем переходить к следующей задаче. Почти всё время разработки тратится на новые задачи, ответов на которые мы не знаем. Часто они новы ужасно скучным образом, например, «как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?» Но именно из-за них эта ситуация отличается от всех остальных (или, по крайней мере, от тех, которые мы смогли найти) и именно это занимает всё наше время.Читать полностью »

Со временем в софтверной индустрии придумали несколько способов более быстрого и безопасного выпуска качественного кода. Многие основаны на идеях вроде непрерывной интеграции, непрерывной поставки ПО, гибкой методологии разработки, DevOps и разработки через тестирование. Все эти методологии объединяет одно: они позволяют разработчикам быстро выпускать код безопасными, небольшими, последовательными шагами.

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

В течение многих лет мы обновляли фронтенд Facebook трижды в день, используя простую стратегию веток master и release. Инженеры избирательно выбирали из ветви master изменения в коде, которые прошли ряд автоматизированных тестов, для включения в ветвь release, откуда происходили ежедневные обновления. В целом, таким способом выбиралось от 500 до 700 изменений в день. Раз в неделю мы отрезали новую ветвь release и собирали изменения, которые не отобрались в течение недели.

Быстрые релизы огромного масштаба - 1
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js