Введение

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

Итак, что такое Agile?

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

Команда гибких разработчиков работает над своими программными проектами итеративно, в так называемых «спринтах». Спринты обычно представляют собой интервалы в 1–4 недели, когда команда разработчиков создает и поставляет работающее программное обеспечение. Таким образом, продукт намного проще улучшить, потому что вы получаете отзывы клиентов не реже одного раза в 4 недели. Если бы вы проинкубировали свой проект в течение 6 месяцев и доставили его прямо своим клиентам, они могут захотеть, чтобы вы что-то изменили. И эти вещи, возможно, были разработаны несколько месяцев назад, что значительно затрудняет возврат и изменение их.

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

Как вы можете его использовать?

Очевидно, что портфельные проекты, над которыми работают младшие разработчики, не предназначены для работы в течение 1–4 недель, но это не значит, что вы не можете работать над ними, используя принципы гибкой разработки. Что вы можете сделать, так это настроить несколько фиктивных спринтов в своем календаре, а затем итеративно показать приложение своему другу, чтобы он мог проверить. Таким образом, вы следуете принципу предоставления функционального программного обеспечения и получения обратной связи. Вы не можете получить обратную связь о приложении, не имеющем функциональности (если вы не покажете им свою IDE / текстовый редактор), поэтому это заставит вас привыкнуть к тому, чтобы делать достаточное количество интерфейса и серверной части для тестирования определенных функций.

Другой способ практиковать гибкую разработку - это работать с партнером над проектом и иметь так называемую стойку. Стенд - это когда вы и ваш партнер решаете, над чем они собираются работать в течение дня, и это довольно частое явление в agile-командах. Тем более что сейчас мы работаем полностью удаленно.

Заключение

Надеюсь, это дало вам представление о том, что такое гибкая разработка и как вы можете применить на практике некоторые из ее основных принципов. Я рекомендую реализовать это в вашем следующем проекте, чтобы вы могли стать полноценным agile-разработчиком! Спасибо за прочтение!

Https://en.wikipedia.org/wiki/Agile_software_development