>А какого инструмента вы ждете? ))) Ну, я собственно не жду :) А основные требования к инструменту в данном контексте - удобство для буферной зоны+невозможность неиспользования разработчиками.
>У нас под это дело уже хз сколько лет написан собственный web портал, >который периодически подгоняется малыми усилиями под изменения в компании. У нас сейчас у каждого центра разработки своя базулятка, самописанная на своем инструменте со всеми из этого следствиями. И я как раз сейчас собираюсь вместо этого сделать один на всех web-based issue tracker. Получится - займусь в т.ч. и сбором статистики - подсчетом коэффициентов, внутренней стоимостью и много чем еще.
>Только еще вдобавок с каждым разом требования все меняются ))) Ну неспособность держать рамки проекта и учитывать зафиксированные договоренности я даже упоминать не стал из-за очевидности :)
>Соответственно есть некий коэф качества (T1+Tд)/Tд. Да, про это тоже уже думал, собственно были бы статданные - много чего можно повертеть и посчитать :)
>Возможно это более обоснованно, чем просто нижняя ассимптотика обещаний? >Особенно, если качество увязать со скоростью и оценкой ))) Ну у меня пока что одна из главных проблем с заказчиками в том, что они реально не понимают очевидных вещей. Что если n программистов делают задачу t времени, то это не означает, но 2n сделают за t/2 и т.п., что, если модельная программка на аксессе, написанная в филиале манагером, уставшим от непрерывной и бессмысленной ручной работы за месяц после работы, более-менее решает его задачки, то это вообще ничего не говорит о сроках разработки и внедрения модуля с такой же функциональностью, только для всех таких манагеров всей сети и т.п. Поэтому - даже доказательство нижней границы с ресурс шитом и критикал пасом производит отрезвляющий эффект и приводит к некоторой осознанности процесса обсуждения хода проекта.
>Я там же написал почему в полной мере у нас scrum как набор методик целиком не прижился. Да, я вполне понимаю. Я как раз думаю скорее не о применении у себя, а о внятном аутсорсере с такой моделью работы.
> Ну, я собственно не жду :) А основные требования к инструменту в данном контексте - удобство для буферной зоны+невозможность неиспользования разработчиками.
А почему разработчикам то надо закрывать к этой информации доступ? Пусть пользуются! Дополнительный стимул (в его исходном понимании ))) ) для роста производительности отдельного разработчика )))
> У нас сейчас у каждого центра разработки своя базулятка, самописанная на своем инструменте со всеми из этого следствиями
Ух... посчитайте на досуге во сколько встанет разработка единого экстранета для всех с удовлетворением потребностей всех "филиалов". Я думаю, цифра будет ооочень внушительной.
> Да, про это тоже уже думал, собственно были бы статданные - много чего можно повертеть и посчитать Так возьмите основные задачки, посчитайте их среднюю временную оценку. Можно даже считать аналогично коэфицентами качества - нагляднее будет. Ну например: Функциональность "Бла бла" оценивается как T = 1.5*(t1+t2+t3)+1.4*(t4) - те состоит грубо из 2х частей (t1+t2+t3) и (t4) со своими СРЕДНИМИ коэфицентами качества. Потом применяйте коэфиценты разработчиков и получите оценку сколько тот или иной разработчик будет делать эту "Бла бла". Я не настаиваю. Всяк кулик свое болото хвалит. Просто вот еще способ как через такие коэфиценты считать.
> Что если n программистов делают задачу t времени, то это не означает, но 2n сделают за t/2 и т.п.,
На это мы всегда клиентам рассказываем такую байку: - Пусть один солдат роет яму 1м*1м*1м за один час. А за сколько такую же яму сделают 2 солдата? - За 0.5 часа, - говорит клиент. - Хорошо, а 10 солдат? - За 0.1 часа?! - А вот и нет! Они ее НИКОГДА не выроют!!! Тк мешают другим. В любом проекте есть некая критическая масса людей, как менеджеров (у семи нянек...) так и разработчиков (солдаты в яме..)
> Я как раз думаю скорее не о применении у себя, а о внятном аутсорсере с такой моделью работы. Не выйдет. Там очень большой упор делается на частоту и открытость общения. Без него просто не работает. Организовать поток информации между аутсорсом и вами такой же как между вами и разработчиком за соседним столом с ежедневными scrum meeting'амим увы не получается. В аутсорсе прелесть в том, что процесс теоретически должен проходить ооочень быстро, чтобы клиент не успел опомниться и напридумывать чего-то сверх тз. Иначе комутативные связи с аутсорсом сьедают очень много ресурсов.
>А почему разработчикам то надо закрывать к этой информации доступ? Пусть пользуются! Дополнительный >стимул (в его исходном понимании ))) ) для роста производительности отдельного разработчика ))) Не, я про другое (двойные отрицания - плохая привычка :), про то, чтобы у разработчиков не было возможности этим _не_ пользоваться - т.е. использование д.б. обязательным. а закрывать смысла, естественно нет.
>Ух... посчитайте на досуге во сколько встанет разработка единого экстранета для всех с >удовлетворением потребностей всех "филиалов". Я думаю, цифра будет ооочень внушительной. Все разработчики - в хедофисе, хотя и в разных зданиях, но это не проблема. и для них будет общее решение. А для всех филиалов - только общая морда заявки,результат - мылом и мылом же квитанции об изменениях статусов и отчеты об исполняемых заявках. Здесь проблем, выливающихся в стоимость я не вижу.
>Так возьмите основные задачки, посчитайте их среднюю временную оценку. Дык. Как это не смешно, но я реально не могу сейчас сейчас ничего подсчитать, т.к. заметное количество информации в этих базах неактуально, процентов 20 давно исполненных задач в базах не закрыто и т.п. Т.е. кроме внедрения инструмента еще будет много проблем непосредственно с исполнителями, которые привыкли к другому. Я в данный момент вторую неделю просто пытаюсь актуализировать состояние баз - народ героически пытается сопротивляться, не получается, конечно, но процесс растянулся.
>Я не настаиваю. Всяк кулик свое болото хвалит. Эх-х, было б за что хвалить... за челлендж?
>Не выйдет. ... >Иначе комутативные связи с аутсорсом сьедают очень много ресурсов. да я знаю, но помечтать-то хочется :))
Ну, я собственно не жду :) А основные требования к инструменту в данном контексте - удобство для буферной зоны+невозможность неиспользования разработчиками.
>У нас под это дело уже хз сколько лет написан собственный web портал,
>который периодически подгоняется малыми усилиями под изменения в компании.
У нас сейчас у каждого центра разработки своя базулятка, самописанная на своем инструменте со всеми из этого следствиями. И я как раз сейчас собираюсь вместо этого сделать один на всех web-based issue tracker. Получится - займусь в т.ч. и сбором статистики - подсчетом коэффициентов, внутренней стоимостью и много чем еще.
>Только еще вдобавок с каждым разом требования все меняются )))
Ну неспособность держать рамки проекта и учитывать зафиксированные договоренности я даже упоминать не стал из-за очевидности :)
>Соответственно есть некий коэф качества (T1+Tд)/Tд.
Да, про это тоже уже думал, собственно были бы статданные - много чего можно повертеть и посчитать :)
>Возможно это более обоснованно, чем просто нижняя ассимптотика обещаний?
>Особенно, если качество увязать со скоростью и оценкой )))
Ну у меня пока что одна из главных проблем с заказчиками в том, что они реально не понимают очевидных вещей. Что если n программистов делают задачу t времени, то это не означает, но 2n сделают за t/2 и т.п., что, если модельная программка на аксессе, написанная в филиале манагером, уставшим от непрерывной и бессмысленной ручной работы за месяц после работы, более-менее решает его задачки, то это вообще ничего не говорит о сроках разработки и внедрения модуля с такой же функциональностью, только для всех таких манагеров всей сети и т.п. Поэтому - даже доказательство нижней границы с ресурс шитом и критикал пасом производит отрезвляющий эффект и приводит к некоторой осознанности процесса обсуждения хода проекта.
>Я там же написал почему в полной мере у нас scrum как набор методик целиком не прижился.
Да, я вполне понимаю. Я как раз думаю скорее не о применении у себя, а о внятном аутсорсере с такой моделью работы.
Reply
А почему разработчикам то надо закрывать к этой информации доступ? Пусть пользуются! Дополнительный стимул (в его исходном понимании ))) ) для роста производительности отдельного разработчика )))
> У нас сейчас у каждого центра разработки своя базулятка, самописанная на своем инструменте со всеми из этого следствиями
Ух... посчитайте на досуге во сколько встанет разработка единого экстранета для всех с удовлетворением потребностей всех "филиалов". Я думаю, цифра будет ооочень внушительной.
> Да, про это тоже уже думал, собственно были бы статданные - много чего можно повертеть и посчитать
Так возьмите основные задачки, посчитайте их среднюю временную оценку. Можно даже считать аналогично коэфицентами качества - нагляднее будет. Ну например: Функциональность "Бла бла" оценивается как T = 1.5*(t1+t2+t3)+1.4*(t4) - те состоит грубо из 2х частей (t1+t2+t3) и (t4) со своими СРЕДНИМИ коэфицентами качества. Потом применяйте коэфиценты разработчиков и получите оценку сколько тот или иной разработчик будет делать эту "Бла бла".
Я не настаиваю. Всяк кулик свое болото хвалит. Просто вот еще способ как через такие коэфиценты считать.
> Что если n программистов делают задачу t времени, то это не означает, но 2n сделают за t/2 и т.п.,
На это мы всегда клиентам рассказываем такую байку:
- Пусть один солдат роет яму 1м*1м*1м за один час. А за сколько такую же яму сделают 2 солдата?
- За 0.5 часа, - говорит клиент.
- Хорошо, а 10 солдат?
- За 0.1 часа?!
- А вот и нет! Они ее НИКОГДА не выроют!!! Тк мешают другим.
В любом проекте есть некая критическая масса людей, как менеджеров (у семи нянек...) так и разработчиков (солдаты в яме..)
> Я как раз думаю скорее не о применении у себя, а о внятном аутсорсере с такой моделью работы.
Не выйдет. Там очень большой упор делается на частоту и открытость общения. Без него просто не работает. Организовать поток информации между аутсорсом и вами такой же как между вами и разработчиком за соседним столом с ежедневными scrum meeting'амим увы не получается. В аутсорсе прелесть в том, что процесс теоретически должен проходить ооочень быстро, чтобы клиент не успел опомниться и напридумывать чего-то сверх тз. Иначе комутативные связи с аутсорсом сьедают очень много ресурсов.
Reply
Не, я про другое (двойные отрицания - плохая привычка :), про то, чтобы у разработчиков не было возможности этим _не_ пользоваться - т.е. использование д.б. обязательным. а закрывать смысла, естественно нет.
>Ух... посчитайте на досуге во сколько встанет разработка единого экстранета для всех с >удовлетворением потребностей всех "филиалов". Я думаю, цифра будет ооочень внушительной.
Все разработчики - в хедофисе, хотя и в разных зданиях, но это не проблема. и для них будет общее решение. А для всех филиалов - только общая морда заявки,результат - мылом и мылом же квитанции об изменениях статусов и отчеты об исполняемых заявках. Здесь проблем, выливающихся в стоимость я не вижу.
>Так возьмите основные задачки, посчитайте их среднюю временную оценку.
Дык. Как это не смешно, но я реально не могу сейчас сейчас ничего подсчитать, т.к. заметное количество информации в этих базах неактуально, процентов 20 давно исполненных задач в базах не закрыто и т.п. Т.е. кроме внедрения инструмента еще будет много проблем непосредственно с исполнителями, которые привыкли к другому.
Я в данный момент вторую неделю просто пытаюсь актуализировать состояние баз - народ героически пытается сопротивляться, не получается, конечно, но процесс растянулся.
>Я не настаиваю. Всяк кулик свое болото хвалит.
Эх-х, было б за что хвалить... за челлендж?
>Не выйдет.
...
>Иначе комутативные связи с аутсорсом сьедают очень много ресурсов.
да я знаю, но помечтать-то хочется :))
Reply
хорошая байка, спасибо, буду пользоваться :)
Reply
Leave a comment