Все же "балансировка бэклога" подходит как раз для молодых проектов. Когда разработка настолько динамичная, что горизонт планирования задач постоянно меняется и вынуждены менять задачи на ходу. Балансировка как раз помогает, не привызываться к каким-то квотам бэклога, не ограничивать себя при выборе что делать: фичи или техдолг. Сейчас критичные фичи, в след иттерации (конденции, "спринт") заполняем техническими задачами. Это прозрачно и для команды, и для менеджеров, меньше раздражения.
А вот альтернатива с квотам ("20% на техдолг"), увы, эффективно работает, когда процессы разработки настолько зрелые, что по каждой команде считаются емкость (estimates) бэклога за иттерацию. И за счет емкости бэклога понятно сколько это 20% и действительно будут ли они сделаны.
Более конкретно отвечая на вопрос - а как лучше делать на совсем ранней стадии проекта может даже стартапа. По опыту, лучше сначала сосредоточиться на ключевых фичах, поставить продукт на какие-то рельсы, выпустить MVP или полную версию, а техническими задачами заняться через полгода, ну край год, после старта проекта. (но не затягивать!) И воспользоваться тактикой балансировки.
Да, у нас такая задача есть в будущем) Это очень удобно, когда по нагрузке каждого инженера, можно его распределить на МР в качестве ревьювера, таким способом баланс автоматически будет контролировать. Возможно данное решение будет выложено в Open Source
На данный момент в RuStore НЕТ следящего кода, специально прям, которые собирает личные данные или иную информацию о пользователи в течении его сессии в приложении. Сбор данных есть только в авторизации (без этого никак) и для продуктовой аналитики (просто метрики), напр, для использование фич, как, часто или нет и т.д Но весь этот сбор нужен только для развития приложения, продукта, для каких-то "третьих" причин не смогут применяться.
Мы тщательно следим за таким понятие, как - сбором личным данных. Сейчас в RuStore Android даже минимально приватных пермишинов используется, только для его в целом работы.
По той же системе, что написано. Мы постарались, чтобы правила код ревью были едиными между всеми направлениями RuStore, иначе сложно будет добиваться общего качества кода. Т.к мы живем отчасти в монорепе, это помогает использовать единые правила CI/CD цикла, в том числе и ревью. Автоматизация у нас проводится через использование стат. анализаторов, типа Detekt, чтобы максимально рутиные вещи связанные с синтаксисом, стилем, может семантические структуре в коде, анализатор сам выявлял и заставлял исправлять до создания MR. Это сокращает время "ручного" ревью. Unit-тесты тоже, кстати помогают, полуавтоматизировать код ревью. Каким образом? Таким, что тесты заставляют писать код правильно по нашим требованиям: чисто, соблюдая структуру и т.д
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Все же "балансировка бэклога" подходит как раз для молодых проектов. Когда разработка настолько динамичная, что горизонт планирования задач постоянно меняется и вынуждены менять задачи на ходу. Балансировка как раз помогает, не привызываться к каким-то квотам бэклога, не ограничивать себя при выборе что делать: фичи или техдолг. Сейчас критичные фичи, в след иттерации (конденции, "спринт") заполняем техническими задачами. Это прозрачно и для команды, и для менеджеров, меньше раздражения.
А вот альтернатива с квотам ("20% на техдолг"), увы, эффективно работает, когда процессы разработки настолько зрелые, что по каждой команде считаются емкость (estimates) бэклога за иттерацию. И за счет емкости бэклога понятно сколько это 20% и действительно будут ли они сделаны.
Более конкретно отвечая на вопрос - а как лучше делать на совсем ранней стадии проекта может даже стартапа. По опыту, лучше сначала сосредоточиться на ключевых фичах, поставить продукт на какие-то рельсы, выпустить MVP или полную версию, а техническими задачами заняться через полгода, ну край год, после старта проекта. (но не затягивать!) И воспользоваться тактикой балансировки.
Да, у нас такая задача есть в будущем) Это очень удобно, когда по нагрузке каждого инженера, можно его распределить на МР в качестве ревьювера, таким способом баланс автоматически будет контролировать. Возможно данное решение будет выложено в Open Source
На данный момент в RuStore НЕТ следящего кода, специально прям, которые собирает личные данные или иную информацию о пользователи в течении его сессии в приложении.
Сбор данных есть только в авторизации (без этого никак) и для продуктовой аналитики (просто метрики), напр, для использование фич, как, часто или нет и т.д Но весь этот сбор нужен только для развития приложения, продукта, для каких-то "третьих" причин не смогут применяться.
Мы тщательно следим за таким понятие, как - сбором личным данных. Сейчас в RuStore Android даже минимально приватных пермишинов используется, только для его в целом работы.
По той же системе, что написано. Мы постарались, чтобы правила код ревью были едиными между всеми направлениями RuStore, иначе сложно будет добиваться общего качества кода. Т.к мы живем отчасти в монорепе, это помогает использовать единые правила CI/CD цикла, в том числе и ревью.
Автоматизация у нас проводится через использование стат. анализаторов, типа Detekt, чтобы максимально рутиные вещи связанные с синтаксисом, стилем, может семантические структуре в коде, анализатор сам выявлял и заставлял исправлять до создания MR. Это сокращает время "ручного" ревью.
Unit-тесты тоже, кстати помогают, полуавтоматизировать код ревью. Каким образом? Таким, что тесты заставляют писать код правильно по нашим требованиям: чисто, соблюдая структуру и т.д