Люди! Экономисты !
George Seriakov
Привет!
On Tue, 06 Jan 98 20:44:04 +0300, in fido.su.dbms.case Andrey V
Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>> Кто-нибудь занимается прогнозированием трудоемкости и длительности
>> разработки ???
>Без заданного процесса и статистики по _схожим_ работам, короче на SEI
>CMM Level меньше 4, делать какие либо прогнозы с точностью выше
>плюс-минус паравоз (100%) не имеется возможности.
Не пугай человека. Когда система хорошо пропроектирована, можно
сносно оценивать трудоемкости. Например, год назад я сидел в комнате с
разработчиками и тогда умел оценивать для клиент/сервера с удаленными
данными. Там получается линейно от числа таблиц и экранов. С весовыми
коэффициентами, в зависимости от сложности их. Чисел уже не помню.
Точность десятки процентов. Главное - правильно выбрать переменные. Для
обычных пакетных обработчиков это количество квадратиков на структурных
схемах.
>Повышать SEI CMM Level нужно.
Я уже рассказывал?
- CMM Level 0: работники не хотят и не особенно и работают,
- CMM Level -1: начальники им активно мешают.
---
George Seriakov (seri...@aha.ru)
michael
Привет!
Георгий отвечал на некое письмо, которого в оригинале я, к сожалению,
не видел.
> On Tue, 06 Jan 98 20:44:04 +0300, in fido.su.dbms.case Andrey V
> Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>
> >> Кто-нибудь занимается прогнозированием трудоемкости и длительности
> >> разработки ???
>
> >Без заданного процесса и статистики по _схожим_ работам, короче на SEI
> >CMM Level меньше 4, делать какие либо прогнозы с точностью выше
> >плюс-минус паравоз (100%) не имеется возможности.
>
> Не пугай человека. Когда система хорошо пропроектирована, можно
> сносно оценивать трудоемкости. Например, год назад я сидел в комнате с
> разработчиками и тогда умел оценивать для клиент/сервера с удаленными
> данными. Там получается линейно от числа таблиц и экранов. С весовыми
> коэффициентами, в зависимости от сложности их. Чисел уже не помню.
По поводу SEI CMM -- неправда. Там оценки начинаются и на втором уровне.
Позволю себе напомнить, что там уже выбрана модель Жизненного Цикла,
разработана документация на этапы ЖЦ и на процессы, поддерживающие
эти этапы. Уже отслеживаются ошибки и, как минимум, подразумевается,
что проект не первый (Уровень-то ПОВТОРЯЕМОСТИ -- Repeatable).
А следовательно и ошибки не в сотнях процентов при прогнозе.
Другой вопрос, что для выхода даже на 2 уровень необходимо с соответствующими
специалистами поработать не менее полугода по разработке и принятию
соответствующих стандартов и документации для своей группы программистов.
> Точность десятки процентов. Главное - правильно выбрать переменные. Для
> обычных пакетных обработчиков это количество квадратиков на структурных
> схемах.
Здесь сильно важен момент прогноза -- если квадратики уже есть,
то система наполовину разработана (если проектированию уделяется
достаточное время). А на этом этапе трудно ошибиться на 100%.
А вот на этапе анализа требований методик прогнозирования практически нет.
А вот там-то они нужны больше всего!
> >Повышать SEI CMM Level нужно.
Просто через пару-пяток лет с конторами у которых этот уровень меньше 2
никто и разговаривать не будет (прошу заметить, что уровень присваивается
специальными центрами и выдается соответствующее свидетельство).
Michael V. Tokarev
George Seriakov
Привет!
On Thu, 08 Jan 98 10:44:37 +0300, in relcom.comp.software-eng michael
<mic...@tokareff.pgu.karelia.su> wrote:
>Георгий отвечал на некое письмо, которого в оригинале я, к сожалению,
>не видел.
Поскольку оно было в su.dbms.case.
>По поводу SEI CMM -- неправда. Там оценки начинаются и на втором уровне.
Вот тут есть интересный вопрос. Грубо говоря, чем оценки на
втором уровне отличаются от оценок на 4-м?
>Просто через пару-пяток лет с конторами у которых этот уровень меньше 2
>никто и разговаривать не будет (прошу заметить, что уровень присваивается
>специальными центрами и выдается соответствующее свидетельство).
Звучит фантастически, но мне известны московские конторы,
которые начинают заботиться о качестве своего процесса разработки.
Вплоть до найма соответствующих специалистов.
>Michael V. Tokarev
---
George Seriakov (seri...@aha.ru)
Andrey V Khavryutchenko
В связи с тем, что fido7-gate при кросспосте не посылает письма в
юзнетовские группы, повторяю свои ответы. Sorry, за возможные дубляжи
seri...@aha.ru (George Seriakov) writes:
> On Tue, 06 Jan 98 20:44:04 +0300, in fido.su.dbms.case Andrey V
> Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>
> >> Кто-нибудь занимается прогнозированием трудоемкости и длительности
> >> разработки ???
>
> >Без заданного процесса и статистики по _схожим_ работам, короче на SEI
> >CMM Level меньше 4, делать какие либо прогнозы с точностью выше
> >плюс-минус паравоз (100%) не имеется возможности.
>
> Не пугай человека. Когда система хорошо пропроектирована, можно
> сносно оценивать трудоемкости. Например, год назад я сидел в комнате с
> разработчиками и тогда умел оценивать для клиент/сервера с удаленными
> данными. Там получается линейно от числа таблиц и экранов. С весовыми
> коэффициентами, в зависимости от сложности их. Чисел уже не помню.
> Точность десятки процентов. Главное - правильно выбрать переменные. Для
> обычных пакетных обработчиков это количество квадратиков на структурных
> схемах.
Да, но это означает, что _уже_ были выбраны метрики (количество
таблиц и экранов) и была набрана статистика по ним. Т.е. имелись
предпосылки к SEI CMM Level 4.
BTW, для всех групп, которые я видел подняться до SEI CMM Lvl 3 можно
достаточно быстро -- слишком малы коллективы по сравнению с
американскими. Так что не все так страшно :)
> >Повышать SEI CMM Level нужно.
>
> Я уже рассказывал?
> - CMM Level 0: работники не хотят и не особенно и работают,
> - CMM Level -1: начальники им активно мешают.
CMM Level -2: активный саботаж со стороны всего персонала :)
--
SY, Andrey V Khavryutchenko
'Sides, if talent never saved bad management how is any software ever
written. ;) -- ni...@access.digex.net (Nigel Tzeng)
Andrey V Khavryutchenko
michael <mic...@tokareff.pgu.karelia.su> writes:
> Привет!
>
> Георгий отвечал на некое письмо, которого в оригинале я, к сожалению,
> не видел.
Оригинал пролетал в фидошной инкарнации :) -- fido7.su.dbms.case
> > On Tue, 06 Jan 98 20:44:04 +0300, in fido.su.dbms.case Andrey V
> >Khavryutchenko <akh...@compchem.kiev.ua> wrote:
> >
> > >> Кто-нибудь занимается прогнозированием трудоемкости и
> > >>длительности разработки ???
> >
> > >Без заданного процесса и статистики по _схожим_ работам, короче
> > >на SEI CMM Level меньше 4, делать какие либо прогнозы с точностью
> > >выше плюс-минус паравоз (100%) не имеется возможности.
> > Не пугай человека. Когда система хорошо пропроектирована, можно
> >сносно оценивать трудоемкости. Например, год назад я сидел в комнате
> >с разработчиками и тогда умел оценивать для клиент/сервера с
> >удаленными данными. Там получается линейно от числа таблиц и
> >экранов. С весовыми коэффициентами, в зависимости от сложности
> >их. Чисел уже не помню.
>
> По поводу SEI CMM -- неправда. Там оценки начинаются и на втором
> уровне. Позволю себе напомнить, что там уже выбрана модель Жизненного
> Цикла, разработана документация на этапы ЖЦ и на процессы,
> поддерживающие эти этапы. Уже отслеживаются ошибки и, как минимум,
> подразумевается, что проект не первый (Уровень-то ПОВТОРЯЕМОСТИ --
> Repeatable). А следовательно и ошибки не в сотнях процентов при
> прогнозе. Другой вопрос, что для выхода даже на 2 уровень необходимо
> с соответствующими специалистами поработать не менее полугода по
> разработке и принятию соответствующих стандартов и документации для
> своей группы программистов.
Конечно. Но именно на 4 уровне сбор _количественной_ информации
становится главной целью.
> > Точность десятки процентов. Главное - правильно выбрать
> >переменные. Для обычных пакетных обработчиков это количество
> >квадратиков на структурных схемах.
>
> Здесь сильно важен момент прогноза -- если квадратики уже есть, то
> система наполовину разработана (если проектированию уделяется
> достаточное время). А на этом этапе трудно ошибиться на 100%. А вот
> на этапе анализа требований методик прогнозирования практически нет.
> А вот там-то они нужны больше всего!
Само собой. Когда система уже спроектиррована, оценить трудоемкость
ее кодирования обычно не представляет труда. Другое дело, оценить
время _проектирования_ ... Вот для этого и нужны 3 предыдущих уровня
CMM (IMO)
> > >Повышать SEI CMM Level нужно.
>
> Просто через пару-пяток лет с конторами у которых этот уровень меньше
> 2 никто и разговаривать не будет (прошу заметить, что уровень
> присваивается специальными центрами и выдается соответствующее
> свидетельство).
Насколько я понял систему сертификации, компания приглашает
сертифицированного специалиста и тот проводит аудит. Так?
Также, насколько я знаю уровень выдается бессрочно и повторной
проверке не подлежит :)
> Michael V. Tokarev
Andrey V Khavryutchenko
seri...@aha.ru (George Seriakov) writes:
> Привет!
>
> On Thu, 08 Jan 98 10:44:37 +0300, in relcom.comp.software-eng michael
> <mic...@tokareff.pgu.karelia.su> wrote:
>
> >По поводу SEI CMM -- неправда. Там оценки начинаются и на втором уровне.
>
> Вот тут есть интересный вопрос. Грубо говоря, чем оценки на
> втором уровне отличаются от оценок на 4-м?
На 4-м уровне они являются основным объектом внимания, в отличие от
предыдущих уровней.
> >Просто через пару-пяток лет с конторами у которых этот уровень меньше 2
> >никто и разговаривать не будет (прошу заметить, что уровень присваивается
> >специальными центрами и выдается соответствующее свидетельство).
>
> Звучит фантастически, но мне известны московские конторы,
> которые начинают заботиться о качестве своего процесса разработки.
> Вплоть до найма соответствующих специалистов.
Имена, имена! Если это, конечно, не тайна.
Мой начальник не верит, что это возможно в нашей стране.
Michael V. Tokarev
Привет!
> > > >Повышать SEI CMM Level нужно.
> >
> > Просто через пару-пяток лет с конторами у которых этот уровень меньше
> > 2 никто и разговаривать не будет (прошу заметить, что уровень
> > присваивается специальными центрами и выдается соответствующее
> > свидетельство).
>
> Насколько я понял систему сертификации, компания приглашает
> сертифицированного специалиста и тот проводит аудит. Так?
> Также, насколько я знаю уровень выдается бессрочно и повторной
> проверке не подлежит :)
>
> SY, Andrey V Khavryutchenko
Мне кажется, ты неправильно понял. Во всяком случае во втором предложении.
Уровень не выдается бессрочно, т.к. команды могут меняться,
проекты тоже, компании растут и т.д.
Там есть какой-то срок и, как я подозреваю, на каждый уровень
распространяется своя давность.
Michael V. Tokarev.
Andrey V Khavryutchenko
"Michael V. Tokarev" <mic...@tokareff.pgu.karelia.su> writes:
[ CMM Lvl сертификация ]
> > Насколько я понял систему сертификации, компания приглашает
> > сертифицированного специалиста и тот проводит аудит. Так?
> > Также, насколько я знаю уровень выдается бессрочно и повторной
> > проверке не подлежит :)
>
> Мне кажется, ты неправильно понял. Во всяком случае во втором предложении.
> Уровень не выдается бессрочно, т.к. команды могут меняться,
> проекты тоже, компании растут и т.д.
> Там есть какой-то срок и, как я подозреваю, на каждый уровень
> распространяется своя давность.
Логично. Но реальность, как показывает опыт, редко укладывается в
рамки логики :)
Одной из первых компаний, получивших SEI CMM Lvl 5, была Motorola
India (еще в 1992 г). Как у них сейчас с этим? Просто у меня есть
информация, что некоторые компании (не наши) используют это
исключительно в качестве маркетинговой меры :(
Michael V. Tokarev
Hi!
Извиняюсь, если это уже покажется флеймом, но хочется дополнить.
> [ CMM Lvl сертификация ]
> > > Насколько я понял систему сертификации, компания приглашает
> > > сертифицированного специалиста и тот проводит аудит. Так?
> > > Также, насколько я знаю уровень выдается бессрочно и повторной
> > > проверке не подлежит :)
> >
> > Мне кажется, ты неправильно понял. Во всяком случае во втором предложении.
> > Уровень не выдается бессрочно, т.к. команды могут меняться,
> > проекты тоже, компании растут и т.д.
> > Там есть какой-то срок и, как я подозреваю, на каждый уровень
> > распространяется своя давность.
>
> Логично. Но реальность, как показывает опыт, редко укладывается в
> рамки логики :)
>
> Одной из первых компаний, получивших SEI CMM Lvl 5, была Motorola
> India (еще в 1992 г). Как у них сейчас с этим? Просто у меня есть
> информация, что некоторые компании (не наши) используют это
> исключительно в качестве маркетинговой меры :(
Я работал в Моторолле в Питерском отделении (правда 3 года назад).
Внутри компании они говорят, что там в Индии этот сертификат не закончился.
Вряд ли 5 уровень СММ дается на пару лет -- наверняка срок
от 5 до 10 лет.
И, кстати, по их словам, таких контор всего 2 во всем мире.
Могу еще сказать, что на самом деле в этой фирме
СММ уделяется очень боьшое внимание, чего я не слышал про тот же
Мелкософт, хотя Билли я уважаю чрезмерно.
Michael V. Tokarev
Andrey V Khavryutchenko
"Michael V. Tokarev" <mic...@tokareff.pgu.karelia.su> writes:
> Hi!
>
> Извиняюсь, если это уже покажется флеймом, но хочется дополнить.
Ни в коем случае! В основном это был вопрос к вам, т.к. когда то
оговорились, что работали в Мотороле.
> > Одной из первых компаний, получивших SEI CMM Lvl 5, была Motorola
> >India (еще в 1992 г). Как у них сейчас с этим? Просто у меня есть
> >информация, что некоторые компании (не наши) используют это
> >исключительно в качестве маркетинговой меры :(
>
> Я работал в Моторолле в Питерском отделении (правда 3 года назад).
> Внутри компании они говорят, что там в Индии этот сертификат не
> закончился. Вряд ли 5 уровень СММ дается на пару лет -- наверняка
> срок от 5 до 10 лет. И, кстати, по их словам, таких контор всего 2 во
> всем мире.
Motorolla и Boeing?
> Могу еще сказать, что на самом деле в этой фирме СММ
> уделяется очень боьшое внимание, чего я не слышал про тот же
А я и не про Моторолу говорил. Я ее очень уважаю.
Информация была про другую штатовскою аэрокосмическую корпорацию (не
Боинг :).
> Мелкософт, хотя Билли я уважаю чрезмерно.
По неформальным оценкам в comp.software-eng, у его компании CMM 2.
> Michael V. Tokarev
Michael V. Tokarev
Hi!
> > Я работал в Моторолле в Питерском отделении (правда 3 года назад).
> > Внутри компании они говорят, что там в Индии этот сертификат не
> > закончился. Вряд ли 5 уровень СММ дается на пару лет -- наверняка
> > срок от 5 до 10 лет. И, кстати, по их словам, таких контор всего 2 во
> > всем мире.
>
> Motorolla и Boeing?
О второй компании я ничего не слышал :-(
> > Мелкософт, хотя Билли я уважаю чрезмерно.
>
> По неформальным оценкам в comp.software-eng, у его компании CMM 2.
У меня знакомый работает в Штатах на Билли. Когда будет оказия,
я попробую узнать. Если это не корпоративный секрет, конечно. :-)
Michael V. Tokarev
Andrey V Khavryutchenko
"Michael V. Tokarev" <mic...@tokareff.pgu.karelia.su> writes:
> > > Я работал в Моторолле в Питерском отделении (правда 3 года назад).
> > > Внутри компании они говорят, что там в Индии этот сертификат не
> > > закончился. Вряд ли 5 уровень СММ дается на пару лет -- наверняка
> > > срок от 5 до 10 лет. И, кстати, по их словам, таких контор всего 2 во
> > > всем мире.
> >
> > Motorolla и Boeing?
>
> О второй компании я ничего не слышал :-(
Слухи, слухи... Опять же, говорят, что где-то на сайте SEI есть
список компаний, которым присвоили SEI CMM Lvl >3. Но поскольку он
огромный, то колупаться там....
> > > Мелкософт, хотя Билли я уважаю чрезмерно.
> >
> > По неформальным оценкам в comp.software-eng, у его компании CMM 2.
>
> У меня знакомый работает в Штатах на Билли. Когда будет оказия,
> я попробую узнать. Если это не корпоративный секрет, конечно. :-)
Боюсь, что внутри компании они оценок не проводили. То есть это может
быть лишь на уровне суждения отдельных людей. Но все равно интересно.
George Seriakov
Привет!
On 11 Jan 1998 23:10:23 +0200, in relcom.comp.software-eng Andrey V
Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>> > По неформальным оценкам в comp.software-eng, у его компании CMM 2.
>>
>> У меня знакомый работает в Штатах на Билли. Когда будет оказия,
>> я попробую узнать. Если это не корпоративный секрет, конечно. :-)
>
>Боюсь, что внутри компании они оценок не проводили. То есть это может
>быть лишь на уровне суждения отдельных людей. Но все равно интересно.
Этот отдельный человек - Буч.
MsgID = <63t858$puc$1...@rational2.rational.com>
"Grady Booch" <e...@rational.com> posted with deletions:
> >> I recently attended a talk in which a speaker from Carnegie Melon
> >> declared that Microsoft was a "Level 0 or below" company.
>
>
> i'd certainly take exception to that characterization. having worked inside
> microsoft, i'd rate a number of their teams at level 3.
>
> egb
---
George Seriakov (seri...@aha.ru)
Andrey V Khavryutchenko
seri...@aha.ru (George Seriakov) writes:
> On 11 Jan 1998 23:10:23 +0200, in relcom.comp.software-eng Andrey V
> Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>
[ MS CMM Level ]
> > Боюсь, что внутри компании они оценок не проводили. То есть это
> >может быть лишь на уровне суждения отдельных людей. Но все равно
> >интересно.
>
> Этот отдельный человек - Буч. MsgID =
> <63t858$puc$1...@rational2.rational.com>
А Буч и Марк Паулк все же разные люди :)
> "Grady Booch" <e...@rational.com> posted with deletions:
>
> > >> I recently attended a talk in which a speaker from Carnegie
> > >>Melon declared that Microsoft was a "Level 0 or below" company.
> >
> >
> > i'd certainly take exception to that characterization. having
> >worked inside microsoft, i'd rate a number of their teams at level 3.
Ну, dejanews и я пользоваться умею :) Только поздно сейчас, поэтому
расскажу по памяти.
Там дальше были претензии к этой оценке в плане того, что CMM Level 3
относится не к _team_, а к _organisation_. Поэтому говорить о
команде третьего уровня не вполне корректно.
Хотя какое это имеет значение при неправильно определенных исходных
требованиях? :-|
vrud...@onestone.de
In article <x7n2h1z8...@netmaster.compchem.kiev.ua>,
Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
> Там дальше были претензии к этой оценке в плане того, что CMM Level 3
> относится не к _team_, а к _organisation_. Поэтому говорить о
> команде третьего уровня не вполне корректно.
У меня сложилось впечатление, что не просто к организации, а к офигенно
большой организации. При этом вопросы эффективности работы и качество
самого выдаваемого на гора продукта остаются за кадром. Кстати когда я
читал репорт о "Возврате средств от введения CMM", просто покатывался со
смеху. Основная мыслЯ: "Ну посмотрите какой хороший _ПРОЦЕСС_ получился!"
Так и вспоминается Жванецкий.
> --
> SY, Andrey V Khavryutchenko
>
> 'Sides, if talent never saved bad management how is any software ever
> written. ;) -- ni...@access.digex.net (Nigel Tzeng)
Кстати:
Кто-нибудь знает о Nigel Tzeng поподробнее?
Есть ли официальные противники СММ?
Regards!
Vit
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
vrud...@onestone.de
In article <34c071e2...@195.2.69.61>,
seri...@aha.ru (George Seriakov) wrote:
> >> > По неформальным оценкам в comp.software-eng, у его компании CMM 2.
> >>
> >> У меня знакомый работает в Штатах на Билли. Когда будет оказия,
> >> я попробую узнать. Если это не корпоративный секрет, конечно. :-)
> >
> >Боюсь, что внутри компании они оценок не проводили. То есть это может
> >быть лишь на уровне суждения отдельных людей. Но все равно интересно.
>
> Этот отдельный человек - Буч.
> MsgID = <63t858$puc$1...@rational2.rational.com>
Тогда уж стоит привести и следующий ответ на выступление Буча:
From: Chris Kerlin <chris_...@email.mot.com>
Newsgroups: comp.software-eng
Subject: Re: Microsoft Capability Maturity (was Re: SEI's Failure)
Date: Thu, 06 Nov 1997 12:24:36 -0500
Organization: Motorola, Plantation FL
Message-ID: <3461FD...@email.mot.com>
Кстати заткнули Буча давольно быстро. И общий вывод из этой ругани у меня
такой: Мелкомягкий - единственный производитель софта у которого подобный
способ производства экономически эффективен. И только из-за его размера и
великолепного маркетинга.
> ---
> George Seriakov (seri...@aha.ru)
vrud...@onestone.de
In article <AASJA...@tokareff.pgu.karelia.su>,
mic...@tokareff.pgu.karelia.su wrote:
> > Одной из первых компаний, получивших SEI CMM Lvl 5, была Motorola
> > India (еще в 1992 г). Как у них сейчас с этим? Просто у меня есть
> > информация, что некоторые компании (не наши) используют это
> > исключительно в качестве маркетинговой меры :(
Так эта бодяга и затевалась для того, чтобы правительство и МО США знало
с кем можно заключать контракты, а с кем - нет.
Смотрите на DejaNevs Motorolla India. Большой спор был.
> Я работал в Моторолле в Питерском отделении (правда 3 года назад).
> Внутри компании они говорят, что там в Индии этот сертификат не закончился.
> Вряд ли 5 уровень СММ дается на пару лет -- наверняка срок
> от 5 до 10 лет.
> И, кстати, по их словам, таких контор всего 2 во всем мире.
Вроде-бы поболе. В США точно не менее пяти.
> Могу еще сказать, что на самом деле в этой фирме
> СММ уделяется очень боьшое внимание, чего я не слышал про тот же
> Мелкософт, хотя Билли я уважаю чрезмерно.
А нахрена Билли такая сертификация?
> Michael V. Tokarev
vrud...@onestone.de
In article <x767ns3...@netmaster.compchem.kiev.ua>,
Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
> Конечно. Но именно на 4 уровне сбор _количественной_ информации
> становится главной целью.
На 4 уровне сбор количественной информации становится _главной_ целью.
Вот о чем стоит задуматься.
> --
> SY, Andrey V Khavryutchenko
>
> 'Sides, if talent never saved bad management how is any software ever
> written. ;) -- ni...@access.digex.net (Nigel Tzeng)
Regards!
Andrey V Khavryutchenko
vrud...@onestone.de writes:
> In article <x7n2h1z8...@netmaster.compchem.kiev.ua>,
> Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>
> > Там дальше были претензии к этой оценке в плане того, что CMM Level
> >3 относится не к _team_, а к _organisation_. Поэтому говорить о
> >команде третьего уровня не вполне корректно.
>
> У меня сложилось впечатление, что не просто к организации, а к
> офигенно большой организации. При этом вопросы эффективности работы и
> качество самого выдаваемого на гора продукта остаются за
> кадром. Кстати когда я читал репорт о "Возврате средств от введения
> CMM", просто покатывался со смеху. Основная мыслЯ: "Ну посмотрите
> какой хороший _ПРОЦЕСС_ получился!" Так и вспоминается Жванецкий.
RTFM :) SEI CMM не ставит целью разработку хорошего продукта. Это
рекомендации к тому как построить процесс который будет выдавать
продукцию в гарантированные сроки и с гарантированным качеством.
Цена продукта остается за кадром (как всегда у военных :)
> > -- SY, Andrey V Khavryutchenko
> >
> > 'Sides, if talent never saved bad management how is any software
> >ever written. ;) -- ni...@access.digex.net (Nigel Tzeng)
>
> Кстати: Кто-нибудь знает о Nigel Tzeng поподробнее? Есть ли
> официальные противники СММ?
Есть. Поименно не помню :)
vrud...@onestone.de
In article <x7k9c2r...@netmaster.compchem.kiev.ua>,
Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
> RTFM :) SEI CMM не ставит целью разработку хорошего продукта. Это
> рекомендации к тому как построить процесс который будет выдавать
> продукцию в гарантированные сроки и с гарантированным качеством.
Я бы составил фразу по другому: сертификация SEI CMM ставит целью
определить производителя, который произведет выдаст продукт с
гарантированным качеством и установить за "справедливую" цену.
> Цена продукта остается за кадром (как всегда у военных :)
Не только цена.
Качество бывает разное. Качество софта может быть:
1) низкмм содержанием ошибок/отклонений от спецификации
2) удобством работы пользователя и соответствия его задачам
3) предоставление возможностей не имеющих аналогов на рынке.
> > Кстати: Кто-нибудь знает о Nigel Tzeng поподробнее? Есть ли
> > официальные противники СММ?
>
> Есть. Поименно не помню :)
Что это за организации и где их искать?
>
> --
> SY, Andrey V Khavryutchenko
>
> 'Sides, if talent never saved bad management how is any software ever
> written. ;) -- ni...@access.digex.net (Nigel Tzeng)
Regards!
Andrey V Khavryutchenko
vrud...@onestone.de writes:
> In article <x7k9c2r...@netmaster.compchem.kiev.ua>,
> Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>
> > RTFM :) SEI CMM не ставит целью разработку хорошего продукта. Это
> > рекомендации к тому как построить процесс который будет выдавать
> > продукцию в гарантированные сроки и с гарантированным качеством.
>
> Я бы составил фразу по другому: сертификация SEI CMM ставит целью
> определить производителя, который произведет выдаст продукт с
> гарантированным качеством и установить за "справедливую" цену.
Сертификация -- да. Но SEI CMM не зациклен на сертификации. Лично я
пытаюсь его использовать для прямой цели -- построить процесс.
> > Цена продукта остается за кадром (как всегда у военных :)
>
> Не только цена.
> Качество бывает разное. Качество софта может быть:
> 1) низкмм содержанием ошибок/отклонений от спецификации
> 2) удобством работы пользователя и соответствия его задачам
> 3) предоставление возможностей не имеющих аналогов на рынке.
В определение процесса разработки включается определение качества
продукта.
> > > Кстати: Кто-нибудь знает о Nigel Tzeng поподробнее? Есть ли
> > > официальные противники СММ?
> >
> > Есть. Поименно не помню :)
>
> Что это за организации и где их искать?
Противники CMM в виде организаций? Не знаю. Соотв. комитет ISO
наверное :) А людей поодиночке хватает -- достаточно поднять архивы
comp.software-eng
vrud...@onestone.de
In article <x7d8htq...@netmaster.compchem.kiev.ua>,
Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
> Сертификация -- да. Но SEI CMM не зациклен на сертификации. Лично я
> пытаюсь его использовать для прямой цели -- построить процесс.
Вы пытаетесь использовать сам SEI CMM или отдельные методики, которые в
него входят? Каков размер Вашей организации? Как Вы определите тот
процесс, который в ней сейчас? Какими методами Вы собираетесь "построить
процесс" и что сюда входит? В какой области Вы работаете?
> > Не только цена.
> > Качество бывает разное. Качество софта может быть:
> > 1) низкмм содержанием ошибок/отклонений от спецификации
> > 2) удобством работы пользователя и соответствия его задачам
> > 3) предоставление возможностей не имеющих аналогов на рынке.
>
> В определение процесса разработки включается определение качества
> продукта.
Военное определение, не стоит об этом забывать. Качество товара на рынке -
совершенно иное, чем у заказной разработки.
> Противники CMM в виде организаций? Не знаю. Соотв. комитет ISO
> наверное :)
http://www.esi.es/Projects/SPICE.html
У них есть уровень 0 (полный провал)
Уровень 1 - конечный продукт выдан.
Дальнейшие уровни очень похоже.
> А людей поодиночке хватает -- достаточно поднять архивы
> comp.software-eng
Меня интересует аналог SEI CMM для очень маленьких, малых и средних фирм.
> --
> SY, Andrey V Khavryutchenko
Regards!
Andrey V Khavryutchenko
vrud...@onestone.de writes:
> In article <x7d8htq...@netmaster.compchem.kiev.ua>,
> Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>
> > Сертификация -- да. Но SEI CMM не зациклен на сертификации. Лично
> >я пытаюсь его использовать для прямой цели -- построить процесс.
>
> Вы пытаетесь использовать сам SEI CMM или отдельные методики, которые
> в него входят?
Правильнее всего, наверное, будет сказать, что пытаюсь использовать
все методики, которые имеет смысл применять в данной организации.
Например бессмыслено говорить об организации SEPG в организации из 4-х
человек.
> Каков размер Вашей организации?
4 человека. Два здесь, два "там" :)
> Как Вы определите тот процесс, который в ней сейчас?
Имеется в виду уровень? Такой себе "суровый" CMM Lvl 1. Сейчас для
меня главное -- убедить руководство, что это имеет смысл делать. Уже
есть положительные изменения: от состояния "это невозможно" до "в
нашей стране это нереально" :-\
> Какими методами Вы собираетесь "построить процесс" и что сюда
> входит?
Построить процесс разработки програмного обеспечения для меня означает
1) определить набор деливераблов, которые должны быть получены для
успешного ваполнения проекта
2) предложить методы создания таких деливераблов
3) определить степень необходимости тестирования каждого из
деливераблов
4) предложить временнУю схему получения деливераблов и их объем
(e.g. waterfall vs iterative style)
> В какой области Вы работаете?
Бизнес-приложения, БД.
Достижение высоких уровней CMM вряд ли оправдано для нашей
организации. Оптимальным уровнем является 3.
> > > Не только цена. Качество бывает разное. Качество софта может
> > >быть: 1) низкмм содержанием ошибок/отклонений от спецификации 2)
> > >удобством работы пользователя и соответствия его задачам 3)
> > >предоставление возможностей не имеющих аналогов на рынке.
> > В определение процесса разработки включается определение качества
> >продукта.
>
> Военное определение, не стоит об этом забывать. Качество товара на
> рынке - совершенно иное, чем у заказной разработки.
Так я об этом и говорю. Определение качества конечного продукта
входит (должно входить :) в определение этого продукта. Т.е. в
project statement должны явно декларироваться цели, которых необходимо
достигнуть.
> > Противники CMM в виде организаций? Не знаю. Соотв. комитет ISO
> >наверное :)
>
> http://www.esi.es/Projects/SPICE.html
>
> У них есть уровень 0 (полный провал) Уровень 1 - конечный продукт
> выдан. Дальнейшие уровни очень похоже.
Еще не просмотрел достаточно полно, но, насколько я успел заметить,
они не противопоставляют себя CMM, а определят процесс сертификации
организации.
> > А людей поодиночке хватает -- достаточно поднять архивы
> >comp.software-eng
>
> Меня интересует аналог SEI CMM для очень маленьких, малых и средних
> фирм.
Аналогично. Особенно для коллективов до 10 человек.
Есть PSP -- Personal Software Process. Но он по определению нацелен
на одного человека. К сожалению, пока не смог изучить его более
подробно.
--
SY, Andrey V Khavryutchenko
'Sides, if talent never saved bad management how is any software ever
George Seriakov
Привет!
On 17 Jan 1998 01:32:27 +0200, in relcom.comp.software-eng Andrey V
Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>> Какими методами Вы собираетесь "построить процесс" и что сюда
>> входит?
>Построить процесс разработки програмного обеспечения для меня означает
0) Выделить стадии разработки (построить модель ЖЦ)
> 1) определить набор деливераблов, которые должны быть получены для
>успешного ваполнения проекта
на всех стадиях разработки. Тут еще неплохо оговорить отделение
проектирования от кодирования.
> 2) предложить методы создания таких деливераблов
> 3) определить степень необходимости тестирования каждого из
>деливераблов
Способы тестирования выходных документов на всех стадиях
разработки.
> 4) предложить временнУю схему получения деливераблов и их объем
>(e.g. waterfall vs iterative style)
Я бы еще советовал озаботиться организацией тестирования,
отчужденного от разработчика.
---
George Seriakov (seri...@aha.ru)
Andrey V Khavryutchenko
seri...@aha.ru (George Seriakov) writes:
> On 17 Jan 1998 01:32:27 +0200, in relcom.comp.software-eng Andrey V
> Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>
> >> Какими методами Вы собираетесь "построить процесс" и что сюда
> >> входит?
>
> >Построить процесс разработки програмного обеспечения для меня означает
>
> 0) Выделить стадии разработки (построить модель ЖЦ)
Да, но я считаю, что этим лучше заняться после п.1 -- тогда будет
предметный разговор, а не спор Analysis vs Design ;)
> > 1) определить набор деливераблов, которые должны быть получены для
> >успешного ваполнения проекта
>
> на всех стадиях разработки. Тут еще неплохо оговорить отделение
> проектирования от кодирования.
Кодирование есть отдельная стадия разработки. IMO вполне достаточно.
> > 2) предложить методы создания таких деливераблов
> > 3) определить степень необходимости тестирования каждого из
> >деливераблов
>
> Способы тестирования выходных документов на всех стадиях
> разработки.
Да, конечно. Правильнее будет переформулировать мое утверждение так:
3) определить степень необходимости и способы тестирования каждого
из деливераблов
> > 4) предложить временнУю схему получения деливераблов и их объем
> >(e.g. waterfall vs iterative style)
>
> Я бы еще советовал озаботиться организацией тестирования,
> отчужденного от разработчика.
Т.е. пишет test-cases и собственно тестирует _не_ тот человек, который
пишет деливерабл? Согласен, но почему это нужно оговаривать
специально?
vrud...@onestone.de
In article <x7zpkwo...@netmaster.compchem.kiev.ua>,
Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
> Правильнее всего, наверное, будет сказать, что пытаюсь использовать
> все методики, которые имеет смысл применять в данной организации.
> Например бессмыслено говорить об организации SEPG в организации из 4-х
> человек.
Но это уже не сам CMM. Кстати они обещали практические примеры применения
методики. Вы их не встречали?
> > Каков размер Вашей организации?
>
> 4 человека. Два здесь, два "там" :)
Ну это не тот уровень, чтобы делать "процесс". Хотя бы для того, чтобы
процесс контролировать на должном уровне нужно 3 человека.
> > Как Вы определите тот процесс, который в ней сейчас?
>
> Имеется в виду уровень? Такой себе "суровый" CMM Lvl 1. Сейчас для
> меня главное -- убедить руководство, что это имеет смысл делать. Уже
> есть положительные изменения: от состояния "это невозможно" до "в
> нашей стране это нереально" :-\
Почитайте Tom DeMarco. Лучшие книжки для убеждения руководства.
> Построить процесс разработки програмного обеспечения для меня означает
> 1) определить набор деливераблов, которые должны быть получены для
> успешного ваполнения проекта
> 2) предложить методы создания таких деливераблов
> 3) определить степень необходимости тестирования каждого из
> деливераблов
> 4) предложить временнУю схему получения деливераблов и их объем
> (e.g. waterfall vs iterative style)
Как Вы оцениваете затраты на подобное мероприятие? Кстати Ваше начальство
согласно с Вашим определением успеха проекта?
> > В какой области Вы работаете?
>
> Бизнес-приложения, БД.
>
> Достижение высоких уровней CMM вряд ли оправдано для нашей
> организации. Оптимальным уровнем является 3.
Вы хотите достигнуть уровня 3, или разработать и внедрить методики уровня
3?
> Так я об этом и говорю. Определение качества конечного продукта
> входит (должно входить :) в определение этого продукта. Т.е. в
> project statement должны явно декларироваться цели, которых необходимо
> достигнуть.
Как показывает практика, этого не достаточно.
> Еще не просмотрел достаточно полно, но, насколько я успел заметить,
> они не противопоставляют себя CMM, а определят процесс сертификации
> организации.
Да. Но не для МО США.
> Есть PSP -- Personal Software Process. Но он по определению нацелен
> на одного человека. К сожалению, пока не смог изучить его более
> подробно.
Изучил %-/ Статистические данные основаны на группе 12 студентов.
Первоначальный разброс больше "наблюдаемого эффекта". Единственное, в чем
виден очевидный прогресс - производительность в количестве линий кода в
час. Задания в этой методике элементарные. Выполнение примерно за час. У
приятеля, у которого был курс PSP, который проводил человек из SEI,
остались самые неприятные впечатления. Правда, если человек совершенно
ничего не понимает, PSP может чему-то помочь. В ней встречаются отдельные
интересные моменты, но весь конспект лекций оставил пренеприятное
впечатление соц.производства.
> --
> SY, Andrey V Khavryutchenko
Regards!
Vit
PS.: Результаты эксперемента (Lawrence & Jeffery 1985) из книжки Tom
DeMarco
Прогноз времени разработки: Средняя производительность:
Только программистом 8.0
Только руководителем проекта 6.6
Совместно программистом и рук. проекта 7.8
Системным аналитиком 9.5
(Не оценивается) _12.0_
Вот так то.
vrud...@onestone.de
In article <x7lnwdf...@netmaster.compchem.kiev.ua>,
Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
> Т.е. пишет test-cases и собственно тестирует _не_ тот человек, который
> пишет деливерабл? Согласен, но почему это нужно оговаривать
> специально?
Качество. Цель того, кто пишет - наименьше количество найденых ошибок,
цель того, кто тестирует - максимальное. Достижением цели определяется
удовлетворение от работы и размер прилагаемых усилий. Еще полезно
внесение третьей стороной стандартных ошибок, для проверки качества
тестирования.
> --
> SY, Andrey V Khavryutchenko
Regards!
Vit
-------------------==== Posted via Deja News ====-----------------------
Andrey V Khavryutchenko
vrud...@onestone.de writes:
> In article <x7lnwdf...@netmaster.compchem.kiev.ua>,
> Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>
> > Т.е. пишет test-cases и собственно тестирует _не_ тот человек,
> >который пишет деливерабл? Согласен, но почему это нужно оговаривать
> >специально?
>
> Качество. Цель того, кто пишет - наименьше количество найденых ошибок,
> цель того, кто тестирует - максимальное. Достижением цели определяется
> удовлетворение от работы и размер прилагаемых усилий. Еще полезно
> внесение третьей стороной стандартных ошибок, для проверки качества
> тестирования.
Нет, я понимаю _зачем_ это надо. Меня интересовало почему это нужно
_особенно_ оговаривать. Хотя после некоторых внутренних событий, я
убедился, что оговаривать нужно _все_ детали.
--
SY, Andrey V Khavryutchenko
'Sides, if talent never saved bad management how is any software ever
Andrey V Khavryutchenko
vrud...@onestone.de writes:
> In article <x7zpkwo...@netmaster.compchem.kiev.ua>,
> Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>
> > Правильнее всего, наверное, будет сказать, что пытаюсь использовать
> >все методики, которые имеет смысл применять в данной организации.
> >Например бессмыслено говорить об организации SEPG в организации из
> >4-х человек.
>
> Но это уже не сам CMM.
А что такое "сам" CMM? Это когда команда в 100+ человек и толпа
манагеров? А бюджет начинается с $10M ? :)))
Если я скажу, что я хочу применить методики CMM к малым и очень малым
организациям, так точнее будет? :) BTW, этого же хотите и Вы, если я
правильно понимаю.
<plug>
Ко мне можно обращаться на ты
</>
> Кстати они обещали практические примеры применения методики. Вы их
> не встречали?
Практические примеры применения чего?
Вряд ли какая либо компания откроет достаточно данных по процессу
внутреннего преобразования. Даже если сейчас хорошо, то кому
захочется показывать как было плохо :)
> > > Каков размер Вашей организации?
> > 4 человека. Два здесь, два "там" :)
>
> Ну это не тот уровень, чтобы делать "процесс". Хотя бы для того, чтобы
> процесс контролировать на должном уровне нужно 3 человека.
Почему? Я считаю, что даже для одного человека имеет смысл
придерживаться какого-либо _определенного_ процесса. Другое дело, что
он может быть документирован на обратной стороне notebook'а
(бумажного).
Т. е. размер организации влияет лишь на строгость задания процесса.
Именно поэтому движение началось от DoD, как самой крупной в Штатах
организации.
> > > Как Вы определите тот процесс, который в ней сейчас?
> > Имеется в виду уровень? Такой себе "суровый" CMM Lvl 1. Сейчас для
> >меня главное -- убедить руководство, что это имеет смысл делать. Уже
> >есть положительные изменения: от состояния "это невозможно" до "в
> >нашей стране это нереально" :-\
>
> Почитайте Tom DeMarco. Лучшие книжки для убеждения руководства.
Эээх... Во первых тут купить что-либо очень трудно, а во вторых (и
главное) -- это же не мне нужно читать книги, а руководству :(
А оно как всегда убеждено в своей правоте...
> > Построить процесс разработки програмного обеспечения для меня
> >означает 1) определить набор деливераблов, которые должны быть
> >получены для успешного ваполнения проекта 2) предложить методы
> >создания таких деливераблов 3) определить степень необходимости
> >тестирования каждого из деливераблов 4) предложить временнУю схему
> >получения деливераблов и их объем (e.g. waterfall vs iterative style)
>
> Как Вы оцениваете затраты на подобное мероприятие? Кстати Ваше
> начальство согласно с Вашим определением успеха проекта?
Нет. Оно уже ни с чем не согласно. Я реализую super-micro-CMM для
одного человека :(
(Как назвать реплику "Ты плохой программист" в ответ на просьбу
показать документированные требования для проекта?..)
> > > В какой области Вы работаете?
> > Бизнес-приложения, БД.
> >
> > Достижение высоких уровней CMM вряд ли оправдано для нашей
> >организации. Оптимальным уровнем является 3.
>
> Вы хотите достигнуть уровня 3, или разработать и внедрить методики
> уровня 3?
Ммм... не совсем понимаю разницу. Я хочу, чтобы моя команда имела бы
по крайней мере повторяемость (хороших) результатов.
> > Так я об этом и говорю. Определение качества конечного продукта
> >входит (должно входить :) в определение этого продукта. Т.е. в
> >project statement должны явно декларироваться цели, которых
> >необходимо достигнуть.
>
> Как показывает практика, этого не достаточно.
Конечно. Задать цель (в project statement) еще недостаточно. Нужно
ее еще и достичь. :)
> > Еще не просмотрел достаточно полно, но, насколько я успел заметить,
> >они не противопоставляют себя CMM, а определят процесс сертификации
> >организации.
> Да. Но не для МО США.
Не понял фразу. В том смысле, что для DoD сертификация, проведенная
по методике SPICE недействительна? Почему?
> > Есть PSP -- Personal Software Process. Но он по определению нацелен
> >на одного человека. К сожалению, пока не смог изучить его более
> >подробно.
>
> Изучил %-/ Статистические данные основаны на группе 12 студентов.
> Первоначальный разброс больше "наблюдаемого эффекта". Единственное, в
> чем виден очевидный прогресс - производительность в количестве линий
> кода в час. Задания в этой методике элементарные. Выполнение примерно
> за час. У приятеля, у которого был курс PSP, который проводил человек
> из SEI, остались самые неприятные впечатления. Правда, если человек
> совершенно ничего не понимает, PSP может чему-то помочь. В ней
> встречаются отдельные интересные моменты, но весь конспект лекций
> оставил пренеприятное впечатление соц.производства.
Понятно. У меня самого были некоторые сомнения.
> Vit
>
> PS.: Результаты эксперемента (Lawrence & Jeffery 1985) из книжки Tom
> DeMarco
>
> Прогноз времени разработки: Средняя производительность:
> Только программистом 8.0
> Только руководителем проекта 6.6
> Совместно программистом и рук. проекта 7.8
> Системным аналитиком 9.5
> (Не оценивается) _12.0_
>
> Вот так то.
Т. е. срок/стоимость проекта, в среднем, в два раза выше, чем
оценивает руководитель проекта? Впечатляет...
vrud...@onestone.de
In article <x7en24f...@netmaster.compchem.kiev.ua>,
Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
> А что такое "сам" CMM? Это когда команда в 100+ человек и толпа
> манагеров? А бюджет начинается с $10M ? :)))
Да. Это МЕТОДИКА. С огромным количеством документации.
> Если я скажу, что я хочу применить методики CMM к малым и очень малым
> организациям, так точнее будет? :) BTW, этого же хотите и Вы, если я
> правильно понимаю.
На сколько я понимаю, эти методы контроля процесса были разработаны не
SEI, а возникли в самом процессе. Есть другие источники, их описывающие.
Лично я им доверяю больше.
> Ко мне можно обращаться на ты
ОК. Аналогично.
> > Кстати они обещали практические примеры применения методики. Вы их
> > не встречали?
>
> Практические примеры применения чего?
Лучшие практики SEI CMM. Видимо по-этому и перенесли они сроки выпуска
второго варианта.
> Вряд ли какая либо компания откроет достаточно данных по процессу
> внутреннего преобразования. Даже если сейчас хорошо, то кому
> захочется показывать как было плохо :)
Одно из условий работы консультантов - возможность использования данных в
публикациях. И полно таких исследований. Вот с неудачными проектами дело
обстоит гораздо хуже.
> > Ну это не тот уровень, чтобы делать "процесс". Хотя бы для того, чтобы
> > процесс контролировать на должном уровне нужно 3 человека.
>
> Почему? Я считаю, что даже для одного человека имеет смысл
> придерживаться какого-либо _определенного_ процесса. Другое дело, что
> он может быть документирован на обратной стороне notebook'а
> (бумажного).
Но это уже не СММ.
> Т. е. размер организации влияет лишь на строгость задания процесса.
И СММ и ISO описывают эту строгость. Накладные расходы на контроль
процесса - 5-10%. С начала больше 10, потом где-то около 5, но не меньше.
> Именно поэтому движение началось от DoD, как самой крупной в Штатах
> организации.
Вопрос в том, что оно на этом и закончилось. Практически большинство фирм
выполняет формальности чтобы пройти сертификацию и получить военные
заказы. И только.
> > Почитайте Tom DeMarco. Лучшие книжки для убеждения руководства.
>
> Эээх... Во первых тут купить что-либо очень трудно, а во вторых (и
> главное) -- это же не мне нужно читать книги, а руководству :(
> А оно как всегда убеждено в своей правоте...
Когда я был в Питерской фирме, любой человек, ездивший в командировку за
кордон привозил книгу или еще чего-нибудь труднодостоаваемое.
Я копирую страничку и прикладываю к своему письму. Нужный абзац обвожу
маркером. Очень помогает.
> > Как Вы оцениваете затраты на подобное мероприятие? Кстати Ваше
> > начальство согласно с Вашим определением успеха проекта?
>
> Нет. Оно уже ни с чем не согласно. Я реализую super-micro-CMM для
> одного человека :(
Я бы назвал это организацией собственного процесса. Я тоже этим
занимаюсь, но времени написать соответствующий софт, нет. Именно с этого
и надо начинать. Я бы даже сказал, что с точки зрения экономической
только этим заниматься и имеет смысл.
Начальство обычно убеждает успех на практике, а не толстые книги, которые
ему некогда читать.
> (Как назвать реплику "Ты плохой программист" в ответ на просьбу
> показать документированные требования для проекта?..)
Фраза правильная. Хороший кодировщик может расчитывать на
документированные требования, хороший аналитик должен создать их сам.
Рабочая обстановка, если работаешь не на военных, не на критические АСУ,
типа медицинских, и не на системы реального времени, а "для
пользователя". Надо садиться с товарищем рядом, гладить его по головке и
аккуратненько записывать каждую мысль. Потом принести четко оформленную
бумагу, заставить прочитать и понять. Попытаться натолкнуть на умные
мысли, порисовать картинки. После чего итерацию повторить до
удобоваримого вида бумаги. Каждый раз полезно просить поставить подпись,
или записать свои соображения.
Пока я в одиночку разрабатывал проекты для клиентов, я изучил нескольго
ГОСТов, ОСТов, пару книг по шрифтам, всевозможные виды БД и т.д. Сколько
картинок я нарисовал тяжело вспомнить. Каждый проект выдавал в качестве
побочного продукта килограммы макулатуры. Но ни одного изменения ТЗ после
начала кодирования не потребовалось. Расширения требований иногда
возникали, но тут я рылся в своей пачке и находил нужный лист. После чего
все дополнения переходили в требования к новому релизу.
В одном проекте мы очень хорошо наладили процесс, обмениваясь мейлами (с
Швейцарией), в которых каждое требование было вынесено в отдельный
параграф и пронумеровано. Я все это хранил в одном файле и когда возникал
какой-то вопрос, просто выполнял поиск по ключевому слову. После чего
следовал ответ, что под номером таким было предложено сделать следующее,
под номером таким было сообщено о такой-то ошибке, и номер такой внес
следующие исправления. Отсюда следует, что требование номер N может быть
выполнено так или так, соответственно получаем это и это или то и то.
> > Вы хотите достигнуть уровня 3, или разработать и внедрить методики
> > уровня 3?
>
> Ммм... не совсем понимаю разницу. Я хочу, чтобы моя команда имела бы
> по крайней мере повторяемость (хороших) результатов.
Ты говоришь о команде, а не об организации. СММ - это уровень
организации. Ваша цель (я имею ввиду команду) достигается и на уровне 1.
Что сама команда об этом думает?
Главный вопрос в том, что при размере команды меньше 20 человек первый
фактор, который стоит учитывать - человеческий. Попробуйте провести опрос
что хорошо, что плохо, каковы причины удач и неудач. Поделитесь знаниями
в данной области, если нужно дайте почитать книги. Мой опыт показывает,
что это дает гораздо более весомый эффект, чем внедрение самой
многообещающей методики. Тем более, что в последнем случае она может быть
просто саботирована и все неудачи будут на нее спихнуты.
> Конечно. Задать цель (в project statement) еще недостаточно. Нужно
> ее еще и достичь. :)
Вопрос в том, что если ее задать неправильно, цена ее достижения
повышается, если правильно, вероятность ее достижения выше.
> Не понял фразу. В том смысле, что для DoD сертификация, проведенная
> по методике SPICE недействительна? Почему?
Во-первых, ее еще нет. Во-вторых, у каждой страны и области индустрии
свои сертефицирующие организации. Существующие сейчас военные стандарты в
других областях не применяют. ( Я кстати их видел и был очень удручен их
объемом)
> > PS.: Результаты эксперемента (Lawrence & Jeffery 1985) из книжки Tom
> > DeMarco
> >
> > Прогноз времени разработки: Средняя производительность:
> > Только программистом 8.0
> > Только руководителем проекта 6.6
> > Совместно программистом и рук. проекта 7.8
> > Системным аналитиком 9.5
> > (Не оценивается) _12.0_
> >
> > Вот так то.
>
> Т. е. срок/стоимость проекта, в среднем, в два раза выше, чем
> оценивает руководитель проекта? Впечатляет...
Нет. Вывод не верен. Тут не говориться о точности оценок. Оценки
могут быть и самыми точными, хотя, конечно, точность оценок
программиста выше, чем у руководителя проекта и ниже, чем у
независимого аналитика, специализирующегося на подобных оценках.
Важно тут совершенно другое. Здесь рассматривается только
производительность. (Как я понял средняя по различным метрикам на
нескольких десятках проектов). Вывод следующий: Если программиста не
гнать и не требовать выполнения проекта к следующией пятнице, то
эффективность его работы выше, чем при любой, даже самой профессиональной
оценке. В основном потому, что он делает меньше ошибок и не латает дыры в
спешном порядке. Обычно при четко означеном сроке время, потребное на
качество, приносится в жертву. В результате работа выполняется в два раза
дольше с большим количеством ошибок в результате.
Вот так то.
> --
> SY, Andrey V Khavryutchenko
Regards!
vrud...@onestone.de
In article <x7g1mkf...@netmaster.compchem.kiev.ua>,
Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
Разделение тестирования и кодирования.
> Нет, я понимаю _зачем_ это надо. Меня интересовало почему это нужно
> _особенно_ оговаривать. Хотя после некоторых внутренних событий, я
> убедился, что оговаривать нужно _все_ детали.
"Стоимость разработки имеет свойство мигрировать из контролируемых
областей в неконтролируемые" Tom DeMarco.
Разделение тестирования и кодирования - один из основных принципов. Также
как и необходимость комментариев или учета рекламаций первые 6 месяцев
после выхода продукта.
Оговаривать, точнее внедрять основные принципы путем обучения и
административных мер - необходимо. Все детали лучше оговаривать, оставляя
возможность для совершенствования и подгонки под конкретные нужды.
George Seriakov
Привет!
On 19 Jan 1998 23:55:50 +0200, in relcom.comp.software-eng Andrey V
Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>Вряд ли какая либо компания откроет достаточно данных по процессу
>внутреннего преобразования. Даже если сейчас хорошо, то кому
>захочется показывать как было плохо :)
ИМХО компании, начавшие улучшать свои процессы начинают о них
разговаривать. Молчат только о плохой организации.
---
George Seriakov (seri...@aha.ru)
George Seriakov
Привет!
On 19 Jan 1998 23:55:50 +0200, in relcom.comp.software-eng Andrey V
Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>(Как назвать реплику "Ты плохой программист" в ответ на просьбу
>показать документированные требования для проекта?..)
Обычно это означает, что твое рабочее время ничего не стоит для
говорящего такое.
---
George Seriakov (seri...@aha.ru)
Andrey V Khavryutchenko
vrud...@onestone.de writes:
> In article <x7en24f...@netmaster.compchem.kiev.ua>,
> Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>
> > > Ну это не тот уровень, чтобы делать "процесс". Хотя бы для того, чтобы
> > > процесс контролировать на должном уровне нужно 3 человека.
> >
> > Почему? Я считаю, что даже для одного человека имеет смысл
> > придерживаться какого-либо _определенного_ процесса. Другое дело, что
> > он может быть документирован на обратной стороне notebook'а
> > (бумажного).
>
> Но это уже не СММ.
Возможно. Но для себя я и не ставлю целью построить CMM. Меня
интересует не CMM как таковой, а те преимущества, что он дает.
[skip]
> > Именно поэтому движение началось от DoD, как самой крупной в Штатах
> > организации.
>
> Вопрос в том, что оно на этом и закончилось. Практически большинство фирм
> выполняет формальности чтобы пройти сертификацию и получить военные
> заказы. И только.
Но это ведь не уменьшает правильности CMM подхода? Просто со стороны
рынка коммерческих продуктов отсутствуют такие высокие требования, и,
естественно, компании предпочитают отделываться более дешево -- вешать
лапшу на уши.
> > > Как Вы оцениваете затраты на подобное мероприятие? Кстати Ваше
> > > начальство согласно с Вашим определением успеха проекта?
> >
> > Нет. Оно уже ни с чем не согласно. Я реализую super-micro-CMM для
> > одного человека :(
>
> Я бы назвал это организацией собственного процесса. Я тоже этим
> занимаюсь, но времени написать соответствующий софт, нет. Именно с этого
> и надо начинать. Я бы даже сказал, что с точки зрения экономической
> только этим заниматься и имеет смысл.
Знаю. Но ведь прежде чем писать софт, нужно описать требования к нему
:)
> Начальство обычно убеждает успех на практике, а не толстые книги, которые
> ему некогда читать.
Угу.
> > (Как назвать реплику "Ты плохой программист" в ответ на просьбу
> > показать документированные требования для проекта?..)
>
> Фраза правильная. Хороший кодировщик может расчитывать на
> документированные требования, хороший аналитик должен создать их сам.
> Рабочая обстановка, если работаешь не на военных, не на критические АСУ,
> типа медицинских, и не на системы реального времени, а "для
> пользователя". Надо садиться с товарищем рядом, гладить его по головке и
> аккуратненько записывать каждую мысль. Потом принести четко оформленную
> бумагу, заставить прочитать и понять. Попытаться натолкнуть на умные
> мысли, порисовать картинки. После чего итерацию повторить до
> удобоваримого вида бумаги. Каждый раз полезно просить поставить подпись,
> или записать свои соображения.
Пытаюсь сделать то же, но предпочитаю e-mail. Документирует намного
лучше :)
> Пока я в одиночку разрабатывал проекты для клиентов, я изучил нескольго
[skip для краткости]
> выполнено так или так, соответственно получаем это и это или то и то.
Спасибо за то, что поделился опытом.
> > > Вы хотите достигнуть уровня 3, или разработать и внедрить методики
> > > уровня 3?
> >
> > Ммм... не совсем понимаю разницу. Я хочу, чтобы моя команда имела бы
> > по крайней мере повторяемость (хороших) результатов.
>
> Ты говоришь о команде, а не об организации. СММ - это уровень
> организации. Ваша цель (я имею ввиду команду) достигается и на уровне 1.
Повторяемость достигается на CMM Lvl 2. Lvl 1 -- базовый.
> Что сама команда об этом думает?
>
> Главный вопрос в том, что при размере команды меньше 20 человек первый
> фактор, который стоит учитывать - человеческий. Попробуйте провести опрос
> что хорошо, что плохо, каковы причины удач и неудач. Поделитесь знаниями
> в данной области, если нужно дайте почитать книги. Мой опыт показывает,
> что это дает гораздо более весомый эффект, чем внедрение самой
> многообещающей методики. Тем более, что в последнем случае она может быть
> просто саботирована и все неудачи будут на нее спихнуты.
Согласен.
> > Конечно. Задать цель (в project statement) еще недостаточно. Нужно
> > ее еще и достичь. :)
>
> Вопрос в том, что если ее задать неправильно, цена ее достижения
> повышается, если правильно, вероятность ее достижения выше.
Я об этом и говорю :)
> > > PS.: Результаты эксперемента (Lawrence & Jeffery 1985) из книжки Tom
> > > DeMarco
> > >
> > > Прогноз времени разработки: Средняя производительность:
> > > Только программистом 8.0
> > > Только руководителем проекта 6.6
> > > Совместно программистом и рук. проекта 7.8
> > > Системным аналитиком 9.5
> > > (Не оценивается) _12.0_
> > >
> > > Вот так то.
> >
> > Т. е. срок/стоимость проекта, в среднем, в два раза выше, чем
> > оценивает руководитель проекта? Впечатляет...
>
> Нет. Вывод не верен. Тут не говориться о точности оценок. Оценки
> могут быть и самыми точными, хотя, конечно, точность оценок
> программиста выше, чем у руководителя проекта и ниже, чем у
> независимого аналитика, специализирующегося на подобных оценках.
>
> Важно тут совершенно другое. Здесь рассматривается только
> производительность. (Как я понял средняя по различным метрикам на
> нескольких десятках проектов). Вывод следующий: Если программиста не
> гнать и не требовать выполнения проекта к следующией пятнице, то
> эффективность его работы выше, чем при любой, даже самой профессиональной
> оценке. В основном потому, что он делает меньше ошибок и не латает дыры в
> спешном порядке. Обычно при четко означеном сроке время, потребное на
> качество, приносится в жертву. В результате работа выполняется в два раза
> дольше с большим количеством ошибок в результате.
Vit, этот вывод не следует из исходных данных :)
Но, тем не менее, я с ним согласен. Правда как тогда быть с
прогнозируемостью и реальными проектами?
--
SY, Andrey V Khavryutchenko
'Sides, if talent never saved bad management how is any software ever
Andrey V Khavryutchenko
seri...@aha.ru (George Seriakov) writes:
> On 19 Jan 1998 23:55:50 +0200, in relcom.comp.software-eng Andrey V
> Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>
> >Вряд ли какая либо компания откроет достаточно данных по процессу
> >внутреннего преобразования. Даже если сейчас хорошо, то кому
> >захочется показывать как было плохо :)
>
> ИМХО компании, начавшие улучшать свои процессы начинают о них
> разговаривать. Молчат только о плохой организации.
Не обязательно. Есть компании, не заинтересованные в publicity.
Встречал упоминания в comp.software-eng
vrud...@onestone.de
In article <x767neg...@netmaster.compchem.kiev.ua>,
Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
> Возможно. Но для себя я и не ставлю целью построить CMM. Меня
> интересует не CMM как таковой, а те преимущества, что он дает.
Абсолютно точно дает сертификацию :-)
Остальное вилами по воде писано. Не существует статистики провалов
попыток его применения. А преимущества... :-/ Стоит учесть, что
производительность они меряют в линиях кода, что одно уже вызывает у меня
глубокие сомнения. Процесс получается красивый. Продукт - не известно.
Почитай "Return on Investment from Software Process Improvement as
Measured by U.S. Industry"
(http://www.stsc.hill.af.mil/crosstalk/1996/apr/returnon.html)
Вопрос: Готова ли фирма, в которой ты работаешь, к затратам на достижение
таких преимуществ, которые дает улучшение процесса, даже, если
предположить, что для малой фирмы процент затрат на это дело такой же,
как и для больших.
> > > Именно поэтому движение началось от DoD, как самой крупной в Штатах
> > > организации.
> >
> > Вопрос в том, что оно на этом и закончилось. Практически большинство фирм
> > выполняет формальности чтобы пройти сертификацию и получить военные
> > заказы. И только.
>
> Но это ведь не уменьшает правильности CMM подхода? Просто со стороны
> рынка коммерческих продуктов отсутствуют такие высокие требования, и,
> естественно, компании предпочитают отделываться более дешево -- вешать
> лапшу на уши.
Проблема несколько в другом. CMM сертификация, также как и ISO,
предполагает выполнение определенных требований. Большинство попыток
выполнения этих требований связано не с логикой процесса, а с выполнением
формальных инструкций, которые обычно не обладают должной гибкостью.
В коммерческих продуктах отсутствует не высокие требования, а
формализация этих требований. И, в некоторой мере, повторяемость условий.
МО не волнует цена, на рынке цена является определяющим фактором. Есть
фирмы использующие отдельные методы пятого уровня, но находящиеся на
первом. И _не_собирающиеся_ лезть выше по причинам экономической
неэффективности.
Следует добавить, что МО и другим бюрократическим структурам скорее можно
всучить какую-нибудь фигню, чем на рынке. IMHO именно это и послужило
причиной создания SEI.
"Если Ваша организация не применяет ISO 9000, Вы скорее всего не знаете
что это такое, если применяет, то Вы точно этого не знаете." С.Адамс
"Принцип Дильберта"
....
> Знаю. Но ведь прежде чем писать софт, нужно описать требования к нему
> :)
Не всегда. В некоторых случаях можно только создать прототип, проверить
гипотезу, построить новую. И повторить все с начала.
> Пытаюсь сделать то же, но предпочитаю e-mail. Документирует намного
> лучше :)
Этот способ хуже по той причине, что нельзя обсудить картинки, порисовать
чего-нибудь, да и просто установить человеческий контакт. Потом при
личной встрече труднее получить отписку. Самый хороший вариант - разумное
сочитание того и другого.
> > Пока я в одиночку разрабатывал проекты для клиентов, я изучил нескольго
> [skip для краткости]
> > выполнено так или так, соответственно получаем это и это или то и то.
Кстати. Мой отец говорил, что начальник не ищет решения, он их принимает.
Поэтому нужно давать не менее двух возможных вариантов даже в том случае,
если есть единственный верный. Я думаю, что для пользователя это тоже
справедливо. По крайней мере необходимость выбирать заставляет начинать
думать ;-)
> > Ты говоришь о команде, а не об организации. СММ - это уровень
> > организации. Ваша цель (я имею ввиду команду) достигается и на уровне 1.
>
> Повторяемость достигается на CMM Lvl 2. Lvl 1 -- базовый.
Смотря чего повторяется. Например коммерческий успех может повторяться
при уровне 1 и не повторяться при уровне 2. Если рискнуть и применить
новую методику, то повторяемость не гарантирована, а эффективность может
повыситься.
> > > > PS.: Результаты эксперемента (Lawrence & Jeffery 1985) из книжки Tom
> > > > DeMarco
> > > >
> > > > Прогноз времени разработки: Средняя производительность:
....
> > ... Вывод следующий: Если программиста не
> > гнать и не требовать выполнения проекта к следующией пятнице, то
> > эффективность его работы выше, чем при любой, даже самой профессиональной
> > оценке....
>
> Vit, этот вывод не следует из исходных данных :)
Следует. Прогноз времени разработки == намеченые сроки выполнения работы.
Читай план. Другими словами: если плана нет, то нет и срока сдачи проекта
=> нет давления на разработчика.
> Но, тем не менее, я с ним согласен. Правда как тогда быть с
> прогнозируемостью и реальными проектами?
Я долго рассматривал различные варианты, но в конце концов выбрал (точнее
вернулся в очередной раз) к следующему: 'Quality before Deadline before
Functionality' (Слоган Siemens Nixdorf Systems Software)
Прогнозировать сроки реальных проектов должна независимая группа
экспертов, причем сроки эти не должны деталироваться ниже уровня группы
или использоваться как определяющий фактор планирования разработки.
Полезно знать зависимости Время _разработки( функциональность) ;
конечная_стоимость_проекта( персонал ) но на рынке ПО не это играет
определяющую роль. Обычно экономический эффект от таких мероприятий не
столь высок, а риск провала велик. Один дорогой большой проект в котором
я принимал участие провалился по причине неучета мелких факторов (таких
как болезни и отпуска) и негибкости. Если процесс спланирован на верху и
внедряется сверху вниз, то велика вероятность того, что на нижнем уровне
получится профанация, чему я тоже был свидетель. А контролировать процесс
менеджмент не смог, хотя и пытался. Кстати на эту тему (метрики в
реальном мире) есть интересная статья в том же журнале, которую я советую
прочитать: ( http://www.stsc.hill.af.mil/CrossTalk/1997/dec/metrics.html)
> --
> SY, Andrey V Khavryutchenko
Regards!
Andrey V Khavryutchenko
vrud...@onestone.de writes:
> In article <x767neg...@netmaster.compchem.kiev.ua>,
> Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>
> > Возможно. Но для себя я и не ставлю целью построить CMM. Меня
> >интересует не CMM как таковой, а те преимущества, что он дает.
>
> Абсолютно точно дает сертификацию :-)
:)
> Остальное вилами по воде писано. Не существует статистики провалов
> попыток его применения. А преимущества... :-/ Стоит учесть, что
> производительность они меряют в линиях кода, что одно уже вызывает у
> меня глубокие сомнения. Процесс получается красивый. Продукт - не
> известно. Почитай "Return on Investment from Software Process
> Improvement as Measured by U.S. Industry"
> (http://www.stsc.hill.af.mil/crosstalk/1996/apr/returnon.html)
В процессе чтения. Может прокомментирую позже.
> Вопрос: Готова ли фирма, в которой ты работаешь, к затратам на
> достижение таких преимуществ, которые дает улучшение процесса, даже,
> если предположить, что для малой фирмы процент затрат на это дело
> такой же, как и для больших.
Теперь я убежден, что нет. Следующий вопрос -- как повысить личную
эффективность как дизайнера/кодера/тестера при deadline-давлении со
стороны менеджмента?
[ сертификация для получения DoD заказов ]
> > Но это ведь не уменьшает правильности CMM подхода? Просто со
> >стороны рынка коммерческих продуктов отсутствуют такие высокие
> >требования, и, естественно, компании предпочитают отделываться более
> >дешево -- вешать лапшу на уши.
>
> Проблема несколько в другом. CMM сертификация, также как и ISO,
> предполагает выполнение определенных требований. Большинство попыток
> выполнения этих требований связано не с логикой процесса, а с
> выполнением формальных инструкций, которые обычно не обладают должной
> гибкостью.
Согласен.
[skip]
> "Если Ваша организация не применяет ISO 9000, Вы скорее всего не
> знаете что это такое, если применяет, то Вы точно этого не знаете."
> С.Адамс "Принцип Дильберта"
:)
> ....
>
> > Знаю. Но ведь прежде чем писать софт, нужно описать требования к
> >нему :)
>
> Не всегда. В некоторых случаях можно только создать прототип,
> проверить гипотезу, построить новую. И повторить все с начала.
Ну, тогда нужно сформулировать гипотезу. Нельзя программировать
"просто так". Какую-то цель программист все таки имеет. Лучше ее
сформулировать заранее, чтобы потом не получить прекрасного решения
неправильной задачи.
[skip]
> Кстати. Мой отец говорил, что начальник не ищет решения, он их
> принимает. Поэтому нужно давать не менее двух возможных вариантов
> даже в том случае, если есть единственный верный. Я думаю, что для
> пользователя это тоже справедливо. По крайней мере необходимость
> выбирать заставляет начинать думать ;-)
:)
[skip]
> > > > > PS.: Результаты эксперемента (Lawrence & Jeffery 1985) из
> > > > >книжки Tom DeMarco
> > > > >
> > > > > Прогноз времени разработки: Средняя производительность:
> ....
> > > ... Вывод следующий: Если программиста не гнать и не требовать
> > >выполнения проекта к следующией пятнице, то эффективность его
> > >работы выше, чем при любой, даже самой профессиональной оценке....
> > Vit, этот вывод не следует из исходных данных :)
>
> Следует.
> Прогноз времени разработки == намеченые сроки выполнения
> работы.
Да.
> Читай план.
???
> Другими словами: если плана нет, то нет и срока
> сдачи проекта => нет давления на разработчика.
Да. Но как из этого следует повышение эффективности труда
разработчика при отсутствии давления на него?
> > Но, тем не менее, я с ним согласен. Правда как тогда быть с
> >прогнозируемостью и реальными проектами?
>
> Я долго рассматривал различные варианты, но в конце концов выбрал
> (точнее вернулся в очередной раз) к следующему: 'Quality before
> Deadline before Functionality' (Слоган Siemens Nixdorf Systems
> Software)
Sigh. Твои слова, да менеджменту в уши.... :(
[skip]
> Кстати на эту тему (метрики в
> реальном мире) есть интересная статья в том же журнале, которую я
> советую прочитать: (
> http://www.stsc.hill.af.mil/CrossTalk/1997/dec/metrics.html)
Спасибо за ссылки.
--
SY, Andrey V Khavryutchenko
'Sides, if talent never saved bad management how is any software ever
vrud...@onestone.de
In article <x7ra61e...@netmaster.compchem.kiev.ua>,
Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
> > (http://www.stsc.hill.af.mil/crosstalk/1996/apr/returnon.html)
>
> В процессе чтения. Может прокомментирую позже.
Журнал интересный. Имеет смысл почитать и остальные номера. Там по этой
теме статей полно. В последнем номере David P. Quinn рассказывает о том,
что метод хорош, несмотря на некоторые неудачные его реализации и что
надо делать для того, чтобы он не провалился.
> Теперь я убежден, что нет. Следующий вопрос -- как повысить личную
> эффективность как дизайнера/кодера/тестера при deadline-давлении со
> стороны менеджмента?
Если бы я знал, я бы работал не здесь и за зарплату по крайней мере раза
в два выше. :-) Попытаюсь вкратце рассказать о том, что знаю.
Тут для руководителя нужно сочетание таких качеств, как знание психологии
и социологии (как у тебя с ними ;-) ), опыт, знания в области SE, талант
и удача. Основной принцип - оградить людей от любого давления, дать им
хорошую мотивацию, создать из них слаженную команду. Остальное они
сделают сами.
С первым более менее просто. Начальнику подается докладная о том, что по
результатам исследований (например Боэм есть и в русском переводе)
проекты такого объема не были выполнены раньше чем через N месяцев. "Мы
конечно сделаем все возможное, но не в наших силах пробежать стометровку
за 9 секунд."(С) Tom DeMarco. Или о том, что в прошлом проекте, который
был сделан в чересчур сжатые сроки, было пропущено столько-то ошибок,
исправление которых заняло столько-то времени и следующие клиенты
отказались от покупки системы именно из-за ошибок. "Если мы выпустим
проект на месяц раньше, не выполнив запланированных тестов и не создав
проектной документации, то за следующие после выпуска 6 месяцев мы
потратим столько-то дополнительных времени и денег на исправление ошибок.
В лучшем случае." Естественно надо иметь на руках цифры. Причем собирать
их придется обязатьельно подпольно. ;-)
> > Не всегда. В некоторых случаях можно только создать прототип,
> > проверить гипотезу, построить новую. И повторить все с начала.
>
> Ну, тогда нужно сформулировать гипотезу. Нельзя программировать
> "просто так". Какую-то цель программист все таки имеет. Лучше ее
> сформулировать заранее, чтобы потом не получить прекрасного решения
> неправильной задачи.
Согласен. Полезно записывать все идеи и хранить их в архиве, чтобы потом
было на чем учиться. Я, например, делал одно задание "как можно быстрее",
хотя и знал, что нужно на самом деле. Потом требования изменились и
пришлось переделывать "как надо". Во второй раз в подобном случае я
показал, что за два месяца работы две недели ушли на переделку диаграммы
классов и межклассовых интерфейсов после того, как "все работало", и
просто сказал, что лажу гнать не буду. Меня не поняли, но отстали.
> > Прогноз времени разработки == намеченые сроки выполнения
> > работы.
>
> Да.
>
> > Читай план.
>
> ???
Календарное планирование. Руководители очень любят рисовать картинки в
тулах обещающих сделать идиотов гениями, например MS Project. (Эта группа
делает проект А к такому-то числу, эта группа - проект Б к такому-то,
потом они передают результаты группе тестирования объединяются и начинают
делать проект В, который заканчивают к 7 ноября.) Вот то, что это просто
картинки и отравлять их надо не руководителю проекта, а сразу в помойное
ведро они не понимают.
( Я участвовал в проекте с подобной техникой "организации процесса
разработки", который со свистом пролетел.)
> > Другими словами: если плана нет, то нет и срока
> > сдачи проекта => нет давления на разработчика.
>
> Да. Но как из этого следует повышение эффективности труда
> разработчика при отсутствии давления на него?
Из эксперемента.
Повторяю. В тех случаях, когда сроки работы не задавались,
производительность была самая высокая. ( Средняя производительность 12.0
в 24 исследованых промышленных проектах.) Когда сроки задавались
начальником проекта - самая низкая (6.6 в 23 исследованных проектах).
Соответственно когда самим программистом - 8.0 в 19 проектах,
программистом совместно с начальником проекта - 7.8 в 16, системным
аналитиком 9.5 в 21. Исследования провели Michael Lawerence & Ross
Jeffery из университета New South Wales в 1985 году.
> > Я долго рассматривал различные варианты, но в конце концов выбрал
> > (точнее вернулся в очередной раз) к следующему: 'Quality before
> > Deadline before Functionality' (Слоган Siemens Nixdorf Systems
> > Software)
>
> Sigh. Твои слова, да менеджменту в уши.... :(
:-))) Было дело. (Ты тоже попытаться можешь, можешь даже на меня
ссылаться, но я бы не советовал. "Менеджмент" обижается, а хорошие
руководители знают это сами.)
Один раз я круто поругался с самым главным начальником (после того, как
мой непосредственный не смог со мной справиться). Я услышал про себя
много лестного: и то, что моя задача на кнопочки нажимать, и то, что я
должен испытывать радость только от того, что то, что я делаю вдруг
заработает, что сверху все видно лучше и т.д. В результате, так как я
твердо стоял на том, что мне на работу надо три недели, а через две будет
только полное глюков убожество, начальник нашел возможность подключить к
работе на неделю еще одного человека, имевшего опыт работы с используемой
библиотекой, которую я не знал абсолютно. В результате одна неделя была
потрачена на создание двух слабозависимых частей, а во вторую я провел
интеграцию, тестирование, подготовил документацию и демонстрацию. Мой
проект оказался единственным, который был готов за день до момента
приезда клиентов. Стиль фирмы - ночная сборка и отладка проектов с
обратным отсчетом времени в часах. Сейчас они пытаются от этого отойти,
но не очень успешно. (Почему - могу рассказать, но не в ньюсах.)
Вот еще несколько мыслей на эту тему.
Перед новым годом в comp.software-eng прошла итрересная группа постингов
прод заголовком "Why high-tech Employer switch job". Я много этих
постингов храню в архиве. Основная причина ухода - бесперспективность
работы на старом месте. Низкое качество результатов и ковбойские методы
работы - основные признаки этого.
Если люди гонят лажу и знают, что гонят лажу, в конце концов они уходят.
Просто потому, что не хотят снижать свою самооценку. Уходить они начинают
собираться сразу после того, как понимают, что от них требуют гнать
некачественный продукт. В таком состоянии они могут работать и год, и
два, и десять, но требовать от них стремления к достижению целей или
высокой производительности бесполезно. (Как например от меня сейчас. :-(
) В первую очередь качество продукта нужно самой команде разработчиков.
Для повышения самооценки. Качество, которое сама команда считает
соответствующим. Оно обычно выше, чем требуемое потребителем или
начальством. Но оно - единственно верное. Выдать продукт, когда команда
считает, что он еще сырой - удар по самооценке настолько сильный, что
команда перестает быть командой и превращается в группу людей, которым
стыдно смотреть друг другу в глаза.
Ну и на закуску пара вопросов из книжки, которую я сейчас читаю: "Вопрос
1: Как велика была текучесть кадров в Вашей фирме в последние годы?
Вопрос 2: Как велика средняя стоимость, заменить ушедшего сотрудника?"
akh...@kbi.kiev.ua
vrud...@onestone.de wrote:
>
> In article ?x7ra61e...@netmaster.compchem.kiev.ua>,
> Andrey V Khavryutchenko ?akh...@compchem.kiev.ua> wrote:
>
> > > (http://www.stsc.hill.af.mil/crosstalk/1996/apr/returnon.html)
> >
> > В процессе чтения. Может прокомментирую позже.
>
> Журнал интересный. Имеет смысл почитать и остальные номера. Там по этой
> теме статей полно. В последнем номере David P. Quinn рассказывает о том,
> что метод хорош, несмотря на некоторые неудачные его реализации и что
> надо делать для того, чтобы он не провалился.
Обязательно!
> > Теперь я убежден, что нет. Следующий вопрос -- как повысить личную
> > эффективность как дизайнера/кодера/тестера при deadline-давлении со
> > стороны менеджмента?
продолжение вопроса: ... кроме как сменить место работы ;) ... :(
> Если бы я знал, я бы работал не здесь и за зарплату по крайней мере раза
> в два выше. :-) Попытаюсь вкратце рассказать о том, что знаю.
>
> Тут для руководителя нужно сочетание таких качеств, как знание психологии
> и социологии (как у тебя с ними ;-) ), опыт, знания в области SE, талант
> и удача. Основной принцип - оградить людей от любого давления, дать им
> хорошую мотивацию, создать из них слаженную команду. Остальное они
> сделают сами.
>
> С первым более менее просто. Начальнику подается докладная о том, что по
[skip]
> В лучшем случае." Естественно надо иметь на руках цифры. Причем собирать
> их придется обязатьельно подпольно. ;-)
Собирать данные ведь нужно по своей производительности. Я уже слышу
слова менеджера о том, что наши условия другие и требуется другая
производительность. Хотя эти слова, как никакие другие, убеждают в
необходимости смены места работы.
> > > Не всегда. В некоторых случаях можно только создать прототип,
> > > проверить гипотезу, построить новую. И повторить все с начала.
> >
> > Ну, тогда нужно сформулировать гипотезу. Нельзя программировать
> > "просто так". Какую-то цель программист все таки имеет. Лучше ее
> > сформулировать заранее, чтобы потом не получить прекрасного решения
> > неправильной задачи.
>
> Согласен. Полезно записывать все идеи и хранить их в архиве, чтобы потом
> было на чем учиться. Я, например, делал одно задание "как можно быстрее",
Хм. Попробую.
> хотя и знал, что нужно на самом деле. Потом требования изменились и
> пришлось переделывать "как надо". Во второй раз в подобном случае я
> показал, что за два месяца работы две недели ушли на переделку диаграммы
> классов и межклассовых интерфейсов после того, как "все работало", и
> просто сказал, что лажу гнать не буду. Меня не поняли, но отстали.
>
> > > Прогноз времени разработки == намеченые сроки выполнения
> > > работы.
> >
> > Да.
> >
> > > Читай план.
> >
> > ???
>
> Календарное планирование. Руководители очень любят рисовать картинки в
> тулах обещающих сделать идиотов гениями, например MS Project. (Эта группа
> делает проект А к такому-то числу, эта группа - проект Б к такому-то,
> потом они передают результаты группе тестирования объединяются и начинают
> делать проект В, который заканчивают к 7 ноября.) Вот то, что это просто
> картинки и отравлять их надо не руководителю проекта, а сразу в помойное
> ведро они не понимают.
>
> ( Я участвовал в проекте с подобной техникой "организации процесса
> разработки", который со свистом пролетел.)
>
> > > Другими словами: если плана нет, то нет и срока
> > > сдачи проекта => нет давления на разработчика.
> >
> > Да. Но как из этого следует повышение эффективности труда
> > разработчика при отсутствии давления на него?
>
> Из эксперемента.
Есть. Ответ на постинги после 8 часов за разгребанием кривого кода,
написанного частично в 1'500 км от тебя, а частично, в другом
полушарии дает себя знать :)
Я неправильно понял заголовок второй колонки. По непонятным причинам
это трансформировалось у меня в оцениваемый срок проекта. Sorry for
confusion.
> Повторяю. В тех случаях, когда сроки работы не задавались,
> производительность была самая высокая. ( Средняя производительность 12.0
> в 24 исследованых промышленных проектах.) Когда сроки задавались
> начальником проекта - самая низкая (6.6 в 23 исследованных проектах).
> Соответственно когда самим программистом - 8.0 в 19 проектах,
> программистом совместно с начальником проекта - 7.8 в 16, системным
> аналитиком 9.5 в 21. Исследования провели Michael Lawerence ? Ross
> Jeffery из университета New South Wales в 1985 году.
Tnx за подробные разъяснения.
> > > Я долго рассматривал различные варианты, но в конце концов выбрал
> > > (точнее вернулся в очередной раз) к следующему: 'Quality before
> > > Deadline before Functionality' (Слоган Siemens Nixdorf Systems
> > > Software)
> >
> > Sigh. Твои слова, да менеджменту в уши.... :(
>
> :-))) Было дело. (Ты тоже попытаться можешь, можешь даже на меня
> ссылаться, но я бы не советовал. "Менеджмент" обижается, а хорошие
> руководители знают это сами.)
Я так и скажу. Менеджмент пусть обижается, но выдавать на гора sh$t я
не буду.
> Один раз я круто поругался с самым главным начальником (после того, как
> мой непосредственный не смог со мной справиться). Я услышал про себя
> много лестного: и то, что моя задача на кнопочки нажимать, и то, что я
> должен испытывать радость только от того, что то, что я делаю вдруг
> заработает, что сверху все видно лучше и т.д. В результате, так как я
Ммм... А руководитель был советский? Или "их"? У меня есть еще остатки
надежды на то, что не все менеджеры "там" используют
коммандно-административный язык.
> твердо стоял на том, что мне на работу надо три недели, а через две будет
> только полное глюков убожество, начальник нашел возможность подключить к
> работе на неделю еще одного человека, имевшего опыт работы с используемой
> библиотекой, которую я не знал абсолютно. В результате одна неделя была
> потрачена на создание двух слабозависимых частей, а во вторую я провел
> интеграцию, тестирование, подготовил документацию и демонстрацию. Мой
> проект оказался единственным, который был готов за день до момента
> приезда клиентов. Стиль фирмы - ночная сборка и отладка проектов с
> обратным отсчетом времени в часах. Сейчас они пытаются от этого отойти,
> но не очень успешно. (Почему - могу рассказать, но не в ньюсах.)
You're welcome at akh...@compchem.kiev.ua
> Вот еще несколько мыслей на эту тему.
>
> Перед новым годом в comp.software-eng прошла итрересная группа постингов
> прод заголовком "Why high-tech Employer switch job". Я много этих
> постингов храню в архиве. Основная причина ухода - бесперспективность
> работы на старом месте. Низкое качество результатов и ковбойские методы
> работы - основные признаки этого.
Да, да. Я тоже с большим интересом наблюдал за этим тредом и
переписывался
с некоторыми из авторов.
> Если люди гонят лажу и знают, что гонят лажу, в конце концов они уходят.
> Просто потому, что не хотят снижать свою самооценку. Уходить они начинают
> собираться сразу после того, как понимают, что от них требуют гнать
> некачественный продукт. В таком состоянии они могут работать и год, и
> два, и десять, но требовать от них стремления к достижению целей или
> высокой производительности бесполезно. (Как например от меня сейчас. :-(
Т.е. такая же ситуация повторяется у тебя и сейчас?
> ) В первую очередь качество продукта нужно самой команде разработчиков.
> Для повышения самооценки. Качество, которое сама команда считает
> соответствующим. Оно обычно выше, чем требуемое потребителем или
> начальством. Но оно - единственно верное. Выдать продукт, когда команда
> считает, что он еще сырой - удар по самооценке настолько сильный, что
> команда перестает быть командой и превращается в группу людей, которым
> стыдно смотреть друг другу в глаза.
Интересно, а можно заставить менеджмент выдать _документ_, в котором они
требуют снижения качества (т.е. лажу) и с помощью него давить со
стороны клиента? К чему это может привести кроме скандала? :)
> Ну и на закуску пара вопросов из книжки, которую я сейчас читаю: "Вопрос
> 1: Как велика была текучесть кадров в Вашей фирме в последние годы?
> Вопрос 2: Как велика средняя стоимость, заменить ушедшего сотрудника?"
М-да. Правильные вопросы. Если бы я хорошо подумал про причины 100%
текучести за год, я бы здесь не оказался. (Менеджера-виновника распада
предыдущей команды убрали, но, как оказалось, это "corporate policy"
#$%ь ее)
-- akhavr
vrud...@onestone.de
In article <34C7407D...@kbi.kiev.ua>,
akh...@kbi.kiev.ua wrote:
> > > Теперь я убежден, что нет. Следующий вопрос -- как повысить личную
> > > эффективность как дизайнера/кодера/тестера при deadline-давлении со
> > > стороны менеджмента?
>
> продолжение вопроса: ... кроме как сменить место работы ;) ... :(
Менять шило на мыло? Хороших руководителей настолько мало, что
вероятность попасть под их руководство очень мала. :-( Я искал в Германии
профессоров, которые занимаются SE на том уровне, который мне интересен.
После длительного изучения выходящей в университетах литературы могу
сказать, что они встречаются. Иногда. :-(
Обычно менеджмент плох не потому, что хочет быть таким, а потому, что не
умеет руководить. Например на руководящие позиции выдвигаются люди,
которые успешно работали в какой-то технической области. При этом
никакого обучения и тренировки не предусматривается. Вот и начинает
человек руководить как умеет, а умеет он работать с техникой и пытается
те же методы применить к людям. Выходит всегда плохо. Из двух хороших
руководителей, с которыми я непосредственно работал, у одного был очень
большой опыт руководства, у второго - обширные теоретические и
практические познания в области создания софта и желание учиться у
других.
Вообщем на мой взгляд существуют два варианта менеджеров, вольно цитируя
"Принцип Дильберта" С.Адамса ( кстати посмотри
http://www.unitedmedia.com/comics/dilbert/ ):
1. "Джим! Ты великолепный инженер. Ты любишь свою работу и добился
превосходных результатов. Ты не умеешь общаться с людьми и твои познания
психологии и социологии на уровне пищерного человека. Поэтому мы решили,
что руководить новым проектом будешь ты!"
2. "Робинсон совершенно никудышный инженер. Все, за что он берется терпит
провал. У нас есть только один способ спасти новый проект от его
тлетворного влияния - сделать его руководителем проекта."
В первом варианте все более-менее решаемо. Если начальнику показать
цифры, если предоставить результаты собственных измерений, если логически
доказать и объяснить, то он сам будет помогать двигаться в нужном
направлении.
Во втором варианте (или первом близком ко второму) я думаю придется
менять место работы. Но перед этим я бы все-таки пошел на конфликт и
попытался противостоять давлению менеджмента, даже играя по его правилам,
которые обычно не очень чистые.
Во-первых, полученый опыт работы "как надо" ценен сам по себе. Во-вторых,
скучно не будет, особенно если нервы крепкие, а работа дурная. В-третьих,
есть вероятность того, что ситуация изменится. ( Один раз руководителя
нашей группы перевели на другой проект. Но и за все дыры в проекте
ответственность перешла на тех, кто затеял бучу. Пол месяца семья меня
почти не видела, но в результате потом работать было приятно и весело.)
> > В лучшем случае." Естественно надо иметь на руках цифры. Причем собирать
> > их придется обязатьельно подпольно. ;-)
>
> Собирать данные ведь нужно по своей производительности. Я уже слышу
> слова менеджера о том, что наши условия другие и требуется другая
> производительность. Хотя эти слова, как никакие другие, убеждают в
> необходимости смены места работы.
Во-первых, это не верно. Оказавшись "в тех условиях" и почитав про них
книги, я понял, что они совершенно такие же. Люди (отнюдь не все) просто
понимают важность создания нормального процесса производства и не жалеют
на это времени и денег. Скупой платит дважды всегда и везде.
Во-вторых, менеджеры не умеют считать. Слишком сильно наследие
социализма. Впрочем в крупных фирмах на западе все то же самое. Основная
проблема в том, что обычно не учитываются "побочные факторы". Американцы
считают для лазеров КПД "от розетки", а наши "от номинальной мощности".
Поэтому и жрет американский прибор в четыре раза меньше электричества,
выдавая в два раза больше энергии.
Совершенно та же ситуация с софтом. Если учитывать затраты от начала
работы до того момента, когда продукт "сдан", получается одно, а если от
начала написания ТЗ до конца исправления рекламаций клиента и регулярной
"поддержки", то совсем обратное.
В-третьих, производительность зависит от условий. Но зависит всегда и
везде одинаково. Консультационная фирма Tom DeMarco переодически
проводит исследования производительности
===== Я вкратце изложу, что написано в книжке, которая сейчас лежит у
меня на столе. =====
На продуктивность не влияют: * Языки программирования. ... (Кроме
применения ассемблера) * Опыт работыю ... (Кроме случаев опыта меньше 6
месяцев) * Число ошибок в программе... (Программисты, у которых
контрольные тесты результатов не обнаружили ошибок, в среднем оказались
даже производительнее тех, которые выдали программы с множеством ошибок)
* Зарплата...
....
Два программиста, работающих в одной фирме _не_отличаются_ по
производительности более, чем на 21%. (!!! VR)...
Этот эффект предсказал Harlian Mills уже в 1981 году:
"Разница в производительности 10:1 между отдельными программистами
объяснима; но еще существует отношение 10:1 в производительности
программистских фирм." (Mills, Harlian D.: "Software Productivity in the
Enterprise", Boston, Little Brown, 1983)
======
Далее (в книге ) следует разбор признаков плохих условий и способы борьбы
с ними. Среди прочего:
мала площадь рабочего места, рабочая обстановка не спокойная,
отсутствие защищенности приватной сферы (как бы это по русски выразить
:-/ ), невозможность отключения телефона, невозможность перевода
телефонного звонка, ( на секретаршу) частые помехи от других людей,
заставляющие прерывать работу.
Например в одной фирме просто предложили сделать звонок телефона
максимально тихим. В результате, когда люди не могли прервать работу, они
не были вынуждены поднимать трубку. Что дало рост производительности. Или
если человек не хочет, чтобы ему мешали, он ставит на стол красный флажок
и спокойно работает.
....
> Я так и скажу. Менеджмент пусть обижается, но выдавать на гора sh$t я
> не буду.
Желаю тебе удачи при любом исходе. Надеюсь, что тебе удасться все-таки
убедить начальство в том, что это им не менее нужно, чем тебе.
....
> > Один раз я круто поругался с самым главным начальником (после того, как
> > мой непосредственный не смог со мной справиться). Я услышал про себя
....
> Ммм... А руководитель был советский? Или "их"? У меня есть еще остатки
> надежды на то, что не все менеджеры "там" используют
> коммандно-административный язык.
Не все менеджеры "там", не все менеджеры "тут", но большинство по другому
не умеет. Книга С.Адамса "Принцип Дильберта", которую я (и не только я)
так люблю цитировать, описывает жизнь обычных больших западных фирм.
Когда я ее читал, ощущение было такое, что описывается наше родное
социалистическое предприятие. Есть, конечно, капиталистический колорит,
но грабли, по которым люди ходят - одни и те же.
....
> > Если люди гонят лажу и знают, что гонят лажу, в конце концов они уходят.
....
> > высокой производительности бесполезно. (Как например от меня сейчас. :-(
>
> Т.е. такая же ситуация повторяется у тебя и сейчас?
Сложно сказать. Фирма на большом подъеме и быстро растет. Ситуация
бардака может быть или болезнью роста или стилем производства. Недавно
консультационная фирма дала свои рекомендации руководству. С тех пор
начался просто идиотизм. Руководитель отдела производства софта - человек
умный и хочет сделать все нормально, но не знает как. (По крайней мере в
психологии он просто наивен.)
Посмотрим. Есть технические и организационные проблемы, которые фирма
должна рано или поздно начать решать. Пока нового места я не ищу, но
учусь тому, что на этом месте мне врядли пригодиться.
....
> Интересно, а можно заставить менеджмент выдать _документ_, в котором они
> требуют снижения качества (т.е. лажу) и с помощью него давить со
> стороны клиента? К чему это может привести кроме скандала? :)
Конечно нет. Кто же выдаст такой документ, будучи в здравом уме? :-)
Документ тут даже не нужен. Нужно совпадение предсказаний с результатами.
Потом просто имеет смысл сказать начальнику. "Нам нужно... В прошлый раз
мы не сделали, так-то и так, в результате получилось следующее... Если мы
и в этот раз не будем считаться с реальностью, то опять получим такие-то
результаты."
Один раз руководитель нашего проекта выбил ( почти в прямом смысле слова
:-) ) из руководства возможность переписать все заново (а то что мы
"развивали" было просто ужасно) и не добавлять новые функциональные
возможности два месяца. Месяц мы рисовали картинки. Второй делали хороший
код. После этого группа выпускала новые релизы практически без ошибок, и
одновременно производительность резко повысилась.
> > Ну и на закуску пара вопросов из книжки, которую я сейчас читаю: "Вопрос
> > 1: Как велика была текучесть кадров в Вашей фирме в последние годы?
> > Вопрос 2: Как велика средняя стоимость, заменить ушедшего сотрудника?"
>
> М-да. Правильные вопросы. Если бы я хорошо подумал про причины 100%
> текучести за год,
Такого я еще нигде не встречал! >:-/
> я бы здесь не оказался. (Менеджера-виновника распада
> предыдущей команды убрали, но, как оказалось, это "corporate policy"
> #$%ь ее)
Если менеджера убрали, то не все еще потеряно. Нынешний, надеюсь, не
хочет чтобы то же произошло и с ним. Т.е. результаты ему скорее всего
нужны, а вот с умением их достигать и доверием к подчиненным у него не
очень. Это можно использовать. ( Раз 100% работу сменило, значит
отступать есть куда. ;-) )
> -- akhavr
Чего-то я разошелся. :-/
Andrey V Khavryutchenko
vrud...@onestone.de writes:
> In article <34C7407D...@kbi.kiev.ua>,
> akh...@kbi.kiev.ua wrote:
>
> > > > Теперь я убежден, что нет. Следующий вопрос -- как повысить
> > > >личную эффективность как дизайнера/кодера/тестера при
> > > >deadline-давлении со стороны менеджмента?
> > продолжение вопроса: ... кроме как сменить место работы ;) ... :(
>
> Менять шило на мыло? Хороших руководителей настолько мало, что
> вероятность попасть под их руководство очень мала. :-(
Прав, конечно...
> Вообщем на мой взгляд существуют два варианта менеджеров, вольно
> цитируя "Принцип Дильберта" С.Адамса ( кстати посмотри
> http://www.unitedmedia.com/comics/dilbert/ ):
О! Спасибо за урл. Давно искал.
> Во-первых, полученый опыт работы "как надо" ценен сам по
> себе. Во-вторых, скучно не будет, особенно если нервы крепкие, а
> работа дурная. В-третьих, есть вероятность того, что ситуация
> изменится. ( Один раз руководителя нашей группы перевели на другой
> проект. Но и за все дыры в проекте ответственность перешла на тех, кто
> затеял бучу. Пол месяца семья меня почти не видела, но в результате
> потом работать было приятно и весело.)
Есть один очень хороший труд: What I didn't ask at my interview, but
you should. http://www.bit-net.com/~logain/interview/
Жаль, что я его нашел после того как нашел работу. (Так автору и
написал :)
> > > Ну и на закуску пара вопросов из книжки, которую я сейчас читаю:
> > >"Вопрос 1: Как велика была текучесть кадров в Вашей фирме в
> > >последние годы? Вопрос 2: Как велика средняя стоимость, заменить
> > >ушедшего сотрудника?"
> > М-да. Правильные вопросы. Если бы я хорошо подумал про причины
> >100% текучести за год,
>
> Такого я еще нигде не встречал! >:-/
Я наверное не совсем верно посчитал. Прошлая команда распалась
полностью.
> > я бы здесь не оказался. (Менеджера-виновника распада предыдущей
> >команды убрали, но, как оказалось, это "corporate policy" #$%ь ее)
>
> Если менеджера убрали, то не все еще потеряно. Нынешний, надеюсь, не
> хочет чтобы то же произошло и с ним. Т.е. результаты ему скорее всего
> нужны, а вот с умением их достигать и доверием к подчиненным у него не
> очень. Это можно использовать. ( Раз 100% работу сменило, значит
> отступать есть куда. ;-) )
Буду ориентироваться на это.
Tnx за интересный разговор.
--
SY, Andrey V Khavryutchenko
'Sides, if talent never saved bad management how is any software ever
George Seriakov
Привет!
On Thu, 22 Jan 1998 05:11:09 -0600, in relcom.comp.software-eng
vrud...@onestone.de wrote:
>> Теперь я убежден, что нет. Следующий вопрос -- как повысить личную
>> эффективность как дизайнера/кодера/тестера при deadline-давлении со
>> стороны менеджмента?
>Тут для руководителя нужно сочетание таких качеств, как знание психологии
>и социологии (как у тебя с ними ;-) ), опыт, знания в области SE, талант
>и удача.
Стандартные качества менеджера (см. _любую_ западную книжку по
менеджменту) + знание процессов разработки.
>Основной принцип - оградить людей от любого давления, дать им
От любого давления, кроме своего. :-)
>хорошую мотивацию, создать из них слаженную команду. Остальное они
>сделают сами.
Нет. Нужно поставить задачу. Само ничего не сделается.
>Vit
---
George Seriakov (seri...@aha.ru)
Alexander V.Didytch
George Seriakov wrote:
> >Основной принцип - оградить людей от любого давления, дать им
>
> От любого давления, кроме своего. :-)
>
> >хорошую мотивацию, создать из них слаженную команду. Остальное они
> >сделают сами.
Если своё давление не в тему то всё очень быстро надоедат.
> Нет. Нужно поставить задачу. Само ничего не сделается.
>
Тоже мало. В одной книжке было сказано "Plan, organize and control, cotrol,
control ...."
Как правильно организовать control -- не ко мне. На своём опыте знаю только
как его не надо
организовывать. ;)
Sincerely, Alexander
--
..and Bill Gates says, "Let's close all the windows, get out, get back
in, and see if that fixes it." -- by Charles Martin
vrud...@onestone.de
In article <350d19a1...@news.aha.ru>,
seri...@aha.ru (George Seriakov) wrote:
> >Тут для руководителя нужно сочетание таких качеств, как знание психологии
> >и социологии (как у тебя с ними ;-) ), опыт, знания в области SE, талант
> >и удача.
>
> Стандартные качества менеджера (см. _любую_ западную книжку по
> менеджменту) + знание процессов разработки.
Принцип Дильберта: Люди не способные выполнять какую-либо полезную работу
вытесняются туда, где они могут принести меньше всего вреда - в менеджмент.
> >Основной принцип - оградить людей от любого давления, дать им
>
> От любого давления, кроме своего. :-)
От _любого_.
> >хорошую мотивацию, создать из них слаженную команду. Остальное они
> >сделают сами.
>
> Нет. Нужно поставить задачу. Само ничего не сделается.
Это подразумевалось.
> ---
> George Seriakov (seri...@aha.ru)
Regards!
Vit
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
vrud...@onestone.de
In article <350D148D...@usa.net>,
"Alexander V.Didytch" <unknown....@usa.net> wrote:
> Как правильно организовать control -- не ко мне. На своём опыте знаю только
> как его не надо
> организовывать. ;)
И как же не надо?
> Sincerely, Alexander
Alexander V.Didytch
vrud...@onestone.de wrote:
> > Как правильно организовать control -- не ко мне. На своём опыте знаю только
> > как его не надо
> > организовывать. ;)
>
> И как же не надо?
1. Не заставляйте людей писать отчёты (недельные, месячные и т.д.) лучше сами
приходите к ним и общайтесь о ходе их работы если Вы не разбираетесь в деталях
то назначайте ответсвенных по направлениям которые их знают и могут
пообщаться
с разработчиками и могут потом обьяснить Вам состояние дел.
1а. Если сотрудник говорит что -- он не может установить флаг из-за того что
wind-а глючит
и непонятно какие тут использовать функции это значит что он в процессе
1b. Если сотрудник это говорит во второй раз это значит что у него постепенно
опускаются
руки. Соберите людей которые хотя как-то могут помочь разобраться в
проблемме.
1c. Никогда не делайте человека "который знает всё" любое его высказывание
может из
него сделать посмешише. Такие люди сами выделяются из коллектива и люди
их
начинают уважать. Если таких людей назначать то после одного - двух
обращения
ним кто-то получит корявый ответ то больше к ним никогда обращаться не
будут и их
мнение для коллектива ничего не будет стоить.
После такого хода событий этот человек Вам скажет -- ко мне ни с какими
проблемами
не обращались -- вывод - в проекте все OK ?
2. Каждый раз после итоговых разговоров с меняйте сетевой график работ.
3. Никогда не говорите о возникших проблемах у разработчика при остальных.
Сначала
а. разберитесь в проблеме
б. попытайтесь понять что помешало человеку всё зделать правильно
в. если в вы в конце концов не уверены на все 100% что это только его
проблемы
никогда не докоряйте его этим.
4. Распределяйте ответсвенность за изменения, дополнения и т.д. между конкретными
людьми
как бы привлекательным и еффективным не казалось новое предложение. Реально
оценивайте затраты на её реализацию. Порой добавление одного поля в таблицу
приводит
к неделям работы.
5. Если проект, на стадии когда всё надоело, придумывайте повод для сбора
сотрудников на PARTY
личным примером поддерживайте их (рыба ведь начинает гнить с головы).
6. Никогда не говорите сотруднику что он не прав или так делать вообще нельзя --
делайте
это в любой другой форме иначе у него отпадёт всякое желание предлагать что-то
новое или
рассказывать Вам о своих проблеммах.
7. Вы можете сказать на сколько готова сейчас система ? Если нет не требуйте
такогоже отчёта
от своих сотрудников или просите их давать ЭТО только для информативности.
Такой информации
доверять НЕЛЬЗЯ.
8. Не забывайте говорить "Я не прав. Или Я виноват в том что не сказал Вам что
надо было
делать ... " Сотрудник не виноват в Ваших проблемах.
9. Сотрудника не волнуют то что что-то надо делать быстрее или то что из-за Ваших
ошибок в
планированиии на него наваливается большое количество работы. Не
обольщайтесь бесплатными
рабочими часами. При их большом количестве сотрудники на работе начнут
заниматься тем чем
они занимаются в
свободное время (DOOM, пиво и т.д.) что приведёт к полной деморализации и
даже
полному распаду коллектива (хотя как класно там было работать !)
9а. Никогда не говорите сотруднику о том что ему необходимо прийти на работу
в выходные.
Пока он сам не почувсвует необходимость в этом его работа будет крайне
не продуктивной.
Мдааа. Что можно сказать о CMM тех компаний в которых я работал ?
Sincerely, Alexander
P.S. Предлагаю расширить этот список. И начать ведение FAQ нашей эхи именно с
Как не надо организовывать контроль за выполнением работ. И вооще
как не надо организовывать разработку.
Что скажет уважаемый Moderator ?
--
If You want to feel OK -- INSTALL Your Windows Every Day !
vrud...@onestone.de
In article <350FD3B4...@usa.net>,
"Alexander V.Didytch" <unknown....@usa.net> wrote:
> > > Как правильно организовать control -- не ко мне. На своём опыте знаю
> > > только как его не надо организовывать. ;)
> >
> > И как же не надо?
>
> 1. Не заставляйте людей писать отчёты (недельные, месячные и т.д.) лучше
> сами приходите к ним и общайтесь о ходе их работы
Ой! Не надо. А то тут у меня начальник, переодически пробегая мимо, застывает
и подплывает ко мне. "Чего у тебя тут сделано?" Я сначала думал, что он хоть
что-нибудь запоминает. Проверено. Ему важен сам факт. Хреново, что обычно
подобные устремления появляются у начальников в самое неподходящее время.
> 3. Никогда не говорите о возникших проблемах у разработчика при остальных.
:-(
Наверно стоит сказать "не обвиняйте в неумении решать проблему"
> 4. Распределяйте ответсвенность за изменения, дополнения и т.д. между
> конкретными людьми
> как бы привлекательным и еффективным не казалось новое предложение.
Это как? Коллективная ответственность или круговая порука? Или тут "Не"
пропущено?
> 5. Если проект, на стадии когда всё надоело, придумывайте повод для сбора
> сотрудников на PARTY
А если они столько не выпьют?
> 6. Никогда не говорите сотруднику что он не прав или так делать вообще
> нельзя -- делайте это в любой другой форме ...
Не называйте сотрудника идиотом?
> Мдааа. Что можно сказать о CMM тех компаний в которых я работал ?
Да не много. Это отнюдь не связано однозначно.
George Seriakov
Привет!
On Wed, 18 Mar 1998 16:01:24 +0200, in relcom.comp.software-eng "Alexander
V.Didytch" <unknown....@usa.net> wrote:
>> И как же не надо?
>1. Не заставляйте людей писать отч╙ты (недельные, месячные и т.д.) лучше сами
...
>Мдааа. Что можно сказать о CMM тех компаний в которых я работал ?
Он не намного меньше CMM L1 :-).
>P.S. Предлагаю расширить этот список. И начать ведение FAQ нашей эхи именно с
> Как не надо организовывать контроль за выполнением работ. И вооще
> как не надо организовывать разработку.
>Что скажет уважаемый Moderator ?
После некоторого обсуждения пойдет в FAQ (он сейчас на
www.aha.ru/~seriakov/FAQlist.htm).
---
George Seriakov (seri...@aha.ru)
George Seriakov
Привет!
On Tue, 17 Mar 1998 03:33:58 -0600, in relcom.comp.software-eng
vrud...@onestone.de wrote:
>> >Тут для руководителя нужно сочетание таких качеств, как знание психологии
>> >и социологии (как у тебя с ними ;-) ), опыт, знания в области SE, талант
>> >и удача.
>> Стандартные качества менеджера (см. _любую_ западную книжку по
>> менеджменту) + знание процессов разработки.
>Принцип Дильберта: Люди не способные выполнять какую-либо полезную работу
>вытесняются туда, где они могут принести меньше всего вреда - в менеджмент.
Ты шутишь. Менджмент - сложная работа, требующая опыта;
неквалифицированный человек на этом месте может принести много вреда.
>> >Основной принцип - оградить людей от любого давления, дать им
>> От любого давления, кроме своего. :-)
>От _любого_.
Видимо, мы разные люди. Мне нужно некоторое усилие, чтобы оказать на
кого-либо давление.
vrud...@onestone.de
In article <35110cc...@news.aha.ru>,
seri...@aha.ru (George Seriakov) wrote:
> >Принцип Дильберта: Люди не способные выполнять какую-либо полезную работу
> >вытесняются туда, где они могут принести меньше всего вреда - в менеджмент.
>
> Ты шутишь. Менджмент - сложная работа, требующая опыта;
> неквалифицированный человек на этом месте может принести много вреда.
Зато именно на этом месте он может свалить ответственность на других. И хорошо
получается. Красиво.
> ---
> George Seriakov (seri...@aha.ru)