Инженерная зрелость. Исследование практик и триггеров
Почему одни команды релизят предсказуемо и без героизма, а другие тушат пожары на продакшене каждую неделю? Мы решили выяснить, какие инженерные практики превращают разработку в систему с понятными процессами и предсказуемыми результатами. Исследование 100+ респондентов.
https://habr.com/ru/articles/963202/
#инженерная_зрелость #процессы_разработки #devops #cicd #тестирование #документация #инженерная_культура #исследование
Технически дизайн
Эта статья будет полезна как разработчикам, так и менеджерам. Если вы представляете большую компанию с неограниченным бюджетом, возможно, она вам не пригодится. В погоне за продуктивностью часто создаются «гибкие» системы, гибкость которых на деле оказывается иллюзорной. В результате возникают простои, необходимость переделывать свеженаписанный код, а также искать и исправлять баги. При этом такие системы не освобождают нас от необходимости оставлять после себя структурированные артефакты в виде верхнеуровневой документации. Что можно предпринять, чтобы ускорить разработку и при этом обеспечить проект документацией? Как известно, минимальные действия приносят максимальный результат . Это применимо ко всем сферам деятельности человека, включая разработку программного обеспечения. В этой статье я расскажу об одном небольшом, но крайне эффективном действии, которое способно изменить ваш процесс разработки.
https://habr.com/ru/articles/920258/
#продуктивность_команды #разработка #процессы_разработки #процессы_разработки_по
Почему ты пропустил баг? Или как настроены процессы в обеспечении качества
Мне нравится наблюдать за менторами, которые учат быть независимыми в тестировании и слать всех нафиг т.к. тестирование это не поиск багов, а сравнение ожидаемого результата с фактическим, и если нет требований, то и сравнивать нечего! Прекрасно, вам должны платить просто так! Ведь мы работаем только так как написано в ISTQB, а там много чего написано) И на заборе тоже написано... Вам задают простой вопрос, почему вы пропустили баг на прод? Это обычный разбор полетов после релиза и нужно учится на своих ошибках, прежде чем стартанет следующий горящий релиз! И нам необходимо объяснить причину, которая скрывается не только в процессах тестирование, но и в процессах всей команды. Какой баг?
https://habr.com/ru/articles/915708/
#тестирование_по #qa #обеспечение_качества #процессы_тестирования #процессы_разработки #процессы_в_it #agile #поиск_багов
Как посчитать производительность команды разработки?
Среди топ‑менеджеров, а также линейных руководителей в IT‑компаниях периодически возникает вопрос: является ли та или иная команда разработки производительной? Пытаясь ответить на этот вопрос, многие приходят в тупик, так как осязать цифровое производство крайне непросто, а уж измерить его — тем более! В данной статье мы с вами попробуем разобраться, каким образом все‑таки можно попробовать измерить производительность команды разработки . Также стоит подчеркнуть, что все описанное в статье уже применяется в IT компании Flang , в которой я на данный момент времени являюсь CTO.
https://habr.com/ru/articles/907432/
#эффективность_работы #управление_разработкой #управление_командой #измерение_производительности #метрики_производительности #процессы_разработки #процессы_управления #процессы_в_it
Петля обратной связи в процессах
В рамках этой статьи мы разберёмся, как работают петли обратной связи в процессах, какие бывают их виды, в чём их преимущества и недостатки, а также где и как их лучше применять.
https://habr.com/ru/articles/879122/
#Петля_обратной_связи #процессы_разработки #менеджмент_проектов #qa_management #qa_lead #time_management
Как рефакторить большие системы: Процессы
В предыдущей статье Введение в проблематику я познакомил вас с техническим состоянием системы, структурой департамента и метриками, которые можно снимать с продукта. Если вы ещё не читали, то рекомендую начать именно с неё, чтобы понимать контекст: как у нас устроена орг. структура, в чём специфика нашего продукта и в каком состоянии была система. Когда мы определили на каком этапе жизненного цикла находится наш продукт и после оценки существующих метрик(если есть) — об этом можно почитать в предыдущей статье, мы пришли к выводу о желании и необходимости доработки продукта, то я предлагаю начать разбор с процессов. Я поделюсь своим опытом, который помог не только повысить производительность отдельных команд, но и в целом улучшить работу департамента. Мы поговорим о том, какие процессы нужны, когда их действительно стоит внедрять, как избежать карго-культов и неэффективных митингов, а также разберёмся с внутренними и внешними процессами, наймом и постепенным внедрением изменений.
https://habr.com/ru/articles/877638/
#управление_разработкой #процессы_разработки #процессы_в_it #метрики #рефакторинг #технический_долг
Избегайте эффекта якоря при оценке задач
Был ли у вас хоть раз в жизни подобный диалог с начальником или тимлидом? Тимлид: {name}, за сколько времени сделаешь эту задачу? За неделю успеешь? Я: Да. Может быть, чуть больше — ещё тестами надо покрыть. Дней десять, наверное. В итоге вы делаете задачу месяц. У меня такое случалось не раз. И я всегда восхищался людьми, которые могут сразу сказать: «Какая неделя? Здесь работы минимум на месяц». Мы попадаем в такие ситуации не потому что мы глупые. Это происходит из-за когнитивного искажения, известного как эффект якоря
https://habr.com/ru/articles/875932/
#эффект_якоря #оценка_задач #оценка_трудозатрат #оценка_времени #процессы_разработки
Как рефакторить большие системы
Это первая вводная статья из цикла про рефакторинг больших систем. В ней я опишу продукт, департамент, в котором я находился, а так же расскажу про то, какие методы оценивания состояния системы можно использовать.
https://habr.com/ru/articles/860854/
#управление_разработкой #процессы_разработки #процессы_в_it #метрики #метрики_продукта #рефакторинг #технический_долг
Дока сервиса, с которым интегрируешься, неполная и неактуальная. Тестовых площадок нет. Как выжить системному аналитику?
История об испытаниях, которые ждут аналитика в стартапе. Расскажу о том, как выстроить процесс, когда разработка и аналитика стартуют вместе, как поддерживать частые изменения и как мы выкручивались без тестовых площадок.
Три недели кодирования экономят два дня проектирования
Когда я был юн, я ненавидел архитектурное проектирование и документацию, и считал единым источником правды код. Если вы знакомы с мемом в заголовке статьи, то конечно же знаете, к чему это привело меня в конечном счете. Эта история про то, как я пришел к необходимости процесса обязательного технического анализа по задачам для программистов. Писать постановку, но чуть-чуть
https://habr.com/ru/articles/825880/
#технический_анализ #net #разработка #управление_разработкой #спецификация #agile #архитектура #процессы_разработки
Как защитить PROD от багов и себя от стресса
Сегодня хочу поговорить про баги на ПРОДе и о том как защитить команду от этого, ведь для реализации необходима помощь всей команды в выстраивании процессов разработки ПО. Прекрасное название этой статьи говорит само за себя - если не получается защитить команду от багов, то точно получиться защитить себя от стресса, ведь не все зависит от QA. Важно подсветить, что под багом подразумевается отличие ожидаемого результата от фактического. Мы ожидали, что при нажатии кнопки А будет окно В, но происходит совершенно другое. На схеме выше отображаются риски не только появления бага, но и не предусмотренных ошибок в виде программа не делает лучше, а только затрудняет использование. Первый риск: Идея попадает к аналитику Владелец продукта и аналитик на этапе проектирования тех. требований могут некорректно описать логику нового функционала (флоу). Заказчик имел ввиду одно, а по итогу в спецификациях совершенно другое. Решение данной проблемы может зависеть от правил взаимодействия с заказчиком в вашей команде. Второй риск: разработка по тех. требованиям Frontend и Backend разработчики берут задачи из бэклога в спринт, но в задаче может быть прикреплена устаревшая документация, ее может и вовсе не быть.
https://habr.com/ru/articles/804171/
#баги #тестирование #qa #qa_testing #разработка #testing #регрессионное_тестирование #приемочное_тестирование #процессы_разработки #команда_разработки
Почему Заказчики не знают своих процессов?
Привет всем, я на Хабре недавно, и это стало для меня отдушиной. Спасибо тем, кто находит в себе силы давать советы и вести диалог - это очень помогает. Не все я могу использовать сразу на практике, но как минимум это разгружает от морального напряжения. И если честно, то не ожидал, что моя предыдущая статья кому-то “зайдет”. И в комментах даже будет дискуссия. Приятно. Спасибо. Недавно перечитывая комменты к предыдущей статье, подумал, что может и по текущей теме получится создать обсуждение. Увидеть как происходит взаимодействие с клиентами у других. Хотя, как мне кажется, природа взаимодействия с клиентами примерно одинакова у всех. Здесь постараюсь описать свои наблюдения и мысли о важной проблеме, когда клиент сам не совсем понимает чего он хочет на самом деле.
https://habr.com/ru/articles/795045/
#клиенты #процессы #процессы_в_it #процессы_разработки #процесс_разработки #знания_организации #аналитика #аналитика_проекта #взаимодействие #взаимоотношения
