1. 7 +- 2 если следовать Скраму. Если почитаете Джоэл о программировании то увидите что и там советуют эксель. Если разработчиков больше, стоит подумать о разделении на отделы, как поступают многие крупные компании, в том числе и майкрософт.
2. Конечно правильно. Только мне честно плевать на проблемы ПМ-а, и я не готов облегчать ему работу за свой счет. В итоге продукт производим мы.
3. Так и будет. Если раньше и без жиры я мог месяц делать вид что работаю и это оставалось незамеченным, потому что даже никто не спрашивал а что я вообще делаю, и сколько времени осталось. А я мог позволить, так как никому никаких сроков не называл. Когда будет все на блюдичке, ПМ вообще из своего угла будет выходить только в туалет.
4. Я не про эту отвественность. Я про другую, такую как следить за изменением подзадач, и вовремя ставить на себя же новые, следить за переключением с одной задачи на другую, отмечая увеличение общего времени по каждой, следить за проблемами, отражая все в жире, и т.д.
5. Нужна, согласен. Хотя я бы использовал бы eTraxis.Но она нежна нам, программистам. И как ПМ будет неуспевать если он даже не начинал. Вот пусть начнет а потом придет и скажет я не успеваю, наймут еще одного. А сейчас он вообще ничего в голове не держит, и даже не пытается.
6. Опять вы меня не поняли. Для заказчика должен висеть план на стене, и презентация раз в месяц. Жира ему не нужна. Поэтому если ПМ будет вести все дела в Жире, ему придется переносить всю информацию отдельно в тот же эксель или мс проджект, для того что бы показать заказчику, и поддерживать оба варианта.
agile-like разработкой тут и не пахнет. А разработчики — раздолбаи все равно ничего заносить не будут. Я иак и сказал что менять ничего в своей работе с жирой не буду. По крайней мере пока не уижу других, шагов по улучшению процесса.
Вы не поняли наверное
>1 — х*й. планы с реальностью совпадают на очень недолгом промежутке времени.
Я не горю что они сами по себе будут совпадать. Их надо поддерживать, и корректировать ежедневно.
2. Это время необходимо учитывать. Есть идиальная оценка а есть реальная, которая строится с учетом рисков. Сначало можно просто умножать на 2-3, потом, когда соберется статистика, можно вычислить и более точный коэфициент. Почитайте XP там об этом сказано.
совершенно верно. у нас очень сложная и непонятная ситуация. ведь просрочки были как раз из-за отсутвия процесса, поэтому страдать должны те кто этот процесс должен был налаживать. ведь так? а получается что опять крайние программисты.
А мне наша секретарша, в ответ на приставания «Оксан, ну подари мне что нибудь», подарила кружку с раздваивающимся от тепла мужиком))) Хорошо что удалось поменять у знакомой девушки, над которой так же прикололись одногруппники, подарив ей чашку с раздевающейся девушкой. Она у меня до сих пор.
А можно подробнее как называется такая модель, кем она считается наиболее эффективной, в чем её суть, где можно почитать, для каких отраслей применяется еще?
Кстати, в одной прошлой компании у нас уже была такая история. Один из наших отделов разработал инструмент для отчетности, взамен устаревшего. Крутой такой, красивый. Много фишек. Но им никто не пользовался. Наш отдел официально отказался им пользоваться, с поддержки начальника отдела. Другие просто забивали. Разработчики тулзы сильно обиделись, ведь такая крутая штука, столько фич, столько любви вложено в неё. Я поговрил с начальником того отдела, и выяснилось что он пытался сделать инструмент удобный для ПМ-ов, что бы можно было смотреть прогресс по задачам, строить графики и тд. А то что программерам это все нафиг не нужно, они хотят заниматься интересным кодингом а не тыканьем кнопок, об этом не подумали.
В итоге проблему решили так, сделали кнопочку, по нажатию на которую появлялось окошко в котором было просто поле ввода, селект со списком задач и кнопочка «отправить отчет». С этого момента все стали тулзой пользоваться, ибо избавились от излишних формальностей.
Обсудим. Сейчас обсудили с ПМ-ом. Он не отрицает что это все нужно лично ему, и типа от программеров не потребуется ничего делать. Но тут же в разговоре выясняется что делать таки придется, «ну этож мелочи» как он говорит. Вообщем, я ему сказал делай с JIRA что хочешь, только, что бы нас это не касалось. Он просто не понимает что пытается подменить Жирой личное общение и не понимает чем это грозит. И есть у меня чувство что хорошим это не кончится. Будут вопросы потом к программистам: почему не отметил время, почему не закрыл подзадачу, почему не отметил изменения в подзадачах и т.д.
Пока я ему предложил встречный вариант — ежедневная отчетность. У нас даже есть инструмент для этого, только им никто не пользуется. Он согласен, что отчетность нужна (типа что сегодня делал и сколько времени ушло), но пока недопонимает, что это полностью удовлетворяет его потребностям в аналитике и при этом занимает у программистов максимум 15 мин времени причем в конце дня когда вся работа закончена, не отвлекая. Теперь решение за техдиром.
Я не против формализации, и мало того я каждый день горяю что у нас нет процесса, и первый выступаю за его наладку. Мало того в начале проекта я сам занимался этими вещами, планированием, распределением задач, контролем, и мы четко укладывались в сроки, и процесс был налажен. Потом задачи разработки и уход в отпуск вынудили переложить эту ответственность на неумеху ПМ-а. После этого все пошло крахом. Но опыт наладки процесса у меня есть и я только за формализацию обоими руками.
НО формализация ради формализации — зло. А здесь, возникает ощущение что хотят все сделать правильно, но не знают как, или не могут избавится от стереотипов.
1. Планы ДОЛЖНЫ отражать реальную ситуацию в каждый момент времени.
2. А какая разница какие задачи сколько времени делались? Главное сколько было потрачено времени на всю итерацию. Этих данных достаточно для оценки эффективности работы программиста. Но в любом случае ПМ или там Тимлид должны ежедневно контроллировать процесс, таким образом у них эта информация все равно будет, так как они корректируют план ежедневно, и если им интересна история, можно например загнать планы в svn
3. Опять же информация по подзадачам должна быть у тимлида на карте(в екселе где угодно). Программер итак знает как он будет делать задачу, и тимлид просто интересуется каждый день какие из подзадачь в каком состоянии. Так он будет еще и контроллировать, кроме общего хода работ, любые изменения в процессе и влиять на него (часто некоторые подзадачи можно отложить, если не укладываемся в сроки, но делать это надо своевременно).
Мое мнение что
1. JIRA не для этого мусора интересного только ПМ-у и тимлиду
2. Это попытка облегчить себе работу.
3. Такой подход расслабляет, можно не общаться каждый день с программерами, можно не контроллировать процесс, все есть в JIRA
4. Это может побудить к перекладыванию некоторой отвественности на плечи программистов
5. Это использование сложного инструмента взамен простого
6. Процесс либо будет дублироваться либо будет недоступен для заказчика, который не хочет ничего знать о JIRA и это его право.
Я то понял для чего все это. Мне непонятно причем тут JIRA. Аналитика нужна и полезна, но почему нельзя руководствоватся данными планов? В начале итерации распределены задачи, оценены. Прогресс смотрим ежидненвно. По итогам итерации анализируем. Мне непонятно зачем в JIRA версии если версии должны определятся по набору запланированных фич в начале итерации и по количеству их реально выполненных вконце. Для чего здесь понятие компонент? Подзадач? Эти вещи вообще каккой имеют практический смысл?
кризис в 98 никак не мог вас затронуть так как это был нас кризис. А сейчас мировой, но ваш дефолт Россию затронет только на небольшую сумму доллга но она не критическая.
Разговоры эти имеют под собой основания. Нефиг было оружие в Грузию поставлять задорма, распиливая бабло. Нефиг было ерепенится и угрожать что не пцустите флот обратно. Нефиг газ тырить, нефиг русский язык запрещать, нефиг фашистам памятники ставить, нефиг историю переписывать. Украинцы не виноваты. Виноваты ваши власти которым вы доверились и которые загнали вас в эту вот жопу и когда Россия могла бы вам помочь, она помогает Белоруссии и Исландии, а вы у МВФ клянчите.
А вообще Украину лично я не недолюбливаю. Правда на территории ни разу небыл, но жил то долгое время рукой подать, многие знакомые и наверное даже предки родом оттуда. А недолюбливаю власти ваши, это да, но кто их у вас любит? Все с кем горил горят, ну да, ну мудак наш Ющенко, это всем понятно. Так что это не только мое мнение.
Это политика. Пока Тимошенко нам нужна мы будем её салом угощать. Уж лучше чем вашего Ющенко. Его вы сами надеюсь засадите подальше пока он остаток вашей армии не распродал)))
В интересах Украинского и Русского народов дружить. Но если мы без вас таки переживем, хотя и жаль, братский народ, одна нация и религия, то вы без России врятли.Надеюсь хоть кризис всех нас научит дружить снова. Хотя у меня со знакомыми с Украины исключительно хорошие отношения
2. Конечно правильно. Только мне честно плевать на проблемы ПМ-а, и я не готов облегчать ему работу за свой счет. В итоге продукт производим мы.
3. Так и будет. Если раньше и без жиры я мог месяц делать вид что работаю и это оставалось незамеченным, потому что даже никто не спрашивал а что я вообще делаю, и сколько времени осталось. А я мог позволить, так как никому никаких сроков не называл. Когда будет все на блюдичке, ПМ вообще из своего угла будет выходить только в туалет.
4. Я не про эту отвественность. Я про другую, такую как следить за изменением подзадач, и вовремя ставить на себя же новые, следить за переключением с одной задачи на другую, отмечая увеличение общего времени по каждой, следить за проблемами, отражая все в жире, и т.д.
5. Нужна, согласен. Хотя я бы использовал бы eTraxis.Но она нежна нам, программистам. И как ПМ будет неуспевать если он даже не начинал. Вот пусть начнет а потом придет и скажет я не успеваю, наймут еще одного. А сейчас он вообще ничего в голове не держит, и даже не пытается.
6. Опять вы меня не поняли. Для заказчика должен висеть план на стене, и презентация раз в месяц. Жира ему не нужна. Поэтому если ПМ будет вести все дела в Жире, ему придется переносить всю информацию отдельно в тот же эксель или мс проджект, для того что бы показать заказчику, и поддерживать оба варианта.
agile-like разработкой тут и не пахнет. А разработчики — раздолбаи все равно ничего заносить не будут. Я иак и сказал что менять ничего в своей работе с жирой не буду. По крайней мере пока не уижу других, шагов по улучшению процесса.
>1 — х*й. планы с реальностью совпадают на очень недолгом промежутке времени.
Я не горю что они сами по себе будут совпадать. Их надо поддерживать, и корректировать ежедневно.
2. Это время необходимо учитывать. Есть идиальная оценка а есть реальная, которая строится с учетом рисков. Сначало можно просто умножать на 2-3, потом, когда соберется статистика, можно вычислить и более точный коэфициент. Почитайте XP там об этом сказано.
В итоге проблему решили так, сделали кнопочку, по нажатию на которую появлялось окошко в котором было просто поле ввода, селект со списком задач и кнопочка «отправить отчет». С этого момента все стали тулзой пользоваться, ибо избавились от излишних формальностей.
Пока я ему предложил встречный вариант — ежедневная отчетность. У нас даже есть инструмент для этого, только им никто не пользуется. Он согласен, что отчетность нужна (типа что сегодня делал и сколько времени ушло), но пока недопонимает, что это полностью удовлетворяет его потребностям в аналитике и при этом занимает у программистов максимум 15 мин времени причем в конце дня когда вся работа закончена, не отвлекая. Теперь решение за техдиром.
НО формализация ради формализации — зло. А здесь, возникает ощущение что хотят все сделать правильно, но не знают как, или не могут избавится от стереотипов.
2. А какая разница какие задачи сколько времени делались? Главное сколько было потрачено времени на всю итерацию. Этих данных достаточно для оценки эффективности работы программиста. Но в любом случае ПМ или там Тимлид должны ежедневно контроллировать процесс, таким образом у них эта информация все равно будет, так как они корректируют план ежедневно, и если им интересна история, можно например загнать планы в svn
3. Опять же информация по подзадачам должна быть у тимлида на карте(в екселе где угодно). Программер итак знает как он будет делать задачу, и тимлид просто интересуется каждый день какие из подзадачь в каком состоянии. Так он будет еще и контроллировать, кроме общего хода работ, любые изменения в процессе и влиять на него (часто некоторые подзадачи можно отложить, если не укладываемся в сроки, но делать это надо своевременно).
Мое мнение что
1. JIRA не для этого мусора интересного только ПМ-у и тимлиду
2. Это попытка облегчить себе работу.
3. Такой подход расслабляет, можно не общаться каждый день с программерами, можно не контроллировать процесс, все есть в JIRA
4. Это может побудить к перекладыванию некоторой отвественности на плечи программистов
5. Это использование сложного инструмента взамен простого
6. Процесс либо будет дублироваться либо будет недоступен для заказчика, который не хочет ничего знать о JIRA и это его право.
Разговоры эти имеют под собой основания. Нефиг было оружие в Грузию поставлять задорма, распиливая бабло. Нефиг было ерепенится и угрожать что не пцустите флот обратно. Нефиг газ тырить, нефиг русский язык запрещать, нефиг фашистам памятники ставить, нефиг историю переписывать. Украинцы не виноваты. Виноваты ваши власти которым вы доверились и которые загнали вас в эту вот жопу и когда Россия могла бы вам помочь, она помогает Белоруссии и Исландии, а вы у МВФ клянчите.
А вообще Украину лично я не недолюбливаю. Правда на территории ни разу небыл, но жил то долгое время рукой подать, многие знакомые и наверное даже предки родом оттуда. А недолюбливаю власти ваши, это да, но кто их у вас любит? Все с кем горил горят, ну да, ну мудак наш Ющенко, это всем понятно. Так что это не только мое мнение.
В интересах Украинского и Русского народов дружить. Но если мы без вас таки переживем, хотя и жаль, братский народ, одна нация и религия, то вы без России врятли.Надеюсь хоть кризис всех нас научит дружить снова. Хотя у меня со знакомыми с Украины исключительно хорошие отношения