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

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

Z>>Извините, может я плохо объяснил.
Z>>У нас есть начальник отдела программеров. У него в подчинение находится примерно 30 программеров.
Z>>И он ПОНИМАЕТ, что процесс отстой

pik>ну вернулисъ мы назад, после того что ты тут написал вывод может бытъ один — он не соответсвует своей должности и гнатъ его надо в шею, разве это не очевидно?

Ну, 1-е: я этого не могу
2-е: в теории, он готов к изменениям

Здравствуйте, pik,

это, конечно же, очевидно, но думаю, что "гнать его в шею" находится вне полномочий ТС.

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


Z>Ну, 1-е: я этого не могу
а я и не требую

Z>2-е: в теории, он готов к изменениям
а как он попал на эту позицию?

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


V_S>это, конечно же, очевидно, но думаю, что "гнать его в шею" находится вне полномочий ТС.

ну это как посмотретъ на ситуацию. если он начал "воду мутитъ" а началъник отдела совсем "не в теме" то естъ вариант что он может вышестоящему руководтсву о ситуации доложитъ, сделатъ предложения, показатъ как надо как должно бытъ ну и если убедит то занятъ позицию НО

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

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


V_S>>это, конечно же, очевидно, но думаю, что "гнать его в шею" находится вне полномочий ТС.

pik>ну это как посмотретъ на ситуацию. если он начал "воду мутитъ" а началъник отдела совсем "не в теме" то естъ вариант что он может вышестоящему руководтсву о ситуации доложитъ, сделатъ предложения, показатъ как надо как должно бытъ ну и если убедит то занятъ позицию НО

И сразу можно апдейтить резюме

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

pik>>ну это как посмотретъ на ситуацию. если он начал "воду мутитъ" а началъник отдела совсем "не в теме" то естъ вариант что он может вышестоящему руководтсву о ситуации доложитъ, сделатъ предложения, показатъ как надо как должно бытъ ну и если убедит то занятъ позицию НО

Z>И сразу можно апдейтить резюме

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

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

Z>Заметил, что процесс у нас не отвечает никаким методологиям/фреймуоркам, ну может немного смахивает на водопад

А есть какие-то проблемы, кроме несоответствия процесса методологиям и фреймворкам?

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

V_S>1. Какие проблемы ты хочешь решить с помощью [некоей методологии]?

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

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

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

Z>>Заметил, что процесс у нас не отвечает никаким методологиям/фреймуоркам, ну может немного смахивает на водопад

Pzz>А есть какие-то проблемы, кроме несоответствия процесса методологиям и фреймворкам?

Ну, я писал...


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

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

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

Z>>И он ПОНИМАЕТ, что процесс отстой

V_S>Дык? Если он понимает, и если обсуждение с ним уже проводилось, — в чем проблема-то? Тогда поговори с ним уже конкретнее: "Вот есть [некая методология], она позволит решить такие-то и такие-то проблемы, за такой-то срок. Я готов взяться за внедрение этой методологии. Считаю, что в такие-то сроки будут достигнуты такие-то показатели качества разработки. Мне нужна административная поддержка от Вас такая-то."

Наверное, самая подходящее решение.
У меня только нет опыта в этой отрасли.
Но есть много мотивации

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

Z>[1]" Проблему простоя или гонок. [2]Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года. [3]Проблему, что на 5000 солюшенов нет ни одного юнит теста. [4]Проблему, что нет команды, [5]сроки кидаются в воздух, [6]мысль о парном программировании вводить коллег в ужас."

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

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

3 — это, заметьте, само по себе проблемой не является. Проблема, это когда много ошибок в софтварии, или софтварий разваливается при попытке в нем что-то изменить и т.д. и т.п.

4 — что это значит?

5 — что это значит?

6 — меня она тоже приводит в ужас, если честно. Вернее, в недоумение. Парно хорошо детей делать и двуручной пилой пилить, а не программы писать.

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

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

Z> Проблему простоя или гонок.
Это больше похоже на плохое планирование. И эта проблема может существовать при любой методологии.

Z> Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года.
Ну если есть чего показать раньше, то кто мешает. А если нечего показать, то методология не поможет.
Про короткие итерации с рабочим продуктом в конце я знаю, но встречал подобное в командах, которые и слова Agile не слыхали.

Z> Проблему, что на 5000 солюшенов нет ни одного юнит теста.
Вообше то юнит тесты можно добавить вне зависимости от методологии. И более того, никакая методология сама их не добавит.

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

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

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

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

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

Z>Как быть? Дать им всё завалить?

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

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

Z>1. Проблему простоя или гонок.
Это реально есть или в книжке прочитано?

Z>Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года.
Это стало реальной проблемой для бизнеса или в книжке прочитано?

Z>Проблему, что на 5000 солюшенов нет ни одного юнит теста.
Это не проблема

Z>Проблему, что нет команды, сроки кидаются в воздух,
Это стало реальной проблемой для бизнеса или в книжке прочитано?

Z>мысль о парном программировании вводить коллег в ужас.
И это тоже не проблема. Вообще, использование Agile или RUP, использование табов или пробелов, использование svn или git или perforce, будь он неладен, а так же то, что начальник слушает музыку Самоа и смотрит фильмы про Тасманию — всё это не проблемы.

Z>3. Ну, с чего то надо начать. В скраме не так много ограничений, хотя если и их будет слишком много, можно дискуссировать о канбане, например. Аргументы — хочу сделать процесс лучше.

Что значит "лучше"? Разверните, а то получается как в анекдоте про армянское радио: "Армяне лучше чем грузины. — Чем лучше? — Чем грузины."

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

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

Z>>[1]" Проблему простоя или гонок. [2]Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года. [3]Проблему, что на 5000 солюшенов нет ни одного юнит теста. [4]Проблему, что нет команды, [5]сроки кидаются в воздух, [6]мысль о парном программировании вводить коллег в ужас."

Pzz>1 — существует в каком-то виде при любом процессе. Проблема в том, что люди не машины, и их производительность колеблется в широких пределах. Кроме того, не существует точных методик оценки трудоемкости того или иного задания, до того, как это задание исполненно.

Ну, мы вообще производительность не измеряем никак.

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

Именно так. И почему то есть предпочтение, чтобы клиент вообще не знал, чем мы занимаемся.
И ещё раз — презентация раз в пол-года.

Pzz>3 — это, заметьте, само по себе проблемой не является. Проблема, это когда много ошибок в софтварии, или софтварий разваливается при попытке в нем что-то изменить и т.д. и т.п.

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

Pzz>4 — что это значит?

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

Pzz>5 — что это значит?

Никто никак не расчитывает сколько времени возьмет что-то большое.
В конце не успеваем и выкидываем разную функциональность.

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

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

Z>Ну, мы вообще производительность не измеряем никак.

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

Z>И ещё раз — презентация раз в пол-года.

Во многих случаях этого достаточно. Заказчику совершенно не интересны внутренние технические "потроха" вашего софта. А соответствие софта требованиям Заказчика — эта задача должна решаться аналитиками, путем постоянного отслеживания требований Заказчика, их актуальности и соответствия софта требованиям. Непонятно только, если ваши аналитики мышей не ловят — чем здесь может помочь именно Agile, а не любая другая методология? Если исходные требования неверны, неполны или неактуальны, — любая методология, включая Agile, приведет к выдаче в релиз софта, не соответствующего требованиям Заказчика.

Z>Если система большая и не покрыта тестами, и ее не писали трансформеры — ошибок будет много.

У тебя есть факты (статистика, плотность ошибок и др.)? Или это только теоретические рассуждения?
Как ты собираешься измерять плотность ошибок, покрытие кода тестами и пр.? Иначе без фактических данных как ты сможешь утверждать, что покрытие тестами "улучшило" софт или "ухудшило"?

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

Так вот эта проблема и является ключевой. Не понимаю только, чем тут поможет именно Agile, а не любая другая методология? Любой приличный PM знает:
"Четыре основных правила менеджмента:
1. Найти нужных людей.
2. Дать им ту работу, для которой они лучше всего подходят.
3. Не забывать о мотивации.
4. Помогать им сплотиться в одну команду и работать так дальше.
Все остальное — административная ерундистика."
(с)

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

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

Z>>1. Проблему простоя или гонок.
AK>Это реально есть или в книжке прочитано?

Реально.

Z>>Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года.
AK>Это стало реальной проблемой для бизнеса или в книжке прочитано?

Реально — они ожидают другого. С клиентом я не контактирую, т.к. он хер его знает кто и хер его знает где

Z>>Проблему, что на 5000 солюшенов нет ни одного юнит теста.
AK>Это не проблема

...а проблема в том, что есть баги? поэтому они и есть.

Z>>Проблему, что нет команды, сроки кидаются в воздух,
AK>Это стало реальной проблемой для бизнеса или в книжке прочитано?

реально.
А ещё есть поддержка 7-и разных версий продукта у разных клиентов.

Z>>мысль о парном программировании вводить коллег в ужас.
AK>И это тоже не проблема. Вообще, использование Agile или RUP, использование табов или пробелов, использование svn или git или perforce, будь он неладен, а так же то, что начальник слушает музыку Самоа и смотрит фильмы про Тасманию — всё это не проблемы.

Фильмы и музыка — это был пример "самопроталкивания".
Ну мы же не комманда — поэтому люди этого шугаются

Z>>3. Ну, с чего то надо начать. В скраме не так много ограничений, хотя если и их будет слишком много, можно дискуссировать о канбане, например. Аргументы — хочу сделать процесс лучше.

AK>Что значит "лучше"? Разверните, а то получается как в анекдоте про армянское радио: "Армяне лучше чем грузины. — Чем лучше? — Чем грузины."

Упорядочнее и чтобы все понимали что-где-когда.

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

Pzz>>6 — меня она тоже приводит в ужас, если честно. Вернее, в недоумение. Парно хорошо детей делать и двуручной пилой пилить, а не программы писать.
Z>Поэтому у нас (и наверное у вас) есть люди, которые если уйдут в отпуск, работа в их сфере остановится, т.к. никто не знаком с их сферой. Ну и вообще, я встречал только позитивные фидбэки о парном программинге.

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

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

Pzz>>>6 — меня она тоже приводит в ужас, если честно. Вернее, в недоумение. Парно хорошо детей делать и двуручной пилой пилить, а не программы писать.
Z>>Поэтому у нас (и наверное у вас) есть люди, которые если уйдут в отпуск, работа в их сфере остановится, т.к. никто не знаком с их сферой. Ну и вообще, я встречал только позитивные фидбэки о парном программинге.

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

Станислав, может вы и правы.
Никогда не практиковал, хотя очень хотелось бы
Не практиковал — потому как в 5-6 фирмах, которых я работал, никто этого не хотел. Так же как TDD и т.д.

Документация — в принципы, если только необходима.
Комментарии — после нескольких чисток становятся мусором
Доклады? Ну было бы хорошо, но нету

Прямо начинаешь сомневаться — а кто то этим вообще пользуется?...

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

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

Z>>Ну, мы вообще производительность не измеряем никак.

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

Z>>И ещё раз — презентация раз в пол-года.

V_S>Во многих случаях этого достаточно. Заказчику совершенно не интересны внутренние технические "потроха" вашего софта. А соответствие софта требованиям Заказчика — эта задача должна решаться аналитиками, путем постоянного отслеживания требований Заказчика, их актуальности и соответствия софта требованиям. Непонятно только, если ваши аналитики мышей не ловят — чем здесь может помочь именно Agile, а не любая другая методология? Если исходные требования неверны, неполны или неактуальны, — любая методология, включая Agile, приведет к выдаче в релиз софта, не соответствующего требованиям Заказчика.

Z>>Если система большая и не покрыта тестами, и ее не писали трансформеры — ошибок будет много.

V_S>У тебя есть факты (статистика, плотность ошибок и др.)? Или это только теоретические рассуждения?
V_S>Как ты собираешься измерять плотность ошибок, покрытие кода тестами и пр.? Иначе без фактических данных как ты сможешь утверждать, что покрытие тестами "улучшило" софт или "ухудшило"?

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

V_S>Так вот эта проблема и является ключевой. Не понимаю только, чем тут поможет именно Agile, а не любая другая методология? Любой приличный PM знает:
V_S>"Четыре основных правила менеджмента:
V_S>1. Найти нужных людей.
V_S>2. Дать им ту работу, для которой они лучше всего подходят.
V_S>3. Не забывать о мотивации.
V_S>4. Помогать им сплотиться в одну команду и работать так дальше.
V_S>Все остальное — административная ерундистика."
V_S>(с)

Ты всё классно сформулировал!

Надо подумать