составьте список важнейших инженерных подходов и практик

Инженерные практики Agile

Время чтения: 6 минут

Отправим вам статью на:

В последнее время в графе «сервисы» у большинства компаний-разработчиков программного обеспечения все чаще и чаще встречаются слова «agile development». Наша компания идет в ногу со временем, и поэтому внедрение методологий agile и waterfall не заставило себя долго ждать. Сегодня мы расскажем об инженерных практиках agile, об их полезности и удобстве использования.

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

Немаловажным фактором при внедрении практик является понимание преимуществ и возможностей того или иного инструмента, а также сложностей и специфики внедрения.

Нашей командой успешно были внедрены следующие инженерные практики agile:

Code Review

Ревизия кода, систематическая проверка исходного кода программы, позволяющая обнаружить и исправить ошибки, оставшиеся незамеченными. Эта практика позволяет разрабатывать более стабильные и качественные программные продукты. Данная практика была внедрена нами на основе инструмента Review Bord. Этот инструмент позволяет проводить ревизию кода после каждого изменения в версии продукта и предоставляет все необходимые возможности для этого.

Code Review особо хорош в применении, когда в команде работают новички. Более опытные программисты назначаются ревьюверами за остальными участниками команды. Раз в неделю или чаще ревьюверы смотрят код и вносят свои замечания и предложения по его улучшению. Таким образом, исходный код программы становится более структурированным и стабильным, что делает конечный продукт более стабильным и легким в сопровождении.

Until Testing

Code Refactoring

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

Build Automation

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

Continuous Integration

Данная практика направлена на выполнение частых автоматизированных сборок проекта с целью выявления и решения интеграционных проблем. Ее внедрение производилось на основе Hudson Continuous Integration Server, представляющий собой сервис сервера непрерывной интеграции со всеми необходимыми возможностями.

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

В разработке программного продукта самое важное — взаимодействие с заказчиком. Использование инженерных практик и подходов a gile подразумевает регулярную и довольно тесную связь с ним. Процесс создания продукта становится открытым и обсуждается на каждом этапе, поэтому исключена возможность того, что конечный продукт не будет в полной мере соответствовать ожиданиям клиента. Таким образом, заказчик и исполнитель берут на себя одинаковую ответственность за конечный результат, что свидетельствует о высокой профессиональной культуре обеих сторон.

Подпишитесь

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

Источник

Лучшие приемы и практики Agile для технических и нетехнических команд

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

Знаменитая методология была создана для разработки ПО. Поэтому практически все практики Agile применяются именно там. Однако это не мешает применять Agile и многим нетехническим командам.

Компании, которые не связаны с IT быстро обнаружили преимущества использования гибкого мышления и некоторых Agile-практик, которые могут помочь бизнесу достичь большего, принести клиентам максимум пользы и удовольствия, а также сплотить команду внутри.
С 2001 года Agile-принципы оформили в знаменитый манифест Agile, а сама методология стала стандартным процессом разработки ПО.

Каковы ключевые практики Agile сделали методологию столь известной и востребованной?

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

Список лучших практик Agile

Очередь задач

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

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

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

В управлении бэклогом определяющую роль играет собрание backlog grooming, во время которого представители Agile команды обсуждают детали бэклога продукта и готовят очередное планирование спринта.

Итерации

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

Клиентоориентированность

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

User stories

User stories включают описание, критерии приемки и оценку времени. Когда они слишком сложны, менеджеры продуктов разделяют их на более мелкие.

Agile-роли

Методология включает разные роли и, соответственно, разные их названия. Если обобщать, роли в Agile можно разделить по группам, включающим:

Value stream analysis

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

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

Timeboxing

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

Спринты продолжаются в соответствии с указанными таймфреймами. Обычно от двух недель до одного месяца. Scrum-митинги обычно продолжаются около 15 минут.

Ежедневные собрания

Например, Scrum meeting — это ежедневное мероприятие, короткая утренняя или дневная встреча, обычно организованная менеджером продукта или владельцем продукта. Длится 10-15 минут и требует присутствия Скрам-мастера и всей команды. Такая встреча организуется, чтобы:

Sprint demo meeting

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

Retrospective meeting

Речь идет о ретроспективе по окончательному итеративному развитию. Retrospective meeting рекомендуется посещать всем членам команды. Клиенты также могут участвовать.
Здесь обсуждаются возможности улучшения процессов, качества работы, используемых инструментов и т. д.

Тестирование

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

Burndown chart

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

Приоритизация требований

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

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

Планирование релиза

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

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

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

Этот список можно продолжать и дополнять другими интересными практиками. Однако какие же практики могут быть использованы нетехникеской командой?

Яркий пример — использование бэклога и приоритизация задач командой авиатранспортной компании Air Methods, которая специализируется на оказании скорой помощи.

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

Так команда пришла к Agile-практике использования и управления бэклогом и определению приоритетов. За визуализацию стали отвечать инструменты Trello.

На доске собираются запросы заинтересованных сторон, команда присваивают каждому зеленый или красный лейбл. “Зеленые” проекты можно выполнять сейчас, “красные” попадают в очередь.

Ежемесячно команда и заинтересованные собираются для определения новых приоритетов, голосуют и дискуссируют.

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

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

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

Источник

Философия рабочего процесса

4.7. Инженерные практики

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

Немаловажным фактором является понимание преимуществ и возможностей того или иного инструмента, а также сложностей и специфики его внедрения.

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

Code Refactoring. Это не просто техника. Благодаря развитию и распространению Agile рефакторинг стал полноценным техническим направлением деятельности. Refactoring предписывает осуществление изменений внутренней структуры исходного кода, которые не должны повлечь изменения в поведении программы. За счет применения Code Refactoring достигается упрощение структуры программного продукта и повышение скорости его работы. Это способ систематического приведения кода в порядок, при котором шансы появления новых ошибок минимальны. В сущности, при проведении рефакторинга кода вы улучшаете его дизайн уже после того, как он создан.

Как следствие получаем экономию на дальнейшем сопровождении и поддержке.

Build Automation. Это техника автоматической сборки исходного кода, выполнения тестов и развертывания программы на целевом ландшафте. Автоматизация позволяет повысить качество процесса разработки и поставки продукта. Результаты Build Automation не так очевидны бизнес-заказчикам системы, но за счет внедрения этой техники с технической команды снимается часть работы, после чего они могут направить освободившиеся ресурсы на более значимые для бизнес-пользователей активности.

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

4.8. Краткие выводы

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

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

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

Источник

Инженерные подходы и чеклисты: как не сойти с ума в хаосе задач

Привет! Меня зовут Олег, и я frontend-разработчик в Альфа-Банке. Я хочу рассказать вам немного философскую историю — про инженерный подход к разработке, про мою первую работу и грабли, которые я там собрал, про то, почему чеклисты очень важны (и спасают жизни).

А еще про то, как продолжать продуктивно работать и не закопаться во множестве мелких и не очень задач.

Всё началось с хаоса.

На моей первой работе (не Альфа, нет) меня как-то взяли и сразу бросили на амбразуру, сказали, парень, теперь ты делаешь CRM, комп вон там. Что делать и как делать — я вообще не понимал. Что обычно делают в такой ситуации? Правильно — бегут к коллегам и начинают уточнять у них, как тут на сервак код доставить, как дела с гитом, какие практики используем, а какие нет, и прочее. Мне такой подход помог, и я постоянно советую делать это и другим. Спрашивайте, задавайте вопросы, даже если кажутся вам очевидными, уточняйте то, что надо уточнять. Это нормально. Ненормально — не спрашивать.

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

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

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

Ладно, это лирика, давайте поближе к практике.

В жизни

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

Но это простой пример с тремя переменными. Само собой, в работе часто бывает иначе. И сильно иначе. Процесс усложняется, когда у вас появляются бэкенд, документация, CI/CD и прочие важные штуковины.

И тут уже не получится сходу взять и сказать, какой процесс самый медленный и с чего стоит начинать. Здесь процесс оптимизации самого медленного этапа будет выглядеть так:

Может звучать сумбурно, поэтому распишу подробнее.

Что делать, есть у вас есть какие-то параллельные задачи, которыми вы заняты?

В этом случае самый длинный маршрут вы будете искать по дням суммарно. На картинке выше это примерно 6 дней. Начинайте с него, с этого самого длинного процесса. Получается, что вы в этом примере будете улучшать бэкенд, потому что он занимает 4,5 дня. Это тоже не так сложно, но когда вы к этому приходите и начинаете так делать, замечаете, что жить становится проще.

Вернусь к примерам о своем рабочем хаосе. Мне прилетала куча задач и я ничего не успевал. Я понял, что имеется ограничение во фронтенде (то есть во мне), что проблема не в тестировщике, потому что он баги находит, а именно на моей стороне. Чтобы что-то с этим делать, я стал думать, как использовать это ограничение.

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

Сейчас я стараюсь делать не больше 2 задач параллельно (параллельно, а не одновременно). Раньше я мог дать тестировщику задачу и пойти делать следующую, но если тестировщик находил баг, мне приходилось делать чекаут, вспоминать и переключаться на то, какой код там был написан, а это тяжелее, чем кажется, когда ты часто переключаешься. Да и в целом переключение дорого обходится. Старайтесь не делать более 2 задач параллельно. 3 задачи это вот уже способ зашиться.

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

Ещё про ограничения

Само собой, ограничения можно расширить. В нашем примере — нанять еще одного фронта. Тоже логично, больше фронтов — больше задач они успеют сделать. Тогда ограничение перенесется в другое место.

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

Чеклисты

Чеклисты реально помогают делать жизнь проще. В моей работе сейчас очень помогает вот этот чеклист для Альфа-Банка, где довольно много этапов, которые надо пройти.

Чеклисты даже жизни спасают, я приведу небольшой отрывок из книги «Понимать риски. Как выбирать правильный курс»:

На заре авиации пилоты летали на самолетах, которые не были так оснащены техническими средствами, как в наши дни. Чек-листы стали использоваться в ВВС США только после того, как выяснилось, что бомбардировщик В‑17 – слишком большой самолет и не может управляться только одним человеком. В 2009 г., когда сразу после взлета из аэропорта Ла Гуардия у самолета US Airways рейс 1549 заглохли оба двигателя, пилоты выполнили все предусмотренные чек-листами действия в такой аварийной ситуации, включая и попытку повторного запуска двигателей. Бортпроводники, опять же в соответствии с чек-листами, строго следили за правильной подготовкой пассажиров к аварийной посадке. Подобные чек-листы – простой и недорогой инструмент повышения безопасности.

В медицине наблюдается другая картина. Ежегодно некорректное использование центральных венозных катетеров вызывает приблизительно 80 тыс. случаев инфицирования кровотока, и в результате около 28 тыс. человек умирает в реанимационных отделениях американских больниц. А те пациенты, которым удается выжить, проводят в реанимации в среднем дополнительно еще одну неделю. Общие затраты на лечение подобных инфекций оцениваются в 2,3 млрд долларов в год. Что может спасти этих людей? Более совершенные лекарства для лечения инфекций, более совершенные технологии? Ответ таков: совершенствование культуры ошибок.

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

1) вымыть руки с мылом;
2) обработать кожу пациента хлоргексидиновым антисептиком;
3) накрыть пациента стерильной простыней;
4) носить стерильную маску, шапочку, фартук и перчатки;
5) наложить стерильный материал поверх катетера после введения катетера в вену.

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

Проновост убедил администрацию больницы разрешить медсестрам останавливать врачей, если те пропускали какую-либо из предписанных пяти мер. Это революционное новшество нарушило иерархическую структуру, в которой средний медицинский персонал (преимущественно женщины) прежде не имел права давать указания врачам-хирургам (преимущественно мужчинам). Через год, на протяжении которого строго соблюдались эти инструкции, показатель инфекционного заражения кровотока у пациентов больницы снизился с 11 % до 0 (!). А в течение следующих 15 месяцев было отмечено всего 2 случая такого заражения. Только в одной этой больнице список инструкций предотвратил 43 случая заражения, 8 смертей и сэкономил 2 млн долларов.

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

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

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

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

Свой чеклист я отсортировал по действиям — 1 действие = 1 пункт чеклиста. Здесь главное тоже не упороться совсем сильно и не уйти в чеклисты ради чеклистов. «Сверстать страницу» — хороший пункт. «Сверстать контролы» — еще подробнее, поможет не забыть про контролы и их нюансы.

Почему просто кодить недостаточно

Тесты нужны. Но нужны не всегда. К примеру, делаете вы лендинг, один раз, и не планируете к нему потом возвращаться — тогда тут нет смысла очень сильно упарываться. Можно покрыть юнитами селекторы или использовать end2end, но юнит-тесты для остального это уже трата времени.

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

Допустим, у вас есть какой-то хороший скилл, например, работа с CI/CD. Дизайнер дал вам макет и ушел в отпуск, у вас возникла пара правок или вопросов, но пока он не вернется из отпуска, все, процесс стоит. Расширяйте свои скиллы, потому что если слабое место в процессе будет на стороне дизайна, ну зашивается дизайнер по ряду причин, вы сможете ему помочь. Это дополнительный набор знаний, но его можно осилить. Само собой, я сейчас не говорю о том, чтобы полностью и полноценно заменять специалиста, я про базовые навыки.

Выводы

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

Ну и список полезных книг:

Используете ли вы чеклисты, считаете их необходимыми? Если у вас какой-то свой подход к ведению или созданию чеклиста, поделитесь в комментариях, пожалуйста.

Источник