Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Работа Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
 Re: Как оценивать время на разработу?  [new]
mayton
Member

Откуда: loopback
Сообщений: 47657
Об чем тут?

Делать break down сложной user story на subtasks - и измерять это правильный способ .

По поводу тестового стенда от Билайна.

Это риски на которые автор не влияет. Их нужно просто письменно закрепить. Дескать мы начнем активную разработку синхронно с доступами.

До этого система будет работать на моках.
5 июн 20, 07:32    [22146101]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
fkthat
Member

Откуда:
Сообщений: 2865
Так-то если подумать, то оценивать именно "время" на разработку оно нафиг никому не нужно (если только ты не получаешь деньги поминутно за затраченное время). Есть достаточно короткая итерация (спринт), есть список стори, которые хотим сделать за эту итерацию - кому какая разница, потратит на эту задачу Вася 2 часа в начале первой недели, или потратит на неё Петя 4 часа в середине второй недели. Это все какой-то древний рудимент, когда сидит надсмотрщик, крутит песочные часы и отслеживает, вдруг, не дай б-г, кто-то на пять минут дольше завозился, чем ему приказали.
5 июн 20, 08:00    [22146106]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
mayton
Member

Откуда: loopback
Сообщений: 47657
Если кто-то начинает трекать твои опоздания в офис или интересуется где ты слил 30 минут времени
за вчера (по репортам нету) - то самое время помахать рукой такой работе.
5 июн 20, 08:56    [22146122]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
bga83
Member

Откуда: Город герой Ленинград
Сообщений: 31243
mayton
Если кто-то начинает трекать твои опоздания в офис или интересуется где ты слил 30 минут времени
за вчера (по репортам нету) - то самое время помахать рукой такой работе.
на эту тему был довольно забавный случай лет 10 назад. Начальник взъелся на на пару моих коллег за экобы медленную работу и заставил писать подробнейший отчет о том когда чем занимался, сколько заняло. Один из коллег помимо всего прочего досконально расписал как в сортир ходил, на что именно и сколько времени там ушло. Больше подобных хотелок со стороны начальника не возникало
5 июн 20, 09:23    [22146136]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
mayton
Member

Откуда: loopback
Сообщений: 47657
Я имею в виду что когда проблемы с бюджетом - начинается херня. Вообще в 99% случаев лид всегда
знает кто бокапорет на проекте и кто слабое звено. И для этого не нужно играть в глобальную слежку.
5 июн 20, 09:28    [22146143]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
L_argo
Member

Откуда:
Сообщений: 1206
Ну классика же:

1. Оценить время на работу.
2. Умножить полученную цифру на 3.
3. Умножить полученную цифру на 3, даже если п.2 уже выполнен.
(с)
5 июн 20, 09:39    [22146160]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
chel_2000
Member

Откуда: Москва
Сообщений: 836
listtoview,

У вас же есть описание API от билайна? Сделайте мок с примитивным поведением, параллельно уведомите стороны о сыгравших рисках из-за получения доступа, которые двигают проект вправо.
5 июн 20, 09:50    [22146169]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62609
Блог
Zmeelov2
Сложившаяся практика такова, что на момент старта проекта не известны не то, что подзадачи - многие задачи не определены. А это неизбежные просчеты в архитектуре и скоростное костылестроение.

Ну почему же неизбежные. Вполне избежные. Другой вопрос, что сложившаяся практика некоторых кривых команд - "тяп-ляп и в продакшн, первую версию всегда выбрасывать, поэтому не тратьте на неё время и силы, и всё это не бага, а фича и так и надо разрабатывать".
5 июн 20, 10:24    [22146199]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
mayton
Member

Откуда: loopback
Сообщений: 47657
softwarer
Другой вопрос, что сложившаяся практика некоторых кривых команд - "тяп-ляп и в продакшн, первую версию всегда выбрасывать, поэтому не тратьте на неё время и силы, и всё это не бага, а фича и так и надо разрабатывать".

Это называется итеративная разработка.
5 июн 20, 10:31    [22146208]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62609
Блог
mayton
softwarer
Другой вопрос, что сложившаяся практика некоторых кривых команд - "тяп-ляп и в продакшн, первую версию всегда выбрасывать, поэтому не тратьте на неё время и силы, и всё это не бага, а фича и так и надо разрабатывать".

Это называется итеративная разработка.

Ну не совсем. Итеративная разработка вполне может существовать сама по себе, без обязательного тяп-ляп и выбрасывать. Это уже личная криворукость разработчиков. Собственно, "водопад", который у определённых религиозных адептов является ипостасью дьявола, на самом деле ровно та же итеративная разработка.
5 июн 20, 10:50    [22146223]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
fkthat
Member

Откуда:
Сообщений: 2865
softwarer
на самом деле ровно та же итеративная разработка.

Водопад это "инкрементная" разработка. Не "итеративная". "Инкремент", это когда мы строим небоскреб. Сначала делаем фундамент, потом поочередно строим этаж за этажом, потом крышу, потом этаж за этажом прокладываем коммуникации, потом этаж за этажом делаем отделку, готово, заселяем. "Итератив" это когда мы строим коттеджный поселок. Построили полностью под заселение первый дом, потом строим полностью под заселение второй и т.д. Не везде применимо (например, в случае с тем же небоскребом) , но, там где применимо, то очевидный плюс в том, что начиная строить домик номер N мы учитываем опыт, косяки и т.п. строительства всех домов с номерами от 1 до N-1, плюс, можем внести коррективы (например, на рынке появился новый строительный суперраствор для кирпичной кладки).
5 июн 20, 11:07    [22146238]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
Vyatich
Member

Откуда:
Сообщений: 3497
softwarer
mayton
пропущено...

Это называется итеративная разработка.

Ну не совсем. Итеративная разработка вполне может существовать сама по себе, без обязательного тяп-ляп и выбрасывать. Это уже личная криворукость разработчиков. Собственно, "водопад", который у определённых религиозных адептов является ипостасью дьявола, на самом деле ровно та же итеративная разработка.

И давно "водопад" стал итеративной разработкой?
5 июн 20, 11:15    [22146243]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 27731
fkthat
softwarer
на самом деле ровно та же итеративная разработка.

Водопад это "инкрементная" разработка. Не "итеративная". "Инкремент", это когда мы строим небоскреб. Сначала делаем фундамент, потом поочередно строим этаж за этажом, потом крышу, потом этаж за этажом прокладываем коммуникации, потом этаж за этажом делаем отделку, готово, заселяем. "Итератив" это когда мы строим коттеджный поселок. Построили полностью под заселение первый дом, потом строим полностью под заселение второй и т.д. Не везде применимо (например, в случае с тем же небоскребом) , но, там где применимо, то очевидный плюс в том, что начиная строить домик номер N мы учитываем опыт, косяки и т.п. строительства всех домов с номерами от 1 до N-1, плюс, можем внести коррективы (например, на рынке появился новый строительный суперраствор для кирпичной кладки).


Все не так.

Итеративная инкрементальная разработка - это когда в конце итерации мы добавляем в продукт нечто полезное.
Некую так называемую ценность. Она и есть инкремент, и это и есть Agile.
5 июн 20, 11:22    [22146248]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62609
Блог
Vyatich
И давно "водопад" стал итеративной разработкой?

С того момента, когда в нём появилось понятие поэтапного ввода в эксплуатацию. Когда именно это произошло - я не знаю, это было до моего рождения.

fkthat
Водопад это "инкрементная" разработка. Не "итеративная". "Инкремент", это когда мы строим небоскреб. Сначала делаем фундамент, потом поочередно строим этаж за этажом

Водопад в программировании быстро превратился в строительство кварталов. Сначала первая очередь строительства (10 домов), потом вторая очередь (ещё 10 домов), потом третья (ещё 20).

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

Сообщение было отредактировано: 5 июн 20, 11:31
5 июн 20, 11:30    [22146254]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
fkthat
Member

Откуда:
Сообщений: 2865
softwarer
С того момента, когда в нём появилось понятие поэтапного ввода в эксплуатацию.

Это еще не итератив. Теоретически, в небоскребе мы можем, допустим, первый этаж сразу под заселение делать, но переиграть второй этаж после того, как мы заселили первый уже не выйдет.
5 июн 20, 11:46    [22146268]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62609
Блог
fkthat
Это еще не итератив. Теоретически, в небоскребе мы можем, допустим, первый этаж сразу под заселение делать, но переиграть второй этаж после того, как мы заселили первый уже не выйдет.

Если это верно, это всего лишь значит, что Ваша строительная аналогия не подходит для программирования.

+
На всякий: программисты очень плохо разбираются в строительстве. Рекомендую как-нибудь поговорить с настоящими строителями, они расскажут про программистские аналогии на этот счёт много интересного.
5 июн 20, 11:49    [22146271]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
fkthat
Member

Откуда:
Сообщений: 2865
softwarer
Водопад в программировании быстро превратился в строительство кварталов. Сначала первая очередь строительства (10 домов), потом вторая очередь (ещё 10 домов), потом третья (ещё 20).

Ну в агиле все то же самое, только кварталы поменьше. В случае факапов менее болезнено получить луч поноса только от жителей N домов и сразу через месяц, чем получить его от жителей 12*N домов, хоть и только через год.
5 июн 20, 11:52    [22146273]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
listtoview
Member

Откуда:
Сообщений: 2359
вот например когда PM занимается оценкой, это пальцем в небо
архитектор и тимлид должны, тогда правдоподобнее
5 июн 20, 11:56    [22146278]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
Vyatich
Member

Откуда:
Сообщений: 3497
softwarer
Vyatich
И давно "водопад" стал итеративной разработкой?

С того момента, когда в нём появилось понятие поэтапного ввода в эксплуатацию. Когда именно это произошло - я не знаю, это было до моего рождения.

Вы уверены, что этапы - это про итерации?
Или вы понимаете под "водопадом" что-то своё?

Каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит.

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a waterfall) through the phases. The next phase is started only after the defined set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model". In this model, phases do not overlap.
5 июн 20, 11:56    [22146279]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62609
Блог
fkthat
Ну в агиле все то же самое, только кварталы поменьше.

Именно так. А размеры кварталов определяются двумя вещами: во-первых, масштабностью, сложностью и смыслом самой задачи (запросом клиента), а во-вторых, технологическими возможностями. Грубо говоря, в 98-м году я бы заманался каждую неделю ездить через полгорода к заказчику выкатывать обновления на прод, а сегодня уже понятие "спринт" откровенно устаревшее и нормально выкатывать позадачно, результаты работы нескольких часов.

fkthat
В случае факапов менее болезнено получить луч поноса только от жителей N домов

Зависит от смысла задачи. Для жилых домов, где основной скоуп интересов на уровне "моя квартира" - оно так и есть. Но если это комплекс связанных зданий, например, цеха какого-нибудь завода, раннее заселение может оказаться бессмысленным и вызовет ровно те самые лучи поноса.

Сообщение было отредактировано: 5 июн 20, 12:02
5 июн 20, 12:03    [22146282]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
Нестандартное мышление
Member

Откуда:
Сообщений: 78
Разработка новой системы - это космос. Тут вообще планировать трудно. Это как художника спросить - за какое время вы напишите картину?

А если стандартные итерации, то тогда возможно по усредненным временам предыдущих разработок считать. Умножив на 2.
5 июн 20, 12:03    [22146283]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
mayton
Member

Откуда: loopback
Сообщений: 47657
Ого тут теоретики подтянулись.
5 июн 20, 12:06    [22146287]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3708
mayton
Ого тут теоретики подтянулись.

Подкинем дровишек...

Итеративная инкрементальная разработка (IID) как альтернатива модели водопада

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

Разработка ПО – молодая отрасль, и не приходится удивляться, что построенная в соответствии со схемой «требования, проектирование, реализация» упрощенческая модель водопада,
предусматривающая создание ПО за один проход на основании заранее составленных документов устояла в ходе первых попыток найти идеальный процесс разработки.
Можно назвать и другие причины, объясняющие быстрое распространение и долгую популярность идеи «водопада». Эту идею легко объяснить и легко запомнить. "Выяви требования, потом проектируй, а потом реализуй".
Она создает иллюзию упорядоченного, объяснимого и обеспечивающего возможность измерений процесса, размеченного простыми вехами, взятыми из документов (например, "стадия выявления требований завершена").
IID труднее и описать, и понять.

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

Картинка с другого сайта.

Согласно этой модели каждая итерация должна начинаться с выделения целей и планирования очередной итерации, определения основных альтернатив и ограничений при ее выполнении,
их оценки, а также оценки возникающих рисков и определения способов избавления от них. Итерация должна заканчиваться оценкой результатов проведенных в ее рамках работ.
Основным новым элементом спиральной модели является общая структура действий на каждой итерации – планирование, определение задач, ограничений и вариантов решений,
оценка предложенных решений и рисков, выполнение основных работ итерации и оценка их результатов.

В настоящее время большинство специалистов отдают предпочтение IID. Водопадная модель хорошо удовлетворяет потребностям управления проектом. С практической точки зрения эта модель непригодна.
Вот несколько причин этого:
  • При формировании требований к ПО пользователи редко имеют четкое представление о том, что им нужно, и не могут сформулировать все, что им известно.
  • Даже если мы можем изложить все требования к системе, существует множество деталей, которые будут обнаружены лишь после того, как процесс проектирования продвинется довольно далеко.
  • Внешние силы приводят к изменению требований, причем некоторые из этих изменений могут свести на нет ранее принятые решения.
  • Представление о том, будто разработчик ПО создает свой программный продукт свободным от ошибок на основе спецификации требований, абсолютно нереалистично.
Ошибки в требованиях и их реализации выявляются только в конце проекта, когда написан весь код, поэтому трудоемкость их исправления становится просто огромной.
5 июн 20, 12:14    [22146299]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
DaniilSeryi
Member

Откуда:
Сообщений: 1718
listtoview
сабж

Модератор: Тема перенесена из форума "ASP.NET".


Прикидываете время выполнения, умножаете на 2 и увеличиваете порядок.
5 июн 20, 13:58    [22146378]     Ответить | Цитировать Сообщить модератору
 Re: Как оценивать время на разработу?  [new]
mayton
Member

Откуда: loopback
Сообщений: 47657
Мне вспоминается английска песенка где Король в конце-концов с слезами и соплями сказал

- Просил я только масла на завтрак мне подать.
5 июн 20, 13:58    [22146379]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Работа Ответить