Рубрика «экстремальное программирование»

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

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

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

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

О плюсах парного программирования - 1

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

Парное программирование

Мне кажется, чтобы просто объяснить, как устроено парное программирование, можно привести в пример раллийные гонки. Там есть водитель (драйвер) и штурман (навигатор). Водитель сосредоточен непосредственно на управлении автомобилем. Штурман же контролирует на каком участке мы сейчас едем, и подсказывает пилоту о предстоящих поворотах и трамплинах.

Так же и в парном программировании.
Читать полностью »

Разработка программного обеспечения — это труд, который требует своевременного принятия правильных решений. CTO, архитекторы, тимлиды и сами разработчики регулярно делают выбор в пользу тех или иных инструментов, платформ и фреймворков.

Но все принимаемые решения нужно как-то «синхронизировать». Один из резидентов Hacker News отметил, что ему приходилось наблюдать за тем, как пяти сотням разработчиков в одной крупной компании разрешили самостоятельно принимать некоторые решения в «отрыве» от команды. По его словам, это был хаос. И хотя команда начала работать быстрее, она двигалась в никуда, потому что позднее возникали проблемы на этапах поддержки ПО.

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

Поэтому мы решили начать серию постов о «гибких» методологиях, чтобы еще раз рассмотреть их особенности, сравнить варианты и помочь вашим компаниям оптимизировать процессы. Сегодня мы говорим о Scrum, канбан и экстремальном программировании.

«Гибкая разработка»: кратко о методологиях Agile - 1Читать полностью »

image

С тех пор как я начал выполнять обязанности системного архитектора, мне чаще приходится рисовать прямоугольники и стрелки, чем писать программный код. С этим можно было бы бороться, например, бессонными ночами участвовать в проектах с открытым исходным кодом, создавать подтверждения осуществимости концепции и демонстрационный код, но и там тоже нужно рисовать прямоугольники, чтобы продемонстрировать архитектуру. Эта статья посвящена визуализации обмена сообщениями в распределенных системах, сервис-ориентированной архитектуре (SOA) и микросервисным приложениям при использовании методологии разработки agile (этот термин потерял свое значение, но более подходящего в данном случае нет).
Читать полностью »


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