Какой то профессиональный юмор?
Test Driven Development - одна из идеологий разработки решений экстремального прогрвммирования. Грубо говоря, это когда требования пишутся через ряд тестов, которые решение должны выполниться успешно.
Я это так понимаю, но лучше взгляни на Вики. Там лучше описано.
https://en.m.wikipedia.org/wiki/Test-driven_development
Я это так понимаю, но лучше взгляни на Вики. Там лучше описано.
https://en.m.wikipedia.org/wiki/Test-driven_development
Википедия как то странно выглядит...
Видимо, товарищ с мобильника отвечал, линк на мобильную версию вики.
Оно же для десктопа: https://en.wikipedia.org/wiki/Test-driven_development
Оно же для десктопа: https://en.wikipedia.org/wiki/Test-driven_development
Оно же для десктопа, но по русски: https://ru.wikipedia.org/wiki/Разработка_через_тестирование
Да, про манагеров, которым сначала на конференциях ездят по ушам про всякие "модные тенденции", а потом они старательно мешают работать разработчикам, пытаясь эти "сакральные знания" воплотить.
Новомодные методологии не всегда зло, если 7 раз подумать над рациональностью их использования в текущем проекте учитывая сроки. А другая крайность - это Huyak-huyak driven development, что вполне может прокатить на малых проектах.
коней на переправе не меняют. ТЗ -> созтавления плана действия -> естимейт (оценки сроков) -> согласование с заказчиком -> выполнение. Вклинивать нововведение на последнем пункте, это по сути откат ко второму. И чем больше работы уже сделано, тем больнее будет внедрятся изменение.
Иногда стоит выбор: каким-то образом долго и муторно адаптировать легаси-код с его метастазами по всему проекту, написанный студентом в девяностых, либо по-быстрому переписать велосипед с учётом новых стандартов/использовать готовую проверенную 7 раз либу. Так что иногда действительно проще "переделать всё".
Да но решение переделывать всё принимается не во время выполнения, а во время составления плана. И если уж на этом моменте решили не переделывать, то лучше, как сказали выше, "не менять коней на переправе". Конечно всякое бывает, но если вам пришлось переделывать, то ошибки вы допустили на предыдущих этапах.
я, конечно, не настаиваю, но более жизненный вариант:
согласование с заказчиком -> естимейт (оценки сроков) -> соcтавление плана действия -> ТЗ -> выполнение
согласование с заказчиком -> естимейт (оценки сроков) -> соcтавление плана действия -> ТЗ -> выполнение
А что ты будешь согласовывать с заказчиком не имея ТЗ?
У тебя получается следующее:
З. У меня для вас работа, плачу n-денег
И. За неделю сделаем
И. надо подумать как потратить деньги
З. Напишите мне винду
И. совершает суицид
У тебя получается следующее:
З. У меня для вас работа, плачу n-денег
И. За неделю сделаем
И. надо подумать как потратить деньги
З. Напишите мне винду
И. совершает суицид
И. выкатывает болгенос, все довольны, хэпи энд ^_^
Просто ВольфДП имел в виду ТЗ как набор запросов заказчика, а УберЗаец - ТЗ как формальный документ в ворде.
А это очень просто. Заказчик думает, что представляет конечный результат, но на самом деле совершенно его не представляет. Манагер хочет продать товар и согласен на любой бред, что несет заказчик. Пишется какое-то совершенно формальное и идиотское ТЗ. В процессе реализации этого ТЗ начинают всплывать нюансы, заказчик начинает объяснять, что когда он говорил про теплые котлеты, то имел в виду плавленный сыр. А дальше начинаются свистопляски из компромиссов и костылей. А потом манагеры говорят, что подогнали крутого клиента, а инженеры опять все обосрали.
Я такой геморрой часто вижу, слава богу сам в него редко вляпываюсь. Некоторые на нем учатся, некоторые не учатся, а некоторые, бля, ставят в пример со словами "но вот раньше ж все-таки что-то ж вышло. Можно так же херово все организовать и в этот раз".
Я такой геморрой часто вижу, слава богу сам в него редко вляпываюсь. Некоторые на нем учатся, некоторые не учатся, а некоторые, бля, ставят в пример со словами "но вот раньше ж все-таки что-то ж вышло. Можно так же херово все организовать и в этот раз".
согласовывать буду мутные фантазии заказчика. потому что заказчик, приходящий с готовым ТЗ - это что-то из области влажных фантазий теоретиков
впрочем, я уже понял, что таким как я здесь не рады
впрочем, я уже понял, что таким как я здесь не рады
Ну, это, вроде, только waterfall, есть и другие методологии. Но сути это не меняет - переделывать все всегда дорого и (почти?) всегда не оправдано.
Та епт. К каждому новому выпуску этот коментарий. Хоть тег такой добавляй.
В этом комикс в основном профессиональный юмор.
это джун?
это PM
Чтобы написать коммент, необходимо залогиниться