Это рецензия на презентацию, которую я дал Джексон район и разработчики приложений встречается В августе 2019 года.
Программный процесс определен
Что такое «программный процесс», и нужен ли я/нужен один? По сути, это именно то, на что это похоже — процесс, который вы или ваша компания принимаете, чтобы создать, тестировать и выпустить кусок программного обеспечения. Так что, независимо от того, являетесь ли вы сольным разработчиком, работающим над побочными проектами дома или частью огромной команды в многомиллиардном бизнесе, вы реализуете какую-то форму программного процесса, независимо от того, понимаете ли вы это или нет.
Я начал работать в Kopis Mobile в декабре 2016 года. С тех пор мы сосредоточились на улучшении и оптимизации нашего программного процесса. Сегодня я собираюсь отвезти вас в путешествие, хотя эпохи программного процесса, через который мы прошли в Kopis Mobile, начиная с темных веков.
Темные века
Честно говоря, даже темный век был бы улучшением для нашего программного процесса — мы были больше похожи на пещерных людей сразу после обнаружения огня.
Нам было удобно с GIT и использовать его в командной обстановке. Мы использовали модифицированную схему разветвления потока GIT, чтобы обеспечить некоторую структуру в нашей среде GIT. И это было около степени нашего программного процесса в то время. Все остальное было немного беспорядочным: развертывающие ключи для приложений Android хранились на машине одного человека (я думаю, что они были резервированы на компакт -диске?) Много вопросов «Работа на моей машине».
В то время нас было шесть в команде инженеров, и мы были очень залиты. В большинстве проектов был один разработчик, ответственный за всю новую работу. Мы следили за развитием сроков, где наши приоритеты были установлены тем, какой проект имел ближайший срок. Это было напряженно, это повредило моральный дух (даже если бы мы не узнали его в то время), и у нас был плохой Фактор автобуса Анкет
Ренессанс
Для нас открытие, которое вызвало наш эпохи Возрождения, было гибким и схватками. Но это не было немедленным ударом. У нас было несколько попыток внедрения в реализации Scrum, прежде чем по-настоящему совершить его в конце 2017 года. Многие из наших «неудач» проистекают из убеждения, что традиционные гибкие и схватки не работали для нас. Вещи как:
- У нас было несколько продуктов и контрактов, над которыми мы работали, но только одна команда
- Наши результаты обычно были обязаны по контракту, а не управляемые клиентами
- Из -за нашего рынка у нас было ограниченное взаимодействие с клиентами, что затрудняло получение обратной связи и итерации
Эти проблемы почти не давали нам осознавать силу схватки. Многие из наших ранних трудностей вращались вокруг нас, пытаясь навязать наш процесс на существующие инструменты, которые дали нам много головных болей. Некоторое время мы использовали Jira, потому что другие в компании использовали ее, но это не сработало для нас в инженерии. Мы мигрировали в Gitlab для нашего репозитория и попытались использовать проблемы проекта для отслеживания функций, но это также не сработало для нас.
Общей проблемой было отсутствие видимости/поддержки команд по перекрестному продукту-помните, что мы были небольшой командой, работающей над несколькими проектами одновременно. Итак, мы пошли в старую школу, используя белую доску и липкие ноты с цветовой кодировкой для проекта. Это дало нам перекрестную доску Scrum Scrum, которую мы так хотели. И это сработало отлично, пока у нас не было, чтобы член команды ушел на дистанционную работу на три месяца на другой стороне страны. Таким образом, используя физическую плату в качестве прототипа, мы создаем цифровое решение, которое связано с экземпляром OpenProject, который мы начали использовать для планирования и хранения функций для будущей работы.
В то время как мы выясняли наши инструменты, выпущенные, мы также выясняли, как заставить реальную методологию Scrum работать для нашей команды. Мы начали с двух, а затем с тремя недельными спринтами, с полдня для планирования в начале и полдня, чтобы поделиться тем, что мы достигли с командой в обзоре, и обсудить, как все прошло в ретро. Некоторое время мы объединили эти два полдня в один длинный обзор/День ретро/планирования, который мы все решили через некоторое время, чтобы провести в конференц -зале вместе (компания, по крайней мере, обедала в те дни).
Возраст исследования
Поскольку вся команда наконец -то поняла, над чем работал все остальные в любой момент времени и куда мы, как команда. Наряду с этим пониманием пришло сознательное желание разрушить бункеры и обеспечить перекрестное обучение, где мы могли. Иногда это было неудобно, но это была определенно правильная идея. Поощряя людей работать над вещами, которые они не привыкли работать над тем, чтобы заставить нас изучать код друг друга и поделиться некоторыми из этих племенных знаний, которые присуща в проекте Silo’d.
Другим способом помочь перекрестному обучению и качеству кода было введение обзоров слияний. Ранее наш процесс состоял в том, чтобы внедрить функцию, проверить ее до тех пор, пока вы не были удовлетворены, а затем объедините ее в нашу разработку филиала. После того, как мы внедрили обзоры Merge, мы заблокировали разработку филиала, так что все слияния для разработки должны были пройти через обзор и получить одобрение другим членом команды, прежде чем быть отмеченным, как это сделано.
Хотя мы никогда не были бы полностью взаимозаменяемы — и это никогда не было целью — все в команде выиграли от того, что кто -то еще знал по опыту, через какие проблемы они сталкивались, и иметь кого -то еще в команде, чтобы отскочить идеи. Как и ранние исследователи, мы узнали больше о нашем мире и о проблемах и возможностях, которые он предлагал.
Промышленная революция
Поскольку мы продолжали наш рост и обучение, мы начали смотреть наружу от того, что делали другие компании и какие инструменты и процессы мы могли бы использовать в нашей компании. Это вызвало нашу промышленную революцию. Так же, как первая промышленная революция, которая вращалась вокруг перехода от товаров ручной работы к машиностроенным, наша промышленная революция включала автоматизацию многих утомительных задач, связанных с разработкой программного обеспечения. Поскольку мы уже использовали Gitlab для нашего репозитория кода, имело смысл, что наш первый крупный скачок произошел из -за обучения и реализации непрерывной интеграции Gitlab и непрерывной доставки (CI/CD).
Обычно при беге git push На вашей машине файлы отправляются в ваш репозиторий, и все — они просто сидят там. Но существует способ использовать команду магических работников робота для взятия кода, который вы совершили, создали свое приложение, запустили тесты и развернули его на ваш сервер или магазин мобильных приложений. Есть много разных поставщиков CI: Circleci, Jenkins, Travis CI и т. Д. Gitlab имеет встроенное решение CI/CD — даже их бесплатный уровень предлагает некоторый доступ к своим бегунам CI, которые могут создавать и проверять ваш код. Мы размещаем Gitlab в помещениях, поэтому со временем мы создали парк бегунов, чтобы построить все, от прошивки PIC до приложений для Android и всего, что между ними.
Это было единственное изменение, которое, как я считаю, оказало наибольшее влияние на улучшение нашего программного процесса, так как это помогло многим из наших проблем с темным возрастом. Сборки программного обеспечения должны были быть воспроизводимы на бегуне — не более », но это работает на моей машине». Если его нельзя построить с помощью чистого изображения CI, то это похоже на вас вообще не может быть построено. Развертывающие ключи и другие секреты хранятся в частных переменных, к которым есть только бегуны, к которым они нуждаются в них. Так много утомительных, повторяющихся действий автоматизировано, что позволяет вам сосредоточиться на более важных задачах.
Будущее
Наше путешествие по программному процессу далеко не завершено. Есть все еще болевые точки, о которых мы знаем, и другие, я уверен, что мы еще даже не рассмотрели. На данный момент существует две большие области улучшения, на которой мы хотим сосредоточиться — улучшение автоматического тестирования и качества кода, а также лучшие способы управления техническим обслуживанием кода и техническим долгом.
Ключевые выводы
- Нет никаких решений «Один размер» к программному процессу. То, что работает для нас, может не работать для вас точно, поэтому вам нужно выяснить, где вы находитесь, куда вы направляетесь и как вы хотите туда добраться.
- Разбейте бункеры — Это была одна из лучших вещей, которые мы сделали, чтобы помочь моральному духу.
- Инвестировать в автоматическое инструменты — Нет никаких причин, по которым вы должны подчеркнуть из -за ручной сборки и развертывания процессов в 2020 году.
- Потратьте время, чтобы документировать, разработать и усовершенствовать свой программный процесс — Как и в случае с непрерывным образованием, всегда есть чему поучиться и улучшить ваш собственный процесс программного обеспечения.
Без звука
Я надеюсь, что это вдохновило вас на то, чтобы взглянуть на ваш программный процесс, особенно если вы не задумывались о нем недавно или никогда (без стыда!). Где вы или ваша команда в своем путешествии по улучшению процесса? Что вы или ваша компания делаете, чем гордитесь или знаете, что вам нужна помощь?
Механическое фото трубопровода от Мартин Адамс на Неспособный
Изображение пещерных жителей из Spongebob Squarepants на Nickelodeon
Сило фото от Себастьян Грочович на Неспособный
Стрелковая доска фото из Силиконовой долины на HBO
Оригинал: «https://dev.to/sweenr/software-process-a-journey-through-history-nip»