На текущем месте работы, у нас в командах есть менеджеры, которые помогают командам. У них разный набор навыков - у кого-то он более технический, у кого-то сильнее прокачены софт скилы. Но команды можно собирать исходя из слабых сторон отдельных людей, чтобы в совокупности они дополняли друг друга.
А вы не замеряли результаты работ у таких команд на длительном промежутке времени? Есть предположение, что забирая у сеньоров время на менеджмент вы теряете больше, чем получили бы если доверили эту задачу мидл менеджеру. У менеджера может быть больше знаний в этой области, разработчик будет заниматься тем, что ему больше нравиться и лучше получается. Вы же не убрали тестировщиков из компании и не сказали остальным, что теперь это только их задача - отвечать за качество продукта?
Пару примеров преднамеренного техдолга и пути его устранения в моей команде: 1) Отдали в прод фичу сейчас в прод из-за сроков. Она работает, но реализация не лучшая. Решение: Сразу заводится отдельная задача в беклог со своим приоритетом и решается когда наступает черёд. 2) Фича вышла, а внутренняя документация (например в Confluence) еще не обновлена (Устаревшая документация тоже техдолг). Решение: В условной user story, при ее создании, заводится отдельная задача на обновления информации для отвественного в вашей команде за эту часть работы (технический писатель, аналитик, менеджер, qa и тд).
В обоих случаях техдолг намеренно создается в угоду скорости, но есть прогнозируемый срок его закрытия в будущем.
Не сливаться с проблем - очень ценный навык. Причем, не только в работе, но и в жизни. Важно, чтобы у вас хватило сил преодолеть кочку на пути к светлому будущему.
Да, это дополнительная точка притяжения внутри компании. Иногда, это позволяет удержать людей от смены работы, уменьшить текучку. Это даже экономически может быть выгодно для компании :)
Как раз пошел по такому пути еще до прочтения данной статьи. Решил структурировать те материалы, которые прочитал/посмотрел и оставлять на них краткую рецензию. А потом перенес еще это в канал телеги, так как часто советовал коллегам что-то из того что посмотрел. А репост из канала отправлять удобнее, чем искать по своим заметкам :)
Возможно я чего-то не понял, но как отдельные стенды решили вопросы из начала статьи?
Безопасность: Возможна потеря данных, нарушение функциональности; Быстрая обратная связь: Отсутствие возможности быстро получить фидбек от коллег или клиентов до завершения работы над задачей.
1) А чем это глобально отличается от user story и дальнейшее разделение на задачи? Вы как раз говорите в тексте, что продукт "юзер-ориентированный". 2) Бывает ли, что баги, которые создаются как саб таски, не фиксятся сразу, а отправляются в беклог? 3) Делаются ли баги в отдельных merge request-ах от разработки для доставки изменений или это просто отдельные коммиты в основную таску?
К сожалению, это так. Тут зависит от процессов в компании. Наша идея по добавлению отдельных задач родилась не просто так. Когда в нужный момент не находиться документа, данных нужных тебе для решения задачи и это как эффект домино задевает бизнес - ему чуть проще в будущем объяснить необходимость выделения времени на такие активности. А отдельные задачи скорее для прозрачности процесса.
Да, это важный вопрос. Главное не оказаться в ситуации, когда накопившийся техдолг не даст вам сделать новую фичу вовремя или скорость разработки увеличиться в условные 2 раза. Могут начать уходить люди из команды. Эти факты можно перевести в потерянные деньги. Бизнес обычно говорит на этом языке и относительно хорошо понимает историю с "инвестициями" и "получаемой будущей прибылью".
А то команда может просто начать в будущем увеличивать оценку задач, закладывая в нее необходимости переделать старое.
Часто, для внедрения каких-то изменений надо показать какую проблему вы будете решать. Как в первом вашем кейсе. Чтобы не получилось так, что вы что-то внедрили из-за его популярности/полезности, но у команды/заказчика не было проблем в этой области. В таком случае, ваши изменения могут быть не оценены по заслуге или просто не прижиться.
В ws есть messages. Можно ли автотестами проверять статусы там? Например, есть плеер на фронте который общается с видеобекендом по ws. И в messages есть статусы текущей ситуации с видео (play, pause и тд).
Вроде есть пункт про "Вибростенды: проверка на транспортировку". Вы же про это?
Просто даже dodo, которых вы приводите в пример, уже ушли от этой модели - https://www.youtube.com/watch?v=U3pmbdw_cEc
На текущем месте работы, у нас в командах есть менеджеры, которые помогают командам. У них разный набор навыков - у кого-то он более технический, у кого-то сильнее прокачены софт скилы. Но команды можно собирать исходя из слабых сторон отдельных людей, чтобы в совокупности они дополняли друг друга.
А вы не замеряли результаты работ у таких команд на длительном промежутке времени? Есть предположение, что забирая у сеньоров время на менеджмент вы теряете больше, чем получили бы если доверили эту задачу мидл менеджеру. У менеджера может быть больше знаний в этой области, разработчик будет заниматься тем, что ему больше нравиться и лучше получается.
Вы же не убрали тестировщиков из компании и не сказали остальным, что теперь это только их задача - отвечать за качество продукта?
А это автотесты для миграции только самого проекта или связанные сущности тоже можно проверить таким способом (тест-кейсы, документы из confluence)?
Пару примеров преднамеренного техдолга и пути его устранения в моей команде:
1) Отдали в прод фичу сейчас в прод из-за сроков. Она работает, но реализация не лучшая.
Решение: Сразу заводится отдельная задача в беклог со своим приоритетом и решается когда наступает черёд.
2) Фича вышла, а внутренняя документация (например в Confluence) еще не обновлена (Устаревшая документация тоже техдолг).
Решение: В условной user story, при ее создании, заводится отдельная задача на обновления информации для отвественного в вашей команде за эту часть работы (технический писатель, аналитик, менеджер, qa и тд).
В обоих случаях техдолг намеренно создается в угоду скорости, но есть прогнозируемый срок его закрытия в будущем.
В киберспорте точно есть "Лига чемпионов бизнеса", где играют между собой команды из разных компаний в cs и другие игры. Так что прецедент есть :)
Согласен, полностью. У нас тоже в Краснодаре точно собираются и играют. А на спартакиаде в ПАО "Ростелеком" точно есть соревнования по волейболу.
Не сливаться с проблем - очень ценный навык. Причем, не только в работе, но и в жизни. Важно, чтобы у вас хватило сил преодолеть кочку на пути к светлому будущему.
Да, это дополнительная точка притяжения внутри компании. Иногда, это позволяет удержать людей от смены работы, уменьшить текучку. Это даже экономически может быть выгодно для компании :)
Ооо, отличный результат. Полумарафон это длинная дистанция, вы молодец.
Как раз пошел по такому пути еще до прочтения данной статьи. Решил структурировать те материалы, которые прочитал/посмотрел и оставлять на них краткую рецензию. А потом перенес еще это в канал телеги, так как часто советовал коллегам что-то из того что посмотрел. А репост из канала отправлять удобнее, чем искать по своим заметкам :)
SQL-инъекция на OWASP Juice Shop - ссылка не ведет на раздел статьи, поправьте пожалуйста :)
Возможно я чего-то не понял, но как отдельные стенды решили вопросы из начала статьи?
Безопасность: Возможна потеря данных, нарушение функциональности;
Быстрая обратная связь: Отсутствие возможности быстро получить фидбек от коллег или клиентов до завершения работы над задачей.
Из интересного еще есть - "Не используй шаблон задачи на разработку, а придумывай свой собственный стиль подачи материала"
1) А чем это глобально отличается от user story и дальнейшее разделение на задачи? Вы как раз говорите в тексте, что продукт "юзер-ориентированный".
2) Бывает ли, что баги, которые создаются как саб таски, не фиксятся сразу, а отправляются в беклог?
3) Делаются ли баги в отдельных merge request-ах от разработки для доставки изменений или это просто отдельные коммиты в основную таску?
К сожалению, это так. Тут зависит от процессов в компании. Наша идея по добавлению отдельных задач родилась не просто так. Когда в нужный момент не находиться документа, данных нужных тебе для решения задачи и это как эффект домино задевает бизнес - ему чуть проще в будущем объяснить необходимость выделения времени на такие активности. А отдельные задачи скорее для прозрачности процесса.
Да, это важный вопрос. Главное не оказаться в ситуации, когда накопившийся техдолг не даст вам сделать новую фичу вовремя или скорость разработки увеличиться в условные 2 раза. Могут начать уходить люди из команды.
Эти факты можно перевести в потерянные деньги. Бизнес обычно говорит на этом языке и относительно хорошо понимает историю с "инвестициями" и "получаемой будущей прибылью".
А то команда может просто начать в будущем увеличивать оценку задач, закладывая в нее необходимости переделать старое.
Скорее наоборот, если поесть - будут силы на написание документации.
Отсутствие же указывает, что энергии хватило только на написание решения задачи.
Часто, для внедрения каких-то изменений надо показать какую проблему вы будете решать. Как в первом вашем кейсе.
Чтобы не получилось так, что вы что-то внедрили из-за его популярности/полезности, но у команды/заказчика не было проблем в этой области. В таком случае, ваши изменения могут быть не оценены по заслуге или просто не прижиться.
В ws есть messages. Можно ли автотестами проверять статусы там?
Например, есть плеер на фронте который общается с видеобекендом по ws. И в messages есть статусы текущей ситуации с видео (play, pause и тд).