Всем доброго времени суток,
Я программист и работаю достаточно давно,но до сих пор ошибаюсь со сроками.

Вопрос:
1) подскажите книги , линки , методологию как научится правильно определять сроки выполнения задания или проекта.
2) Как коректно и грамотно аргументировать эти сроку руководству.

Заранее спасибо.

On 15.01.2013 18:00, RobinHood wrote:

> Всем доброго времени суток,
> Я программист и работаю достаточно давно,но до сих пор ошибаюсь со сроками.
Все и всегда ошибались, ошибаются и будут ошибаться, если они не
пророки. Это так, по определению.

Ну а чтобы уменьшить ошибку, разбивай задачу до ясных подзадач
длительностью 3-5 дней. С вот с теми подзадачами, что не до конца ясны,
как повезет.

Здравствуйте, Vzhyk, Вы писали:

V>On 15.01.2013 18:00, RobinHood wrote:


V>Ну а чтобы уменьшить ошибку, разбивай задачу до ясных подзадач
V>длительностью 3-5 дней. С вот с теми подзадачами, что не до конца ясны,
V>как повезет.

Ок , спасибо.
Ну а всетаки есть хорошие книги на эту тему?

On 15.01.2013 18:13, RobinHood wrote:

> Ок , спасибо.
> Ну а всетаки есть хорошие книги на эту тему?
Не знаю. Я больше на своем опыте основываюсь. А 3-5 дней было проверено
на живых людях.

Здравствуйте, RobinHood, Вы писали:

Еще разок дам эту ссылку -- Programmer Time Translation Cheatsheet -or- Why Programmers Are Bad at Estimating Times..

Из книг посоветовал бы неувядающую классику Ф. Брукса. Хотя сроки оценивать она не научит, а больше объяснит природы пропила сроков,
и что не надо делать, чтобы не сделать хуже.

Здравствуйте, RobinHood, Вы писали:

RH> 1) подскажите книги , линки , методологию как научится правильно определять сроки выполнения задания или проекта.

Методология очень простая: садишься и детально представляешь себе как именно ты будешь делать эту задачу. Типа, вот тут мне надо добавить 5 полей в БД, значит нужно поправить тут, там, и еще написать пару SQL скриптов. Потом эти поля нужно протащить в модель, для этого нужно поправить OR mapping в таком-то файле и написать такие-то тесты. И так до конца. В процессе будут попадаться этапы которые ты представляешь смутно, значит нужно исследовать или закладываться на риски. Тренируйся и со временем ты сможешь играть такие планы в голове достаточно быстро.

RH> 2) Как коректно и грамотно аргументировать эти сроку руководству.

Записывай планы в тетрадочку, руководству этого будет достаточно.

On 15.01.2013 18:25, Miroff wrote:

> Записывай планы в тетрадочку, руководству этого будет достаточно.
Руководство разное бывает, посему тут как повезет, кому достаточно, кому
нет, а кому достаточно, но через 3-5 дней он твои сроки в 3 раза подрежет.

Здравствуйте, Vzhyk, Вы писали:

V>Руководство разное бывает, посему тут как повезет, кому достаточно, кому
V>нет, а кому достаточно, но через 3-5 дней он твои сроки в 3 раза подрежет.

Подрежет, сорвешь демонстративно или выкатишь наполовину готовую фичу. Желание подрезать пропадает после одного раза.

Руководство может начать торговаться, но тут главное жертвовать функционалом, а не качеством. Вместо пяти полей добавить одно, а четыре захардкодить; вместо контрола со списком сделать одно большое текстовое поле в котором значения разделяются запятыми; вместо редактора отчетов сделать поле, в которое пользователи могут руками ввести запрос.

Здравствуйте, Vzhyk, Вы писали:

V>On 15.01.2013 18:25, Miroff wrote:

>> Записывай планы в тетрадочку, руководству этого будет достаточно.
V>Руководство разное бывает, посему тут как повезет, кому достаточно, кому
V>нет, а кому достаточно, но через 3-5 дней он твои сроки в 3 раза подрежет.

А ты им вот это показывай:
http://www.youtube.com/watch?v=tBn7WLeEpA4

Здравствуйте, RobinHood, Вы писали:

RH> 1) подскажите книги , линки , методологию как научится правильно определять сроки выполнения задания или проекта.

Методика простая: прикидываешь сроки при наиболее пессиместичном варианте развития событий и умножаешь на 3.

RH> 2) Как коректно и грамотно аргументировать эти сроку руководству.

Если что пеняй все на меня.

On 15.01.2013 18:46, Miroff wrote:

> Подрежет, сорвешь демонстративно или выкатишь наполовину готовую фичу.
> Желание подрезать пропадает после одного раза.
Сразу виден малый опыт. Во-первых, не пропадет, во-вторых, на тебя же
всех собак и повесят, в-третьих, фиг зарплату повысят.

> Руководство может начать торговаться, но тут главное жертвовать
> функционалом, а не качеством.
Руководство, что больное, чтобы торговаться с тобой? Конечно оно
торговаться не будет — оно просто прикажет, а если не нравиться, можешь
увольнятся.

On 15.01.2013 19:05, bkat wrote:

> А ты им вот это показывай:
Откуда такая наивность? Руководство в 90% случаях не волнует подобное,
если не нравиться, можешь увольняться, найдем "менее конфликтных и
готовых к компромиссам".

Здравствуйте, Vzhyk, Вы писали:

V>On 15.01.2013 19:05, bkat wrote:

>> А ты им вот это показывай:
V>Откуда такая наивность? Руководство в 90% случаях не волнует подобное,
V>если не нравиться, можешь увольняться, найдем "менее конфликтных и
V>готовых к компромиссам".

Ну тогда авраль и работай по 80 часов в неделю

On 15.01.2013 20:32, bkat wrote:

> Ну тогда авраль и работай по 80 часов в неделю
Зачем, есть другие методы борьбы с таким руководством, причем можно
вообще около 10% времени рабочего тратить на такое руководство.
Метод — ИБД.

Здравствуйте, Vzhyk, Вы писали:

V>Метод — ИБД.

И ты на это способен? И на подковерные игры тоже?

Неее... Это не мой путь.
ИБД — это же со скуки можно помереть.
Пусть лучше увольняют

RH> Ну а всетаки есть хорошие книги на эту тему?

Одна из лучших, что мне попадалась — "Agile Estimating and Planning", автор — Mike Cohn.

On 15.01.2013 23:44, bkat wrote:

> И ты на это способен? И на подковерные игры тоже?
"Жить захочешь — не так раскорячишься". Но правда через некоторое время
от оного начинает не просто тошнить, а рвать. Почему я и свалил с
последней конторы (но чем они меня восхитили — это количеством ИБД и
тем, что при этом еще контора может вполне успешно существовать).

> ИБД — это же со скуки можно помереть.
Можно чем-то интересным для себя в это время заниматься. Обычно там, где
процветает ИБД — менеджеры бесконечно тупы и вся их жизнь проходит в
"крысиных бегах" (для этого ум не нужен, нужны быстрые типичные рефлексы).

Здравствуйте, RobinHood, Вы писали:

RH>Вопрос:
RH> 1) подскажите книги , линки , методологию как научится правильно определять сроки выполнения задания или проекта.
RH> 2) Как коректно и грамотно аргументировать эти сроку руководству.

В качестве вводной в тему книги можно посоветовать "Сколько стоит программный проект" С. Макконнелл

Здравствуйте, RobinHood, Вы писали:

RH>Всем доброго времени суток,
RH> Я программист и работаю достаточно давно,но до сих пор ошибаюсь со сроками.

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

RH>Вопрос:
RH> 1) подскажите книги , линки , методологию как научится правильно определять сроки выполнения задания или проекта.
есть на эту тему книга от карнеги мелон — PSP (personal software process)
делишь задачу на осмысленные части. далее сохраняешь план. потом по ходу выполнения задачи пишешь сколько заняло времени. накапливаешь статистику промахов. допустим ошибаешься в 2 раза. Будущие оценки делаешь с учетом этого коэффициента, те в 2 раза больше.

RH> 2) Как коректно и грамотно аргументировать эти сроку руководству.
Пиши как можно больше текста и строк в твоей оценке. То есть есть строка "задача х — у часов". у начальства не должно быть ощущений что строку с задачей х можно выкинуть. если обосновать величину у сложно и его может начальство уменьшить, то уменьши сам и напиши больше строк.

RH>Заранее спасибо.
Удачи

Здравствуйте, RobinHood, Вы писали:

RH>Всем доброго времени суток,
RH> Я программист и работаю достаточно давно,но до сих пор ошибаюсь со сроками.

RH>Вопрос:
RH> 1) подскажите книги , линки , методологию как научится правильно определять сроки выполнения задания или проекта.
RH> 2) Как коректно и грамотно аргументировать эти сроку руководству.
Стандартный подход это оцена по loc и метрики сколько ты пишешь строк кода в день помноженное на коэффициент сложности. Это даёт грубую оценку. Вообще, все эти оценки нужно строить на основе статистики по предыдущим задачам или задачам сделанные другими людьми, т.е. для себя сохраняй где-нибудь информацию по количеству строк кода, описание задачи и сложность на тот момент. Я вполне удачно прогнозировал затраты.
Есть ещё методика COCOMO для проектов вцелом. Где-то на форуме читал, что оценки с её помощью дают хороший результат.