Методология разработки на недельных проектах

Код писать можно разными способами. Можно попытаться заранее распланировать каждую функцию, а потом заполнять их кодом. Можно сделать только “каркас”, минимальную версию, а потом добавлять туда фичи. Методология разработки ПО – это система, которая определяет, как писать код, как определять справляетесь вы или нет, как контролировать ход развития продукта.

Зачем читать эту статью?

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

Чего в статье не будет

• Подробного разбора всех методологий разработки и всех тонкостей Agile
• Простого TODO как организовать командную разработку. Это сложная тема, в одну статью не уместишь

Давай уже скорее про Agile!

Вы наверняка много раз слышали слово Agile, и в этом разделе речь пойдёт именно о нём. Но чтобы понять чем он так хорош и почему он на слуху, нужно сначала разобраться в его предке, Waterfall.

Waterfall

До Agile одной из самых популярных методологий был waterfall. Эта методология как бы напрашивается сама собой и основная её идея очень проста: сначала планируем разработку в мельчайших деталях, а затем уже начинаем писать код.

На схеме “водопад” выглядит так:

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

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

Самый простой и понятный пример waterfall, который приходит в голову — это выбор вуза. Вы долго и мучительно выбираете вуз и направление обучения, а затем, когда выбор сделан, учитесь в нём 4 года. В этой же аналогии легко понять, почему этот подход называют ерундой: не понравилось выбранное направление? Надо было выбирать лучше, поменять уже нельзя! Хочешь поменять — начинай с самого начала. Отсюда и название: водопады не текут вверх по течению, вы не можете поменять требования на этапе написания кода.

Разговоры о тяжеловесности и неповоротливости waterfall велись очень долго. В процессе появлялись другие системы ведения разработки, в том числе в 90-е появился целый ряд более простых и лёгких методологий разработки, но больше всех отличился Agile.

Agile

Agile — буквально переводится как “гибкий”, и в русскоязычной литературе фигурирует как Гибкая методология разработки.

Рождение Agile — это принятие его манифеста, текст которого точно стоит прочитать лично, документ совсем небольшой. Это и есть весь Agile, который является общепринятым. Позже он оброс практиками и литературой разных авторов, которые старались следовать принципам манифеста в своих компаниях. Но не всё что про Agile им является, читайте такую литературу с осторожностью, оглядываясь на основной документ — манифест.

Из-за того, что сам манифест — это в первую очередь “фундамент”, но не готовый “дом”, многие следуют ему по-разному. Есть сложные схемы следования этой методологии, я же пользуюсь самой минимальной и простой, как мне кажется на данный момент. И делаю я это не просто так, а следуя одному из правил манифеста:

Простота — искусство минимизации лишней работы

В дзене питона, кстати, есть то же самое правило, но чуть другими словами:

Simple is better than complex.

Как я следую Agile: пример от автора

Когда мне хочется начать пет-проект, в первую очередь я пытаюсь устаканить общие вопросы: кто им будет пользоваться, какая от проекта польза, как о нём узнают и т.д. Так я закрываю риски, что приложением никто не будет пользоваться. На недельных проектах обычно все эти вопросы уже решил за вас заказчик, и беспокоиться об этом не нужно.

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

Так вы сможете понять, что пользователям реально важно. Часто получается так, что какая-то фича казалась вам очень важной, но на деле о ней никто не говорит, она никому не нужна.

Далее вы составляете план развития продукта на шаг вперёд: какие фичи вам нужно добавить как можно скорее, чтобы пользователи стали чуть счастливее? С каких из них вы получите наибольшую пользу за минимальный бюджет?

И так, итерация за итерацией, продукт будет развиваться далее.

Наивысшим приоритетом признается удовлетворение заказчика за счёт ранней и бесперебойной поставки ценного программного обеспечения, п. 1 Манифеста Agile

Критика Agile

Приведу прямую цитату из Вики:

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

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

Эта критика не актуальна для недельного проекта, в нём нет никакой “долгой перспективы”, так что с ней зафакапиться сложно. Если не хочется факапиться с этим и далее, стоит учитывать долгосрочную перспективу при принятии всех важных технических решений в продукте. Например, при выборе “flask или django” можно сразу выписать плюсы и минусы обоих фреймворков относительно продукта, который хочется получить в итоге. Принятие ответственных технических решений обычно требуют от сениоров. Новичкам и джунам на проектах стоит сконцентрироваться на краткосрочной пользе для MVP.

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта, п. 9 Манифеста Agile

Пример планирования в краткосрочной перспективе

Agile не исключает планирование. Он лишь предлагает не писать ТЗ на 400 страниц, а сфокусироваться на получении минимальной версии продукта на старте.

Если у планирования нет никакого результата, кроме потраченного времени – это не планирование, а прокрастинация. Если вы хотите что-то спланировать – определите, что будет являться результатом этого планирования: Excel-таблица, схема БД в dbdiagram? Заранее подумайте, как я пойму, что я выполнил задачу планирвания?

Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды, п. 6 Манифеста Agile

Приведу пример краткосрочного планирования:

Я хочу написать чатбота. У меня на выбор 2 библиотеки: python-telegram-bot и aiogram. Результат планирования очевиден: я закончил планировать, когда я выбрал, какой библиотекой мы будем пользоваться.

По первой много туториалов, есть примеры использования прямо в репозитории. По второй тоже много туториалов и примеров, но писать надо будет на асинхронном Python, которым моя команда не владеет. Это даст возможность оптимизации бота под огромные нагрузки в далёком будущем. Но до проблемы высоких нагрузок ещё пара лет, и все эти пару лет мы будет двигаться в несколько раз медленнее из-за выбора в пользу асинхронности.

Вывод: стоит взять синхронную python-telegram-bot, чтобы двигаться быстрее. Это поможет сдать MVP быстрее и куда быстрее внедрять новые фичи.

Прочитал, хочется подробностей! Что ещё почитать?

Все статьи ниже будут продолжать идеи, о которых мы говорили здесь. Но в них будут более подробно раскрыты отдельные пункты манифеста Agile, а также будет куда больше уже конкретных примеров из жизни.

• Не знаешь что выбрать — спроси у заказчика
• Меньше — значит больше