Size: a a a

QA — русскоговорящее сообщество

2021 May 01

15

12345 54321 in QA — русскоговорящее сообщество
ясное дело, что на задачах "хочу приложение - рабочий кабинет для функционера Х" нельзя назвать оценки сразу и нельзя даже через две недели. Но если такая задача поступает без детального бизнесТЗ, то команда сами себе буратины если эту задачу им продавили на RnD
источник

R(

Roman (rpwheeler) in QA — русскоговорящее сообщество
Если у вас получилось провести все нужные вам эксперименты и были под рукой все нужные данные — отлично. Но так везёт не всем и не всегда.
источник

R(

Roman (rpwheeler) in QA — русскоговорящее сообщество
Ну в своё время — не буду показываь пальцем где — участвовал в оценках проектов командой. Что-то отказали сразу. На что-то мы сказали пол-года, другая команда сказала два месяца. Проект достался им. На релиз у них ушло всё равно пол-года, тим лид скачал что они зарелизили, попробовал, и сказал ... нехорошее слово сказал.
источник

15

12345 54321 in QA — русскоговорящее сообщество
полгода кодили без демо? водопад?)
источник

R(

Roman (rpwheeler) in QA — русскоговорящее сообщество
Не знаю. Та команда вообще с нами рядом не сидела.
источник

AG

Andrew Gasov in QA — русскоговорящее сообщество
Любую задачу можно эстимировать.
Даже ресерч.
Если ты не можешь её эстимировать, значит её надо дробить на подзадачи и этапы и оценивать по мере появления конкретики при движении от начальных к конечным.

Брать в работу задачи, которые не можешь оценить могут себе позволить очень многие, но это не делает эту практику правильной.
источник

R(

Roman (rpwheeler) in QA — русскоговорящее сообщество
> Любую задачу можно эстимировать.
> Даже ресерч.

Угу, ибо есть много простых и неправильных решений, а также простых и неправильных эстимейтов. Если у вас есть внешние зависимости — а они в современном мире есть почти всегда — любой эстимейт это "кот в мешке", потому что вы не знаете что в ваших зависимостях или как их поменяют.

Практические примеры:

- приложение было основано на Windows Communication Framework или как-то так. Через месяц разработки найдено что WCF вместо "нормального результата" в одном реквесте из 100 тысяч возвращает всё по нулям. Решение продакт овнера — выкинуть WCF, всё на бэкенде переписать. Плюс две недели к вашим эстимейтам.

- Эппл выкатывает новую iOS, ваш компонент становится deprecated и нестабильным. Вместо того чтобы заниматься чем вы сейчас занимаетесь, надо заменять компонент чтобы приложение не крэшилось. Плюс две недели к вашим эстимейтам.

- Вы взяли переделку за компаний Икс. а у них там аццкий отстойкод. НИКОГДА не берите переделки-доделки, не посмотрев кода.  Что бы вы не делали, новые креши каждый день тестирования. Хана вашим эстимейтам.
источник

15

12345 54321 in QA — русскоговорящее сообщество
хм, разве это все нельзя свести к фразе "Сначала убедитесь, что вы берете в работу именно то, что думайте, а потом уже подписывайтесь"? Опять же, личный опыт, но три сеньора в шляпах куа-разраб-аналитик могут это сделать до подписания финансово важных обязательств)
источник
2021 May 02

AG

Andrew Gasov in QA — русскоговорящее сообщество
Простите, но я все ещё не понимаю, в чем проблема.

Давать эстимейты не зная объём работы - идиотизм.
Как и вообще браться за работу не зная, что надо делать.
Обычно в таких ситуациях люди берут определённое количество времени на ресерч, потом описывают скоуп работ и по нему дают эстимейт.

Эстимейты могут меняться.
От зависимостей (которыми, конечно, стараются по максимуму управлять ради такого), от изменения требований, от факторов внешней среды и пр.

Эстимейты могут быть ошибочными.
Потому что «не так понял задачу», потому что «пришлось в последний момент переделывать вот это и это».


И то, и другое - нормальная ситуация, до тех пор пока ты можешь объяснить почему это произошло и стараешься минимизировать процент таких ситуаций.
Это не делает эстимейты чем-то не работающим, не нужным или «котом в мешке».
Неожиданно, любая оценка/прогноз может быть ошибочной.
источник

R(

Roman (rpwheeler) in QA — русскоговорящее сообщество
Проблема в реальном мире, в то время как эстимейт — это одна из моделей идеального мира, где "тело движется равномерно и прямолинейно ... " , а другие тела — не влияют.
Но в реальном мире есть куча проблем. Например: Вы сделали эстимейт, у вас два программиста подхватили "корону", один вылетел на две недели, второй на месяц {я знаю такие случаи в реальных командах}.

Эстимейт, как скрам, хорош когда вы начинали этот продукт, вы его знаете, и более чем менее контролируете что происходит. Тогда "вы движетесь равномерно и прямолинейно", но и то с поправками на события внешнего мира (не одной короной, чрезвычайная ситуация рядом с вашим датацентром — экстремальный мороз с отключениями электросети как недавно в Техасе, или, наоборот, лесные пожары — могут отправить ваши эстимейты подальше).

Эстимейты могут навернуться в каждой точке где вы НЕ контролируете то, что происходит — сталкиваетесь с легаси кодом, с другой командой которая может поломать или незаделиверить, работаете на том же энве который может сломаться,  нарываетесь на целый ряд больших и сложных багов.

Киберпанк, эвона, наэстимейтили уже на весь мир. Теперь на весь мир эстимейтят когда будет патч.

В тестировании по-моему хорошо иметь скептическое отношение, не сотворять себе кумиров из эстимейтов тоже.
источник

R(

Roman (rpwheeler) in QA — русскоговорящее сообщество
Но то часть первая, есть реальные ситуации когда точные эстимейты не нужны или невозможны или самообман:
— Вам поставлена задача сделать что-то за два месяца. У вас есть минимальный скоуп и дальнейшие пожелания. Сделаете минимальный — уже хорошо. Сделаете больше — очень хорошо. Но задача такова что надо выкатываться за два месяца, ну плюс неделя — больше не дадут, что сделаете то и сделаете.
— Вы делаете итеративно какой-то MVP с меняющимися пожеланиями. Потом его показывают потенциальным заказчикам. После этого он может пойти дальше (и вот тогда надо будет эстимейты), или потенциальные заказчики не захотят финансировать проект, и ничего не надо дальше делать.
— платформа слишком новая и сырая. Всё может три раза поменяться и перекостылиться
— у вас есть предел по ресурсам (объему памяти за который система не может выйти), который вы  изначально не учли, а работают  на тот же проект 4-5 команд, каждая из которых тестирует свои модули отдельно,. Вы дали эстимейты, но тут настал предел ресурсов, в который то что вы сделали не вписывается.  Скажем, текущий лимит до предела шесть гиг памяти,  вам нужно четыре, но перед вами четыре съедает другая команда, и их модуль нужнее чем ваш.
источник

K

Keane in QA — русскоговорящее сообщество
Так а в чём проблема? Вы оцениваете возможные риски. Оцениваете время на решение подобных проблем и закладываете его в общее время выполнения задачи.

Вжух, и всё готово.
источник

RG

Richard Gears in QA — русскоговорящее сообщество
второй день из пустого в порожнее переливаете )
источник

K

Keane in QA — русскоговорящее сообщество
😂😂😂
источник

K

Keane in QA — русскоговорящее сообщество
Вы говорите, что существуют задачи, в которых нельзя установить сроки и приводите пример, где срок установлен в 2 месяца. Как это работает?
источник

AG

Andrew Gasov in QA — русскоговорящее сообщество
Я вот тоже, честно говоря, так и не понял.

Если объём работы примерно осязаем - можно давать грубую оценку и конкретизировать её по мере формализации задач.
Если объём работы не осязаем, то перед там, как давать эстимейты (и, собственно, начинать что-то делать) - надо определиться с тем, что вы всё таки делаете (а из того, что вы делаете можно вывести скоуп работ, а из скоупа- эстмейты).

Есть риски, которые оцениваются и закладываются в эстимейт.
Есть буффер на случай внешних изменений.
Но даже если случилось что-то, что нельзя было оценить заранее и ваши эстимейты поменялись - это не делает эстимейты не работающей практикой.
Это просто говорит о том, что иногда эстимейты ошибочны.
источник

БЛ

Борис (KeR) Лушкин... in QA — русскоговорящее сообщество
А еще, это все можно собрать, чтоб не потерялось, и положить в @shooandendlessagony
🙂
источник

K

Keane in QA — русскоговорящее сообщество
По сути, простое знание того, что на отрезке выполнения задачи, например в 6 месяцев, точно пойдёт что-то не так (кто-то заболеет, уволится, прилетит макаронный монстр и т.д.), уже помогает лучше оценивать сроки и закладывать в них время на решение "условно непредвиденных" проблем.
источник

SR

Sergey Raspopov in QA — русскоговорящее сообщество
что то мне подсказывает, что риск факторы, типа пожаров, землетрясений, атаки инопланетян, смены законодательства это форс-мажор и закладывать их в срок никто не будет. Разрабатывать без сроков можно если вы гугл, у которого кладбище продуктов, превышает разумные рамки или госуха, у которой бюджет резиновый.
Но при этом даже на НИОКРы дается оценка сроков и бюджетов. А это извините не разработка более менее изместных уже систем, и не переписывается за неделю парой маньяков.
источник

AG

Andrew Gasov in QA — русскоговорящее сообщество
Надо будет рассказать ребятам из гугла, что оно, оказывается, могут забить на эстимейты и просто говорить «ну, когда-нибудь сделаем».
источник