21.09.2010 19:18, Eugeny__ пишет:

> E__>>Ну честно, не могу я серьезно себе представлять это. У вас там
> системы документооборота/багофичетрекера нету, что-ли? Зачем этот цирк
> по утрам?
>
> G>Речь шла про scrum daily meeting
>
> Все подобные системы, своды правил и прочие инструкции сделаны для
> обезьян

Осторожнее со scrum, несчастный, жрецы Agile уже мастерят твою куклу,
чтобы проткнуть её иголками

--
WBR,
Serge.

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


>> G>Речь шла про scrum daily meeting
>>
>> Все подобные системы, своды правил и прочие инструкции сделаны для
>> обезьян

H>Осторожнее со scrum, несчастный, жрецы Agile уже мастерят твою куклу,
H>чтобы проткнуть её иголками

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

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

L>Сможете припомнить, чего такого армия (любая) создала за всю историю человечества?
Дач понастроила немало

E__>Я стараюсь выбирать работу так, чтобы жить поближе к идеальному миру. И ведь получается же!

ты же наверно и из рашки почти свалил?

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


E__>>Я стараюсь выбирать работу так, чтобы жить поближе к идеальному миру. И ведь получается же!

D>ты же наверно и из рашки почти свалил?

Я всю жизнь, как-бы, в Украине прожил. Так что даже не знаю, что ответить. Сваливать пока никуда не хочу.

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

E__>Я стараюсь выбирать работу так, чтобы жить поближе к идеальному миру. И ведь получается же!

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

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

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

E__>Знаешь, у меня серьезное недоверие всем расписанным по полочкам, шагам и красиво иллюстрированным диаграммками систем управления людьми.

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

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

Ну и как-то всё очень общо у тебя получается. Правила — плохо.

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

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

E__>>Знаешь, у меня серьезное недоверие всем расписанным по полочкам, шагам и красиво иллюстрированным диаграммками систем управления людьми.

G>У всех методик есть свои области применимости. Задача грамотного менеджера и заключается в том, чтобы скомбинировать методики идеально подходящие к его ситуации.

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

G>Ты вроде говоришь все правильно. Люди не винтики и всё такое. Индивидуальный подход. А между тем именно своды правил и прочие инструкции, то есть то, что называется "процессом разработки" позволяет этот процесс упорядочить, сделать предсказуемым и управляемым. Избавиться от бардака в котором тут все горазды друг друга обвинять.
G>Без процесса возникает именно что бардак.
G>Процесс даёт разработчику ответы на очень важные вопросы.
G>- Как его контролируют и что считается хорошо выполненной работой, а что плохо выполненой.
G>- Что делать в случае исключительных ситуаций.
G>- В конце-концов, что же вообще надо делать
G> Все те правила которые по-твоему "для роботов" созданы в первую очередь чтобы отвечать на эти вопросы. Иначе придеться делать "незнамо что незнамо для чего".
G>Тебя ведь не смутит правило "раз в неделю собрать билд и отдать тестерам"? Оно не делает из людей роботов? А почему тогда "раз в день отчитаться о своей работе" тебя смущает? Одна из задач этих пресловутых ежедневных митингов это максимально быстро сообщить о проблемах (например о недооценке сроков) менеджеру. Что в этом такого уж плохого?

G>Ну и как-то всё очень общо у тебя получается. Правила — плохо.

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

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

Контроль — не единственная схема мотивации. Если сотрудник получает процент с каждого подпроекта, (но при этом не получает ничего за багфиксинг, и не может разрабатывать новое, пока есть баги), то контроль ему и нахрен не нужен. Сам будет делать, и с минимумом багов — это ему выгодно. Это очень грубо, но идея, думаю, понятна. Хотя такая схема в некоторых случаях не применима, но таких случаев, если вдуматься, не так много.
И да, таки процент дожен быть значительным. Только наши менеджеры часто паталогически жадные, им проще стоять с палкой контролировать каждую секунду разработчика, чем мотивировать его. Заодно и ЧСВ растет, как же без него.

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

G>>Ну и как-то всё очень общо у тебя получается. Правила — плохо.

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

Ну тут мы вроде пришли к согласию.
За одним пунктом. Очень часто лучше уж пусть бездумно внедряют "супер-пупер технологией ХХХ", чем вообще бардак. Технология худо-бедно проверена общественностью и в среднем будет работать лучше чем перманентный бардак.

E__>Контроль — не единственная схема мотивации.

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

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

Лично я уверен в том, что эта схема крайне сложна в реализации. Что подтверждает обсуждение в соседней ветке. Например потому, что очень сложно объективно измерять вклад каждого в общее дело.

E__>И да, таки процент дожен быть значительным. Только наши менеджеры часто паталогически жадные, им проще стоять с палкой контролировать каждую секунду разработчика, чем мотивировать его. Заодно и ЧСВ растет, как же без него.

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

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

E__>>Контроль — не единственная схема мотивации.

G>Контроль это лишь косвенно схема мотивации. В первую очередь это именно контроль. Хороший менеджер должен в любой момент времени знать ответ на вопросы: где мы находимся сейчас, сколько сделано, сколько осталось, риски какие сработали/не сработали, какие остались , что получилось, что нет и почему, итд. Знать ответ на эти вопросы помогает именно система контроля.
G>Если контролировать редко — понимание происходящего у менеджера будет очень сильно запаздывать. Есть проекты где это не страшно, а есть где это очень плохо.
G>Слишком часто контролировать впрочем тоже бывает бессмысленно.

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

G>Лично я уверен в том, что эта схема крайне сложна в реализации. Что подтверждает обсуждение в соседней ветке. Например потому, что очень сложно объективно измерять вклад каждого в общее дело.

E__>>И да, таки процент дожен быть значительным. Только наши менеджеры часто паталогически жадные, им проще стоять с палкой контролировать каждую секунду разработчика, чем мотивировать его. Заодно и ЧСВ растет, как же без него.

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

Завтра напишу здесь свои идеи по поводу модели разработки. Что-то подобное используется у нас, и весьма успешно. Кстати, я своему руководству не завидую, и ни в чем не обвиняю. У нас все весьма адекватны. Просто я хочу донести, что модель, когда разработчику самому выгодно работать, и работать хорошо, качественно выгоднее той, в которой в случае падения уровня контроля все начнут бить баклуши. Но эта модель точно не для каждой команды и не для каждого проекта. Серебрянной пули от всего не бывает, особенно если проект — древнее говно мамонта, писанное говнокодерами с использованием сейчас уже попахивающих технологий, подпертое тысячами костылей, и чудом как работающее. В особо упоротых случаях такое проще переписать, чем допиливать.
Вобщем, ждите новых серий, все будет.

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


G>>>Ну и как-то всё очень общо у тебя получается. Правила — плохо.

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

G>Ну тут мы вроде пришли к согласию.
G>За одним пунктом. Очень часто лучше уж пусть бездумно внедряют "супер-пупер технологией ХХХ", чем вообще бардак. Технология худо-бедно проверена общественностью и в среднем будет работать лучше чем перманентный бардак.

Для больших компаний — да. Там лучше дебилкуватый свод правил и тотальная бюрократия, чем неконтролируемый бардак. Но в небольших средах разработчиков, которым выгодно развивать компанию(в том числе и финансово, причем профит виден незамедлительно), чрезмерная бюрократизация и армейская дисциплина ни к чему, она наоборот все затормозит. Слыхили байку про процесс покупки принтера в огромной корпорации и стартапе?

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



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

Ну приведи пример другой организации с жесткой дисциплиной, что ли. А то на ум что-то ничего не приходит. Сделаем правильную индукцию.

G>Мне больше нравится версия, что ответа ты не знаешь.

Да ради бога, если нравится. Только можно в лужу сесть ненароком.

G>А если знаешь, но тебелень писать, то зачем ты пишешь всё остальное? Остальное значит не лень?

Потому что влезая в спор о scrum, некотором не помешало бы с предметом ознакомиться несколько более детально.

L>>>>Кажется, одного из нас жестко дезимформировали по поводу scrum.

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

L>>Наводящий вопрос — кто на этом митинге вообще присутствует и кому они это все рассказывают и зачем?

G>scrum daily meeting :
G># What have you done since yesterday?
G># What are you planning to do today?

Там еще одна очень интересная строчка есть

All are welcome, but only “pigs” may speak

Понять, что это означает и что из этого следует, предлагаю самостоятельно. Не флейма ради, а продолжения разговора для. Будет интересно, обещаю.

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

E__>Ну честно, не могу я серьезно себе представлять это. У вас там системы документооборота/багофичетрекера нету, что-ли? Зачем этот цирк по утрам?

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

L>>Сможете припомнить, чего такого армия (любая) создала за всю историю человечества?
O>Дач понастроила немало


По крайней мере часть знаменитых римских дорог была построена римскими же легионерами

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

L>Возьмите армию как пример организации, где контроль возведен в абсолют.

Не контроль, а выполнение приказа (боевой задачи).

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


Замечательная теория, возьму на вооружение. Правда, не имеет никакого отношения к реальности, там просто "так принято" и все тут.

TL>>Хм... На загнивающем западе, конкретно в его европейской части, жизнь вообще начинается в 7 утра. Зато после работы в 4 ты уже свободен: можно с детями погулять, личную жизнь занять, просто солнце увидеть не в окно офиса.

DB>Основная причина, думаю, в том, что очень многие страны расположены ближе к экватору. А это значит, что в 7-8 часов вечера у них гарантированно темно.


Слушай, ты бы на карту посмотрел или там глобус. Какой еще экватор в Европе? Начинать рабочий день рано — традиция и все.

MP>О, супер, наконец-то появились работодателе, которых интересует не только материальное состояние работников, но и их личная жизнь и половые проблемы. Вот это я понимаю "забота о сотрудниках". Скажите, входит ли временная самка в ваш relocation pack для иногородних?


А у вас не входит?! Скорей обнародуй имя этой отсталой конторы, внесем в черный список

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

Г>Например, в городе Москве приезд на работу к 9-00 или 10-00 обеспечиват работнику отличную возможность иметь регулярную жизнь в пробке или в давке в метро, что отрицательно сказывается на мироощущении. А в качестве бесплатного бонуса либо необходимость приезжать заранее, либо постоянный стрес от риска опоздать.

Ты сам-то пробовал к этому времени приезжать? Я на работу еду к 8-9 обычно, давки в метро, особенно если ехать к 8-ми вообще нет, зато есть куча свободного времени после работы.

TMU>Замечательная теория, возьму на вооружение. Правда, не имеет никакого отношения к реальности, там просто "так принято" и все тут.

Сложный вопрос. Я вот летом немного поработал в Саудовской Аравии, в 3-30 заканчивал работу, в 4 был отеле. Казалось бы, ещё куча времени позагорать возле бассейна, ан нет, через 2 часа свет только от фонарей. Если бы приезжал с работы часов в 6-7, то солнца бы вообще не видел.