Подскажите в каком направлении копать? Проект не дает результатов. Команда есть, есть пм, аналитик, тестеры, программеры. Работы делается масса, а результатов нет. Все сделано "не так", не до конца и т.д.
Вобщем есть какие нибудь технологии по тому, как добиваться результата (получать результат)?

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

А>Команда есть, есть пм, аналитик, тестеры, программеры. Работы делается масса, а результатов нет. Все сделано "не так", не до конца и т.д.

Баг-трекинг ведется? Юнит-тесты есть? По каким критериям разработчик определяет, что поставленная ему задача решена? На основе чего определяется количество человеко-часов, необходимых на выполнение фазы проекта, и какие есть механизмы, чтобы в течение этой фазы определить степень завершенности поставленных задач?

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

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

А>>Команда есть, есть пм, аналитик, тестеры, программеры. Работы делается масса, а результатов нет. Все сделано "не так", не до конца и т.д.

N>Баг-трекинг ведется? Юнит-тесты есть?

Конечно.

N>По каким критериям разработчик определяет, что поставленная ему задача решена?

Тестер ошибке не выставляет.

N>На основе чего определяется количество человеко-часов, необходимых на выполнение фазы проекта

согласно грубым расчетам "х. к носу"

N>и какие есть механизмы, чтобы в течение этой фазы определить степень завершенности поставленных задач?

Как можно померять степень завершенности задач?

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

А>Подскажите в каком направлении копать? Проект не дает результатов. Команда есть, есть пм, аналитик, тестеры, программеры. Работы делается масса, а результатов нет. Все сделано "не так", не до конца и т.д.
А>Вобщем есть какие нибудь технологии по тому, как добиваться результата (получать результат)?

А что значит "не дает результатов"? У тебя есть четкое понимание того что является результатом, а что нет? Если есть, изложи его команде. Еще хотелось бы услышать конкретный пример в стиле: что делалось, что ожидалось, что получилось на самом деле, потому что, ИМХО, "в общем виде" такие проблемы не решаются.

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

N>>По каким критериям разработчик определяет, что поставленная ему задача решена?

А>Тестер ошибке не выставляет.

Я имею в виду, по каким критериям разработчик определяет, что поставленная ему задача решена, и результат можно отдавать на тестирование?

N>>и какие есть механизмы, чтобы в течение этой фазы определить степень завершенности поставленных задач?
А>Как можно померять степень завершенности задач?

Каждая задача должна делиться на атомарные, и в баг-трекере должен вестись трекинг каждой атомарной задачи отдельно.
Критерии того, что задача является атомарной:

* Один конкретный исполнитель
* Известно, к кому и в какие сроки перейдет ответственность, если исполнитель не справится с делом
* Для атомарной задачи исполнитель способен определить количество затраченного на нее времени в часах, и степень ее завершенности в процентах
* Атомарная задача подразумевает однократное выполнение работы, имеющей вполне определенное окончание

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

А>>Тестер ошибке не выставляет.

N>Я имею в виду, по каким критериям разработчик определяет, что поставленная ему задача решена, и результат можно отдавать на тестирование?

Имхо интуиция и ничего больше.

N>>>и какие есть механизмы, чтобы в течение этой фазы определить степень завершенности поставленных задач?
А>>Как можно померять степень завершенности задач?

N>Каждая задача должна делиться на атомарные, и в баг-трекере должен вестись трекинг каждой атомарной задачи отдельно.

Так и есть работа с базой сделана, бизнес логика готова, ui написан, а не работает .

N>Критерии того, что задача является атомарной:

N> * Один конкретный исполнитель
N> * Известно, к кому и в какие сроки перейдет ответственность, если исполнитель не справится с делом

Известно к кому, к нему же и перейдет.

N> * Для атомарной задачи исполнитель способен определить количество затраченного на нее времени в часах, и степень ее завершенности в процентах

1. Никто не будет так планировать все задачи.
2. никто не будет все эти планы читать

N> * Атомарная задача подразумевает однократное выполнение работы, имеющей вполне определенное окончание

Не выходит. Например исправление ошибки, может определить только тестер. А функциональность формы — заказчик.

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

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

А>>Подскажите в каком направлении копать? Проект не дает результатов. Команда есть, есть пм, аналитик, тестеры, программеры. Работы делается масса, а результатов нет. Все сделано "не так", не до конца и т.д.
А>>Вобщем есть какие нибудь технологии по тому, как добиваться результата (получать результат)?

M>А что значит "не дает результатов"? У тебя есть четкое понимание того что является результатом, а что нет?

Рузультат один — чтобы все работало. Если начать раскрывать понятие "все" получиться неск. тысяч фичь, причем имхо документ устареет еще до того как его напишут.

M>Если есть, изложи его команде. Еще хотелось бы услышать конкретный пример в стиле: что делалось, что ожидалось, что получилось на самом деле, потому что, ИМХО, "в общем виде" такие проблемы не решаются.

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

А>Подскажите в каком направлении копать? Проект не дает результатов. Команда есть, есть пм, аналитик, тестеры, программеры. Работы делается масса, а результатов нет. Все сделано "не так", не до конца и т.д.
А>Вобщем есть какие нибудь технологии по тому, как добиваться результата (получать результат)?
Основное — это необходимо поменять дирижера, потому, как если все исполнители нормальны, то дело только в нем.

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

N>>Я имею в виду, по каким критериям разработчик определяет, что поставленная ему задача решена, и результат можно отдавать на тестирование?

А>Имхо интуиция и ничего больше.

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

N>> * Для атомарной задачи исполнитель способен определить количество затраченного на нее времени в часах, и степень ее завершенности в процентах

А>1. Никто не будет так планировать все задачи.
А>2. никто не будет все эти планы читать

Почему Вы так считаете?

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

А>Если начать раскрывать понятие "все" получиться неск. тысяч фичь, причем имхо документ устареет еще до того как его напишут.
По-моему, вам стоит посмотреть в сторону Scrum. В одном из последних номеров "Открытые системы" была обзорная статья, вроде бы и на сайте (http://osp.ru) выложена.

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

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

N>>>Я имею в виду, по каким критериям разработчик определяет, что поставленная ему задача решена, и результат можно отдавать на тестирование?

А>>Имхо интуиция и ничего больше.

N>Разработчик должен знать конкретный список требований, которым должен удовлетворять написанный им модуль, чтобы поставленная перед ним задача считалась решенной. Так как задача является атомарной, то набор этих требований конечен и обозрим. Эти требования (в зависимости от используемого процесса разработки) могут быть как строго зафиксированы в формальном документе, так и существовать в другой форме (например, в аудио-записи обсуждения, или даже в голове у разработчика).

Имхо такой подробный план устареет ближе к середине работы над его исполнением.

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

Это идеализм. Большинство требований естейственно затрагивают UI.

N>>> * Для атомарной задачи исполнитель способен определить количество затраченного на нее времени в часах, и степень ее завершенности в процентах

А>>1. Никто не будет так планировать все задачи.
А>>2. никто не будет все эти планы читать

N>Почему Вы так считаете?

Пробовали

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

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

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

А>>Если начать раскрывать понятие "все" получиться неск. тысяч фичь, причем имхо документ устареет еще до того как его напишут.
R>По-моему, вам стоит посмотреть в сторону Scrum. В одном из последних номеров "Открытые системы" была обзорная статья, вроде бы и на сайте (http://osp.ru) выложена.

Работаем типо-по scrum, может и неправильно. При работе проблем не возникает, проблемы начинаются при сдаче. Все вдруг оказывается недоделанным.

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

А>Имхо такой подробный план устареет ближе к середине работы над его исполнением.

Речь идет о списке требований к атомарной задаче. Как он может измениться в процессе ее решения?

N>>Но надо быть уверенным, что набор этих требований существует. Далее, выполнение каждого из требований должно проверяться юнит-тестом.
А>Это идеализм. Большинство требований естейственно затрагивают UI.

Ну и что? UI не поддается автоматическому тестированию? Или бизнес-логика перемешана с логикой отображения в одном классе?

А>Пробовали

ИМХО, плохо пробовали.

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

А>>Подскажите в каком направлении копать? Проект не дает результатов. Команда есть, есть пм, аналитик, тестеры, программеры. Работы делается масса, а результатов нет. Все сделано "не так", не до конца и т.д.
А>>Вобщем есть какие нибудь технологии по тому, как добиваться результата (получать результат)?
N_C>Основное — это необходимо поменять дирижера, потому, как если все исполнители нормальны, то дело только в нем.

Хотелось бы узнать, что он делает не так.

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

M>>А что значит "не дает результатов"? У тебя есть четкое понимание того что является результатом, а что нет?

А> Рузультат один — чтобы все работало. Если начать раскрывать понятие "все" получиться неск. тысяч фичь, причем имхо документ устареет еще до того как его напишут.

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

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

А>Работаем типо-по scrum, может и неправильно.
А методику "спринтов" используете?

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

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

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

R>Это и есть Scrum.

Или XP, там тоже короткие итерации и вовлечение заказчика

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