Comments 15
Спасибо за очередную правильную статью.
Вещи, для меня лично очевидные, но, как показывает практика, увы, очень многие команды даже до этого годами не могут дойти.
Badoo на хабре всегда радует качественным и толковым материалом. Пишите ещё!
Спасибо за отзыв!
Приятно что то, что я пишу, оказывается полезным.
Мне вдвойне приятно что многие ребята из нашей компании, когда мы делали вычитку, говорили про то что тема «капитанская» и очевидная. Ребята, вы — крутые! С вами работать очень здорово!
В то же время, даже у нас регулярно приходится объяснять и рассказывать подобные элементарные вещи. В том числе и поэтому я и решил написать цикл статей об основах, стараясь максимально подробно описать «почему» и что стоит за решениями и подходами, которые у нас работают.
Приятно что то, что я пишу, оказывается полезным.
Мне вдвойне приятно что многие ребята из нашей компании, когда мы делали вычитку, говорили про то что тема «капитанская» и очевидная. Ребята, вы — крутые! С вами работать очень здорово!
В то же время, даже у нас регулярно приходится объяснять и рассказывать подобные элементарные вещи. В том числе и поэтому я и решил написать цикл статей об основах, стараясь максимально подробно описать «почему» и что стоит за решениями и подходами, которые у нас работают.
Это все может работать нормально только при грамотно организованной инфраструктуре развертывания (оно же DevOps). Если собрать Ваше приложение из отдельно взятой ветки репозитория для Вас проблема, то такой подход к разработке может быть не про Вас.
Скажите, а bugfix у Вас по такому же flow идет? Т.е. обнаружили баг, сделали ветку, поправили, оттестировали сборку из этой ветки, потом влили в основную ветку, оттестировали там на регрессию и в продакшен?
Спасибо за статью.
Скажите, а bugfix у Вас по такому же flow идет? Т.е. обнаружили баг, сделали ветку, поправили, оттестировали сборку из этой ветки, потом влили в основную ветку, оттестировали там на регрессию и в продакшен?
Спасибо за статью.
Собрать приложение с головы любого коммита — не проблема. Ни для нас, ни для любого другого человека, хоть немного понимающего матчасть.
Суть в том, что когда вас больше 200 инженеров, формулировки «сделай, ты же умный и сам знаешь как» не работают. Тут нужны четкие правила. А если учесть что часть людей вообще может не знать git, модели ветвления и принципы работы в команде, являясь при этом крутыми специалистами в других областях, то совсем тяжело.
Когда я делал проект по переходу на git с svn в Баду, я написал пошаговую инструкцию. Прям с примерами консольных команд и четкими правилами «делай так, получишь то-то». Шаги в инструкции были неправильными, если смотреть с точки зрения опытного пользователя git (git — крайне гибкая и мощная система). Но они были такими, чтобы избежать ошибок по-максимуму.
В результате, люди, поработав по инструкции несколько раз, начинали «рубить фишку» и понимать всю гибкость инструмента.
По поводу багфиксов — да, флоу у нас подразумевает одинаковую работу с любыми типами задач. Новая фича, багфикс, эксперимент, рефакторинг — все идет по одному накатанному пути.
Другое дело что иногда баги (а бывает что и фичи) надо делать по-максимуму быстро. Минуя все дополнительные стадии, внося риски. Когда такие ситуации риск оправдывают, мы делаем прагматично — резрабатываем и релизим вне флоу, у нас есть инструменты и соглашения, которые позволяют так делать.
Я думаю, мы напишем статью или сделаем доклад про систему патчей в ближайшее время.
Суть в том, что когда вас больше 200 инженеров, формулировки «сделай, ты же умный и сам знаешь как» не работают. Тут нужны четкие правила. А если учесть что часть людей вообще может не знать git, модели ветвления и принципы работы в команде, являясь при этом крутыми специалистами в других областях, то совсем тяжело.
Когда я делал проект по переходу на git с svn в Баду, я написал пошаговую инструкцию. Прям с примерами консольных команд и четкими правилами «делай так, получишь то-то». Шаги в инструкции были неправильными, если смотреть с точки зрения опытного пользователя git (git — крайне гибкая и мощная система). Но они были такими, чтобы избежать ошибок по-максимуму.
В результате, люди, поработав по инструкции несколько раз, начинали «рубить фишку» и понимать всю гибкость инструмента.
По поводу багфиксов — да, флоу у нас подразумевает одинаковую работу с любыми типами задач. Новая фича, багфикс, эксперимент, рефакторинг — все идет по одному накатанному пути.
Другое дело что иногда баги (а бывает что и фичи) надо делать по-максимуму быстро. Минуя все дополнительные стадии, внося риски. Когда такие ситуации риск оправдывают, мы делаем прагматично — резрабатываем и релизим вне флоу, у нас есть инструменты и соглашения, которые позволяют так делать.
Я думаю, мы напишем статью или сделаем доклад про систему патчей в ближайшее время.
Кто что посоветует для мерж-конфликтов на tortoise hg? Задрала эта тема, стандартный kdiff всё портит в основном и крайне неуклюжий
Давать советы «по фотографии» сложно, как мне кажется. Очень многое зависит от самих конфликтов, языка разработки и подходов и правил командной разработки.
Единственное, что я хотел бы отметить (и часто рекомендую друзьям и знакомым) — забыть про tortoise hg/git/svn/whatever. Равно как и про любые другие UI-инструменты для работы с системами контроля версий. Консоль — вот ключ к пониманию того, как оно устроено изнутри, как работает и что делает в каждом конкретном случае.
Удачи!
Единственное, что я хотел бы отметить (и часто рекомендую друзьям и знакомым) — забыть про tortoise hg/git/svn/whatever. Равно как и про любые другие UI-инструменты для работы с системами контроля версий. Консоль — вот ключ к пониманию того, как оно устроено изнутри, как работает и что делает в каждом конкретном случае.
Удачи!
перестаньте одновременно работать над одними кусками кода:
— если у вас большие файлы — разделите их
— делайте коммиты меньше — чаще сливайтесь
и тогда у вас просто не будет проблемы ))
— если у вас большие файлы — разделите их
— делайте коммиты меньше — чаще сливайтесь
и тогда у вас просто не будет проблемы ))
Несколько вопросов:
1.кто делает декомпозицию задач(какая роль в компании)
2.насколько глубокая делается декомпозиция, возможно пример
3.какое соотношение декомпозиторов и разработчиков, хватает ли ресурса декомпозиторов
4.есть ли тайный смысл в том, что статью данной тематики пишет QA
1.кто делает декомпозицию задач(какая роль в компании)
2.насколько глубокая делается декомпозиция, возможно пример
3.какое соотношение декомпозиторов и разработчиков, хватает ли ресурса декомпозиторов
4.есть ли тайный смысл в том, что статью данной тематики пишет QA
5.кто потом собирает декомпозированные задачи если они разноплановые, верстка, код, дизайн
1) Я подробно описывал процесс на примере одной из команд вот в этой статье. Если кратко, то после того как задача от продактов пришла в разработку, задачу берет разработчик-микропроджектменеджер. Он дальше несет ответственность за сроки задачи и все что касается ее реализации на всех стадиях проекта. Он готовит план разработки, внедрения, продумывает зависимости.
За декомпозицию задачи отвечает тоже он. Как именно он декомпозирует — сам, либо с техническим лидом, либо с помощью других членов команды с архитекторской экспертизой разных компонентов — его дело. Он заинтересован в том, чтобы декомпозиция прошла правильно, так как она колоссально влияет на срок доставки, который он называет и за который отвечает.
Отдельной роли «декомпозитор» у нас нет.
2) Глубина декомпозиции сильно зависит от PRD — задания, которое приходит от продактов. Оно не детальное. Многие аспекты реализации уточняются/дополняются в процессе декомпозиции, а некоторые даже в процессе разработки. Я бы сказал так: мы не стараемся все детализировать и документировать, а пытаемся быть гибкими. Описание достаточно чтобы начать работу? Значит можно начинать. Декомпозиции частей достаточно чтобы начать работу над этими частями? Значит вперед.
3) Поскольку отдельной роли декомпозиторов нет, думаю вопрос не актуален?
4) Тайного смысла нет. Просто так получилось что в Баду QA занимает немаловажную роль, особенно в построении процессов и организации практик и методологий. По правде сказать, я считаю что так должно быть в любой компании и не должно зависеть от роли. Если у вас есть что предложить для улучшения работы — надо предлагать, объяснять, убеждать. Это залог роста для всех, в том числе и для всей компании в целом.
5) Тот же микропроджектменеджер-разработчик, который задачу везет. Либо сам, либо с помощью коллег. Но инициирует, контролирует и отвечает за процесс именно он.
За декомпозицию задачи отвечает тоже он. Как именно он декомпозирует — сам, либо с техническим лидом, либо с помощью других членов команды с архитекторской экспертизой разных компонентов — его дело. Он заинтересован в том, чтобы декомпозиция прошла правильно, так как она колоссально влияет на срок доставки, который он называет и за который отвечает.
Отдельной роли «декомпозитор» у нас нет.
2) Глубина декомпозиции сильно зависит от PRD — задания, которое приходит от продактов. Оно не детальное. Многие аспекты реализации уточняются/дополняются в процессе декомпозиции, а некоторые даже в процессе разработки. Я бы сказал так: мы не стараемся все детализировать и документировать, а пытаемся быть гибкими. Описание достаточно чтобы начать работу? Значит можно начинать. Декомпозиции частей достаточно чтобы начать работу над этими частями? Значит вперед.
3) Поскольку отдельной роли декомпозиторов нет, думаю вопрос не актуален?
4) Тайного смысла нет. Просто так получилось что в Баду QA занимает немаловажную роль, особенно в построении процессов и организации практик и методологий. По правде сказать, я считаю что так должно быть в любой компании и не должно зависеть от роли. Если у вас есть что предложить для улучшения работы — надо предлагать, объяснять, убеждать. Это залог роста для всех, в том числе и для всей компании в целом.
5) Тот же микропроджектменеджер-разработчик, который задачу везет. Либо сам, либо с помощью коллег. Но инициирует, контролирует и отвечает за процесс именно он.
Какой статус у «микропроджектменеджер-разработчик» в иерархии — он как кто: middle/senior разработчик или больше управленец?
Обучаете сами на эту должность(из управленцев или наоборот технарей) или нанимаете готовых?
Какая пропорция «микропроджектменеджер-разработчик» /разработчик в команде?
Пишет ли «микропроджектменеджер-разработчик» что-то сам?
Обучаете сами на эту должность(из управленцев или наоборот технарей) или нанимаете готовых?
Какая пропорция «микропроджектменеджер-разработчик» /разработчик в команде?
Пишет ли «микропроджектменеджер-разработчик» что-то сам?
Это просто разработчик в команде. Уровень может быть разный и мы даем «порулить» фичей новичкам в том числе. Под присмотром более опытных, разумеется — для того, чтобы более слабые набирались опыта.
Обучаем/находим — зависит от. Чаще очень трудно найти полностью готового специалиста по абсолютно всем параметрам, поэтому обычно найм — это компромисс. И мы даем время человеку на то, чтобы он подтянул свои навыки после. Бывает так, что отличный разработчик, который не может менеджить задачи, уходит. Нам не нужны «кодеры», нам нужны взрослые, думающие программисты.
Микропроджектменеджер пишет сам код, да. Пропорция менеджмента/программирования зависит от многих факторов: опыт, «чутье», размер фичи и т.д.
Обучаем/находим — зависит от. Чаще очень трудно найти полностью готового специалиста по абсолютно всем параметрам, поэтому обычно найм — это компромисс. И мы даем время человеку на то, чтобы он подтянул свои навыки после. Бывает так, что отличный разработчик, который не может менеджить задачи, уходит. Нам не нужны «кодеры», нам нужны взрослые, думающие программисты.
Микропроджектменеджер пишет сам код, да. Пропорция менеджмента/программирования зависит от многих факторов: опыт, «чутье», размер фичи и т.д.
В идеальном мире этому надо учить уже на 1-м курсе универа или в старшей школе.
Спасибо, очень интересно и потом пригодится.
UFO just landed and posted this here
Sign up to leave a comment.
Как workflow разработки влияет на декомпозицию задач