Здравствуйте, bkat, Вы писали:
B>Я тоже не в восторге от того, как СММ насаждается. B>Сам был непосредственным участником такого процесса внедрения СММ. B>Меня лично раздирают противоречие между пониманием того, что цели, B>декларируемые тем же СММ вроде верны и очень даже по делу, B>а вот методы достижения целей могут запросто похоронить благие намерения. B>Так что согласен, что не все так просто, как могут заявлять компании, B>помогающие достичь определенный уровень по CMM.
Кстати, а не мог бы ты поделиться своей историей о внедрении CMM? Чертовски интересно.
Здравствуйте, Gaperton, Вы писали:
G>Кстати, а не мог бы ты поделиться своей историей о внедрении CMM? Чертовски интересно.
Если очень кратко, не называя паролей и явок , то получится примерно следующее.
Дело происходило в одной российской фирме, довольно успешно работающей на одну очень крупную
западную фирму.
Поскольку сама западная фирма имела некий уровень СММ, то в соотвествии с одним из КРА 2-го уровня
она обязана была заботиться о том, как фирмы, которым она поручает свою работу, выполняют эту самую работу.
В общем, как я понял, эта крупная западная фирма решила потратить деньги и силы
на то, чтобы вытянуть своих субподрядчиков на определенный уровень СММ.
Альтернативой, как я понял, был разрыв контрактов с теми, кто по ряду
причин не сможет (не захочет) работать над своим процессом.
Такие вот были исходные данные.
Когда я появился в этой российской компании, уже было принято решение, что компания через 2 года должна иметь 3-й уровень. Начальным естественно был классический 1-й уровень со всеми своими прелестями.
Описывать, как все происходило уж слишком долго.
Было все. Были нудные тренинги. Мы написали кучу документов. Очень долго спорили
по поводу того, а что же имел ввиду SEI в своем отчете о CMM.
Во всем этом принимали участие практически все сотрудники компании.
Западная фирма устраила 2 пробные аттестации и только когда убедилась, что да, мы готовы, тогда
организовала саму аттестацию. В итоге 3-й уровень был получен. Сейчас у этой компании 4-й уровень
Я для себя уяснил, что 3-й уровень за 2 с небольшим года – это слишком быстро.
Если бы не было бы гонки, то все прошло бы куда лучше.
Моя личная оценка – 4 года это реальный срок, при котором народу не прошлось гнаться непонятно за чем.
Нужно время на то, чтобы осознать необходимость того, что требует СММ
и реализовать все разумно, а не формально.
Молодые программеры, которые только что с универов, воспринимают идеи СММ
с большим пониманием и при этом не жалуются на то, что он убивает в них творцов.
Более того, это вроде даже круто, работать по процессу и быть частью команды, которая
разрабатывает сложный продукт (тут я опять вспомню про airbus).
Тяжелее всего с теми, кто уже имеет опыт, причем богатый опыт работы в одиночку.
Некоторые вещи из СММ лучше спустить на тормозах и реализовать их формально.
Это сэкономит и время и нервы. Это относится к некоторым вещам из 3-го уровня.
СММ, кстати, еще критикуют за то, что он слишком негибок и прямолинеен в оценке компаний.
Если есть более конкретные вопросы, то спрашивай.
Правда я не обещаю, что отвечу на все вопросы.
Здравствуйте, bkat, Вы писали: B>Более того, это вроде даже круто, работать по процессу и быть частью команды, которая B>разрабатывает сложный продукт (тут я опять вспомню про airbus).
Это точно. У нас до СММ вроде бы не дошло, но внедрение "картошки на руси" я помню. Постепенно проникаешься, и видишь преимущества наличия методики. Когда каждый релиз — это не подвиг, а результат скоординированных усилий группы людей. B>Тяжелее всего с теми, кто уже имеет опыт, причем богатый опыт работы в одиночку.
Это точно. Начиная от "зачем мне рисовать эту модельку?" до "да когда этот инструктор в школу ходил, я уже ентерпрайзы автоматизировал!"
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Спасибо за ответ. Одно не понятно — что изменилось у вас? Стали сдавать продукты быстрее/медленнее,
дороже/дешевле, качество стало выше или ниже, итд. Каковы твои субъективные оценки оверхэда от следованию процессу.
B>Молодые программеры, которые только что с универов, воспринимают идеи СММ B>с большим пониманием и при этом не жалуются на то, что он убивает в них творцов. B>Более того, это вроде даже круто, работать по процессу и быть частью команды, которая B>разрабатывает сложный продукт (тут я опять вспомню про airbus).
Ну это-то понятно. Я после университета тоже верил в силу формальных методологий и процессов.
Мне казалось, что я знаю как масштабируется разработка на большие коллективы. Теоретически. Я был готов с удовольствием пробовать новые "формальные" методы на себе, по собственной инициативе, и наблюдать за "магией научных формул" в действии. Что мы и делали.
Ничего. Это не навсегда.
Однажды я беседовал с руководителем группы бизнес-консультантов, который набирал себе команду. Мы с ним имели разговор о технологих реорганизации бизнес-процессов, в котором он в частности отметил: "не придавайте большого значения формальным методам. Гораздо важнее здравый смысл, понимание задачи и умение объясняться простым и понятным языком". Тогда я с ним до конца не согласился, но фразу запомнил. Она настолько неожиданно и общо прозвучала, что аргументов как-то сразу не нашлось.
Теперь я уверен, что _не_ знаю, как правильно организовать разработку большого продукта. В любой команде больше 2 человек возникает проблема с эффективной организацией разработки, и я не знаю как ее можно принципиально решить. По моему ощущению, Методологии не решают этой проблемы. Они вообще гроша ломаного не стоят при их формальном применении, а при неформальном они не есть необходимость. "Гораздо важнее здравый смысл, понимание задачи и умение объясняться простым и понятным языком". До меня это в конце концов дошло. Года за три.
Есть и еще одно, очень простое наблюдение. Наличие "The Right People" в гораздо большей степени влияют на качество результата чем используемые процессы или Методологии.
B>Тяжелее всего с теми, кто уже имеет опыт, причем богатый опыт работы в одиночку.
А еще тяжелее с теми, у кого богатый опыт успешной работы в команде. С такими просто концы. Они, видите-ли, слишком много понимают, умные все стали. Пробовать не хотят все подряд, статистике не верят(!), и занимаются демагогией. Например:"по статистике в среднем у каждого человека на земле одно яйцо!"
Здравствуйте, Gaperton, Вы писали:
G>Спасибо за ответ. Одно не понятно — что изменилось у вас? Стали сдавать продукты быстрее/медленнее, G>дороже/дешевле, качество стало выше или ниже, итд. Каковы твои субъективные оценки оверхэда от следованию процессу.
Тут мне сложно ответить, потому что я в этой фирме уже не работаю
Но кое-что я могу сказать.
1)
Больше всего, наверное, выиграли руководители проектов
и те люди, которые непосредственно общаются с заказчиком.
Скажем, если у тебя есть план, который ты создал по науке
с привлечением скажем COCOMO, провел все формальные review плана
и заказчик подписал его, то это защищает самого руководителя
проекта и его команду.
Аналогично со спецификациями системы.
Т.е. когда руководитель проекта начинает внятно и аргументированно
объяснять, что на изменение требований ему нужно дополнительные 2 недели,
то это дает ему гораздо больше шансов выбить эти самые 2 недели.
Т.е. руководителям проектов точно стало понятней как поступать
и что вообще делать.
2)
Качество продукта тоже стало лучше, потому что нормальные внятные
документированные требования позволили писать хорошие тесты.
Найденные баги гарантированно исправлялись и ни о чем не забывалось.
Хотя конечно же полностью от багов избавляться не удавалось,
и после релиза заказчик иногда находил новые баги
3)
Насчет сроков. Где-то я читал статистику, что в целом достижение
уровней СММ не дает заметного снижения сроков разработки.
Сроки остались в среднем такими же. Но, если раньше срыв первоначальных сроков
приводил к проблемам с заказчиком, то потом эти проблемы стали гораздо менее
острыми, потому что все именения сроков происходили с ведома
и согласия заказчика (см. пункт 1).
Т.е. в итоге при тех же сроках недовольство заказчика стало значительно меньше
плюс качество продука стало объективно выше.
4)
Про "дороже/дешевле" я ничего сказать не смогу.
Скорей всего осталось так же.
5)
Про оверхэд следования процессу.
Если не учитывать начальные затраты на создания самого процесса,
то на мой взгляд получается примерно следующее.
У руководителя проекта никакого оверхеда в общем то нет.
Процесс просто расставил все на свои места и стало понятно зачем вообще нужны
руководители и менеджеры и чем они должны заниматься
Для разработчиков. Тут трудно, потому что нужно определиться,
что есть оверхэд.
Из явного — это заполнение метрик и отчетов.
На это может уходить минут 30 в неделю.
Затем, работа над улучшением процесса — на это предусматривалось пару часов в неделю.
Реально человек мог ничего месяц не делать, а потом один день этому посвятить.
Участие в формальных инспекциях и обсуждениях — это я не считаю оверхедом.
Это просто части работы.
G>Есть и еще одно, очень простое наблюдение. Наличие "The Right People" в гораздо большей степени влияют на качество G>результата чем используемые процессы или Методологии.
Конечно же "The Right People" — это очень важно.
Но если эти самые "The Right People" забывают просмотреть
базу дефектов и исправить баг, найденный тестерами на system testing,
а потом никто не проверил что баг был исправлен, то это проблема.
Это очень глупая, обидная, но очень вероятная ситуация,
когда работают не по процессу...
Я просто хочу подчеркнуть, что процесс сам по себе не отрицает
"The Right People" а наоборот, очень нуждается в них.
Спасибо, в целом все ясно. Складывается впечатление что у вас было все не так плохо, я бы даже сказал "имели место быть отдельные недостатки", и всего-то. Молодцы.
Отдельные комментарии.
B>Т.е. руководителям проектов точно стало понятней как поступать B> и что вообще делать.
B>Процесс просто расставил все на свои места и стало понятно зачем вообще нужны B>руководители и менеджеры и чем они должны заниматься
Есть на эту тему ИМХО.
Года 4 назад я зашел на brainbench (там еще было все бесплатно) и увидет там тест для менеджеров проектов.
О как! — подумал я.
Ну ка глянем!
Глянул.
"2.7 баллов, не хватает на сертификат, вы, в целом, полный лох, сэр."
"Да, кстати, при этом вы круче чем 90% всех экзаменованых на данный момент." Смешно. И, к сожалению, симптоматично.
Менеджеры проектов часто наименее компетентные в своем деле специалисты в команде. Руководитель проекта, который не знает, в чем состоит его работа, относит к плюсам внедрения Методологии те элементы управления проектами, которые неизбежно там содержатся (и которые таки в результате худо-бедно вбили ему в голову). В то время как это не плюс Методологии, это минус менеджеру. И еще не понятно, хорошо это или плохо: заставь дурака богу молиться — он себе лоб расшибет до затылка. Вот так плавно мы переходим к The Right People на своих местах.
G>>Есть и еще одно, очень простое наблюдение. Наличие "The Right People" в гораздо большей степени влияют на качество G>результата чем используемые процессы или Методологии. B>Конечно же "The Right People" — это очень важно. B>Но если эти самые "The Right People" забывают просмотреть B>базу дефектов и исправить баг, найденный тестерами на system testing, B>а потом никто не проверил что баг был исправлен, то это проблема. B>Это очень глупая, обидная, но очень вероятная ситуация, B>когда работают не по процессу... B>Я просто хочу подчеркнуть, что процесс сам по себе не отрицает B>"The Right People" а наоборот, очень нуждается в них.
Right People по крайней мере хоть интересный продукт сделают и бабок нарежут. Пусть они разгилдяи и сорвут сроки и забьют болт на пару багов. Зато продажи пойдут (как насчет Doom3? Ждем-с? А сроки-то сорваны больше чем на год). А вот Кто Попало сделает вам по процессу с отменным качеством и в срок продукт, который никому не нужен и вызывает зевоту на рынке. Имеем: наличие Right People (вне зависимости от наличия процесса) критично для рыночного успеха, их отсутствие (даже при наличии процесса) — фатально. Так кто кому нужен и кто важнее, люди или Процесс?
Я категорически против формулировки "процесс нуждается в людях". Процесс создается людьми потому что они нуждаются в процессе, а когда он уже не нужен, — он больше не применяется. А не наоборот.
The Right People потому и Right, что в состоянии сами идентифицировать проблему (не идиоты, все-таки),
и смогут разработать и внедрить необходимый процесс, который не связан рамками Методологий и нацелен
на решение конкретных проблем учитывая личные особенности и склонности, текущую ситуацию, возможности и желание. Потому как при отсутствии желания он просто не сработает, можно увнедряться до посинения. Right People ведь тоже не отрицают процесса (ма-аленького такого, над которым они имеют контроль), но только если они ему не нужны, он их не хочет, не ищет, и не собирается поиметь
Ну в общем, я думаю, наши позиции не столь уж и разнятся.
Просто тут на РСДН действительно обменяться мнениями довольно
тяжело. По крайней мере мне (я не писатель )
Спасибо за интересные мысли
B>>Тяжелее всего с теми, кто уже имеет опыт, причем богатый опыт работы в одиночку. G>А еще тяжелее с теми, у кого богатый опыт успешной работы в команде. С такими просто концы. Они, видите-ли, слишком много понимают, умные все стали. Пробовать не хотят все подряд, статистике не верят(!), и занимаются демагогией. Например:"по статистике в среднем у каждого человека на земле одно яйцо!"
Немного офтопика...
Даже в этой метрике "количество яиц на душу населения" тоже есть смысл.
Если не дай бог по статистике в среднем у каждого человека на земле будет по 2 яйца,
то это означает что случилось что-то страшное и надо уже давно бить в набат и разбираться
что не так.
Тот же СММ говорит, что метрики должны сбираться, но в нем нет списка обязательнных метрик.
А вот на то, чтобы решить какие и зачем, на это нужно много времени
и каждая контора должна изобрести свой велосипед.
Главное не торопиться и гнать. Спешка — это, на мой взгляд, самый главный враг всех Методолий...
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Gaperton, Вы писали:
G>>Кстати, а не мог бы ты поделиться своей историей о внедрении CMM? Чертовски интересно.
B>Если очень кратко, не называя паролей и явок , то получится примерно следующее.
) ?
B>Описывать, как все происходило уж слишком долго. B>Было все. Были нудные тренинги. Мы написали кучу документов. Очень долго спорили B>по поводу того, а что же имел ввиду SEI в своем отчете о CMM. B>Во всем этом принимали участие практически все сотрудники компании.
все сотрудники??? Почему не ограничились SEPG + 1-2 эксперта по основным "производственным" процессам (A&D, SWE, V&V)?
B>Некоторые вещи из СММ лучше спустить на тормозах и реализовать их формально. B>Это сэкономит и время и нервы. Это относится к некоторым вещам из 3-го уровня.
Можешь поподробнее? Что именно и из каких соображений?
IMHO это имеет смысл делать только с Training Programm и (если фирма небольшая) Intergroup Coordination.
Или что-то еще?
Ничего добавить не смогу. Действительно рынок труда для таких спецов очень мал.
Про конторы, которые делают аудит и готовят конторы к сертификациям,
я не слышал . Вернее слышал, но в глаза не видел...
B>>Описывать, как все происходило уж слишком долго. B>>Было все. Были нудные тренинги. Мы написали кучу документов. Очень долго спорили B>>по поводу того, а что же имел ввиду SEI в своем отчете о CMM. B>>Во всем этом принимали участие практически все сотрудники компании.
C>все сотрудники??? Почему не ограничились SEPG + 1-2 эксперта по основным "производственным" процессам (A&D, SWE, V&V)?
SEPG + 1-2 эксперта организуют и координируют работу. Они же генераторы идей.
Но если "могучая кучка" просто напишет хороший процесс и затем руководство спустит
его просто вниз, то ничего работать не будет.
Опять же совместная работа учит всю команду и шансы пройти сертификацию сильно
повышаются, потому что на сертификации народ рассказывает о том,
что сами придумали и реализовали.
B>>Некоторые вещи из СММ лучше спустить на тормозах и реализовать их формально. B>>Это сэкономит и время и нервы. Это относится к некоторым вещам из 3-го уровня.
C>Можешь поподробнее? Что именно и из каких соображений? C>IMHO это имеет смысл делать только с Training Programm и (если фирма небольшая) Intergroup Coordination. C>Или что-то еще?
Я имел ввиду не целые KPA а некоторые цели из некоторых KPA.
Чтобы ответить точнее, мне надо лезть в сам СММ, смотреть точные формулировки
и вспоминать, что делали мы.
Может позже я это сделаю, но не обещаю
Здравствуйте, bkat, Вы писали:
B>>>по поводу того, а что же имел ввиду SEI в своем отчете о CMM. B>>>Во всем этом принимали участие практически все сотрудники компании.
C>>все сотрудники??? Почему не ограничились SEPG + 1-2 эксперта по основным "производственным" процессам (A&D, SWE, V&V)?
B>SEPG + 1-2 эксперта организуют и координируют работу. Они же генераторы идей. B>Но если "могучая кучка" просто напишет хороший процесс и затем руководство спустит B>его просто вниз, то ничего работать не будет. B>Опять же совместная работа учит всю команду и шансы пройти сертификацию сильно B>повышаются, потому что на сертификации народ рассказывает о том, B>что сами придумали и реализовали.
Оно конечно так, но когда в комманде >50 человек, это не возможно просто физически. Приходится ограничиться только SQA, которым без хорошо осознаного понимания процесса вообще никак и различными Senior SWE в качестве экспертов иногда даже для разных активностей в рамках одного процесса. А для остальных только Role-based trainings и полуформальная передача знаний внутри проэктных комманд.
B>>>Некоторые вещи из СММ лучше спустить на тормозах и реализовать их формально. B>>>Это сэкономит и время и нервы. Это относится к некоторым вещам из 3-го уровня.
C>>Можешь поподробнее? Что именно и из каких соображений? C>>IMHO это имеет смысл делать только с Training Programm и (если фирма небольшая) Intergroup Coordination. C>>Или что-то еще?
B>Я имел ввиду не целые KPA а некоторые цели из некоторых KPA. B>Чтобы ответить точнее, мне надо лезть в сам СММ, смотреть точные формулировки B>и вспоминать, что делали мы. B>Может позже я это сделаю, но не обещаю
Это был вопрос уже скорее академический, можно и не отвечать.
Но есть другой, который меня действительно очень интересует.
Мне, в частности, пришлось очень активно заниматься Configuration & Change Management и после интервью с Lead Assessor, Я очень сильно озадачен его интерпретацией некоторых вещей, относящихся к Traceability (SPE C1(3), AC 10).
Во первых он утверждал, что не только "software requirements, design, code, and test cases" "should be traced to the source" (что само собой разумеется), но и другие документы, которые вообще обычно не включаются в baseline и не поставляются заказчику, причем вторые тоже должны ссылаться на source unique id (причем крайне желательны двусторонние ссылки) а текстовые ссылки типа фразы в history — "reestimated, features X & Y considered, feature Z removed" описывающие соответствующий (и зарегистрированый change request) не катят .
В фирме, где ты работал этого придерживались?
Во вторых "Reason of ANY change should be documented and traced" очень плохо согласуется с cooperative development, когда на реализацию одного CR могут приходиться десятки check-in/check-out (и соответственно записей в history). С кодом это проблем не вызывает, т.к. необходимую информацию можно поместить в комментарий к метке. А вот по поводу документации сьехать на cooperative development и на то, что revision history в первую очередь дла разработчиков, а соотв. требования CMM выполняются благодаря наличию необходимой информации в Release Description не удалось
Как решалась эта проблема? (ложить документацию в Source Control System не предлагать, т.к. тогда придется отказаться от массы полезных фич, предоставляемых системой документооборота и выбросить на мусор все усилия и время потраченые на ее кастомизацию).
Надеюсь не слишком загрузил и Заратустра (NDA, котнракт, etc.) позволяют ответить?
Заранее спасибо
Здравствуйте, Gaperton, Вы писали:
B>>Немного в сторону. B>>Как-то читал, как делаются европейские аэробусы (airbus). B>>Вовлечены в это дело многие тысячи спецов с разных стран. B>>В разных странах проектируют и делают разные части самолета. B>>Потом разные части свозятся на сборочные заводы в Германии B>>и все это дело очень неплохо стыкуется и потом самолеты от airbus летают B>>и уже бьют боинги.
B>>Вот туда надо смотреть и с ними сравнивать, а не с макдональдсами. G>А вот с этим как-раз и нельзя сравнивать.
Полностью согласен.
Поинтересуйтесь — сколько времени разрабатывается какой-нибудь самолёт, сколько при этом задействовано людей и во сколько это обходится. Где то читал, что, в среднем — разработка самолёта это 1.5-2.5 тыс человек, 1-1.5 млрд $, и 7-9 лет работы. Вот почему сегодня весь мир летает на самолётах, разработанных в начале 70-х и лишь слегка усовершенствованых (в основном в области электроники и обивки салона ). B57 летают с 1960-х годов. Если такие деньги, время и кол-во людей задейстовать при разработке ПО — этот софт можно будет как эталон высекать в граните.
Другой пример — с архитектурой. Там сроки разработки проектов — вполне сопоставимы с самолётными (3-7 лет). Кроме того, не один архитектор (крупное здание) с нуля не ваяет — есть куча стандартных СНИПов, ГОСТов, ТУ и прочей дребедени, которой он ДОЛЖЕН пользоваться (это Вам не выбирать STL или свой контейнер использовать — там палкой по пяткам — и вперёд — совершенствоваться у них даже то, как провода по стенкам пускать — строго регламентировано). И занимается подобным проектом в общей сложности от 100 до 300 человек. Стоимость $5M — $15M. Теперь берём, и оцениваем — хотя бы по количеству различных элементов — чему эквивалентен подобный проект в IT... Так вот — по разным оценкам, проект аналогичной сложности делает команда из 6-20 человек в течение 1-2 лет (как видите разброс в оценках Ч-Ч в 7 раз), стоимость проекта оценивается в $100K-$500K. Не бросается в глаза лёгкое несоответствие?
Вот потому то говорить о методологиях в разработке ПО — как о систематическом и надёжном методе организовать процесс разработки с таким же качеством, как разработка самолётов — как минимум — смешно, как максимум — глупо, просто потому, что при разработке ПО ни один работадатель, кроме, возможно, пентагона (вспомним язык ADA, Internet, UDF, RPC и кое-что ещё), оплачивать методологию по-настоящему (как это делается в крупных инженерных проектах) — просто не намерен. (Вы где нибудь видели проект — в котором вся проектная документация подготваливалась бы вовремя и в нужном объёме???)
А без этого методологии разработки (как и всё прочее) — являются минимум — набором "правильных идей" (читай "Благих Намерений" — что-то по их поводу в Библии упоминалось... ) — как максимум — набором полезных инструментов, которым ещё нужно суметь воспользоваться. В таких условиях — всё определяется личностями людей (начальством, программистами, архитекторами...)
Кроме того именно в программировании есть существенная психологическая ловушка, в которую попадается большинство начальников и проектировщиков (особенно если они давно перестали заниматься разработкой). Эта ловушка заключается в том, что сами программы — почти ничего не стоят. То есть когда у вас весь офис завален ворованным софтом (или в случае буржуев — Try&Buy софтом), начальство не сильно задумывается, а сколько будет стоить тот или иной вариант проекта, с использованием "готовых деталей". Но, обычно, они начианют об этом задумываться на этапе внедрения. И тут могут возникнуть пёрлы, с заменой одних модулей — другими. Хотел бы я посмотреть на самолёт — в котором меняют винтовые двигатели — на реактивные... А в софте это бывает довольно часто.
G>Когда детали стыкуются и самолет сразу летит, подробные спецификации на детали уже готовы, G>технология их производства уже отлажена, испытания опытных образцов самолетов уже прошли.
Поговорите с Любым авиаконструктором (или хотя бы послушайте их по ТВ). Когда детали стыкуются — первый раз — и не было исключений в истории авиации — самолёт нормально никогда не летит. Его первый полёт — всегда большой риск. Всегда выясняется, что толи с электрикой проблемы, толи маслопровод (замерзает/перегревается), толи в крыле вибрации выше нормы... Потому уже готовый проект самолёта меняют и доделывают, откуда и набегает такая дикая сумма стоимости разработки нового самолёта... (У нас это называется отладка , а ещё говорят, что в других областях её нет... )
G>В программировании прямой аналогией такого процесса является... компиляция (изготовление "деталей" .obj G>по "чертежам/спецификациям" в виде исходников), и сборка ("изготовление" .exe из готовых "деталей"). И G>с этим у нас вообще проблем никаких, как вы понимаете.
G>Написание программного комплекса больше напоминает изобретение новой модели пассажирского самолета. Он же не сразу взял и полетел. Инженеры думают, делают прототипы деталей, испытывают их, собирают прототип сомолета, продувают его в трубах, занимаются компьютерным моделированием, делают опытные образцы, "отлаживают" их, направляя заказы на доработку деталей заводам производителям, и т.д. Бардак тот еще.
При изготовлении самолётов, каждая деталь — отдельный проект. А уж про такие детали, как двигатель — говорить не приходится...
G>Но им проще. У них интерфейсы между деталями более стандартны, детали от разных самолетов очень похожи по принципиальному устройству, количество возможных видов деталей и их функционал известны заранее (двигатель он и есть G>двигатель, известно что он делает и как). И главное, компоненты слабо связанны друг с другом. Например, известно, что к двигателю надо подвести крепление, трубу с топливом, и управление. В програмных же комплексах интерфейсы между компонентами на порядок сложнее, предполагают сложные сценарии взаимодействия со множеством состояний. Это затрудняет разделение задач и разработку, так как такие непростые интерфейсы приходится разрабатывать заново каждый раз, определяя их функционал. А с двигателями все стандартно.
Конечно. У них все детали стоят в десятки раз дороже, потому тут хочешь не хочешь — придётся пользоваться стандартными "интерфейсами". Им то не скажешь — ребятки, а ну её нафиг программу рассылки почты, за неделю напишем свою...
G>Плюс ко всему, современные программные комплексы превосходят по количеству деталей самолеты. Современный софт — это самые сложные инженерные системы за всю историю человечества. Известно, например, что операционная система OS/360 превосходит по инженерной сложности ракету "Сатурн" с "Аполлоном" и лунным модулем вместе взятыми.
А сама эта ОС — уступает по сложности всего-лишь COM инфораструктуре Windows.
G>Так что, это они должны удивлятся почему у нас хоть что-то работает
Согласен целиком и польностью!!!
> Как решалась эта проблема? (ложить документацию > в Source Control System не предлагать
Source Control System в общем случае не обязано
быть представлено одной программой (CVS, VSS, etc.),
а может включать себя и вашу систему документооборота,
главное, чтобы обеспечивались одно- или двусторонние
ссылки на ревизии кода/документа. Хотя бы просто по дате.
Здравствуйте, Candle645, Вы писали:
C>Здравствуйте, bkat, Вы писали:
B>>>>по поводу того, а что же имел ввиду SEI в своем отчете о CMM. B>>>>Во всем этом принимали участие практически все сотрудники компании.
C>>>все сотрудники??? Почему не ограничились SEPG + 1-2 эксперта по основным "производственным" процессам (A&D, SWE, V&V)?
B>>SEPG + 1-2 эксперта организуют и координируют работу. Они же генераторы идей. B>>Но если "могучая кучка" просто напишет хороший процесс и затем руководство спустит B>>его просто вниз, то ничего работать не будет. B>>Опять же совместная работа учит всю команду и шансы пройти сертификацию сильно B>>повышаются, потому что на сертификации народ рассказывает о том, B>>что сами придумали и реализовали.
C>Оно конечно так, но когда в комманде >50 человек, это не возможно просто физически. Приходится ограничиться только SQA, которым без хорошо осознаного понимания процесса вообще никак и различными Senior SWE в качестве экспертов иногда даже для разных активностей в рамках одного процесса. А для остальных только Role-based trainings и полуформальная передача знаний внутри проэктных комманд.
У нас как раз было чуть больше 50 человек.
На самом деле работы, когда процесс только формируется, хватает всем.
Если учесть, что тех, кто был занят на "горящих" проектах не трогали,
то народу нам явно не хватало...
Вот если было бы больше 100 человек, то всех занять было бы тяжелее
C>Но есть другой, который меня действительно очень интересует. C>Мне, в частности, пришлось очень активно заниматься Configuration & Change Management и после интервью с Lead Assessor, Я очень сильно озадачен его интерпретацией некоторых вещей, относящихся к Traceability (SPE C1(3), AC 10). C>Во первых он утверждал, что не только "software requirements, design, code, and test cases" "should be traced to the source" (что само собой разумеется), но и другие документы, которые вообще обычно не включаются в baseline и не поставляются заказчику, причем вторые тоже должны ссылаться на source unique id (причем крайне желательны двусторонние ссылки) а текстовые ссылки типа фразы в history — "reestimated, features X & Y considered, feature Z removed" описывающие соответствующий (и зарегистрированый change request) не катят . C>В фирме, где ты работал этого придерживались?
Да, мы старались этого придерживаться.
Скажем, если в плановом документе есть ссылка на документ по стандарту кодирования,
то эта ссылка приводится по всем правилам (нами же установленными).
Это означает, что мы указываем UID документа со стандартом кодирования
и версию этого документа. На сам документ навешивается baseline метка и заказчик,
при желании, может добраться до любого документа на который есть ссылки из проектных документов.
В общем это было головной болью для СМ инженера.
Задачей человека, отвественного за "кастомизацию" процесса для нужд проекта было
подготовить список всех документов, которые определют процесс,
а СМ инженер должен был аккуратно навешивать baseline метки метки
Правда вот до двусторонних ссылок дело не дошло (слава богу
C>Во вторых "Reason of ANY change should be documented and traced" очень плохо согласуется с cooperative development, когда на реализацию одного CR могут приходиться десятки check-in/check-out (и соответственно записей в history). С кодом это проблем не вызывает, т.к. необходимую информацию можно поместить в комментарий к метке. А вот по поводу документации сьехать на cooperative development и на то, что revision history в первую очередь дла разработчиков, а соотв. требования CMM выполняются благодаря наличию необходимой информации в Release Description не удалось C>Как решалась эта проблема? (ложить документацию в Source Control System не предлагать, т.к. тогда придется отказаться от массы полезных фич, предоставляемых системой документооборота и выбросить на мусор все усилия и время потраченые на ее кастомизацию).
Мы ложили документацию в Source Control System
Но даже если этого и не делать, а использовать, например, Documentum,
то я тоже проблем не вижу...
Какая разница, где физически лежит документ?
Здравствуйте, bkat, Вы писали:
B>Скажем, если в плановом документе есть ссылка на документ по стандарту кодирования, B>то эта ссылка приводится по всем правилам (нами же установленными). B>Это означает, что мы указываем UID документа со стандартом кодирования
В общем примерно то-же самое, только было мнение, что ссылки "по всем правилам" для документов "которые вообще обычно не включаются в baseline и не поставляются заказчику" являются optional — т.е. весма полезны с точки зрения usability, но не являются обязательными с т.з. CMM.
B>и версию этого документа. На сам документ навешивается baseline метка и заказчик, B>при желании, может добраться до любого документа на который есть ссылки из проектных документов. B>В общем это было головной болью для СМ инженера.
Я б даже сказал CM это вообще главный источник головной боли для девелоперов. А ISM и SPTO для PM/PL
C>>А вот по поводу документации сьехать на cooperative development и на то, что revision history в первую очередь дла разработчиков, а соотв. требования CMM выполняются благодаря наличию необходимой информации в Release Description не удалось Как решалась эта проблема? (ложить документацию в Source Control System не предлагать,
B>Мы ложили документацию в Source Control System B>Но даже если этого и не делать, а использовать, например, Documentum, B>то я тоже проблем не вижу... B>Какая разница, где физически лежит документ?
С технической стороны — есть немного. Используемая система документооборота не поддерживает метки . В общем придется ужесточить условия перевода документов в Approved состояние и давать к нему (в обязательном порядке) "правильные" комментарии.
Спасибо за помощь. Приятно было пообщаться со знающим человеком.
Много ли людей в вашей конторе?
Были ли уже формальные сертификации и какой уровень получен?
Сколько времени ушло на подготовку с момента, когда решили "Да — это нужно".
Как долго вообще зрело решение начать работу в этом направлении?
Были ли серьезные трения SQA с разработчиками и PL?
Здравствуйте, bkat, Вы писали:
B>Может и ты расскажешь о своем опыте
Попытаюсь (в рамках разумного)
B>Много ли людей в вашей конторе?
Здесь (http://www.miratech.ua/company.jsp) утверждается, что >100. Более точной информации дать не могу.
B>Были ли уже формальные сертификации и какой уровень получен?
CMM — Не было. В начале 2002 был получен ISO9001:2000.
B>Сколько времени ушло на подготовку с момента, когда решили "Да — это нужно".
Сложно сказать. Работа над процессом и его внедрением в нашем (аутсорцинговом) отделе началась где-то с средины 2000 (RUP в качестве основной модели разработки, более-менее формализированый Project Management, обучение). В 2001 уже велась целенаправланая работа в направлении ISO9000, и подразумевалась в перспективе CMM. Если говорить не о Process Improvement вообще, а о CMM, то почти 2 года.
B>Как долго вообще зрело решение начать работу в этом направлении?
4 года назад, когда я только пришел сюда работать уже существовало понимание преимуществ в глазах заказчиков которые даст наличие соотв. сертификаций.
B>Были ли серьезные трения SQA с разработчиками и PL?
С разработчиками — нет т.к. SQA напрямую с ними не работает (только консультируем в случае необходимости). С PM/PL иногда случаются споры по поводу интерпретации CMM или адекватности планируемого Project-defined project но серьезных трений нет. (может быть потому, что большинство SQA являются PM/PL ).
B>Заранее спасибо!
B>>Были ли серьезные трения SQA с разработчиками и PL?
C>С разработчиками — нет т.к. SQA напрямую с ними не работает (только консультируем в случае необходимости). С PM/PL иногда случаются споры по поводу интерпретации CMM или адекватности планируемого Project-defined project но серьезных трений нет. (может быть потому, что большинство SQA являются PM/PL ).
У нас SQA выделенный и на проектах ничем другим не занимается.
, то получится примерно следующее.
Они, видите-ли, слишком много понимают, умные все стали. Пробовать не хотят все подряд, статистике не верят(!), и занимаются демагогией. Например:"по статистике в среднем у каждого человека на земле одно яйцо!" 
Почему не ограничились SEPG + 1-2 эксперта по основным "производственным" процессам (A&D, SWE, V&V)? 
. 
А ISM и SPTO для PM/PL 
