Система предлагает менеджеру оптимальную схему перераспределения того, что нужно перенести задачи от загруженной команды A в команду B, а задачи специалиста из команды C передать другому сотруднику с подходящей квалификацией.
Если команды А и Б - это бригады дворников или грузчиков, то это будет хорошо работать. Но если мы говорим про разработку ПО, то если мне вдруг прилетит задача из другого проекта, с которым я не знаком и в который нужно погружаться, а потом меня обратно вернут на мой проект, то целесообразность такого действия будет под вопросом
Мой совет вам - переходите к классический модели разработки, где функциональные требования разрабатывает СА. Если это будут делать разработчики на "груминге", то по мере усложнения продукта, качество его будет падать.
Необходимо было выстроить процесс от момента формирования требований до передачи в разработку и последующего тестирования.
Мне казалось, что этот процесс всегда примерно одинаковый
Мы с командой договорились о следующем:
1. Бизнес-аналитик описывает предметную область по данному сервису согласно нормативным документам.
2. Аналитик описывает основные функциональные требования, а также основные бизнес-процессы, которые должен выполнять сервис.
3. Проверяем требования, чтобы определить, что выполняем, а что выносим за рамки проекта.
4. Окончательно корректируем требования.
5. Прорабатываем дизайн web-интерфейсов.
6. Прорабатываем архитектуру.
7. Декомпозируем требования на задачи для команды разработки.
Почему проработка архитектуры только после п.4 и п.5 ? Она должна быть вместе с п.2
На основании требований составляем сценарии «Программа и методика испытаний» (при этом между собой договорились, что пишем только позитивные сценарии).
Но как измерить эффективность автоматизации, чтобы соотнести с затраченными ресурсами?
На своём опыте мы поняли, что для оценки эффективности подойдёт как раз контроль рабочего времени. Мы отслеживаем, сколько времени тратится на ручной регресс, и сравниваем с затратами на автоматизацию. Так, мы с 2022 года с помощью автоматического тестирования сократили затраты на ручной регресс в 2,5 раза.
Полная мешанина из затраченного времени и затраченных денег.
Например, если разработчики начинали слишком много задач, то мы перенаправляли их на завершение уже начатых.
В 2022 году у нас было в работе 10–15 историй, что в 2–3 раза превышало количество разработчиков и тестировщиков.
Разработчик должен работать над одной задачей. Да, что-то может вернуться после тестирования. Безусловно, разрыв между разработкой и тестированием должен быть минимальным. Разработчики не должны отдавать в тестирование не доделанные задачи. Это все минимальные азы управления процессом разработкой ПО. То что, процессы в командах в серьезной компании могут быть изначально совершенно не налажены - говорит многое об уровне управления в такой компании.
Для быстрого погружения в новую систему очень полезен институт наставничества, если руководитель сам не может выполнить полностью эту роль. Но наставник - это специалист которого назначил руководитель. Вообще HR-ы часто очень часто просто придумывают ненужную активность. На прошлом месте работы, через два месяца как я начал работать мой руководитель резко уволился. На проекте я остался один. На меня легло куча обязанностей, к которым я и не стремился и не был готов. Но приходилось справляться. И тут, через 3 месяца, когда кончился испытательный срок, приходит письмо от HR-ров с поздравлением и вопросом: Как я считаю, готов ли я уже к самостоятельной работе или еще нет. Я ощутил это как издевательство
Как вы думаете, пора ли пересмотреть Agile-манифест или его принципы всё ещё актуальны? Насколько они работают в вашей компании?
Нужная своя голова на плечах, опыт и управленческие навыки
Подумайте, как в 41 году прошлого века смогли в условиях войны эвакуировать сотни заводов и в кратчайшие сроки начать производить новую продукцию? Ведь те, кто это смог осуществить Agile-манифест не читали.
Все зависит от того, какие цели и задачи мы преследуем. Если нам надо что объяснить кому то или, наоборот, хотим что бы нам что объяснили, то да, приведенное в статье ранжирование очевидно. Но бывают и другие цели и задачи: эскалация проблемы, обсуждение вопроса с несколькими людьми сразу, информирование, согласование, фиксирование договоренностей
Должен быть руководитель, который будет принимать решения и отвечать за них. Возможно, перед решением будет обсуждение с техническими специалистами. Если кто то может позволит себе роскошь месяцами выращивать команду с непредсказуемым результатам - это его право, но к процессам управления разработкой в IT это отношения не имеет.
Оказалось, что junior-разработчики могут быть даже продуктивнее, чем middle-разработчики. Да, им может не хватать знаний, но они компенсируют это вовлечённостью и интересом.
К сожалению, не все умеют и хотят работать с начинающими специалистами
Перед запуском мы столкнулись с проблемами нагрузки. В это время я прилетел в Ставрополь к партнёру, и вместе с ним нам удалось собрать окружение для нагрузочного тестирования. Мы нагрузили систему уже имеющимися сценариями запросов и смогли воспроизвести проблему.
Каким образом вы столкнулись с проблемами нагрузки до нагрузочного тестирования и как вы решили саму проблему?
бизнес логика оказалась размазана по всему приложению, а вместе с ней и сами задачи стали сильно связаны друг с другом.
Предполагаю, что теперь при доработки продукта будут сложности.
Запуск системы на фабриках команда провела уже без моего участия. И это для меня главный показатель качества моей работы.
Странно, что вы не довели проект до конца. В статье ничего не сказано насколько в итоге продукт получился качественным и удовлетворяющим ожиданиям заказчика
Ситуация, когда надо приукрасить свои навыки и достижения была, есть и будет как в IT, так и в других областях. Если человек знает, что он может справиться с задачами, которые подразумевает вакансия, а работодатель оценивает претендентов формально, то да, нужно приврать и нужно уметь это делать. Вообще умение приврать нужный и полезный в жизни навык. Вопрос в том, для чего мы это делаем, навредим ли мы этим кому-то, или наоборот принесем пользу.
Аудит дело вторичное, важен работоспособный регламент и его соблюдение. Нужно разделять ИБ, техническую поддержку "теневых решений" со стороны ДИТ, и бизнес-процессов. Что делает какой-то макрос в Excel - владение этими знаниями ответственность руководителя бизнес-подразделения. Нужно ли ДИТ знать и контролировать хранение дистрибутивов всех таблиц в Excel, думаю нет. Излишняя централизация может только помешать
Не хилая схемка для одной маленькой формы ввода, а какой в ней смысл - вообще не понятно.
Если команды А и Б - это бригады дворников или грузчиков, то это будет хорошо работать.
Но если мы говорим про разработку ПО, то если мне вдруг прилетит задача из другого проекта, с которым я не знаком и в который нужно погружаться, а потом меня обратно вернут на мой проект, то целесообразность такого действия будет под вопросом
очень актуальный хаб у статьи: Карьера в IT-индустрии - продать себя подороже, а потом вовремя свалить
Мой совет вам - переходите к классический модели разработки, где функциональные требования разрабатывает СА. Если это будут делать разработчики на "груминге", то по мере усложнения продукта, качество его будет падать.
Не все специальности подразумевают роль проектировщика и не всегда есть особенный проект, который можно выделить
Мне казалось, что этот процесс всегда примерно одинаковый
Почему проработка архитектуры только после п.4 и п.5 ? Она должна быть вместе с п.2
Вы предполагали, что это устроит заказника?
Полная мешанина из затраченного времени и затраченных денег.
Разработчик должен работать над одной задачей. Да, что-то может вернуться после тестирования. Безусловно, разрыв между разработкой и тестированием должен быть минимальным. Разработчики не должны отдавать в тестирование не доделанные задачи.
Это все минимальные азы управления процессом разработкой ПО. То что, процессы в командах в серьезной компании могут быть изначально совершенно не налажены - говорит многое об уровне управления в такой компании.
Для быстрого погружения в новую систему очень полезен институт наставничества, если руководитель сам не может выполнить полностью эту роль. Но наставник - это специалист которого назначил руководитель.
Вообще HR-ы часто очень часто просто придумывают ненужную активность.
На прошлом месте работы, через два месяца как я начал работать мой руководитель резко уволился. На проекте я остался один. На меня легло куча обязанностей, к которым я и не стремился и не был готов. Но приходилось справляться.
И тут, через 3 месяца, когда кончился испытательный срок, приходит письмо от HR-ров с поздравлением и вопросом: Как я считаю, готов ли я уже к самостоятельной работе или еще нет. Я ощутил это как издевательство
Результаты голосования говорят сами за себя
Нужная своя голова на плечах, опыт и управленческие навыки
Подумайте, как в 41 году прошлого века смогли в условиях войны эвакуировать сотни заводов и в кратчайшие сроки начать производить новую продукцию?
Ведь те, кто это смог осуществить Agile-манифест не читали.
Все зависит от того, какие цели и задачи мы преследуем.
Если нам надо что объяснить кому то или, наоборот, хотим что бы нам что объяснили, то да, приведенное в статье ранжирование очевидно.
Но бывают и другие цели и задачи: эскалация проблемы, обсуждение вопроса с несколькими людьми сразу, информирование, согласование, фиксирование договоренностей
Я не хочу, зачем обобщать
Не общаться на рабочем месте в живую и не участвовать в он-лайн совещаниях - утопия.
Да, надо стараться не мешать соседям.
в моем понимании нанести можно только вред
Для согласования, эскалации проблем, оповещения заинтересованных лиц - как правило используют именно почту
Переход из РП в скрам-мастера точно не продвижение
Должен быть руководитель, который будет принимать решения и отвечать за них. Возможно, перед решением будет обсуждение с техническими специалистами.
Если кто то может позволит себе роскошь месяцами выращивать команду с непредсказуемым результатам - это его право, но к процессам управления разработкой в IT это отношения не имеет.
К сожалению, не все умеют и хотят работать с начинающими специалистами
Каким образом вы столкнулись с проблемами нагрузки до нагрузочного тестирования и как вы решили саму проблему?
Смущает несколько моментов:
Предполагаю, что теперь при доработки продукта будут сложности.
Странно, что вы не довели проект до конца. В статье ничего не сказано насколько в итоге продукт получился качественным и удовлетворяющим ожиданиям заказчика
Ситуация, когда надо приукрасить свои навыки и достижения была, есть и будет как в IT, так и в других областях.
Если человек знает, что он может справиться с задачами, которые подразумевает вакансия, а работодатель оценивает претендентов формально, то да, нужно приврать и нужно уметь это делать. Вообще умение приврать нужный и полезный в жизни навык. Вопрос в том, для чего мы это делаем, навредим ли мы этим кому-то, или наоборот принесем пользу.
Аудит дело вторичное, важен работоспособный регламент и его соблюдение. Нужно разделять ИБ, техническую поддержку "теневых решений" со стороны ДИТ, и бизнес-процессов.
Что делает какой-то макрос в Excel - владение этими знаниями ответственность руководителя бизнес-подразделения. Нужно ли ДИТ знать и контролировать хранение дистрибутивов всех таблиц в Excel, думаю нет. Излишняя централизация может только помешать