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

Интересно можно ли переубедить? Хотелось бы стимулировать ответственностью... Или это бесполезное занятие?

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

S>некоторые подчиненные не любят когда их просят составить приблизительный план по выполнению задачи, обосновывая это невозможностью планирования в связи со "спецификой" области разрботки ПО и т.п.

S>Интересно можно ли переубедить? Хотелось бы стимулировать ответственностью... Или это бесполезное занятие?

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

Ну а как стимулировать — ХЗ. Не любит это народ, факт.

Здравствуйте.
И опять Джоэл Сполски

Ставьте очень мелко дроблёные задачи. Это наиболее важная часть в вашей работе по составлению плана. Ваши задачи должны измеряться в часах, а не в днях. (Когда я вижу план, измеряемый в днях, или даже в неделях, я знаю –он не реален). Возможно вы думаете, что план с мелко дроблёными задачами просто более точен. Неправильно! Очень сильно ошибаетесь! Когда вы начнете с плана с грубо определенными задачами и затем разобьёте его на меньшие задачи, вы увидите, что получили другой результат, не просто более точный. Это будет полностью другое число. Почему так получается?

Когда вы ставите мелко дроблёные задачи вы вынуждаете себя фактически вычислять то, какие шаги вы предпримите. Написать подпрограмму foo. Создать диалог такой и такой. Прочитать файл wawa. Эти шаги просто оценить, потому что прежде вы уже писали подпрограммы, создавали диалоги, и читали файлы wawa.

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

Как правило, каждая задача должна быть от 2 до 16 часов. Если у вас в плане стоит задача на 40 часов (одна неделя), значит вы не достаточно её разбили.

Имеется другая причина устанавливать мелкодроблёные задачи: это вынуждает вас разрабатывать проклятое свойство. Если у вас в программе будет некое сомнительное свойство, названное "Межсетевая Интеграция" и вы на него планируете недели, то вы обречены, приятель. Если же вам нужно определить, какие подпрограммы вы собираетесь написать, то вы вынуждены выявить свойство. Заставляя себя планировать вперед на этом уровне, вы устраняете много неустойчивости в программном проекте.

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

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

S>Интересно можно ли переубедить? Хотелось бы стимулировать ответственностью... Или это бесполезное занятие?

Скажу я вот что, и буду прав.

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

_>План как факт — это не плюс в разработке, нужно применять другие методы.
А по-моему как раз именно плюс.
Во-первых видишь все (обозримые) задачи, которые необходимо сделать в рамках проекта;
Во-вторых позволяет более грамотно распределить собственное разработческое время;
В-третьих — повышает ответственность в той части, когда приходишь на работу с утра
и думаешь "Надо сделать то-то то-то". И, сделав это вечером уходишь удовлетворенный
зная, что будешь делать завтра, а не мычительно размышляя на темы "Успею/Не успею".
Ну и кстати, в-четвертых — позволяет отчитаться руководству о проделанной работе,
что тоже немаловажно.

S>в ход идут различные отмазки вроде "ну есть кое-какие идеи — чем не план? зачем его писать если он всеравно поменяется?" короче все как у Ашманова

Если всё как у Ашманова, то у него наверняка есть и решение

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

_>>План как факт — это не плюс в разработке, нужно применять другие методы.
N_C>А по-моему как раз именно плюс.
N_C>Во-первых видишь все (обозримые) задачи, которые необходимо сделать в рамках проекта;
Видишь не все задачи, а только те, которые находятся на текущем листе бумаги.
ПОЧТИ ВСЕГДА, задачи меняются, а иногда и отменяются, и на место них ставятся другие.
Хотя, если сам себе хозяин, то может быть все и видно, смотря какой из тебя проект-манагер, а если нет — то вместо плана нужно использовать более современные методы.

N_C>Во-вторых позволяет более грамотно распределить собственное разработческое время;
План неудобно использовать в комманде.
План трудно изменять.
Опять же, одни проблемы, на которые разработчику приходится отвлекатся.

N_C>В-третьих — повышает ответственность в той части, когда приходишь на работу с утра
N_C>и думаешь "Надо сделать то-то то-то". И, сделав это вечером уходишь удовлетворенный
N_C>зная, что будешь делать завтра, а не мычительно размышляя на темы "Успею/Не успею".
Если человек неорганизован — то ему ничего не поможет. Ни план, ни конопля.
А успею/не успею — всегда имеет место, даже когда план перед глазами, сидишь и смотришь-думаешь, успею/не успею...

N_C>Ну и кстати, в-четвертых — позволяет отчитаться руководству о проделанной работе,
N_C>что тоже немаловажно.
Другие методы существуют. Не в плане дело.

_>>>План как факт — это не плюс в разработке, нужно применять другие методы.
N_C>>А по-моему как раз именно плюс.
N_C>>Во-первых видишь все (обозримые) задачи, которые необходимо сделать в рамках проекта;
_>Видишь не все задачи, а только те, которые находятся на текущем листе бумаги.
Я говорил про план хотя-бы текущей недели (дней трех вперед) — не зря я написал "обозримые" — а это заведомо уместится на одном листе.

_>ПОЧТИ ВСЕГДА, задачи меняются, а иногда и отменяются, и на место них ставятся другие.
Это никак не отменяет ценность планирования. Этак можно вообще сказать, что раз все меняется, то зачем писать программу? Все-равно все изменится и придется переписывать заново.

_>Хотя, если сам себе хозяин, то может быть все и видно, смотря какой из тебя проект-манагер, а если нет — то вместо плана нужно использовать более современные методы.
Например Как не обзови эти методы — конечный результат — все-равно план.

N_C>>Во-вторых позволяет более грамотно распределить собственное разработческое время;
_>План неудобно использовать в комманде.
_>План трудно изменять.
_>Опять же, одни проблемы, на которые разработчику приходится отвлекатся.
1) Очень удобно — по крайней мере мне не надо беспокоится, о том, что делает тот или иной разработчик. Если есть план, то проверяется следование генеральной линии, а не то, придумал-ли себе разработчик новую задачу или нет.
2) Это зависит от костности управления, поставленного в организации. Все это относительно.
3) Никаких проблем. Выбрал очередную задачу и реализуй ее. На что отвлекаться? А вот без плана — наоборот — надо вспоминать, что делать,
сколько это займет времени, согласовывать задачи с соседями и т.п.

_>Если человек неорганизован — то ему ничего не поможет. Ни план, ни конопля.
Неправда твоя. Как раз план больше действует на менее организованных людей. Для них, собственно и составляется. Кстати! Опять-же говоря про теорию. В любой книжке по самоорганизации первое, что говорится: "Для того, чтобы стать более организованным, надо ежедневно составлять план дел на следующий день".

_>А успею/не успею — всегда имеет место, даже когда план перед глазами, сидишь и смотришь-думаешь, успею/не успею...
Да, только одно но... Есть такая фраза (не моя): "Если не знаешь что делать — составь план и четко следуй этому плану. По-крайней мере избежишь мотаний и неопределенности".

_>Другие методы существуют. Не в плане дело.
См. выше — как не обзови, а все равно придет к одному.

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

_>>>>План как факт — это не плюс в разработке, нужно применять другие методы.
N_C>>>А по-моему как раз именно плюс.
N_C>>>Во-первых видишь все (обозримые) задачи, которые необходимо сделать в рамках проекта;
_>>Видишь не все задачи, а только те, которые находятся на текущем листе бумаги.
N_C>Я говорил про план хотя-бы текущей недели (дней трех вперед) — не зря я написал "обозримые" — а это заведомо уместится на одном листе.
У Вас другой подход.
Я неприемлю перепланировать каждые три дня (каждую неделю) переделку списка задач.

_>>ПОЧТИ ВСЕГДА, задачи меняются, а иногда и отменяются, и на место них ставятся другие.
N_C>Это никак не отменяет ценность планирования. Этак можно вообще сказать, что раз все меняется, то зачем писать программу? Все-равно все изменится и придется переписывать заново.
Я говорю про такую бумажку под названием "ПЛАН" и как негативно она влияет на разработку, а не про планирование в целом.

_>>Хотя, если сам себе хозяин, то может быть все и видно, смотря какой из тебя проект-манагер, а если нет — то вместо плана нужно использовать более современные методы.
N_C>Например Как не обзови эти методы — конечный результат — все-равно план.
Ваше право так считать.

N_C>>>Во-вторых позволяет более грамотно распределить собственное разработческое время;
_>>План неудобно использовать в комманде.
_>>План трудно изменять.
_>>Опять же, одни проблемы, на которые разработчику приходится отвлекатся.
N_C>1) Очень удобно — по крайней мере мне не надо беспокоится, о том, что делает тот или иной разработчик. Если есть план, то проверяется следование генеральной линии, а не то, придумал-ли себе разработчик новую задачу или нет.
N_C>2) Это зависит от костности управления, поставленного в организации. Все это относительно.
N_C>3) Никаких проблем. Выбрал очередную задачу и реализуй ее. На что отвлекаться? А вот без плана — наоборот — надо вспоминать, что делать,
N_C>сколько это займет времени, согласовывать задачи с соседями и т.п.
Планирование — должно быть.
План — нет.
Задачи должны разрабатываться отдельно, но могут быть зависимости одних задач от других.
Задачи должны лежать отдельно — это не проблема, ибо разрабатываются они отдельно.
ЛЮБУЮ задачу может взять ЛЮБОЙ член комманды.
Совещания должны быть как минимум каждое утро на 5-10 минут для решения кто что делает, и если ничего — то какие задачи берет.
Прочитайте внимательнее, пожалуйста, то, что я Вам пишу.

_>>Если человек неорганизован — то ему ничего не поможет. Ни план, ни конопля.
N_C>Неправда твоя. Как раз план больше действует на менее организованных людей. Для них, собственно и составляется. Кстати! Опять-же говоря про теорию. В любой книжке по самоорганизации первое, что говорится: "Для того, чтобы стать более организованным, надо ежедневно составлять план дел на следующий день".
А я не хочу организововаться, и хоть дерьмом ты меня корми, план на меня никак не повлияет. А теория — она и есть теория.

_>>А успею/не успею — всегда имеет место, даже когда план перед глазами, сидишь и смотришь-думаешь, успею/не успею...
N_C>Да, только одно но... Есть такая фраза (не моя): "Если не знаешь что делать — составь план и четко следуй этому плану. По-крайней мере избежишь мотаний и неопределенности".
Это, опять же, !актуально для волка, а не для стаи!.

_>>Другие методы существуют. Не в плане дело.
N_C>См. выше — как не обзови, а все равно придет к одному.
Скажем дружно — плана — не нужно.


p.s. Молодой человек. Я с Вами не согласен. И у меня на это есть ряд причин, одна из них — мой опыт. И не надо меня кормить теорией, я вижу практику.

_>Я неприемлю перепланировать каждые три дня (каждую неделю) переделку списка задач.
Утрирование, утрирование — я об этом не говорил.

_>Планирование — должно быть. План — нет.
Планирование есть, а плана — нет. Это просто подмена понятий.

_>Задачи должны разрабатываться отдельно, но могут быть зависимости одних задач от других.
Должны и могут — понятия относительные и сильно зависят от реализуемых систем.

_>ЛЮБУЮ задачу может взять ЛЮБОЙ член комманды.
С утверждением не согласен, но если так поставлена работа, то...

_>Совещания должны быть как минимум каждое утро на 5-10 минут для решения кто что делает, и если ничего — то какие задачи берет.
Ну а я про что говорю? Команда составляет план работ на день. Но при этом есть план работ на несколько дней. Чем это так уж сильно отличается от того, что я писал?

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

_>>>А успею/не успею — всегда имеет место, даже когда план перед глазами, сидишь и смотришь-думаешь, успею/не успею...
N_C>>Да, только одно но... Есть такая фраза (не моя): "Если не знаешь что делать — составь план и четко следуй этому плану. По-крайней мере избежишь мотаний и неопределенности".
_>Это, опять же, !актуально для волка, а не для стаи!.
Да ну? Стая как раз и сильна тем, что все следуют генеральной линии. А если каждый в стае говорит, что он не хочет организовываться — это это как раз вредно для стаи.

_>Скажем дружно — плана — не нужно.
Примеры примеры...

_>p.s. Молодой человек. Я с Вами не согласен. И у меня на это есть ряд причин, одна из них — мой опыт. И не надо меня кормить теорией, я вижу практику.
PS
Как вы все тут любите козырять возрастом? По стилю ведения дискуссии я бы не дал Вам больше 35 лет. А тогда и нечего на возраст кивать.
То, что у Вас так сложилась практика ведения проектов — да на здоровье! Но говорить о том, что это единственно правильный путь — не надо.

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

_>План — это конечно хорошо, но план по сути своей если написан кем-то — то для разработчика это пи##ец.
_>Если самим разработчиком — то это меньший пи##ец, а иногда и просто потраченное немного времени.
_>План как факт — это не плюс в разработке, нужно применять другие методы.
У буржуев есть такое правило — "Если этого не на бумаге — то этого нет вообще". Бюрократия тут не причем. Если у вас нет положительного опыта в использования планов, то попробуйте ответить на такие вопросы (Ответы так же должен дать человек не знающий ваших программистов):
1. Какова производительность программиста Иванова(Петрова, Сидорова)
2. Сколько времени нужно для реализации среднего юзекейса
3. Какие сильные стороны (что лучше делает — цена/качество) программиста Иванова (Петрова, Сидорова)
4. Какие слабые стороны программиста Иванова (Петрова, Сидорова)
5. Понимает ли программист Иванов (Петров, Сидоров) что от него требуется быстрое качественное решение, а не создание нового Microsoft Office в конкретный момент времени.
6. Нужен ли новый программист в команде и когда
7. Что сейчас делает программист Иванов (Петров, Сидоров). У вас в команде 5 человек. У вас в команде 50 человек. У вас в команде 500 человек.
8. Кому отдать "горящюю" путевку на Канары (Реализация быстрой но важной работки в 4 — 6 человекочасов) с наименьшими потерями в текущих процессах.

Если ты видешь группу то на эти вопросы зачастую можешь ответить (конечно не факт что правильно). Ну а вот тебя завтра решили сделать директором. На твое место берут нового человека. Отдел встанет колом или резко "провалится". Так что не имея опыта в планировании — плюсы в разработке уже видны

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

SED>Если ты видешь группу то на эти вопросы зачастую можешь ответить (конечно не факт что правильно). Ну а вот тебя завтра решили сделать директором. На твое место берут нового человека. Отдел встанет колом или резко "провалится". Так что не имея опыта в планировании — плюсы в разработке уже видны

См. Экстремальное программирование.

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

_>Скажу я вот что, и буду прав.

_>План — это конечно хорошо, но план по сути своей если написан кем-то — то для разработчика это пи##ец.
_>Если самим разработчиком — то это меньший пи##ец, а иногда и просто потраченное немного времени.
_>План как факт — это не плюс в разработке, нужно применять другие методы.

а как же тогда быть? написанный менеджером плохо, написаный программером тоже плохо, выходит совсем без плана? а какже время планировать?

Здравствуйте, alex_ez, Вы писали:
_>См. Экстремальное программирование.
Смотрю http://www.xprogramming.ru/Articles/XPlannerReview.html

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

И?

Здравствуйте, Streamer1, Вы писали:
S>а как же тогда быть? написанный менеджером плохо, написаный программером тоже плохо, выходит совсем без плана? а какже время планировать?

12) Никогда, не позволяйте менеджерам ни при каких обстоятельствах, указывать программистам, уменьшать оценку времени. Много начинающих программных менеджеров думают, что они могут "мотивировать" своих программистов, работать быстрее, давая им симпатичные, "плотненькие" (нереально короткие) планы. Я думаю, что этот вид мотивации — без мозгов (brain-dead). Когда я отстаю от плана, я чувствую себя обреченным, попадаю в депрессию, становлюсь неактивным. Когда я работаю с опережением плана, я весел и производителен. План — не место, для психологических игр.

Если ваш менеджер заставляет вас уменьшить оценку времени, есть что делать: Создайте новый столбец в плане, с именем Оценка Рика (предположим вас зовут Рик). Поместите туда свою оценку. Позвольте вашему менеджеру делать всё что угодно с колонкой Нач Оцн. Игнорируйте его оценку. Когда проект выполнен, посмотрите, кто был ближе к действительности. Я обнаружил, что стоит только пригрозить поступать так, как произойдут чудеса, особенно, когда ваш менеджер увидит, что он добился только того что попал на конкурс под названием "как медленно вы можете работать"!

Почему непутёвые менеджеры пытаются заставить программистов снижать оценки времени?

Когда проект начинается, технические менеджеры уходят, встречаются с деловыми людьми, и появляются со списком свойств, который, как они думают, займёт около 3-х месяцев, но в действительности он займёт 9. Когда вы думаете о написании кода без учёта всех шагов, которые предстоит сделать, всегда кажется, что потребуется n времени, хотя реально, скорее всего, потребуется 3n. Когда вы составляете реальный план, вы складываете все задачи и понимаете, что проект оказывается намного более длинный чем казалось сначала. Действительность погружается [куда-то] (Reality sinks in).

Непутёвые менеджеры пытаются ответить на это, прикидывая, как заставить людей, работать быстрее. Это не очень реально. Возможно вы способны нанять больше людей, но им нужно ещё выйти на заданную скорость, возможно они и станут работать на 50% эффективнее в течение нескольких месяцев (при этом понижая эффективность тех кто должен выполнять роль их наставников). Во всяком случае, на этом рынке, добавление хороших программистов может позволить уложиться в 6 месяцев.

Возможно, вы способны добиться от людей на 10% большего выхода исходных текстов, временно, той ценой, что вы заставите их сгореть на 100% за год. Не большой прирост, притом, что это напоминает поедание зерна предназначенного для посева.

Возможно вы способны добиться от людей на 20% большего выхода исходных текстов, прося каждого работать супер тяжело, независимо от того, насколько он устал. Ажиотаж, время отладки удвоится. Идиотский шаг который блестяще отзовется на [вашем] кармическом пути.

Но вы никогда не добьётесь 3n из n, ни при каких обстоятельствах, а если вы думаете, что добьётесь, пожалуйста пришлите мне по е-мэйл график биржевых котировок акций вашей компании, чтобы я мог сыграть на понижение (email me the stock ticker of your company so I can short it).

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

_>>План — это конечно хорошо, но план по сути своей если написан кем-то — то для разработчика это пи##ец.
_>>Если самим разработчиком — то это меньший пи##ец, а иногда и просто потраченное немного времени.
_>>План как факт — это не плюс в разработке, нужно применять другие методы.

S>а как же тогда быть? написанный менеджером плохо, написаный программером тоже плохо, выходит совсем без плана? а какже время планировать?

см. Экстремальное Программирование

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

SED>Здравствуйте, alex_ez, Вы писали:
_>>См. Экстремальное программирование.
SED>Смотрю http://www.xprogramming.ru/Articles/XPlannerReview.html
SED>

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

SED>И?

И все.

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


_>И все.
Я так понял вы привели экстремальное программирование как пример методики в которой не используется планирование вообще и она работает на ура. Но я увидел что планирование тоже есть. Может я не правильно вас понял. Разъясните по подробнее — что вы хотели сказать, рекомендуя смотреть экстремальное программирование.

У нас читал лекции по организации процесса программирования главный архитектор Питерского филиала Motorola. Насколь я его понял, план составляется сверху (проектировщиками) и спускается вниз (к программистам). Обычно разница оценки во времени составляет 30%, вроде бы ее согласовывают уже вместе. Очень важно понимать, что успешным может быть план только в организации, которая знает свой процесс. Должно быть высчитано среднее количество кода, которое пишут программисты в неделю и исходить из этого параметра. Кстати, по мнению преподавателя, этот параметр изменить в фирме очень сложно. Он постоянен.
Я считаю, что план должен быть, но чтобы получить грамотный план должна быть проведена очень большая подготовительная работа менеджерами. Кстати, Motorola собирает около 500 метрик. И у нее CMMI 5 уровня.

_>См. Экстремальное программирование.
И что мы там видим? Доску и карточки? Это да. НО! Только при планировании работ эти карточки берутся и раскладываются
на доске. Таким образом получается тот-же план, только вид сбоку. И XP говорит, вообще-то, если поступает новые задачи,
то происходит пересмотр положения карточек на доске — а это вообще-то и есть пересмотр планов.

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

_>>См. Экстремальное программирование.
N_C>И что мы там видим? Доску и карточки? Это да. НО! Только при планировании работ эти карточки берутся и раскладываются
N_C>на доске. Таким образом получается тот-же план, только вид сбоку. И XP говорит, вообще-то, если поступает новые задачи,
N_C>то происходит пересмотр положения карточек на доске — а это вообще-то и есть пересмотр планов.
Че пристал?..
Работай как привык!
Я же не против

_>Че пристал?..
Мда... Молодой человек, потрудитесь вести себя спокойнее!

_>Работай как привык!
_>Я же не против
Я, вообще-то здесь делюсь мнением. И если что-то не устраивает в моих репликах так и говори.
Я работаю как привык и хотя-бы пытаюсь аргументировать свою точку зрения, а вот от тебя что-то
аргументов кроме "XP и все!" не услышал.

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

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

S>Интересно можно ли переубедить? Хотелось бы стимулировать ответственностью... Или это бесполезное занятие?



если програмист нормальный он на 99% может сказать сколько времени займет тот или иной процес.
советую поменять их!

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

Я уже поделился.
Мои ответы не были поняты, по крайней мере, тобой.
Зачем ругаться?..

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

S>>а как же тогда быть? написанный менеджером плохо, написаный программером тоже плохо, выходит совсем без плана? а какже время планировать?

_>см. Экстремальное Программирование

А ты сам-то его видел?

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

_>>И все.
SED>Я так понял вы привели экстремальное программирование как пример методики в которой не используется планирование вообще и она работает на ура. Но я увидел что планирование тоже есть. Может я не правильно вас понял. Разъясните по подробнее — что вы хотели сказать, рекомендуя смотреть экстремальное программирование.

Я надеюсь, что общение не войдет в переперательство.

Планирование в экстремальном програмировании есть. Но это не "План" как таковой. Это то, что нужно сделать.
Каждый член комманды разработчиков !играет! свою роль и может одновременно является программистом.
Есть такие члены комманды как контролер, архитектор — которые задают и иногда направляют программистов, не мешая выполнять задачу.

Вообще, что я хотел выразить в первом посте:
План — это такая бумажка, которая висит над программистом не давая двигаться вперед, и, фактически, заставляет двигаться назад.
Программирование — это творчество. Представьте себя художником, перед которым поставили задачу нарисовать портрет и дали план: нужно в такие то сроки нарисовать руки, в такие то — ноги, потом туловище, ну и голову в конце. Помоему, это чистой воды бред.
Перенося на более новое направление творчесской деятельности — написание программ — у нас не меняется ни концепция возникновения идей, ни концепция реализации, меняется только инструмент и результат.

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

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

_>Я надеюсь, что общение не войдет в переперательство.
Я тоже.

_>Планирование в экстремальном програмировании есть. Но это не "План" как таковой. Это то, что нужно сделать.
_>Каждый член комманды разработчиков !играет! свою роль и может одновременно является программистом.
_>Есть такие члены комманды как контролер, архитектор — которые задают и иногда направляют программистов, не мешая выполнять задачу.

_>Вообще, что я хотел выразить в первом посте:
_>План — это такая бумажка, которая висит над программистом не давая двигаться вперед, и, фактически, заставляет двигаться назад.
_>Программирование — это творчество. Представьте себя художником, перед которым поставили задачу нарисовать портрет и дали план: нужно в такие то сроки нарисовать руки, в такие то — ноги, потом туловище, ну и голову в конце. Помоему, это чистой воды бред.
_>Перенося на более новое направление творчесской деятельности — написание программ — у нас не меняется ни концепция возникновения идей, ни концепция реализации, меняется только инструмент и результат.
Для начала, давайте посмотрим с другой стороны — со стороны того, кто платит деньги. Он их платит не для того что бы программисту было что кушать пока он будет творить. Он их инвестирует и планирует(!) когда они начнут отрабатываться. Просто так не один нормальный заказчит не скажет — вот вам миллион как сделает позвоните. Он с начала спросит когда это будет сделано, и только после ответа будет принимать решение — давать или не давать денег. А если вы назовете срок без плана — то этот срок будет 99.999% неправильным и не выполнимым. Скажите — вы бы заказали картину у художника, который бы вам на вопрос ответил "Это же творчество! Когда будет готова неизвестно!"? Я думаю нет, во всяком случае я бы не заказал. Кроме того — нет ничего хуже не контролируемого творчества — это то же самое что глухой телефон. Вы даете задание "Измени на кнопке надпись с "Прогрузка" на "Загрузка". Не обозночаете не сроков не контрольных точек. Самое интресное что эта задача не будет сделана и через неделю, это в лучшем случае, а в хучшем вы получите новый юзекейс.
Теперь собственно про планы. Я не стремлюсь сделать план на 100% соответствующий возможностям программиста. Если я пишу задачу "Сделать вывод сообщения для пользователя после акцепта документа — Документ акцептова успешно." для программиста Иванова и я знаю что на реализацию этой задачи он потратит один час, то в плане у него в пункте длительность будет написано 1.3 часа. Идея понятна? Я, лично, не стремлюсь сделать план со 100% загрузкой программиста. Я всегда закладываю буффер примерно в 30%(Сейчас все идет к 20%). На тех задачах, которые решаются первый раз, буфер может достигать 100% самой задачи и называется этот пункт "Риски" (Правда его еще оправдать нужно).
Ну и на последок, повторюсь наверное, творчество для клиента это и есть минус и по этому его нужно планировать. Кроме того, на проектах более 500 человекочасов план просто необходим, так как уже 50 часе вы просто не будете знать что делать, вы будете разрываться.

Не хочу вас обидеть и сразу прошу прощения если случиться именно так, но по вашему посту можно сказать что вы не участвовали в больших проектах. А человек так устроен что он не верит не кому, пока сам не попробует. И только с опытом человек начинает понимать весь смысл выражения "Умный учится не только на своих ошибках — а даже больше на чужих".

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

_>План — это такая бумажка, которая висит над программистом не давая двигаться вперед, и, фактически, заставляет двигаться назад.
Вот еще про это не упомянул. Правильно составленный план как раз показывает куда двигаться дальше. А грамотно составленый план — вызывает у программиста желание двигаться быстрее и качаственнее.

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

SED>Теперь собственно про планы. Я не стремлюсь сделать план на 100% соответствующий возможностям программиста. Если я пишу задачу "Сделать вывод сообщения для пользователя после акцепта документа — Документ акцептова успешно." для программиста Иванова и я знаю что на реализацию этой задачи он потратит один час, то в плане у него в пункте длительность будет написано 1.3 часа. Идея понятна? Я, лично, не стремлюсь сделать план со 100% загрузкой программиста. Я всегда закладываю буффер примерно в 30%(Сейчас все идет к 20%). На тех задачах, которые решаются первый раз, буфер может достигать 100% самой задачи и называется этот пункт "Риски" (Правда его еще оправдать нужно).

Интересно, как определить потребное время для задачи "Исправить баг номер 184, заключающийся в вылете access violation в случайный момент времени с периодом полураспада около 10000 часов"?

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

VP>Интересно, как определить потребное время для задачи "Исправить баг номер 184, заключающийся в вылете access violation в случайный момент времени с периодом полураспада около 10000 часов"?

Видимо это время как раз входит в те самые 30% — написал кусок кода за час — есть 20 минут на исправление багов, можешь их сэкономить, тогда будешь исправлять потом, когда баг обнаружится. (-:

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

VP>Интересно, как определить потребное время для задачи "Исправить баг номер 184, заключающийся в вылете access violation в случайный момент времени с периодом полураспада около 10000 часов"?
Поделюсь опытом и надеюсь он будет полезен. Сейчас у меня таких ошибок не появляется вообще! Как этого добиться? Проанализируйте решения этих ошибок. У меня получилось следующее:
1. Низкое качество кода. Решается вообще без проблем — иногда очень быстро
2. Низкое качество сторонних компонент и библиотек. Решается использованием золотого правила — НЕ ИСПОЛЬЗУЙТЕ НЕ ПРОВЕРЕННЫЕ РЕШЕНИЕ. Я даже сейчас работаю с решениями 3 летней давности. Если возникает необходимость в новом функционале, то как минимум у двух программистов появляется в планах "Тестирование библиотеки ХХХ"(Тестеры сдесь не причем)
3. Баги, с которыми нужно смериться или обойти. Общий процент от всего — менее 0.01. Тут все зависит от ситуации, но зачастую его компенсирует буфер, размер которого прямопропорционален новизне используемой технологии с коэффициентом k. В любом случае эта решаемая проблема и она не стоит выведенного яйца. Приведу свой пример. В BizTalk2004 есть одна фича, о не знании которой рядовой программис завалит все не мыслемые сроки. Я обнаружил эту фичу на втором расширении рисков (были 8 часов, потом стал 12. И последняя 16). Эту фичу я опубликовал. Из-за этой фичи больше небыло не одной задержки.
Удачи вам в решении этих багов

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

Молодой человек, зачем вы вводите людей в заблуждение?..

VP>>Интересно, как определить потребное время для задачи "Исправить баг номер 184, заключающийся в вылете access violation в случайный момент времени с периодом полураспада около 10000 часов"?
SED>Поделюсь опытом и надеюсь он будет полезен. Сейчас у меня таких ошибок не появляется вообще! Как этого добиться? Проанализируйте решения этих ошибок. У меня получилось следующее:

SED>1. Низкое качество кода. Решается вообще без проблем — иногда очень быстро
Низкое качество кода это неверное понятие. Код не может быть Низкокачественным, высококачественным, инакокачественным, код может быть красивым, может быть оптимальным, может быть траспортируемым, может быть на языке Мю, а низкокачественными могут быть помидоры, залежавшиеся с прошлого года в коморке. Выбирали бы вы выражения, когда разговариваете с людьми.

SED>2. Низкое качество сторонних компонент и библиотек. Решается использованием золотого правила — НЕ ИСПОЛЬЗУЙТЕ НЕ ПРОВЕРЕННЫЕ РЕШЕНИЕ. Я даже сейчас работаю с решениями 3 летней давности. Если возникает необходимость в новом функционале, то как минимум у двух программистов появляется в планах "Тестирование библиотеки ХХХ"(Тестеры сдесь не причем)
А при чем тогда тестеры?.. У вас их вообще нет?.. Или тестеры — это вы?

SED>3. Баги, с которыми нужно смериться или обойти. Общий процент от всего — менее 0.01. Тут все зависит от ситуации, но зачастую его компенсирует буфер, размер которого прямопропорционален новизне используемой технологии с коэффициентом k. В любом случае эта решаемая проблема и она не стоит выведенного яйца. Приведу свой пример.
Может не надо примеров? Хватит того, что проблема яйца не стоит... МТС блин...

SED> В BizTalk2004 есть одна фича, о не знании которой рядовой программис завалит все не мыслемые сроки. Я обнаружил эту фичу на втором расширении рисков (были 8 часов, потом стал 12. И последняя 16). Эту фичу я опубликовал. Из-за этой фичи больше небыло не одной задержки.
Че сказал то?... К тому же еще и неграмотно.

SED>Удачи вам в решении этих багов
И на вопрос не ответил, и нафлудил неслабо.
Молодец.

p.s. Зачем RSDN то читаешь?.. да еще через Веб. Или ты книгу пишешь?.. бабки захотелось сделать на людях?..

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


_>Молодой человек, зачем вы вводите людей в заблуждение?..
Я считаю ваш пост личным Оскорблением (читайте правила) и прошу администраторо на это обратить внимание.

_>Низкое качество кода это неверное понятие. Код не может быть Низкокачественным, высококачественным, инакокачественным, код может быть красивым, может быть оптимальным, может быть траспортируемым, может быть на языке Мю, а низкокачественными могут быть помидоры, залежавшиеся с прошлого года в коморке. Выбирали бы вы выражения, когда разговариваете с людьми.
Объяснять долго не буду, но поверьте мне — земля круглая!

SED>>2. Низкое качество сторонних компонент и библиотек. Решается использованием золотого правила — НЕ ИСПОЛЬЗУЙТЕ НЕ ПРОВЕРЕННЫЕ РЕШЕНИЕ. Я даже сейчас работаю с решениями 3 летней давности. Если возникает необходимость в новом функционале, то как минимум у двух программистов появляется в планах "Тестирование библиотеки ХХХ"(Тестеры сдесь не причем)
_>А при чем тогда тестеры?.. У вас их вообще нет?.. Или тестеры — это вы?
А при том что тестеры тестируют конечный продукт! Лично у меня нет тестеров компонетов. Как, например, вы будете тестировать библиотеку загрузки весов DiGi от трех разных фирм.

SED>>3. Баги, с которыми нужно смериться или обойти. Общий процент от всего — менее 0.01. Тут все зависит от ситуации, но зачастую его компенсирует буфер, размер которого прямопропорционален новизне используемой технологии с коэффициентом k. В любом случае эта решаемая проблема и она не стоит выведенного яйца. Приведу свой пример.
_>Может не надо примеров? Хватит того, что проблема яйца не стоит... МТС блин...
ну — ну

SED>> В BizTalk2004 есть одна фича, о не знании которой рядовой программис завалит все не мыслемые сроки. Я обнаружил эту фичу на втором расширении рисков (были 8 часов, потом стал 12. И последняя 16). Эту фичу я опубликовал. Из-за этой фичи больше небыло не одной задержки.
_>Че сказал то?... К тому же еще и неграмотно.
Без комментариев
SED>>Удачи вам в решении этих багов
_>И на вопрос не ответил, и нафлудил неслабо.
_>Молодец.

_>p.s. Зачем RSDN то читаешь?.. да еще через Веб. Или ты книгу пишешь?.. бабки захотелось сделать на людях?..

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

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

SED>Здравствуйте, Vinni-puh, Вы писали:

SED>Проанализируйте решения этих ошибок. У меня получилось следующее:
SED>1. Низкое качество кода.
SED>2. Низкое качество сторонних компонент и библиотек.
Сколько смог вспомнить, подобные трудноуловимые баги у меня возникали именно по этой причине.

SED>Решается использованием золотого правила — НЕ ИСПОЛЬЗУЙТЕ НЕ ПРОВЕРЕННЫЕ РЕШЕНИЕ. Я даже сейчас работаю с решениями 3 летней давности. Если возникает необходимость в новом функционале, то как минимум у двух программистов появляется в планах "Тестирование библиотеки ХХХ"(Тестеры сдесь не причем)
Самое печальное, что эти баги проявляются только при эксплуатации (по условию задачи период полураспада 10000 часов), после того, как сторонняя библиотека уже крепко вросла в проект. А выделить такие ресурсы, как двух программистов, занимающихся тестированием библиотеки, мы к сожалению не можем. Накладно.

SED>3. Баги, с которыми нужно смириться или обойти. Общий процент от всего — менее 0.01.
Ну, по-моему 0.01 — это тоже немало. Хотя иногда так всё и кончается.

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

VP>Самое печальное, что эти баги проявляются только при эксплуатации (по условию задачи период полураспада 10000 часов), после того, как сторонняя библиотека уже крепко вросла в проект.
Согласен, это грустно. Но вы же сейчас можете оценить сколько еще бед она вам принесет? И, например, что буде выгодней сейчас потратить 100 часов на ее "искоренение" или в течении 2 следующих лет потратить 200 часов. Повторюсь — это пример. Потому как в реальной жизни, например, выгодней будет потратить 200 часов из за того что заказчик не даст 100 часов сейчас и выставит неустойку которая не оправдает этих затрат. С другой стороны есть такое правило — сначало исправляем ошибки, потом идем дальше.
VP>А выделить такие ресурсы, как двух программистов, занимающихся тестированием библиотеки, мы к сожалению не можем. Накладно.
Можно тоже оценить затраты на будующее. Что выгодней сейчас потратить время на проверку или потом "бороться". А вообще лучше день потерять, а потом за пять минут долететь


SED>>3. Баги, с которыми нужно смириться или обойти. Общий процент от всего — менее 0.01.
VP>Ну, по-моему 0.01 — это тоже немало. Хотя иногда так всё и кончается.
Если не вести историю по таким фичам, то это просто огромное значение. Ну а если у вас все ходы записаны, то все решается быстро. За исключение нахождения новых, не задокументированных фич

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

_>Скажу я вот что, и буду прав.

Это не тебе решать Критерий истины — практика (с)

_>Планирование — должно быть.
_>План — нет.

валяюсь на полу...

_>А я не хочу организововаться, и хоть дерьмом ты меня корми, план на меня никак не повлияет. А теория — она и есть теория.

Вот именно. Безответственные люди как раз и не хотят организовываться, чтобы не нести ответственность.

_>Программирование — это творчество. Представьте себя художником, перед которым поставили задачу нарисовать портрет и дали план: нужно в такие то сроки нарисовать руки, в такие то — ноги, потом туловище, ну и голову в конце. Помоему, это чистой воды бред.

И где бред? Мой знакомый художник рисует картины и портреты на заказ, и легко называет сроки исполнения. И творчества в рисовании портрета нет никакого.

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

А подойдешь ли ты творчески или сделаешь тупое решение, твой выбор. Некоторые к приготовлению пищи у себя дома подходят творчески, но это не мешает им быть уверенными, что не более чем через 2 часа все поедят.

Здравствуйте, Кодёнок, Вы писали:

_>>Скажу я вот что, и буду прав.
Кё>Это не тебе решать Критерий истины — практика (с)
Это не тебе решать Критерий истины — практика. (с)
))))))

_>>Планирование — должно быть.
_>>План — нет.
Кё> валяюсь на полу...
Ты пол моешь?.. Вставай и читай оригинал до просветления

_>>А я не хочу организововаться, и хоть дерьмом ты меня корми, план на меня никак не повлияет. А теория — она и есть теория.
Кё>Вот именно. Безответственные люди как раз и не хотят организовываться, чтобы не нести ответственность.
А теория — она и есть теория.

_>>Программирование — это творчество. Представьте себя художником, перед которым поставили задачу нарисовать портрет и дали план: нужно в такие то сроки нарисовать руки, в такие то — ноги, потом туловище, ну и голову в конце. Помоему, это чистой воды бред.
Кё>И где бред? Мой знакомый художник рисует картины и портреты на заказ, и легко называет сроки исполнения. И творчества в рисовании портрета нет никакого.
Это не художник. Это фотограф какойто.

Кё>А подойдешь ли ты творчески или сделаешь тупое решение, твой выбор. Некоторые к приготовлению пищи у себя дома подходят творчески, но это не мешает им быть уверенными, что не более чем через 2 часа все поедят.
Читай до просветления, короче.
Пойми с чем спорить — тогда и посморим.

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

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

_>p.s. давайте по делу, если есть факты — то их и говорим, если нету — не надо писать поемы про художников, которые четко знают, когда закончат, с которыми нельзя будет поспорить за неимением локально аналогов.

А это я тебе не факт привел?

Здравствуйте, Кодёнок, Вы писали:

_>>p.s. давайте по делу, если есть факты — то их и говорим, если нету — не надо писать поемы про художников, которые четко знают, когда закончат, с которыми нельзя будет поспорить за неимением локально аналогов.
Кё>А это я тебе не факт привел?
приводи _достоверные_ факты, пожалуйста. а не про "гагарина".

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

_>>>p.s. давайте по делу, если есть факты — то их и говорим, если нету — не надо писать поемы про художников, которые четко знают, когда закончат, с которыми нельзя будет поспорить за неимением локально аналогов.
Кё>>А это я тебе не факт привел?
_>приводи _достоверные_ факты, пожалуйста. а не про "гагарина".

Достоверный это какой? Этот чем не достоверен?

Здравствуйте, Кодёнок, Вы писали:

Кё>Достоверный это какой? Этот чем не достоверен?
Тем, что я не видел такого ни разу, и не могу с этим спорить, или соглашаться.
Я не сказал, что он достоверен, но этот факт просто ставить обсуждение в тупик. Поэтому и говорю — не про "гагарина".

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

Кё>>Достоверный это какой? Этот чем не достоверен?
_>Тем, что я не видел такого ни разу, и не могу с этим спорить, или соглашаться.
_>Я не сказал, что он достоверен, но этот факт просто ставить обсуждение в тупик. Поэтому и говорю — не про "гагарина".

А таких, которые на себя работают, а не наемные, знаешь?

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

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

Тут уже упоминалось, что план это не панацея. Вот давайте составим план на реализацию такой фичи:
получение всех строковых констант из Flash-ролика.

Для того чтобы составить план в часах, нужно сделать следующее:
— Проверить доступены ли дока на этот формат и готовые либы (это заняло ~1 час, заранее время предсказать нельзя)
— Для избранной либы посмотреть качество кода и методы ее интеграции с приложением. В зависимости от сложности либы этот фактор варьируется. (потрачено ~1.5 часа).
— Как минимум собрать либу (это отдельная песня, на это может уходить до нескольких дней, просто на сборку, в реальной задаче это заняло минимум времени)

Проделав указанные шаги, человек сказал, что добавление данной фичи займет 1 час. Итого, получение данных для составления плана, 2.5 часа, работа 1 час. И это время может резко измениться до нескольких дней, если, например, окажется что библиотека с вашим приложением принципиально не может быть слинкована.

К чему все это? К тому, что почасовые планы можно составить только когда структура системы четкая, ясная и нет внешних факторов. Может быть стоит посмотреть чем эти подчиненные занимаются? Несерьезно требовать составить почасовой план от человека занятого творческой работой или работой связанной с неопределенностью.

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

Что же касается методов переубеждения, то если сотрудник не заинтересован в результатах проекта, вряд ли он вам будет выдавать точные планы. Когда он пишет план, то берет на себя ответсвенность, ему это нужно? Если да, то планы будут реальными и постепенно уточняться. Если же нет, то автоматически сработает отмазка: "В любом случае план будет сорван, так что можно в него писать любые цифры. Все равно это меня ни к чему не обязывает".

Ну а вопрос мотивации, это уже совсем другая песня. Тут уже было много копий сломано.

Кё>И где бред? Мой знакомый художник рисует картины и портреты на заказ, и легко называет сроки исполнения. И творчества в рисовании портрета нет никакого.

Ну не совсем. И в портрете и в портретной фотографии есть творчество, в том их смысл. Портрет без творчества — это фотокарточки на документы.

Однако грамотный художник все же может совместить творчество при рисовании со сроками исполнения, а не рисовать портрет до тех пор, пока модель умрет от старости.

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

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

G>Тут уже упоминалось, что план это не панацея. Вот давайте составим план на реализацию такой фичи:
G>получение всех строковых констант из Flash-ролика.

Такие задачи должны делиться как минимум на две: исследование, и по результатам — реализация. Об этом уже было в другом топике. Если задача небольшая (как эта), то вполне нормально в середине попросить разработчика переоценить сроки по результатам исследования. Руководитель же не враг, если вы обнаружите, что работа на самом деле займет в 5 раз больше, то об этом нужно сразу говорить.

G>Проделав указанные шаги, человек сказал, что добавление данной фичи займет 1 час. Итого, получение данных для составления плана, 2.5 часа, работа 1 час.

Забавно, что практически выведенное правило умножать на Пи и тут выполнилось. Выслушали разработчика (час) и умножили.

G>И это время может резко измениться до нескольких дней, если, например, окажется что библиотека с вашим приложением принципиально не может быть слинкована.

Может. Но как часто будет? 1 раз из 100 — вполне приемлемо для бизнеса. Зато в остальных 99 работа замечательно планируется.

G>К чему все это? К тому, что почасовые планы можно составить только когда структура системы четкая, ясная и нет внешних факторов. Может быть стоит посмотреть чем эти подчиненные занимаются? Несерьезно требовать составить почасовой план от человека занятого творческой работой или работой связанной с неопределенностью.

А откуда ты взял почасовые планы? Я таких даже не видел ни разу Речь идет о приблизительных планах (см. первый пост топика). Как минимум, чтобы разработчик всегда знал и мог сказать, что он делает и что собирается делать дальше. Без плана его ответ ("Сливаю классы Дуболом и ТолпаКостоправов") ни о чем не скажет. И ответственности у него без плана нет, потому что спросишь — что делаешь? ответит делаю то-то и это; а то ли делает, нужно ли это вообще делать, успевает или опаздывает — непонятно.

G>Что же касается методов переубеждения, то если сотрудник не заинтересован в результатах проекта, вряд ли он вам будет выдавать точные планы. Когда он пишет план, то берет на себя ответсвенность, ему это нужно? Если да, то планы будут реальными и постепенно уточняться. Если же нет, то автоматически сработает отмазка: "В любом случае план будет сорван, так что можно в него писать любые цифры. Все равно это меня ни к чему не обязывает".

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

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



_>Планирование в экстремальном програмировании есть. Но это не "План" как таковой. Это то, что нужно сделать.

Любой менеджер вам скажет, что список задач без даты их готовности — полная туфта.

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



G>К чему все это? К тому, что почасовые планы можно составить только когда структура системы четкая, ясная и нет внешних факторов. Может быть стоит посмотреть чем эти подчиненные занимаются? Несерьезно требовать составить почасовой план от человека занятого творческой работой или работой связанной с неопределенностью.

Неопределенность — это риск. Риски в любом проекте должны быть сняты на начальных этапах. Лучше вообще до старта.

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

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

S>>>а как же тогда быть? написанный менеджером плохо, написаный программером тоже плохо, выходит совсем без плана? а какже время планировать?

_>>см. Экстремальное Программирование

L>А ты сам-то его видел?

Угу, недавно в юморе пробегала ссылка на блог одного товарища, описывающего признаки "плохого программиста". Список, походу можно дополнять: они везде используют XP.

PS. Лень ссылку искать. Суть там была в том, что самое плохое в разработке ПО — это догматизм.

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

X>Угу, недавно в юморе пробегала ссылка на блог одного товарища, описывающего признаки "плохого программиста". Список, походу можно дополнять: они везде используют XP.

На основе чего вы сделали такой вывод? С какими именно практиками XP вы несогласны?

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

X>Неопределенность — это риск. Риски в любом проекте должны быть сняты на начальных этапах. Лучше вообще до старта.

Риски в общем случае можно снять только одним способом — отказавшись от проекта.

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

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



G>>К чему все это? К тому, что почасовые планы можно составить только когда структура системы четкая, ясная и нет внешних факторов. Может быть стоит посмотреть чем эти подчиненные занимаются? Несерьезно требовать составить почасовой план от человека занятого творческой работой или работой связанной с неопределенностью.

X>Неопределенность — это риск. Риски в любом проекте должны быть сняты на начальных этапах. Лучше вообще до старта.
Не сняты, а определены. Снять риски по определению невозможно.

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

_>>Планирование в экстремальном програмировании есть. Но это не "План" как таковой. Это то, что нужно сделать.

X>Любой менеджер вам скажет, что список задач без даты их готовности — полная туфта.

Я сам менеджер.

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

X>>Угу, недавно в юморе пробегала ссылка на блог одного товарища, описывающего признаки "плохого программиста". Список, походу можно дополнять: они везде используют XP.

L>На основе чего вы сделали такой вывод? С какими именно практиками XP вы несогласны?

Да, мне тоже очень интересно.
Вероятно, изза отсутствия таковых...

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

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

S>>>а как же тогда быть? написанный менеджером плохо, написаный программером тоже плохо, выходит совсем без плана? а какже время планировать?

_>>см. Экстремальное Программирование

L>А ты сам-то его видел?
Конечно видел, стал бы я говорить, если бы не видел...

Хотя, я наверное чтото недосказал, и меня не так поняли.

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

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

X>>Угу, недавно в юморе пробегала ссылка на блог одного товарища, описывающего признаки "плохого программиста". Список, походу можно дополнять: они везде используют XP.

L>На основе чего вы сделали такой вывод? С какими именно практиками XP вы несогласны?

Я не согласен не с XP, а с догмами, вы неправильно меня поняли. Это был выпад в сторону alex_ez

но если уж отвечать на вопрос, то XP сама по себе не панацея, бывают процессы, в которые XP целиком плохо вписывается. Я согласен с теми практиками, от которых есть польза для меня и моей команды: сразу вспоминается только короткие итерации, автоматическое тестирование и code review (парное программирование во многих случаях не оправдано).

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

X>но если уж отвечать на вопрос, то XP сама по себе не панацея, бывают процессы, в которые XP целиком плохо вписывается. Я согласен с теми практиками, от которых есть польза для меня и моей команды: сразу вспоминается только короткие итерации, автоматическое тестирование и code review (парное программирование во многих случаях не оправдано).

Для хорошей отдачи от XP — нужно пользоваться ВСЕМИ практиками XP сразу. Использование некоторых из практик XP — не дадут нужного результата, а часто сделают его хуже. (c) Brooks, кажется.

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

X>>но если уж отвечать на вопрос, то XP сама по себе не панацея, бывают процессы, в которые XP целиком плохо вписывается. Я согласен с теми практиками, от которых есть польза для меня и моей команды: сразу вспоминается только короткие итерации, автоматическое тестирование и code review (парное программирование во многих случаях не оправдано).

Ну уж нет. Взялся за гуж, так уж говори, с какими практиками не согласен.

_>Для хорошей отдачи от XP — нужно пользоваться ВСЕМИ практиками XP сразу. Использование некоторых из практик XP — не дадут нужного результата, а часто сделают его хуже. (c) Brooks, кажется.

Не знаю кто, но уж точно не Брукс.

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

LV>У нас читал лекции по организации процесса программирования главный архитектор Питерского филиала Motorola. Насколь я его понял, план составляется сверху (проектировщиками) и спускается вниз (к программистам). Обычно разница оценки во времени составляет 30%, вроде бы ее согласовывают уже вместе. Очень важно понимать, что успешным может быть план только в организации, которая знает свой процесс. Должно быть высчитано среднее количество кода, которое пишут программисты в неделю и исходить из этого параметра. Кстати, по мнению преподавателя, этот параметр изменить в фирме очень сложно. Он постоянен.
LV>Я считаю, что план должен быть, но чтобы получить грамотный план должна быть проведена очень большая подготовительнА кая работа менеджерами. Кстати, Motorola собирает около 500 метрик. И у нее CMMI 5 уровня.

А кто у них там главный архитектор?

Всем привет. выскажу свое имхо.
Значится так. Первое.
Если вы набрали в команду безответсвенных программистов... то вам для начала необходимо научится набирать команду .
Итак решение напрашивается само собой. Ж)

Второе
если речь всетаки идет о том как планировать время. ТО необходимо вспомнить Черчилля "планирование очень сложная проблема, особенно когда она касается будущего"

мое ИМХО, что касается декомпозиции работы. Это очень правильно Если разрабочик ее не может выполнить, то это прямо указывает на непонимание проблемы. Если проблема не ясна, то говорить о сроках глупо.

Далее основным риском всетаки является невыполнение задачи в срок. Ваша задача выработать план реакции на такой риск. Наверное дейсвтительно достаточно иметь некторое время в запасе. Кроме этого вы должны выработать контрольные точки по которым понятно что риск такого рода наступает.
Ваша задача лишь правильно реагировать. успешный проект может быть задержан на 10% от полного срока проекта.

Далее научите персонал не бояться говорить Вам о проблемах. Очень часто ПМ оказывается последним человеком, узнавшим о том, что все идет наперекосяк.

ну и тд.

Евгений

А и еще в догонку.

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

Удачи

ИМХО. Что действительно хорошо в ХП так это юнит тесты и парное программирование. ну и еще запрещение овертаймов. Хотя это врядли строго ХПшная практика. Юнит тесты и парное программирование по сути дают возможность серьезно выграть на отладке. Не более но и не менее. возводить какуюбытгонибыло методологию в абсолют глупо.

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

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

S>Интересно можно ли переубедить? Хотелось бы стимулировать ответственностью... Или это бесполезное занятие?

привет!
Реально, этому учат — курсов масса, вот к примеру те, на которые сам ходил или своих подчиненных посылал:
http://www.sep.russee.com/

Если точно отмечать, то тут стоит посмотреть на
"Человеческий фактор в разработке ПО" и "Управлеение командами разработчиков" (последний уже прошел и в Питере и Москоу и поа планируется только в СПб — стоит спросить их — когда)

А вообще, кто-нибудь на тренинги ходит или только большие компании да крези по типу меня их туда таскают?

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

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

S>Интересно можно ли переубедить? Хотелось бы стимулировать ответственностью... Или это бесполезное занятие?

Подымите зарплату тем програмистам, которые умеют и составляют планы своей работы на хоть сколько нибудь

Здравствуйте, Аноним, Вы писали:

А>Реально, этому учат — курсов масса, вот к примеру те, на которые сам ходил или своих подчиненных посылал:
А>http://www.sep.russee.com/
А>"Человеческий фактор в разработке ПО" и "Управлеение командами разработчиков" (последний уже прошел и в Питере и

Посмотрел описание курса "Человеческий фактор в разработке ПО" (вот ссылка: http://www.russee.com/index.phtml?aid=30020515). Кроме смеси и так известных психологических методик, тестов и т.п. ничего не нашел.

Хотелось бы прояснить такие вопросы:

1) Курс содержит только краткое изложение различных психологических методик или конкретные управленческие приемы?

2) Если в курсе излагаются управленческие приемы, то чем они отличаются от приемов, изложенных в популярных книжках по управлению? Например, в книжках Дейла Карнеги, В. Тарасова и т.д.?

3) Есть ли конкретные примеры применения этих приемов в области разработки софта. Если такие примеры есть, то сколько? Несколько единиц? Или несколько десятков?

4) Есть ли среди примеров нетривиальные? Сколько?

5) Какие управленческие задачи способны решать изложенные приемы?

6) Сколько из этих задач являются актуальными для ПМов?

7) К каким качественным уровням относятся эти задачи? Т.е. грубо говоря, рассказывается ли о том, как внедрить в команде отдельные процедуры (планирование, отчетность)? Или рассказывается о том, как поставить и наладить технологический процесс по разработке качественного ПО, который бы продержался без существенных изменений 5 — 7 лет?

8) Есть ли у авторов курса открытые публикации, в которых изложены некоторые (не все!) приемы, и по которым можно судить о качестве курса?

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

_>Че пристал?..
_>Работай как привык!
_>Я же не против


Да, хамство прям прёт

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


_>Для хорошей отдачи от XP — нужно пользоваться ВСЕМИ практиками XP сразу. Использование некоторых из практик XP — не дадут нужного результата, а часто сделают его хуже. (c) Brooks, кажется.


Назови хоть один проект, который так делал и закончился успешно ($ принёс и работает)?

D В жизни главное умеренность, а экстремальность тока всё портит

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

SED> Ставьте очень мелко дроблёные задачи. Это наиболее важная часть в вашей работе по составлению плана. Ваши задачи должны измеряться в часах, а не в днях.

Это позиция крайне неопытного менеджера.

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

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

SED>> Ставьте очень мелко дроблёные задачи. Это наиболее важная часть в вашей работе по составлению плана. Ваши задачи должны измеряться в часах, а не в днях.

E>Это позиция крайне неопытного менеджера.
Почему? Оглядываясь назад и сравнивая результаты, я понимаю что человек говорит дело. Во всяком случае у меня так и было — сначала дни — потом часы.

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


SED>>> Ставьте очень мелко дроблёные задачи. Это наиболее важная часть в вашей работе по составлению плана. Ваши задачи должны измеряться в часах, а не в днях.
E>>Это позиция крайне неопытного менеджера.
SED>Почему? Оглядываясь назад и сравнивая результаты, я понимаю что человек говорит дело. Во всяком случае у меня так и было — сначала дни — потом часы.

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

E>Совершенно очевидно, что план может и должен меняться. Если дробить задачи слишком мелко, поддержка плана в здоровом состоянии может превратиться в самоцель, т.е у Вас на это будет уходить слишком много времени, или план быстро перестанет отражать реальную ситуацию. Это время, по моему опыту, лучше посвящать комуникациям с командой.
А кто-же будет дробить план на мелкие задачи? Конкретный исполнитель? Но кто поручится, что он сделает это?

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

E>>Совершенно очевидно, что план может и должен меняться. Если дробить задачи слишком мелко, поддержка плана в здоровом состоянии может превратиться в самоцель, т.е у Вас на это будет уходить слишком много времени, или план быстро перестанет отражать реальную ситуацию. Это время, по моему опыту, лучше посвящать комуникациям с командой.
N_C>А кто-же будет дробить план на мелкие задачи? Конкретный исполнитель? Но кто поручится, что он сделает это?

А зачем вообще дробить его на мелкие задачи?

E>А зачем вообще дробить его на мелкие задачи?
Для того, чтобы более точно рассчитать время на реализацию той или иной задачи. Чем мельче задача, тем это сделать проще, чем она крупнее, тем расчет времени менее точен.

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

E>>А зачем вообще дробить его на мелкие задачи?
N_C>Для того, чтобы более точно рассчитать время на реализацию той или иной задачи. Чем мельче задача, тем это сделать проще, чем она крупнее, тем расчет времени менее точен.

Кому проще? Кто у вас оценивает задачи?

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

E>>А зачем вообще дробить его на мелкие задачи?
N_C>Для того, чтобы более точно рассчитать время на реализацию той или иной задачи. Чем мельче задача, тем это сделать проще, чем она крупнее, тем расчет времени менее точен.

А время на интеграцию результатов этих мелких задач в одно целое как тогда рассчитывать?

E>Кому проще? Кто у вас оценивает задачи?
Скажем так... Оценка осуществляется совместно с непосредственным исполнителем. Самому исполнителю и проще.

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

SED>>> Ставьте очень мелко дроблёные задачи. Это наиболее важная часть в вашей работе по составлению плана. Ваши задачи должны измеряться в часах, а не в днях.
E>>Это позиция крайне неопытного менеджера.
SED>Почему? Оглядываясь назад и сравнивая результаты, я понимаю что человек говорит дело. Во всяком случае у меня так и было — сначала дни — потом часы.

А это вообще реально? Вот у меня часть проекта — написать сервер. Я сам хз какие там подзадачи, да мне и не нужно вникать в это. Я знаю что программист сам легко это сделает, он уже не один сервер написал; я просто описал задачу и он сделал, по времени уложился. Как тут дробить и зачем мне вообще лезть в его работу?

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

E>>Кому проще? Кто у вас оценивает задачи?
N_C>Скажем так... Оценка осуществляется совместно с непосредственным исполнителем. Самому исполнителю и проще.

Очень хорошо, что с исполнителем. Но выходит, что Вы считаете, что лучше исполнителя представляете, как именно и в какой последовательность реализовывать эту (более крупную) задачу? Не пытаетесь ли Вы тем самым делать часть чужой работы? (technical/team lead'a и самого исполнителя)? Уверены ли Вы, что сделаете эту работу заведомо лучше их?

Кё>А время на интеграцию результатов этих мелких задач в одно целое как тогда рассчитывать?
Я же не предлагаю дробить системы на подсистемы. Я предлагаю дробить высокоуровневые задачи на более мелкие.
Здесь далеко не всегда возникает задача интеграции. А если и возникает, то от нее никуда не денешься и в той
ситуации, когда задачу не раздробили. Все равно исполнитель для себя будет задачу дробить.

Кё>А это вообще реально? Вот у меня часть проекта — написать сервер. Я сам хз какие там подзадачи, да мне и не нужно вникать в это. Я знаю что программист сам легко это сделает, он уже не один сервер написал; я просто описал задачу и он сделал, по времени уложился. Как тут дробить и зачем мне вообще лезть в его работу?
И что? Исполнителю поставлена общая задача и выделено общее время. Что и как он делает внутри этого времени — Вы не видите и не оцениваете. Он заболел, ушел в отпуск, уволился и т.п. и работа встает, пока следующий исполнитель не оценит сделанной работы и сколько еще осталось. Раздробить работу на нескольких исполнителей тоже не представляется возможным. В общем и целом Вы или целиком перекладываете оценку времени работы на исполнителя (и оказываетесь в заложниках конкретного исполнителя) или ставите свои планы, рискуя нарваться на то, что исполнитель не сможет решить эту задачу за отведенное время.

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

_>>Планирование в экстремальном програмировании есть. Но это не "План" как таковой. Это то, что нужно сделать.
X>Любой менеджер вам скажет, что список задач без даты их готовности — полная туфта.

Откуда вы взяли, что при этом неизвестны сроки готовности?
При экстремальном планировании оцениваются сроки реализации историй в идеальных неделях. Если поделить их на скорость команды, вы получите реальный срок.

E>Очень хорошо, что с исполнителем. Но выходит, что Вы считаете, что лучше исполнителя представляете, как именно и в какой последовательность реализовывать эту (более крупную) задачу? Не пытаетесь ли Вы тем самым делать часть чужой работы? (technical/team lead'a и самого исполнителя)? Уверены ли Вы, что сделаете эту работу заведомо лучше их?
Стоп. Я не утверждаю, что кто-то конкретный типа PM'а или TL'а должен делать эту работу. Я просто говорю, что план, разбитый на большее количество мелких работ проще оценить по трудоемкости и процентах выполнения. Кто конкретно будет разбивать план на подзадачи не столь важно для конечного результата — детализированного плана. Важно, чтобы он в итоге появился.

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

E>>Очень хорошо, что с исполнителем. Но выходит, что Вы считаете, что лучше исполнителя представляете, как именно и в какой последовательность реализовывать эту (более крупную) задачу? Не пытаетесь ли Вы тем самым делать часть чужой работы? (technical/team lead'a и самого исполнителя)? Уверены ли Вы, что сделаете эту работу заведомо лучше их?
N_C>Я просто говорю, что план, разбитый на большее количество мелких работ проще оценить по трудоемкости и процентах выполнения.

Так вот я и спрашиваю — кому проще то? Почему-то все менеджеры, с кем я на эту тему беседовал и кто делает как Вы, признавались, что это им самим удобнее для понимания, как именно реализуется данная фича, т.к. они не вполне владеют предметной областью
Для девелоперов (если это не студент-второкурсник), а уж тем более для tech lead'a, поверьте, совершенно не нужна декомпозиция задач до нескольких часов.

E>Откуда вы взяли, что при этом неизвестны сроки готовности?
Вопрос был не в этом. Говорили о том, что в XP нет планов.

E>При экстремальном планировании оцениваются сроки реализации историй в идеальных неделях. Если поделить их на скорость команды, вы получите реальный срок.
Это будет тот же план только вид сбоку (о чем я тоже говорил)...

E>Так вот я и спрашиваю — кому проще то? Почему-то все менеджеры, с кем я на эту тему беседовал и кто делает как Вы, признавались, что это им самим удобнее для понимания, как именно реализуется данная фича, т.к. они не вполне владеют предметной областью
Да я не претендую на простоту или сложность. Я говорю про наличие детализированного или недетализированного плана. Если Вам удобнее более общий план (но при этом у Вас отсутствует реальное понимание кто и что делает в конкретный момент) то я с Вами не спорю. Просто с детализированным планом проще работать. Но надо знать меру конечно в детализации. На мой взгляд до часов план все-же детализировать не стоит. А вот до дней — можно.

E>Для девелоперов (если это не студент-второкурсник), а уж тем более для tech lead'a, поверьте, совершенно не нужна декомпозиция задач до нескольких часов.
С этим не спорю.

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

N_C>Да я не претендую на простоту или сложность. Я говорю про наличие детализированного или недетализированного плана. Если Вам удобнее более общий план (но при этом у Вас отсутствует реальное понимание кто и что делает в конкретный момент) то я с Вами не спорю. Просто с детализированным планом проще работать. Но надо знать меру конечно в детализации. На мой взгляд до часов план все-же детализировать не стоит. А вот до дней — можно.

Тема начиналась именно с часов. ОК. Тогда спорить не о чем
Чем кто занимается каждый час меня действительно не интересует. Это интересует тим-лидов и тех-лидов.

E>>Для девелоперов (если это не студент-второкурсник), а уж тем более для tech lead'a, поверьте, совершенно не нужна декомпозиция задач до нескольких часов.
N_C>С этим не спорю.

OK.

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

E>>Откуда вы взяли, что при этом неизвестны сроки готовности?
N_C>Вопрос был не в этом. Говорили о том, что в XP нет планов.

Редкостное заблуждение. Есть план итераций, с указанием, какие user stories входят в какую итерацию и с оценкой их (историй) в ideal weeks.

E>>При экстремальном планировании оцениваются сроки реализации историй в идеальных неделях. Если поделить их на скорость команды, вы получите реальный срок.
N_C>Это будет тот же план только вид сбоку (о чем я тоже говорил)...

Разумеется.

Nikolay_Ch wrote:
>
> E>Очень хорошо, что с исполнителем. Но выходит, что Вы считаете, что
> делать эту работу. Я просто говорю, что план, разбитый на большее
> количество мелких работ проще оценить по трудоемкости и процентах
> выполнения.

Если бы.

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

Короче, если делать по полной программе, то получится как угодно,
но только не просто.

> Кто конкретно будет разбивать план на подзадачи не столь
> важно для конечного результата — детализированного плана.

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

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

> Важно, чтобы он в итоге появился.

Не очень.

Mikhail

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

N_C>И что?

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

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

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

K>Кстати, из практики — между таском, теоретически занимающим
K>один, два, три или четыре часа разницы нет, реально
K>минимальное время на любой отдельный таск — полдня.
Я не спорю.

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

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

S>Интересно можно ли переубедить? Хотелось бы стимулировать ответственностью... Или это бесполезное занятие?

Вот вместе сядь с подчинённым и планируй а не жалуйся.

Докажи свою комптетентность.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Nikolay_Ch, Вы писали:

N_C>>И что?

Кё>То что я не планирую на часы, другие ПМ не планируют на часы и ни у кого нет проблем, а я просто интересуюсь, какие бешенные выгоды сулит такое детализированное планирование?
НАчал новую тему

Автор: SEDEGOFF
Дата: 23.06.06

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


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

Автор: SEDEGOFF
Дата: 23.06.06

Читаю название темы долгое время и в голову приходит только один совет ! Да избавляться от них надо , травить , гнать , ущемлять и т.п. Я вам вообще скажу по секреты все проблемы , баги , проблемы в коллективе, срывы сроков , это во всем они виноваты ! программисты !

Я вообще думаю , надо от них избавляться , от всех , а то вдруг ответственные тоже станут безответственными ?

Да борьба с прогарммистами это очень важное и полезное занятие ! Удачи вам в этом трудном деле , они народ живучий , особенно безответственные !