Как раз мне Scram нравится, как ко всему отношусь к нему не как к догме с авторитетными вождями. Единственный вопрос который меня смущает, это то что тестирование способно разрушить любую итерацию, а отсутствие тестирования лишает смысла рапорт заказчику о готовности фичи.
Вы только что говорили, что реальная доставка будет только через 2,5 спринта
— ничего такого не говорил. Спринт двухнедельный, фича на 2 человека недели пилится одновременно двумя разрабами. Есть еще неделя на тестирование и устранение дефектов. Ничто не предвещало) Но это все чепуха, это был лишь пример того как в конце спринта можно получить запиленную (?), но не протестированную фичу. Наверняка можно и другие случаи из жизни вспомнить. Вопрос в том что с этим дальше делать? Вот тут люди пишут — «Задача является выполненной, если она протестирована» (правда формулировка тоже наводит на мысли, похоже автор не уверен в том что то что не протестировано, то не выполнено). Правильно пишут.
— это был пример ситуации, когда запланированная фича оказалась не протестирована, а не исследование Вашего гениального продукта. Могу слова «фронтэнд/бэкенд» заменить на что то иное, если Вам сложно абстрагироваться.
Прототипируем бэкэнд за пару часов.
— это было сделано, как и другие необходимые телодвижения. Все это можно обсудить на ретроспективе и понять что пошло не так (как всегда виноваты люди). Проблема не в этом конкретном случае, а в ситуации когда фича вроде бы запилена, а времени на тестирование в спринте не осталось.
Как синхронно внести изменения и выкатить в две и более тесно взаимодействующие системы?
— не усложняйте, это типичная фича размером в 2 человеко недели, разбитая на двух разработчиков. Если тут начать «версионировать API» — заказчик этого не поймет.
И, ктсати, тестируют у нас тоже разработчики. Сазерленд требует тестировщиков увольнять. Команда должна быть универсальна и равномерна. Это требование скрама от апологета.
— идиотское требование: у тестировщика и разработчика разная психология, разное отношение к тому что существенно, а что нет, разный набор знаний. Даже обсуждать не интересно. По такой логике и техписы не нужны — разработчик сам все задокументирует)))
Спринты двухнедельные, как правило задачу надо сдать в начале второй недели, чтобы её протестировали, вернули дефекты, поправили их и закрыли.
— это понятно и звучит логично, но возникает вопрос: чем занимаются разработчики вторую неделю, пока тестировщики тестируют фичу? Допустим все получилось сразу и дефектов нет. Получится что разрабы пинают балду до конца итерации или в итерацию начинается подброс не запланированных задач.
Пример: Спринт двухнедельный. Фича — очень длинное древовидное меню, чтобы не положить фронт использовать автоподсос, для реализации нужно сделать что то на бэке, что то на фронте. Задействуем двух разработчиков — один на фронт, второй на бэк, каждому задача на неделю. Оба начинают одновременно и в какой то момент должны объединить свои усилия. По плану остается неделя на тестирование и устранение дефектов.
Дальше все идет не так как планировали) Фронт готов, бэк оказался сложнее чем думалось и затянулся, потом пытаемся соединить — оказалось что фронт и бэк не стыкуются в некоторых местах, фронт дорабатываем, бэк дорабатываем, стыкуем, ловим кучу ошибок (без всякого тестирования). Как результат — вроде сделано, но уперлись в конец спринта и получили фичу без тестирования. Ну а в следующем спринте соответственно получаем тестирование фичи, еще ошибки (уже не тривиальные) и тратим еще неделю на их устранение.
Очевидно, речь о прогоне юнит-тестов в VS средставми самой IDE или R#.
— для меня не очевидно (VS я не пользовался никогда), а в тексте статьи явных указаний на то как именно интервьюируемый гонял тесты (и какие? может интеграционные?) нет.
— похоже речь идет о теории, а не о практике (верный симптом наличие общих фраз и отсутствие каких то чисел). Как практик я знаю, что слабое место скрама — это сдача в конце итерации не протестированных фич (самотестирование разработчиком это чепуха), которые потом возвращаются в следующую итерацию. Заказчику при этом бывает сложно объяснить, почему мы опять делаем то, что ему уже показывали как сделанное.
У каждой истории утверждается т.н. definition of down («условия приёмки»)
— по моему опыту необходимость и глубина тестирования, в первую очередь связаны с личностью разработчика пилившего фичу. Про кого то я знаю что его код не потребуется править, про кого то могу сказать что почти наверняка функционал не реализован так как надо. Конечно что то зависит и от сложности задачи, но основной фактор это личность разработчика. Опытный тимлид учитывает это в разработке. Но в любом случае это плохо вписывается в теорию скрама. Во всяком случае я ясного ответа о том как планировать тестирование в итерацию не получил.
купил проц от амд. Это был страшный провал. Не смотря на высокую заявленную мощность, этот кусок говна прогоняет мои тесты в 5!!! раз медленнее, чем его интеловский аналог
— тут не ясно о какой модели идет речь. У меня Ryzen 7 1700X 3.4 GGz — я доволен как слон (перед этим была мать с двумя двухядерными ксеонами — AMD кратно их превзошел). Вероятно проблема в том что используются однопоточные приложения на которых мощь многоядерной системы не раскрывается.
Если на стендап-встречи не хочет идти вся команда…
я сказал, что буду отмечать в календаре тех, кто приходит на стендапы
— часто разработчик считает что сделал меньше чем должен (результат неверной оценки задачи) и недоволен собой, а учитывая что разрабы люди обычно самолюбивые, необходимость публичного признания (хотя остальным до лампады его проблемы) рождает либо нежелание идти на стендап, либо переработки у особо ответственных.
— а если не являются, то команда пишет код без ошибок?
возможна и организация тестирования в виде «внешнего сервиса» скрам-команды
— что позволяет разработчикам закрывать спринты с нетестированным кодом, т е кодом который возможно вообще не работает или работает неверно.
нет никаких принципиальных проблем в планировании
— пожалуйста, подскажите: какой процент времени итерации в Вашей команде отводится на тестирование и за сколько дней до конца итерации разработчики должны закончить работу, чтобы тестировщики могли протестировать задачи?
Вы говорите максимы, но не отвечаете на вопросы. Речь идет о каком то теоретическом скраме? Ведь не трудно ответить на вопрос, вспомнив как прошло прошлое планирование: «в Вашей версии планирования итерации какой процент времени отводится на тестирование и за сколько дней до конца итерации разработчики должны закончить работу, чтобы тестировщики могли протестировать задачи?»
И что, тестировщики присутствуют на планировании спринта? Ни разу не видел. И насчет «балды» поражен. А как же «покер планирования»?
В итоге хочу узнать: в Вашей версии планирования итерации какой процент времени отводится на тестирование и за сколько дней до конца итерации разработчики должны закончить работу, чтобы тестировщики могли протестировать задачи?
Не прикидывайтесь. Разработчику приходится думать что он скажет на завтрашнем стендапе. Это тонкое психологическое давление с целью заставить людей работать. Если бы это было не так, разрабы охотно бы бежали на стендапы без всякого напоминания — разве плохо пятнадцать минут языком потрепать вместо работы?
Скрам манипулятивен по своему духу — с одной стороны изобразить заказчику что работа идет, с другой стороны подстегнуть разрабов.
— ну и сколько отводится на тестирование и устранение дефектов? Дефект вещь не предсказуемая способная легко поломать спринт. А разработчик норовит тянуть завершение задачи до конца спринта. Из Вашего ответа я не сумел понять сколько времени закладывать в каждую задачу на тестирование. Может есть какие то рекомендации, практики?
Никак не могу понять — какое место занимает тестирование в спринте?
Если спринт завершен без тестирования, то не факт что функциональность рабочая, т е фактически спринт не может считаться завершенным без тестирования. Если включить тестирование в спринт, то сроки почти наверняка погорят из выявленных ошибок (допустим уровня critical).
— ничего такого не говорил. Спринт двухнедельный, фича на 2 человека недели пилится одновременно двумя разрабами. Есть еще неделя на тестирование и устранение дефектов. Ничто не предвещало) Но это все чепуха, это был лишь пример того как в конце спринта можно получить запиленную (?), но не протестированную фичу. Наверняка можно и другие случаи из жизни вспомнить. Вопрос в том что с этим дальше делать? Вот тут люди пишут — «Задача является выполненной, если она протестирована» (правда формулировка тоже наводит на мысли, похоже автор не уверен в том что то что не протестировано, то не выполнено). Правильно пишут.
— не вежливо прозвучало
— это был пример ситуации, когда запланированная фича оказалась не протестирована, а не исследование Вашего гениального продукта. Могу слова «фронтэнд/бэкенд» заменить на что то иное, если Вам сложно абстрагироваться.
— это было сделано, как и другие необходимые телодвижения. Все это можно обсудить на ретроспективе и понять что пошло не так (как всегда виноваты люди). Проблема не в этом конкретном случае, а в ситуации когда фича вроде бы запилена, а времени на тестирование в спринте не осталось.
— не усложняйте, это типичная фича размером в 2 человеко недели, разбитая на двух разработчиков. Если тут начать «версионировать API» — заказчик этого не поймет.
— идиотское требование: у тестировщика и разработчика разная психология, разное отношение к тому что существенно, а что нет, разный набор знаний. Даже обсуждать не интересно. По такой логике и техписы не нужны — разработчик сам все задокументирует)))
— это понятно и звучит логично, но возникает вопрос: чем занимаются разработчики вторую неделю, пока тестировщики тестируют фичу? Допустим все получилось сразу и дефектов нет. Получится что разрабы пинают балду до конца итерации или в итерацию начинается подброс не запланированных задач.
Дальше все идет не так как планировали) Фронт готов, бэк оказался сложнее чем думалось и затянулся, потом пытаемся соединить — оказалось что фронт и бэк не стыкуются в некоторых местах, фронт дорабатываем, бэк дорабатываем, стыкуем, ловим кучу ошибок (без всякого тестирования). Как результат — вроде сделано, но уперлись в конец спринта и получили фичу без тестирования. Ну а в следующем спринте соответственно получаем тестирование фичи, еще ошибки (уже не тривиальные) и тратим еще неделю на их устранение.
— для меня не очевидно (VS я не пользовался никогда), а в тексте статьи явных указаний на то как именно интервьюируемый гонял тесты (и какие? может интеграционные?) нет.
— похоже речь идет о теории, а не о практике (верный симптом наличие общих фраз и отсутствие каких то чисел). Как практик я знаю, что слабое место скрама — это сдача в конце итерации не протестированных фич (самотестирование разработчиком это чепуха), которые потом возвращаются в следующую итерацию. Заказчику при этом бывает сложно объяснить, почему мы опять делаем то, что ему уже показывали как сделанное.
— по моему опыту необходимость и глубина тестирования, в первую очередь связаны с личностью разработчика пилившего фичу. Про кого то я знаю что его код не потребуется править, про кого то могу сказать что почти наверняка функционал не реализован так как надо. Конечно что то зависит и от сложности задачи, но основной фактор это личность разработчика. Опытный тимлид учитывает это в разработке. Но в любом случае это плохо вписывается в теорию скрама. Во всяком случае я ясного ответа о том как планировать тестирование в итерацию не получил.
— тут не ясно о какой модели идет речь. У меня Ryzen 7 1700X 3.4 GGz — я доволен как слон (перед этим была мать с двумя двухядерными ксеонами — AMD кратно их превзошел). Вероятно проблема в том что используются однопоточные приложения на которых мощь многоядерной системы не раскрывается.
— часто разработчик считает что сделал меньше чем должен (результат неверной оценки задачи) и недоволен собой, а учитывая что разрабы люди обычно самолюбивые, необходимость публичного признания (хотя остальным до лампады его проблемы) рождает либо нежелание идти на стендап, либо переработки у особо ответственных.
— а если не являются, то команда пишет код без ошибок?
— что позволяет разработчикам закрывать спринты с нетестированным кодом, т е кодом который возможно вообще не работает или работает неверно.
— пожалуйста, подскажите: какой процент времени итерации в Вашей команде отводится на тестирование и за сколько дней до конца итерации разработчики должны закончить работу, чтобы тестировщики могли протестировать задачи?
В итоге хочу узнать: в Вашей версии планирования итерации какой процент времени отводится на тестирование и за сколько дней до конца итерации разработчики должны закончить работу, чтобы тестировщики могли протестировать задачи?
Скрам манипулятивен по своему духу — с одной стороны изобразить заказчику что работа идет, с другой стороны подстегнуть разрабов.
— ну и сколько отводится на тестирование и устранение дефектов? Дефект вещь не предсказуемая способная легко поломать спринт. А разработчик норовит тянуть завершение задачи до конца спринта. Из Вашего ответа я не сумел понять сколько времени закладывать в каждую задачу на тестирование. Может есть какие то рекомендации, практики?
Если спринт завершен без тестирования, то не факт что функциональность рабочая, т е фактически спринт не может считаться завершенным без тестирования. Если включить тестирование в спринт, то сроки почти наверняка погорят из выявленных ошибок (допустим уровня critical).