Управление разработкой *

Привет, Хабр!

Сегодня я расскажу как с помощью DevOps-практик не только не помочь, но и навредить проекту.

DevOps родился для того, чтобы команды разработки и поддержки работали эффективно и слаженно. Но иногда использование его практик может привести к реальным провалам.

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

Привет. Меня зовут Инга, и я работаю в digital-агентстве Alente.

Мы занимаемся разработкой и продвижением сайтов. Фронт-офис компании состоит из менеджеров, которые заправляют коммуникацией в проектных командах, с клиентами и между ними. Но, помимо этого, в перечень работ любого нашего менеджера, будь то продаван, аккаунт или производственник, входит объяснение всяких непонятных для клиента терминов и в целом добавление прозрачности всем процессам, которые мы как специалисты осуществляем в своей работе.

Одной из самых тёмных и непонятных тем для наших клиентов (текущих и потенциальных) была оценка временных затрат на разработку сайтов.

Стоит сказать о том, что мы в Alente всегда делали относительно небольшие коммерческие проекты: корпоративные сайты, интернет-магазины и несложные веб-сервисы. За 12 лет привыкли работать по фиксированной оценке, так как задачи стали более-менее типовыми. Мы сделали калькулятор с вилками по оценкам этапов и считали всё по нему — и, как правило, попадали в эти оценки. В калькуляторе были типовые блоки, например «отзывы», «страница с каталогом товаров», «авторизация по электронной почте» и прочие.

• Jeff Dexter — руководитель Flight Software and Cybersecurity в SpaceX
• Josh Sulkin — software design lead в Crew Dragon
• Wendy Shimata — отказоустойчивость и безопасность для Dragon
• John Dietrick — разработчик софта для Demo-2
• Sofian Hnaide — Crew Displays software для Demo-2
• Matt Monson — работал для Dragon, а теперь разработчик софта для Starlink

Какую самую безумную/невозможную вещь руководство (ака Илон) просило вас сделать?

Катастрофа случилась неожиданно, когда я пришёл в магазин за продуктами 12 октября 2021 года, и обнаружил, что моё приложение в смартфоне, вместо того, чтобы приветливо встретить меня и показать номер моей карты продавцу, а мне, количество денег на балансе, предложила мне заново зарегистрироваться...

Изменения произошли после очередного обновления ПО, казалось бы, ну что там такого может случиться? Пришлось совершить покупку без карты и попробовать "вылечить" проблему.

Попытка 1. - зарегистрироваться

Ну ок, давай зарегистрируемся снова, привязка по телефону, должно всё восстановиться. Нажимаем кнопку, получаем код и... ПО предлагает активировать старую карту или получить новую, виртуальную, дальше не пускает...

Лезу в сумку, нахожу карту, ввожу номер, результат: "Ваша карта уже активирована, ничем не можем помочь, идите в поддержку, она поможет."

Ну ОК, Пятёрка предлагает воспользоваться поддержкой с помощью WhatsUp, по идее удобно, не надо держать у уха, сообщения сохраняются и т.п. одни плюсы в общем. Мучаюсь с меню робота, зову оператора, пишу сообщение в поддержку, описывая проблему и.... "Ждите ответа." Это было в 10:26 утра, в 14:37 оператор ответил, "Дайте Вашу дату рождения и последние числа номера карты", Я не мог смотреть на телефон в это время, работа и всё такое, открыл через 5 минут в 14:42, однако, оператор уже попрощался со мной и даже попросил оценить качество обслуживания.

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

Все стартаперы (и не только они) сталкиваются со стандартной проблемой развития проекта - добавление нового функционала, который заранее не был заложен. Причины тому могут быть самые разные - как недостаточно детальное планирование при составлении ТЗ, так и объективная ситуация поступления новой информации, на которую надо оперативно реагировать. Выходов из затруднительного положения традиционно два - упаковка новой функции в условно-свободное место старой архитектуры или полная глубокая переработка программной и/или аппаратной части.

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

Приехали артисты в Японию, все написали в райдере, а про розетки забыли. А розетки там другие. Спрашивают «а есть переходники?» Японцы занервничали, забегали, начали боссам звонить. Прошло двадцать минут, возвращаются, говорят: «$2000 и мы снабдим все переходниками». Администратор плюнул, пошел в соседний супермаркет, купил переходники по $10 за штуку.

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

Отличный сборник “лучших практик” в инженерной культуре современных айти компаний. Автор работал в Uber, Skyscanner и Skype в Амстердаме - прим.пер.

Эти 12 вопросов могут помочь понять, на что внутри похожа айтишная компания; и, что особенно важно, об этих вещах очень редко пишут в описаниях вакансий.

Многие компании успешно внедрили практики DevOps в свой инженеринг. Мы в SHARE NOW сделали также. Команды в компании ответственны не только за разработку программ, но и за то как эти программы попадут в продакшен, и как они будут обслуживаться. You build it — you own it.

Остается вопрос — как узнать что мы на правильном пути? Как измерить DevOps? Здесь нам и помогут DORA метрики.

Регрессионное тестирование играет важнейшую роль в разработке продукта и считается непростой задачей. С этим трудно не согласиться, когда вы тестируете то, что уже было протестировано, а потом тестируете это снова. Термин «регрессия» ассоциируется у членов команды с большими усилиями. Мы знаем, насколько головоломным и вместе с тем незаменимым может быть регрессионное тестирование для процесса релиза и спрашиваем «Приведет ли невыполненное регрессионное тестирование к неудовлетворительному результату?» и «Нужно ли проводить регрессионное тестирование, если программа без ошибок – это недостижимая цель?» Что ж, ответом будет «Да! Регрессионное тестирование нужно проводить регулярно».

Что подразумевается под регрессионным тестированием?

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

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

«Lagom är bäst» гласит шведская пословица — «нужное количество лучше».

Лагом — это практически то, что и в финском «Sopivasti» — «в самый раз», a в норвежском «Passelig» — «подходящий, соответствующий».

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

Сегодня ты стал лидером команды. На тебя свалилось огромное количество обязанностей и встреч, от разработки ты потихоньку уходишь. Начало всегда воодушевляет. Утопая в задачах, встречах, обязательствах ты находишь романтику, ты делаешь свою работу хорошо (тебе так кажется).

Но нет, не так хорошо ты выполняешь свою работу. Спринты не закрываются, таски льются рекой, два seniora объявили друг другу войну из PR, а менеджеры решили пойти войной на тебя, объявив тебя виновником всего этого беспорядка. И вот очередное утро, дейли, и после чашки кофе ты задаешь себе вопрос: "А эффективен ли я и моя команда?"

Как он мимо анализа пройти не смог...

Япония... Свет из окон широкими полосами освещает длинное помещение. Цех по сборке телефонных аппаратов. Вдоль стен стоят столы, над каждым склонился работник, каждый что-то делает, но от нашего взора это скрыто ссутуленными спинами. У некоторых на столах стоят дополнительные лампы и увеличительные стёкла на штативе. В конце длинного помещения у стены лицом к нам сидит японец с барабаном и не быстро, но с чёткостью метронома отбивает ритм. Все работники к нему привыкли и не замечают его, но тем не менее каждый удар барабана проносится по нервной системе и вплетается в движения. Каждый делает что-то своё, но общий ритм придаёт всей деятельности гармонию. Работа делается так же ритмично, в ней нет места для пауз и размышлений о бренности бытия. Всё подчинено ритму.

В компании «Арбис» используется стек, который давно оброс стереотипами и предрассудками — это 1С:Платформа. Более того, у большинства 1С прочно связана с бухгалтерией. И, хотя в Арбис программный продукт вообще с ней не связан — это облачное решение, сервис на 1000 пользователей — опытных спецов по 1С для него просто нет. 

И в довершение, компания базируется в Архангельске, где есть утечка кадров в большие города и нет рынок вакансий в принципе небольшой. Даже хуже. Процветает хантинг сотрудников, потому что Абрис — единственная компания, которая воспитывает и учит специалистов по 1С.

Где искать людей? Компания сделала ставку на джунов. Об этом на конференции TeamLead Conf 2021 рассказала Маргарита Маковеева, которая каждого сотрудника в своем отделе выращивала с нуля. И сегодня мы опишем подробности ее решения. Видео ее выступления можно посмотреть здесь.

В данном посте мне хотелось бы поделиться списком книг, которые (по крайне субъективному мнению) являются полезными и весьма практичными для Engineering Manager’а. При этом акцент хочу сделать именно на современных книгах (выпущенных в последние 5-6 лет). Под Engineering Manager’ом, в моем вольном определении, будем понимать бывшего инженера, ставшего руководителем, решающего как технические (например, внедряем RabbitMQ или Kafka), так и административные вопросы (например, план обучения новичков, сколько еще нанять разработчиков и каких и т.п.). Под такое понятие могут подпадать Tech Lead, Team Lead, Project Manager.

• цель грума,
• необходимый минимум,
• уточнение требований и контекста,
• типичные этапы,
• особенности при доработке механик.

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

Но реалии таковы, что удаленка стала must have для найма. И как тогда контролировать? Что выбрать, чтобы наблюдать за сотрудниками - системы трекинга времени, средства трансляции рабочего стола?

А если мы скажем, что ничего? Не надо тратить ресурсы на лишний контроль. И деньги сэкономите, и людям поможете раскрыться. 

Под катом рассказываем, как это у нас работает уже более 5 лет.

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