Выберите все изображения, где есть оценка сроков разработки новой фичи о ^ О ПОДТВЕРДИТЬ / it-юмор :: приколы для программистов :: geek (Прикольные гаджеты. Научный, инженерный и айтишный юмор)
Подробнее
Выберите все изображения, где есть оценка сроков разработки новой фичи
о ^ О
ПОДТВЕРДИТЬ
приколы для программистов,it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Это ошибочный подход который мы не одобряем в компании, нужно смотреть позитивно на вещи и если клиент желает получить эту фичу, то нужно приложить все необходимые усилия для её реализации. Если ситуация столь плоха как вы описываете, то просто мы попросим разработчиков работать 37 часов в сутки и тогда мы точно добьёмся успеха. Теперь идите и работайте, не отвлекайте нас своими провокационными и пораженческими заявлениями.
Мы в 80% случаев ставим обоснованные оценки (не сроки, а приблизительные оценки временной сложности, то есть, выбираем диапазон времени за который возможно что-то выполнить). К счастью, у нас адекватные менеджеры и заказчик, которые понимают, о чём идёт речь и сильно не задалбывают. Но в 20% случаев, когда речь идёт о легаси коде, там вообще лотерея полная.
Я убеждённый противник использования оценок по времени на проектах. Для долгосрочного планирования вполне достаточно стори-поинтов.
У разработчика должна быть возможность спокойно порефакторить код, добавить каких-то недостающих тестов. А не с горящей жопой добавлять в код новые костыли, чтобы успеть к дедлайну.
У нас дедлайн в конце августа - надо показать MVP потенциальному, очень нужному инвестору. MVP делается из говна и палок, ключевой разработчик на три недели в ебенях, одна архиважная ебанная хуевина функционала не работает. Я коммичу и плачу, плачу и коммичу, дебажу и ругаюсь матом на всех известных мне языках. Так то я тоже противник использования оценок по времени на проектах.
Ни разу не видел капчу где бы все ответы были правильными. А вообще сроки обычно прикидываются исходя из времени создания подобного рода продуктов и кол-ва человек их создававших. Типа если нас меньше, а штука сложная + вы хотите новый контент, тогда ждите дохуя.
Вообще говоря, точная оценка сроков - пустая трата времени и сил.
Можно оценить порядок сроков - быстро, порядка недели, порядка месяца, несколько месяцев, дохуя. Это исходит из примерного объема работы.
И всё равно эта оценка неточная, особенно если есть неясные места, которые надо исследовать. Кроме того, в процессе реализации иногда вылазит хуйня, занимающая много времени. Хотя, наоборот тоже случается, когда находится решение, решающее кучу проблем.
I’m CTO, bitch ^
К нам сегодня вышел новый разработчик. Он два часа задумчиво смотрел в монитор. Потом просто встал и ушёл. Больше не берёт трубку и забанил меня в телеге.
Вы реально ему в первый рабочий день показали наш модуль для прайсинга? Там же всё на хранимых процедурах написано, а ещё кус
print("I* A*»A4I")
print (" iliiiiii")
print("□
print("■ □
print("□
print("■ □
printc'i limit”) print("S
printC'Your turn! 1.") player = input()
if player == "e4":
printC'i 4 ft, 6« k 4 K") printC’i t t t t t t t”) print ("□ print("■
print("□ ■ □ ml m □ ■") print(”■
printC’i i i 1 Dili”)
У разработчика должна быть возможность спокойно порефакторить код, добавить каких-то недостающих тестов. А не с горящей жопой добавлять в код новые костыли, чтобы успеть к дедлайну.
сперва отпустили, потом докапываются
Можно оценить порядок сроков - быстро, порядка недели, порядка месяца, несколько месяцев, дохуя. Это исходит из примерного объема работы.
И всё равно эта оценка неточная, особенно если есть неясные места, которые надо исследовать. Кроме того, в процессе реализации иногда вылазит хуйня, занимающая много времени. Хотя, наоборот тоже случается, когда находится решение, решающее кучу проблем.
Основываясь на этом, придумали покер планирования.