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

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

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

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

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

A>Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?

С моей стороны могу лишь дать одну рекомендацию: не торопиться. Не добавлять ни одну новую практику до тех пор, пока старые не вошли в привычку, не стали рафинированными и удобными для всех членов команды. Как пример: если вы решили вести учёт часов, потраченных на решение тикета в саппорт-системе, не внедряйте новые практики до тех пор, пока эта не будет принята и используема всеми. Например, вам может потребоваться интеграция тикет-системы с системой версионного контроля, чтобы разработчик, выполняя commit (push, иное публикационное действие), мог не только автоматически закрывать (передавать в тестирование, ...) тикет, но и указывать количество потраченного времени, скажем, тегом в commit message.

Потому как если начинается "мы наш, мы новый мир построим" — это 100% гарантия натолкнуться на стену непонимания, неприятия и необходимость применения административных мер.

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

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

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

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

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

On 25.02.2013 15:33, Aikin wrote:

> *Vzhyk*, ты ж умный мужик, поэтому напрашивается вопрос: ты потролить
> вышел или действительно знаешь почему это не будет работать?
А если говорить непосредственно о коде, то со своего опыта работы я
пришел к простому выводу: код сам по себе может быть любым. Главное,
чтобы выполнялись функциональные и не функциональные требования, а также
был разделен на независимые, по возможности, небольшие части. Что внутри
каждой части — пофиг, будь там хоть навороченный С++ с стиле
александреску или тупейший С в стиле начала 90-х.
Если требования изменяться, там и видно будет, ибо будущее не возможно
угадать, как бы кому не хотелось. Сам тоже страдаю тем, что хочется
написать идеально, но бью себя по рукам и пишу так, чтобы удовлетворяло
требованиям сейчас, а не в некоем вероятном будущем. Много раз бывало,
пишешь красивый, расширяемый код, а задача заканчивается и к ней никто
не возвращается. А бывает все уверены, что надо быстро-быстро написать и
отвязаться, а оказывается, что именно это и потребует поддержку на
ближайшие несколько лет.

On 15.01.2013 23:44, bkat wrote:

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

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

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

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

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

On 15.01.2013 18:00, RobinHood wrote:

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

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

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

V>On 15.01.2013 19:05, bkat wrote:

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

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

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


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

Когда-то я писал на эту тему. Посмотрите ссылки:

Как делать эстимейты?
Как делать эстимейты? Часть 2.
Как сделать грубый эстимейт?

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

RH>Всем доброго времени суток,
RH> Я программист и работаю достаточно давно,но до сих пор ошибаюсь со сроками.
Потому что оценка и программирование — разные задачи, для них нужна разная тренировка.

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

Personal Software Process — несколько книг в открытом доступе. Но без курсов "не взлетит".

Краткая выжимка из PSP и опыта.
Чтобы научиться прогнозировать срок надо отделить оценку объема от оценки срока.

Объем должен считаться формально, то есть должен учитывать конкретные параметры. Например количество строк кода или количество "входов" и "выходов" модуля, помноженное на коэффициент сложности для типа модуля. Единица измерения не важна, главное чтобы она была одинаковая в команде.

Далее нужна статистика по длительности выполнения задач (с указанным объемом). При наличии уже небольшого количества измерений можно заметить явную корреляцию. Это кстати называется velocity в скраме. Даже если ошибиться в оценки одного модуля, то в среднем на крупной системе оценка будет сходится к мат. ожиданию. Если корреляция не наблюдается, то неправильно оценен объем, какие-то факторы не учтены.

http://files.rsdn.ru/20496/ISV%20Oracle%20final.pdf в этой презентации Gaperton ближе к концу указал эффективный способ.

Самое важное тут оценивать не отдельные задачи, а готовность модуля, в том числе дизайн, разработку, тестирование, деплоймент и вплоть до поставки на production.

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

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

G>>http://files.rsdn.ru/20496/ISV%20Oracle%20final.pdf в этой презентации Gaperton ближе к концу указал эффективный способ.
G>>Самое важное тут оценивать не отдельные задачи, а готовность модуля, в том числе дизайн, разработку, тестирование, деплоймент и вплоть до поставки на production.

A>gandjustas, немного провокационный вопрос, если можно На самом деле он не провокациооный, если знать почему я его задаю
A>Ты это все на практике применял? Как долго? Как внедрял в команде?
Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач.

On 25.02.2013 15:33, Aikin wrote:

> V>Не боишься, что в угоду считаемому параметру программисту будут писать
> V>код хуже?
>
> *Vzhyk*, ты ж умный мужик, поэтому напрашивается вопрос: ты потролить
> вышел или действительно знаешь почему это не будет работать?
В данном случае знаю. Несколько раз на разных конторах начальство
пыталось вводить некие метрики и они срабатывали в первый месяц-два.
Затем программисты быстро-быстро под них подстраивались уменьшая
внимание непосредственной работе. Еще через 4 месяца начальство забивало
на это, ибо по мертикам все красиво, а выхлоп меньше становился.
Это все закономерно, человек не настолько тупой (не робот) и очень
хорошо умеет приспосабливаться и делать то, что ему выгоднее и легче, а
подстроиться под несколько метрик — раз плюнуть. Причем даже если в
системе будут тысячи метрик, то человек все одно быстро найдет
оптимальное поведение с минимальными затратами своих сил.
Фактически, только другой человек (начальник) может быть адекватной
метрикой другому человеку (подчиненному) и даже в этом случае люди
подстраиваются под метрику.

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

RH>> 1) подскажите книги , линки , методологию как научится правильно определять сроки выполнения задания или проекта.
M>Методика простая: прикидываешь сроки при наиболее пессиместичном варианте развития событий и умножаешь на 3.
Это неточная методика. Правильно умножать на π.

RH>> 2) Как коректно и грамотно аргументировать эти сроку руководству.
M>Если что пеняй все на меня.
Если что, π выглядит гораздо более научно.

А если серьёзно, то особо хороших методов для уточнения оценки нет, да и быть не может. Есть лишь рекомендации, чтобы ошибки оценок обнаруживались как можно раньше и вредили проекту как можно меньше: разбивать задачу на очень маленькие таски — 1-2 дня, самый максимум — неделя, устанавливать точный критерий завершенности таска (висящих месяцами "почти сделаных" тасков быть не должно).

Можно аналогию с программированием провести: писать без багов невозможно, но возможно упростить их поиск, уменьшить количество мест для багов, уменьшить ущерб от багов.

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

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

G>>А чего конкретно хочется добиться? И чем занимаетесь?
A>Увеличить точность оценки и прогнозирования сроков. Заказчику, как я говорил, все равно (сколько бы он не бухтел по этому поводу). Мне это нужно для прокачики скилов и получения опыта.
A>Занимаемся desctop/mobile разработкой для заводов по производству шин.

Самый простой способ:
1) Если еще не сделано, то привязать задачи к фичам. У фичи должен быть business value и некоторая независимость от других фич. Все задачи, начиная от анализа, заканчивая бакгфиксом и развертыванием должны быть привязаны к фичам.
2) Взять законченные фичи (по которым разработка не ведется и редко возникает багфикс), попросить команду оценить объем\сложность задачи в условных попугаях. Например маленьая фича — один условный попугай, фича в 2 раза больше — 2 попугая. Лучше использовать нелинейную шкалу, например числа фибоначчи. Главное именно объемы оценивать, а не
3) Записать в качестве baseline то что было выбрано, как один попугай.
4) Взять исторические данные по времени разработки и посчитать сколько реальных человеко-дней требует разработка одного условного попугая. Естественно надо учитывать только time-on-task, а не календарное время. Лучше в днях считать, а не в часах. Часы обычно сильно неточны.
5) Если корреляции между сложностью и временем не наблюдается на всей выборке, то проблем скорее всего упирается в квалификацию разработчиков.

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

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

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

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

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

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

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

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

On 19.02.2013 23:14, gandjustas wrote:

> Например количество строк кода или количество "входов" и
> "выходов" модуля, помноженное на коэффициент сложности для типа модуля.
А можно узнать оперделение сложности?
Ну и второй вопрос, когда я нечно запишу в одну строку, ибо так понятнее
(сила transform и лямбд) или двумя-тремя вложенными циклами, как считать
количество строк будешь?

> Единица измерения не важна, главное чтобы она была одинаковая в команде.
Что лучше для программиста в команде написать в одну строку или 2-3-мя
вложенными циклами?
Не боишься, что в угоду считаемому параметру программисту будут писать
код хуже?

On 26.02.2013 17:53, Aikin wrote:

> Топам можно сказать пофик. У нас почасовка. А у заказчика других проблем
> хватает, чтобы такой "фигней" заниматься.
> Вообще, цель для меня "поучиться/поиграться". Меня тоже устраивает
> текущее положение. В котором у меня есть свободное время и я "хочу
> что-то улучшить".
> Один из скилов, который хочется прокачать это оценка сроков.
Пойми, что как только ты начнешь народ вокруг напрягать, получишь
сопротивление и чем сильне напрягать будешь,тем больше сопротивление
будет. И фактически единственный способ его сломать, или хотя бы
уменьшить — это дополнительное давление с самого верха.
Например, простейший TDD я внедрял таким образом и убеждением и
давлением со стороны топа.

> Вообще-то теретически вариантов много и без топов: личный пример,
> убеждение, обсуждение, "а может попробуем, хуже точно не будет, может и
> выгорит". И это только то что навскидку пришло в голову.
Можно, но затраты личной энергии бешенные. Ибо в этом случае нужно
каждого убеждать, уговаривать, ублажать и т.д.

> Я как разработчик, уже много раз сталкивался с внедрением практив без
> поддержки топов. У меня чаще всего прокатывает "личный пример".
Ты бы лучше свою энергию по делу применил и начал свое что продвигать, а
не на дяде кошелек пополнять. Личная энергия — это все.
А с возрастом ее все меньше и меньше будет.

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

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

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

Здравствуйте, 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 дней было проверено
на живых людях.

On 15.01.2013 18:25, Miroff wrote:

> Записывай планы в тетрадочку, руководству этого будет достаточно.
Руководство разное бывает, посему тут как повезет, кому достаточно, кому
нет, а кому достаточно, но через 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

On 15.01.2013 18:46, Miroff wrote:

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

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

On 15.01.2013 19:05, bkat wrote:

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

On 15.01.2013 20:32, bkat wrote:

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

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

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

Здравствуйте, 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 для проектов вцелом. Где-то на форуме читал, что оценки с её помощью дают хороший результат.

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

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

V>>On 15.01.2013 18:00, RobinHood wrote:


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

RH>Ок , спасибо.
RH> Ну а всетаки есть хорошие книги на эту тему?
например здесь: http://www.arkhipenkov.ru/resources/sw_project_management.pdf

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

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

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

Сразу виден большой опыт и неумение разговаривать с людьми. Демонстративно делать не нужно конечно это по сути рукотворный конфликт. Просто говоришь что такие сроки нереальны.
В нормальных конторах ты отвечаешь за то что ты сказал. Ты называешь Х, начальник говорит Х/3. Ты говоришь не реально, вот план покажи где можно ускорить. Если ты с планом не накосячил то ускорить никак. А дальше как обычно либо сроки подвинуть, либо функционал подрезать(то что выше называлось торговаться) либо людей докинуть(если это возможно). Либо все вместе.

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

ИМХО лучше увольняться с неадекватами работать нереально.

On 19.02.2013 18:04, __SPIRIT__ wrote:

> В нормальных конторах ты отвечаешь за то что ты сказал.
Зуб даешь?

> Ты называешь Х,
> начальник говорит Х/3.
В нормальных конторах так начальник не говорит.

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

>> В нормальных конторах ты отвечаешь за то что ты сказал.
V>Зуб даешь?

Не согласен — озвучивай свою позицию. Если тебе очень нужен мой коллекционный зуб, когда придется выдирать, могу прислать. Или может тебя старая пломба устроит?

>> Ты называешь Х,
>> начальник говорит Х/3.
V>В нормальных конторах так начальник не говорит.

Всяко бывает. Сейчас вот пытаемся впихнуть проект в Х/3. Тут же вопрос как это сделать.
Была задача, на нее эстимэйт Х. А бюджет примерно Х/3. В итоге резали скоп, плясали с требованиями чтобы желаем впихнуть в реальность.
Если бы "начальник" пришел и сказал: "Вот! Я так решил а вы делайте вот это вот за это время. И точка" Ответом ему было бы: "ты решил теперь делай ".
Но в нормальной ситуации, обычно, есть понимание что работу на Х часов нельзя сделать за Х/2 или Х/3 при прочих равных.
И если менеджмент это понимает то желание получить Х/3 это именно желание и рабочий момент. И что это желание может так и остаться желанием

On 19.02.2013 20:08, __SPIRIT__ wrote:

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

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

V>Так чем ты отвечать собрался? Домом? Женой? Детьми? По сути
V>ответсвенность только у тех, у кого есть право принимать решение и
V>именно в рамках этого права, все остальное — пустая болтовня.

Я отвечаю перед заказчиками и менеджментом более высокого уровня за свои решения. Передо мной отвечают мои подчиненные. Домом отвечают только владельцы и то изредка.

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

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

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

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

Оценка проекта и оценка задач — сильно разные вещи. Оценку проекта можно делать и без оценки задач. Это называется "экспертной оценкой" и именно оно чаще всего применяется.

On 19.02.2013 21:45, __SPIRIT__ wrote:

> Я отвечаю перед заказчиками и менеджментом более высокого уровня за свои
> решения.
Так чем ты отвечаешь? Простой вопрос из 3 слов, ты на него ответишь не
можешь уже 3 поста.

> Домом отвечают только
> владельцы и то изредка.
С этими понятно. К тебе это не относится.

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

V>On 19.02.2013 23:14, gandjustas wrote:

>> Например количество строк кода или количество "входов" и
>> "выходов" модуля, помноженное на коэффициент сложности для типа модуля.
V>А можно узнать оперделение сложности?

Зачем? Коэффициент подбирается экспериментальным или эмпирическим путём. Физический смысл его не имеет значения.

V>Ну и второй вопрос, когда я нечно запишу в одну строку, ибо так понятнее
V>(сила transform и лямбд) или двумя-тремя вложенными циклами, как считать
V>количество строк будешь?
Буду бить по почкам за запись в одну строку. Считать сразу проще станет.


>> Единица измерения не важна, главное чтобы она была одинаковая в команде.
V>Что лучше для программиста в команде написать в одну строку или 2-3-мя
V>вложенными циклами?
V>Не боишься, что в угоду считаемому параметру программисту будут писать
V>код хуже?
См ремарку про почки выше. Попытка обмана будет обнаружена на review. Да и нет смысла обманывать. Зп от количества строк не меняется.

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

V>Так чем ты отвечаешь? Простой вопрос из 3 слов, ты на него ответишь не
V>можешь уже 3 поста.

Я отвечаю репутацией, перспективами(в широком смысле не только в плане карьеры), работой в конце концов.

>> Домом отвечают только
>> владельцы и то изредка.
V>С этими понятно. К тебе это не относится.

Да, также как и к тебе.

On 20.02.2013 15:03, __SPIRIT__ wrote:

> Я отвечаю репутацией, перспективами(в широком смысле не только в плане
> карьеры), работой в конце концов.
Во-во. То есть максимум чем ты отвечаешь, что придется сменить работу и
возможно на более высокооплачиваемую.

> Да, также как и к тебе.
Вот поэтому я тебе и пишу, что ничем ни один из наемных работников не
отвечает.

On 20.02.2013 15:02, gandjustas wrote:

> V>Ну и второй вопрос, когда я нечно запишу в одну строку, ибо так понятнее
> V>(сила transform и лямбд) или двумя-тремя вложенными циклами, как считать
> V>количество строк будешь?
> Буду бить по почкам за запись в одну строку. Считать сразу проще станет.
Так как писать-то надо?

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

V>Во-во. То есть максимум чем ты отвечаешь, что придется сменить работу и
V>возможно на более высокооплачиваемую.
V>Вот поэтому я тебе и пишу, что ничем ни один из наемных работников не
V>отвечает.

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

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

V>Ну и второй вопрос, когда я нечно запишу в одну строку, ибо так понятнее
V>(сила transform и лямбд) или двумя-тремя вложенными циклами, как считать
V>количество строк будешь?

V>Не боишься, что в угоду считаемому параметру программисту будут писать
V>код хуже?

Vzhyk, ты ж умный мужик, поэтому напрашивается вопрос: ты потролить вышел или действительно знаешь почему это не будет работать?


СУВ, Aikin

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

G>http://files.rsdn.ru/20496/ISV%20Oracle%20final.pdf в этой презентации Gaperton ближе к концу указал эффективный способ.
G>Самое важное тут оценивать не отдельные задачи, а готовность модуля, в том числе дизайн, разработку, тестирование, деплоймент и вплоть до поставки на production.

gandjustas, немного провокационный вопрос, если можно На самом деле он не провокациооный, если знать почему я его задаю
Ты это все на практике применял? Как долго? Как внедрял в команде?

Дело вот в чем: у меня лично теории по этой теме вагон, а вот на практике я как-то это все опасаюсь применять. Скорее всего потому, что оно итак работает. Я не спорю, что может работаь лучше, но и так неплохо.
Вот и собираю теорию и отзывы от практиков.

СУВ, Aikin

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

V>В данном случае знаю. Несколько раз на разных конторах начальство
V>пыталось вводить некие метрики и они срабатывали в первый месяц-два.
V>Затем программисты быстро-быстро под них подстраивались
Это понятно. Все это сто раз обсасывалось. Пришли к выводу, что мерить производительность программеров, а особенно поощрять/наказывать на основе этой производительности нельзя.

V>Это все закономерно, человек не настолько тупой (не робот) и очень
V>хорошо умеет приспосабливаться и делать то, что ему выгоднее и легче, а
V>подстроиться под несколько метрик — раз плюнуть.
Вот это другой вопрос. Ответ на него только неожиданный: а с чего бы человеку было выгоднее и легче приспосабливаться под метрику?
И получается, что дело не в метрике, а в том, как ее использовать.
gandjustas, а до этого Гапертон, предлагают оценивать сроки с помощью метрик, а не объем пряников и люлей.


V>Фактически, только другой человек (начальник) может быть адекватной
V>метрикой другому человеку (подчиненному) и даже в этом случае люди
V>подстраиваются под метрику.
Люди ошибаются, начальство не всегда компетентно в этих вопросах (именно этим я и пользуюсь работая только 3-4 часа в день), даже если оно компетентно, то должно пройти время, чтобы начальник "просчитал" человека и мог его оценивать.


По поводу резонного замечания "меньше работы за те же деньги -- лучше". Люди у нас работают, в основном, адекватные. И если их не обижать, то и они тебя не обидят. Хотя контроль, конечно же, терять нельзя.
И еще: Мой нормальный ритм -- 3-4 часа в день работы непосредственно над задачами проекта. То же самое я поощряю внутри команды (если человек тянет, конечно). Чем люди будут заниматься в оставшееся время меня не волнует до тех пор пока работа работается. В качестве метрики "работа работается" выступает мое "экспертное мнение" и "реакция заказчика" (мое "экспертное мнение" может тюниться в обе стороны в зависимости от реакции заказчика).

СУВ, Aikin

On 25.02.2013 16:23, Aikin wrote:

> *gandjustas*, а до этого *Гапертон*, предлагают оценивать сроки с
> помощью метрик, а не объем пряников и люлей.
Это да. Причем они считают, и даже имеют некоторые практические
доказательства, что это работает. Я же с ними согласен в применимости
данного только очень похожих повторяемых задачах. В других — обычное
угадывание, называемое экспертной оценкой. И по опыту похожих
повторяемых задач в нашей области мало, обычно каждый раз разная. А если
есть повторяемые и похожие задачи, то их можно автоматизировать.

> Люди ошибаются, начальство не всегда компетентно в этих вопросах (именно
> этим я и пользуюсь работая только 3-4 часа в день), даже если оно
> компетентно, то должно пройти время, чтобы начальник "просчитал"
> человека и мог его оценивать.
Да. Но выбора нет. Причем, начальник может прекрасно это видеть (про 3-4
часа), но есть много причин, по которым он и не требует от тебя большего.

> По поводу резонного замечания "меньше работы за те же деньги -- лучше".
> Люди у нас работают, в основном, адекватные. И если их не обижать, то и
> они тебя не обидят. Хотя контроль, конечно же, терять нельзя.
А тут мы попадаем в обычную физиологию. Вне зависимости от адекватности,
если человек может меньше затратить сил, то он это и сделает.

> И еще: Мой нормальный ритм -- 3-4 часа в день работы непосредственно над
> задачами проекта. То же самое я поощряю внутри команды (если человек
> тянет, конечно). Чем люди будут заниматься в оставшееся время меня не
> волнует до тех пор пока работа работается.
В связи с моим замечание выше, все одно людей надо немного стимулировать
(именно "стимулом"), иначе потихоньку будут уменьшать выработку сами не
замечая этого. Если некоторая работа "приедается", можно подкинуть на
остальные 3-4 часа чего другого, более интересного подчиненному, чего с
расчетом на будущее.

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

V>On 25.02.2013 16:23, Aikin wrote:

>> *gandjustas*, а до этого *Гапертон*, предлагают оценивать сроки с
>> помощью метрик, а не объем пряников и люлей.
V>Это да. Причем они считают, и даже имеют некоторые практические доказательства, что это работает. Я же с ними согласен в применимости данного только очень похожих повторяемых задачах. В других — обычное угадывание, называемое экспертной оценкой. И по опыту похожих повторяемых задач в нашей области мало, обычно каждый раз разная. А если есть повторяемые и похожие задачи, то их можно автоматизировать.
Я работал по скраму — раздельная оценка объема и усредненная производительность в команде действительно лучше, чем угадывание сроков. Реальных метрик, к сожалению, нет, потому что первый раз скорее интуитивно делал и работало, но проекты были простые, а сейчас хромает из-за оценки объема на сложных проектах.

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

A>>Ты это все на практике применял? Как долго? Как внедрял в команде?
G>Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач.
Не совсем в тему, но чего в шарик потянуло? Количество граблей в нем — это для мазохиста какого-то.

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

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

A>>>Ты это все на практике применял? Как долго? Как внедрял в команде?
G>>Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач.
A>Не совсем в тему, но чего в шарик потянуло? Количество граблей в нем — это для мазохиста какого-то.
Ближе к бизнесу, деньги хорошие платят. И если уметь готовить, то сильно экономит силы.

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

На самый главный посыл моего предыдущего сообщения ты не ответил:

V>Это все закономерно, человек не настолько тупой (не робот) и очень
V>хорошо умеет приспосабливаться и делать то, что ему выгоднее и легче, а
V>подстроиться под несколько метрик — раз плюнуть.
Вот это другой вопрос. Ответ на него только неожиданный: а с чего бы человеку было выгоднее и легче приспосабливаться под метрику?
И получается, что дело не в метрике, а в том, как ее использовать.

Вот это было самое главное, остальное контекст и мои мысли по этому поводу.

СУВ, Aikin

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


A>>gandjustas, немного провокационный вопрос, если можно На самом деле он не провокациооный, если знать почему я его задаю
A>>Ты это все на практике применял? Как долго? Как внедрял в команде?
G>Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач.
Спасибо.
Вот как раз "Внедрял очень насильственно" у меня не получится Я уже пару раз "внедрял", получил по сусалу, теперь немного скован в средствах

Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?

СУВ, Aikin

On 26.02.2013 17:13, Aikin wrote:

> Вот это другой вопрос. Ответ на него только неожиданный: *а с чего
> бы человеку было выгоднее и легче приспосабливаться под метрику*?
> Вот это было самое главное, остальное контекст и мои мысли по этому поводу.
Как только метрику начнут использовать прямо или косвенно, неважно, к
оценке труда.
И очень сложно не применить метрику так, даже когда ты оцениваешь объем
работы, основываясь на метриках, что ранее снял по таким проектам.

Я же уже не раз объяснял свое видение метрик, в програмерской работе они
не применимы, потому что у нас не конвейер, по опредлению. И даже на тех
участках работы, где появляется конвейер, он быстро заканчивается,
потому как эта работа автоматизируется тут же.
Но это моя точка зрения и не более.

On 26.02.2013 17:13, Aikin wrote:

> Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?
Только, если убедишь в том, что ты хочешь внедрить топов и они будут
тебя поддерживать.

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

>> Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?
V>Только, если убедишь в том, что ты хочешь внедрить топов и они будут тебя поддерживать.
Топам можно сказать пофик. У нас почасовка. А у заказчика других проблем хватает, чтобы такой "фигней" заниматься.
Вообще, цель для меня "поучиться/поиграться". Меня тоже устраивает текущее положение. В котором у меня есть свободное время и я "хочу что-то улучшить".
Один из скилов, который хочется прокачать это оценка сроков.


V>Только, если убедишь в том,
Вообще-то теретически вариантов много и без топов: личный пример, убеждение, обсуждение, "а может попробуем, хуже точно не будет, может и выгорит". И это только то что навскидку пришло в голову.
Я как разработчик, уже много раз сталкивался с внедрением практив без поддержки топов. У меня чаще всего прокатывает "личный пример".

СУВ, Aikin

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

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


A>>>gandjustas, немного провокационный вопрос, если можно На самом деле он не провокациооный, если знать почему я его задаю
A>>>Ты это все на практике применял? Как долго? Как внедрял в команде?
G>>Да, порядка года, потом случился кризис. Внедрял очень насильственно. Проекты были простые — сайты. Сейчас работаю с sharepoint, не гладко получается, особенно с оценкой объема задач.
A>Спасибо.
A>Вот как раз "Внедрял очень насильственно" у меня не получится Я уже пару раз "внедрял", получил по сусалу, теперь немного скован в средствах

A>Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?

А чего конкретно хочется добиться? И чем занимаетесь?

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

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

Лучше всего для оценки сроков использовать среднее проектерическое: сумма оптимистической и пессиместической оценок помноженная на два.

V>В данном случае знаю. Несколько раз на разных конторах начальство
V>пыталось вводить некие метрики и они срабатывали в первый месяц-два.
V>Затем программисты быстро-быстро под них подстраивались уменьшая
V>внимание непосредственной работе. Еще через 4 месяца начальство забивало
V>на это, ибо по мертикам все красиво, а выхлоп меньше становился.

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

A>gandjustas, а до этого Гапертон, предлагают оценивать сроки с помощью метрик, а не объем пряников и люлей.

Хочу немножко поправить, идеи сии сформулированы отнюдь не уважаемыми участниками форума, но задолго до них. Собственно, эти идеи и легли в основу Agile-процессов.

V>Это да. Причем они считают, и даже имеют некоторые практические
V>доказательства, что это работает. Я же с ними согласен в применимости
V>данного только очень похожих повторяемых задачах. В других — обычное
V>угадывание, называемое экспертной оценкой. И по опыту похожих
V>повторяемых задач в нашей области мало, обычно каждый раз разная. А если
V>есть повторяемые и похожие задачи, то их можно автоматизировать.

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

A>Вообще, цель для меня "поучиться/поиграться". Меня тоже устраивает текущее положение. В котором у меня есть свободное время и я "хочу что-то улучшить".

Это не самая удачная причина для внедрения каких бы то ни было практик. Возможно, вам следует сменить должность на что-нибудь более подходящее вашим интересам. Потому как работодателю обычно интересна не "прокачка скиллов на рабочем месте", а выполнение проектов в срок и без сбоев.
Может, попробуете уговорить руководство официально оформить вас как, например, "советника по процессам", дабы ваши рекомендации могли иметь некий вес и смысл. И не выглядели как инициатива по изучению чего-то нового, но на работе не нужного.

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

G>Personal Software Process — несколько книг в открытом доступе. Но без курсов "не взлетит".

G>Краткая выжимка из PSP и опыта.
G>Чтобы научиться прогнозировать срок надо отделить оценку объема от оценки срока.

G>Объем должен считаться формально, то есть должен учитывать конкретные параметры. Например количество строк кода или количество "входов" и "выходов" модуля, помноженное на коэффициент сложности для типа модуля. Единица измерения не важна, главное чтобы она была одинаковая в команде.

Посоветуй пожалуйста, конкретные книги по Personal Software Process. Наиболее ценные на твой взгляд.
Если читать все подряд что попадается в интернет, то до сути долго придется добираться...
Желательно на русском. Хотя и на английском могу читать. Но на русском читаю быстрее

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

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

G>Оценка проекта и оценка задач — сильно разные вещи. Оценку проекта можно делать и без оценки задач. Это называется "экспертной оценкой" и именно оно чаще всего применяется.

Не совсем понял твою мысль.
Ты имеешь ввиду что С. Макконнелл в "Сколько стоит программный проект" неправильно оценивает проекты?

On 27.02.2013 2:59, SkyDance wrote:

> И как начальство замечало это самое "выхлоп меньше становился"? Стало
> быть, у начальства таки есть вполне конкретные метрики "выхлопа". Просто
> в силу каких-либо причин начальство не в состоянии их квантифицировать и
> формализовать.
Ну еще бы — прибыль, или в более простом варианте проекты начинают
делаться медленее, а картинки становятся красивее.
Каждый человек в полу- годовом промежутке вполне способен заметить такое.

On 27.02.2013 3:08, SkyDance wrote:

> Возможно, в силу недостатка опыта, можно считать, что "задачи каждый раз
> разные". Но это не так, задача каждый раз одинаковая — реализовать то-то
> и то-то вот в таких условиях. Причем чаще всего решений подобной
> проблемы существует несколько, требуется лишь выбрать одно. И выбор этот
> зачастую случаен. По принципу "из двух зол выбирай то, которое еще не
> пробовал".
> С накоплением стажа и опыта участия в разной деятельности понимание
> схожести задач обязательно приходит.
Хотелось, что-то попытаться объяснить тебе, но для высоты твоего опыта
можно только сказать: "Ты не прав". Пройдет время — поймешь. Да и я
через такое воприятие тоже проходил, потом понял, что оно ошибочно.

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

V>Ну еще бы — прибыль,

Прибыль напрямую не связана с выполнением задания/проекта. Она может падать, например, потому, что вышли продукты конкурентов. Или просто сезонно. Иными словами, если программист является исключительно наёмным работником и не получает процента с прибыли, использовать прибыль как метрику бессмысленно.

V>или в более простом варианте проекты начинают
V>делаться медленее, а картинки становятся красивее.

Что в вашем понимании означают выделенные слова? В моём — ровно то, что я написал:

у начальства таки есть вполне конкретные метрики "выхлопа". Просто в силу каких-либо причин начальство не в состоянии их квантифицировать и формализовать.

On 28.02.2013 0:56, SkyDance wrote:

> V>Ну еще бы — прибыль,
>
> Прибыль напрямую не связана с выполнением задания/проекта.
Опять метрики... Метрику чево? Метрику наполняемости кошелька владельцев
и топов?
Я как-то заметил, как только кошельк начинает становиться тоньше — это
все мгновенно чувствуют и начинают быстро-быстро искать дырки в нем и
обычно их заделывают.

> у начальства таки есть вполне конкретные метрики "выхлопа". Просто в
> силу каких-либо причин начальство не в состоянии их квантифицировать
> и формализовать.
Ровно до того момента, как кошелек владельца начинает становиться
тоньше. ДО этого можете с метриками "выхлопа" играться сколько хотите. А
вот как только кошелек начинает худеть, метрики все идут лесом вместе с
упертыми мерятелями.

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

>> Я как разработчик, уже много раз сталкивался с внедрением практив без
>> поддержки топов. У меня чаще всего прокатывает "личный пример".
V>Ты бы лучше свою энергию по делу применил и начал свое что продвигать, а
V>не на дяде кошелек пополнять. Личная энергия — это все.
V>А с возрастом ее все меньше и меньше будет.
У нас с "дядей" win-win. Я ему хорошо работаю и он за это деньги получает, он мне интересные проекты, интересных людей, хорошую зарплату...
На себя я тоже работаю, но чуть-чуть. Объемы не те. Команда маленькая. Проекты тоже. "На себя" я сначала работал чисто для того чтобы узнать "а смогу ли?".
Сейчас подрабатываю на себя чисто для того, чтобы сделать себе имя и не остаться ни с чем в случае чего. Но времени я уделяю на это не много.

V>Можно, но затраты личной энергии бешенные. Ибо в этом случае нужно
V>каждого убеждать, уговаривать, ублажать и т.д.
Я рассматриваю это как прокачку communication skils

СУВ, Aikin

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

A>>Вообще, цель для меня "поучиться/поиграться". Меня тоже устраивает текущее положение. В котором у меня есть свободное время и я "хочу что-то улучшить".

SD>Это не самая удачная причина для внедрения каких бы то ни было практик.
Согласен. Дело было вечером, в конце тяжелого рабочего дня (сейчас, кстати, был такой же). Захотелось поозорничать
На самом деле внедрение практик ради практик я оставил пару лет назад. Сейчас на первом месте все же здравый смысл и необходимость.

SD>Потому как работодателю обычно интересна не "прокачка скиллов на рабочем месте", а выполнение проектов в срок и без сбоев.
С проектами все хорошо

СУВ, Aikin

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

A>>Можешь что-то посоветовать, порекомендовать, опираясь на свой опыт?

SD>С моей стороны могу лишь дать одну рекомендацию: не торопиться.
Спасибо. Я к этому тоже пришел. Но так тяжело себя сдерживать. Хочется всего-всего попробовать

SD> Не добавлять ни одну новую практику до тех пор, пока старые не вошли в привычку, не стали рафинированными и удобными для всех членов команды. Как пример: если вы решили вести учёт часов, потраченных на решение тикета в саппорт-системе, не внедряйте новые практики до тех пор, пока эта не будет принята и используема всеми. Например, вам может потребоваться интеграция тикет-системы с системой версионного контроля, чтобы разработчик, выполняя commit (push, иное публикационное действие), мог не только автоматически закрывать (передавать в тестирование, ...) тикет, но и указывать количество потраченного времени, скажем, тегом в commit message.

SD>Потому как если начинается "мы наш, мы новый мир построим" — это 100% гарантия натолкнуться на стену непонимания, неприятия и необходимость применения административных мер.
Да, я с этим столкнулся Сейчас намного прагматичнее себя несколько летней давности.

СУВ, Aikin

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

G>А чего конкретно хочется добиться? И чем занимаетесь?
Увеличить точность оценки и прогнозирования сроков. Заказчику, как я говорил, все равно (сколько бы он не бухтел по этому поводу). Мне это нужно для прокачики скилов и получения опыта.
Занимаемся desctop/mobile разработкой для заводов по производству шин.

СУВ, Aikin

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

A>>gandjustas, а до этого Гапертон, предлагают оценивать сроки с помощью метрик, а не объем пряников и люлей.
SD>Хочу немножко поправить, идеи сии сформулированы отнюдь не уважаемыми участниками форума, но задолго до них. Собственно, эти идеи и легли в основу Agile-процессов.
Согласен. Вот только я хз кто сформулировал эти идеи, врядли мы об этом узнаем, да это и не важно.

gandjustas был упомянут потому что он начал эту дискуссию. А Гапертон потому что gandjustas сам на него ссылается.

СУВ, Aikin

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

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

G>>Personal Software Process — несколько книг в открытом доступе. Но без курсов "не взлетит".

G>>Краткая выжимка из PSP и опыта.
G>>Чтобы научиться прогнозировать срок надо отделить оценку объема от оценки срока.

G>>Объем должен считаться формально, то есть должен учитывать конкретные параметры. Например количество строк кода или количество "входов" и "выходов" модуля, помноженное на коэффициент сложности для типа модуля. Единица измерения не важна, главное чтобы она была одинаковая в команде.

E>Посоветуй пожалуйста, конкретные книги по Personal Software Process. Наиболее ценные на твой взгляд.
E>Если читать все подряд что попадается в интернет, то до сути долго придется добираться...
E>Желательно на русском. Хотя и на английском могу читать. Но на русском читаю быстрее

Я прочитал все книги по PSP с амазона. Все две...
http://www.amazon.com/Introduction-Personal-Software-Process-Humphrey/dp/0201548097/ref=sr_1_1
http://www.amazon.com/PSP-Self-Improvement-Process-Software-Engineers/dp/0321305493/ref=sr_1_2

Других и не знаю. Но, как говорит Gaperton, без прохождения курса и специализированной тулы для сбора метрик строго следовать PSP не получится. Скорее станет понятно как можно улучшить процесс разработки и даст понимание как пользоваться метриками.

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

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

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

G>>Оценка проекта и оценка задач — сильно разные вещи. Оценку проекта можно делать и без оценки задач. Это называется "экспертной оценкой" и именно оно чаще всего применяется.

E>Не совсем понял твою мысль.
E>Ты имеешь ввиду что С. Макконнелл в "Сколько стоит программный проект" неправильно оценивает проекты?

Я не говорю что неправильно, я говорю что оценка задачи и оценка проекта не всегда связаны.

On 01.03.2013 14:46, gandjustas wrote:

> Других и не знаю. Но, как говорит Gaperton, без прохождения курса и
> специализированной тулы для сбора метрик строго следовать PSP не
> получится.
Логично говорит. Книжки это одно, а работа с перподавателем, примерами и
т.п. это другое.

З.Ы. Гапертон, мне процент за рекламу.

G>Но, как говорит Gaperton, без прохождения курса и специализированной тулы для сбора метрик строго следовать PSP не получится. Скорее станет понятно как можно улучшить процесс разработки и даст понимание как пользоваться метриками.

Поддержу это мнение.
Причем предложу расширить — не только PSP/TSP, но и любые другие методики следует изучать под надзором квалифицированных специалистов. Иначе получится как у меня с RUP, "самостоятельно изученным на практике". К нынешнему моменту ложечки уже нашлись, и объективно эта методология теперь мне кажется логичной и вполне рабочей. Но осадочек остался: первое впечатление было негативным, что и закрепилось в подсознании.

On 04.03.2013 1:17, SkyDance wrote:

> Иначе получится как у меня с RUP, "самостоятельно изученным на
> практике".
Тоже сам разбирался, если бездумно не применять (микроскопом гвозди
забивать) вполне себе ничего.