Как человек, который процветал в подпольной индустрии, которая полагалась на тесные связи и глубокие отношения, одной из самых больших проблем в моем переходе к карьере в веб-разработке была групповая динамика и работа с командой, назначенной кем-то другим.
Как вы, возможно, знаете, быть веб-разработчиком-самоучкой может быть здорово по многим причинам. Однако вы не можете научиться работать с другими, не сотрудничая с ними на самом деле. Этот пост посвящен моему первому групповому проекту и первым шагам на пути к обучению гибкой разработке программного обеспечения.
Одним из главных мотивов моего участия в учебном курсе по кодированию в UC Berkeley extension было изучение веб-разработки с единомышленниками, изучающими одни и те же концепции в одно и то же время. После первых нескольких недель создания фундамента в HTML5, CSS3, JavaScript и jQuery нас втолкнули в наш первый групповой проект.
После назначения проекта и команд все казалось беспорядочным и неорганизованным. Гигантский беспорядок на доске идей разной сложности. Мы устроили вечер для мозгового штурма и обсуждения личных целей проекта. Вскоре мы стали действовать в рамках принципов гибкой разработки, ставя людей выше процесса и инструментов. Мы выслушали каждого члена группы и коллективно определились с идеей для нашего приложения.
После согласования идеи мы начали работать над пользовательскими историями. В нашем случае мы были и заказчиком, и разработчиком. Переговоры по контракту происходили среди нашей команды, как и сотрудничество с клиентами. Каждый разработчик был также заказчиком и наоборот. Предлагая желаемую функцию для приложения или оценивая возможные функции, мы смогли работать вместе как команда, чтобы разработать функции, необходимые для нашего MVP (минимально жизнеспособного продукта).
Вскоре после завершения наших идей и начала разработки работающего программного обеспечения мы столкнулись с проблемами производительности, связанными с нашими вызовами API. Чтобы вернуть желаемые результаты, нам пришлось сделать несколько вложенных вызовов API, что значительно замедлило время ответа. Это заняло слишком много времени, и вместо того, чтобы следовать нашему плану, мы отреагировали на изменение. Мы решили развернуть и изменить нашу идею, чтобы реализовать меньше вызовов AJAX. Это изменение устранило некоторые первоначальные функции, которые мы планировали затруднить, но решение помогло улучшить взаимодействие с пользователем.
Как только мы разобрались с функциями, мы могли начать работу над поставкой работающего программного обеспечения. Нашей целью было не создание документации. Мы были сосредоточены на создании рабочего продукта для наших пользователей. Мы использовали доску проектов, чтобы организовывать и назначать задачи, а также запрограммировали различные части приложения для своевременной доставки.
Благодаря регулярному общению с моей командой, такому как стендапы и работа в непосредственной близости, я узнал, что тесные связи и глубокие отношения действительно можно развивать в команде, назначенной кем-то другим. Мои самые большие проблемы — это мои самые большие возможности для обучения. Я с нетерпением жду возможности узнать больше об гибкой разработке программного обеспечения и внедрении ценностей и принципов в мой рабочий процесс.
Если вы хотите ознакомиться с проектом команды, его можно найти здесь:
