V
привет
Size: a a a
2020 October 23
СК
ну привет
И
Ну и чтобы не уходило много времени на одну таску - надо её разбивать на мелкие части. Так и эстимировать будет легче.
И
Ето называется декомпозиция.
L
Если я тебя правильно понял - тебе надо это всё обсуждать в первую очередь с разрабом, для которого ты создаёшь таску.
Да, ты прав, но иногда разраб не может дать точный ответ по времени. Также, мне для аутсорса необходимо сделать задачу как можно проще и дешевле и с максимальным импактом.
НН
Как я понял, на waterfall собираются все требования, документация и т.д. а потом идет одна итерация, в конце которой происходит релизрелиз.
И если хочешь что то добавить или изменить, то нужно повторять все заново и это уже выльется в новый релиз?
А в RUР этапы разработки и тестирования идут параллельно?
И если хочешь что то добавить или изменить, то нужно повторять все заново и это уже выльется в новый релиз?
А в RUР этапы разработки и тестирования идут параллельно?
я плохо в этом подкован, тут лучше спрашивать тех, кто конкретно в ней работал. Но то как я это вижу, то в случае waterfall есть попытка сделать полноценный тяжеловесный релиз, а в RUP большое внимание уделяется архитектуре и попытка в результате итерации сделать не полноценный релиз. но хотя бы первоначально работающий прототип. То есть в первом случае бизнес получит результат через год, а во втором, какой-то результат есть гораздо раньше. а дальше он просто допиливается.
А
Ребят, вот делаю я задачи для разраба, обсуждаю их с продактом, и иногда он требует переделать всю задачу, т.к. разраб будет долго это реализовывать. Я потихоньку догоняю до некоторых моментов, где там базу надо переделать, где там кэширование не делится, и что эти моменты обсуждаются напрямую с разрабом (или лидом разрабов). Так вот вопрос: есть какие-нибудь материалы или статейки, чтобы помогли начать понимать как вычислять время разработки, время решения задачи?
Статейки не помогут, поможет только практический опыт,когда ты представляешь, пусть и высокоуровнево, что для данной задачи надо будет такие то изменения в базе, в коде, и процедуре деплоя и тп, и на основании этого прикидываешь время разработки. Поэтому планирование и эстимэйты - очень тонкая штука, которая не работает, когда ими занимается вася-манагер с образованием филолога и опытом в ИТ строго в районе менеджемента проектов
И
Да, ты прав, но иногда разраб не может дать точный ответ по времени. Также, мне для аутсорса необходимо сделать задачу как можно проще и дешевле и с максимальным импактом.
Ну, если он не может дать точный ответ - спрашивай временные границы (от и до), ориентируйся по самой большой отметке времени. Лучше, если ты заэстимейтишь 16 часов, а таску сделают за 8 - тогда ты просто дашь ему ещё какую-то. А если ты поставишь 8 часов, а он её будет делать 16 - тогда будут разборы полётов и с тобой, и с ним.
А
ну и в аутсорсе принято разрабом называть сроки в 3 раза больше, потому что манагер все ранво будет пушить их уменьшение, ну и манагер не разработке не разбирается, можно его и обмануть
НН
Как я понял, на waterfall собираются все требования, документация и т.д. а потом идет одна итерация, в конце которой происходит релизрелиз.
И если хочешь что то добавить или изменить, то нужно повторять все заново и это уже выльется в новый релиз?
А в RUР этапы разработки и тестирования идут параллельно?
И если хочешь что то добавить или изменить, то нужно повторять все заново и это уже выльется в новый релиз?
А в RUР этапы разработки и тестирования идут параллельно?
по идее в идеале и в waterfall всё идёт параллельно. То есть как бы пока разрабы делают первый релиз, уже готовится документация ко второму. и потом когда тестеры занимаются полноценным тестированием первого релиза, разрабы могут уже приступить к написанию второго релиза. так что фишка не в этом.
NS
по идее в идеале и в waterfall всё идёт параллельно. То есть как бы пока разрабы делают первый релиз, уже готовится документация ко второму. и потом когда тестеры занимаются полноценным тестированием первого релиза, разрабы могут уже приступить к написанию второго релиза. так что фишка не в этом.
NS
Ещё больше запутался.
NS
Это вообще важно знать? Или, попав на проект, тебе объяснят и понятно все будет?
НН
Это вообще важно знать? Или, попав на проект, тебе объяснят и понятно все будет?
мне кажется, главное в первую очередь понимать разницу между waterfall и agile. ну и хотя бы что существуют какие-то ещё вариации, их названия и хотя бы кратенько о чем они.
НН
Это важно понимать тем, кто управляет проектом. это всё на них по сути.
НН
а если ты пока будешь только учиться - тестировать и что-то ещё, то там уже по ходу можно будет вникнуть, обсудить, посоветоваться, поспрашивать уже знающих людей
И
Ну не совсем на них. Ты же по этому флоу работать будешь и должен его понимать (в идеале)
НН
Ну не совсем на них. Ты же по этому флоу работать будешь и должен его понимать (в идеале)
ну понимать, но понимать изнутри свою часть и понимать всё в целом вещи разные, разве не так?
И
ну понимать, но понимать изнутри свою часть и понимать всё в целом вещи разные, разве не так?
А где граница?
НН
Ну то есть одно дело когда я должен выстроить релизную политику, взаимодействие команд, описать внутренние бизнес процессы, перенести всё это в Жиру и прочее