http://ru.wikipedia.org/wiki/RUP
Я долго думал об этом.
И не раз ловил себя на мысли, что все "продвинутые западные практики" в БОЛЬШИНСТВЕ своём основаны на "демократизме" и "разговоре на равных". А также на вовлечённости "заказчика" (и прочих заинтересованных лиц, в частности и разработчиков) в процесс.
Так вот сколько я видел в своей практике - У НАС (в России) - такого - НЕТ.
Ну НЕ ЧИТАЮТ заказчики диаграммы. И НЕ ДЕТАЛИЗИРУЮТ требования. НИГДЕ, в России. Я лично - такого не видел. И не участвуют в приёмке.
Заказчиками выступают, либо "сильно занятые люди", либо "очень творческие", которым "не до мелочей".
Я это видел кстати ОЧЕНЬ и ОЧЕНЬ давно, когда писал АРМ для канцелярии полка милиции. Году в 94-м.
УМНЫЕ люди пишут - "надо привлекать к разработке stakeholder'ов и выяснять у них ВСЕ детали, чтобы они становились частью команды разработчиков". Я что-то не так понимаю? Может быть. Но я ТАКОГО в своей практике - НЕ ВИДЕЛ. Stakeholder'ам ИНТЕРЕСНО общаться с разработчиками - ТОЛЬКО пока "идея кипит и брызжет". Как только появляются "тысячи нудных и неудобных мелочных вопросов" - интерес - ПРОПАДАЕТ. Что - ЕСТЕСТВЕННО. Интересно же красить "крупными мазками", а детали.. В деталях же - дьявол зарыт... А он - неинтересен.
Это с одной стороны.
А с другой - все эти практики предполагают "командную работу", когда опять же - ВСЕ ВОВЛЕЧЕНЫ в процесс. И КАЖДЫЙ может чем-то поступиться в угоду общему делу. Но какая командная работа может быть, когда у нас - "каждый второй" - гений (это типа самоирония и сарказм в одном флаконе)? Какое "общее дело", если "я лично это вырастил"?
Code Review и указание на необходимость рефакторинга - "это удар по самолюбию". Именно поэтому я на эти темы в последнее время стараюсь говорить "осторожно" (насколько я вообще способен к такой осторожности).
Да и потом. Мы же можем "писать код без ТЗ вовсе". Не нужны нам такие мелочи как ТЗ. Нам так "интереснее". А ТЗ - "отнимают время". А тесты - "тем более". Знакомо?
То есть с ОДНОЙ стороны - все "западные практики" предполагают некий "демократизм" на этапе ОБСУЖДЕНИЯ, а с другой - "собранность и САМОКОНТРОЛЬ" - на этапе РЕАЛИЗАЦИИ. Ни того, ни другого я в России что-то не наблюдаю.
Я конечно передёргиваю (и никого конкретного не имею в виду). Может кстати и "на западе" так же?
Но я просто пытаюсь передать ОЩУЩЕНИЯ. Возможно я неправ. Как любит говорить один мой знакомый - "с этой мыслью надо переспать"...
Тут ИМЕННО дело в "ощущениях", а не в КОНКРЕТНЫХ фактах.
Просто я читаю книги УМНЫХ людей, а по факту - вижу "всё наоборот". И это (что самое странное) - кажется - ОЧЕНЬ естественным. Мол - "ваши западные практики" - нам не указ.
То ли дело в менталитете, то ли в исторической "тоталитарной системе" (хотя это бред по-моему).
То ли я лично - идеализирую "западные практики".
И я не говорю о той организации в которой работаю я. Я говорю о "настроениях вообще". Я много общаюсь с людьми из других организаций. И вижу, что практики "не ложатся" - не по причинам "непонятости" или "неудобности", а именно по причинам "филосовской" несовместимости.
Разрыв очень большой между "технарями" и "генераторами идей".
В итоге приходится "изобретать свои практики". А может это и правильно... Всё должно расти на СВОЕЙ почве.
P.S. Я думал об это же ещё 17-ть лет назад когда работал в Diasoft. Отчасти поэтому я оттуда и ушёл. Может я чего-то так и не понял...
P.P.S Почему-то многие у нас в стране не готовы к "парадигме конвейера" для программной разработки. Это я вижу по вопросам, которые мне задают. Просто - если "конвейер", то вопрос не может "ждать две недели". Или ТЗ - не проработано. У нас в организации кстати - "конвейер". По большей части. Не без проблем, но всё же...
P.P.P.S Просто например вопросы "а зачем тестирование" - повергают меня лично в шок. Хочется спросить - "а зачем методы поверки в технике"?
P.P.P.P.S Не сочтите кстати, что я "брюзжу" (что мне свойственно). Наоборот. Я пытаюсь конструктивно посмотреть на реалии. И делать из них выводы. Глупо же обижаться на дождь, но можно например взять зонтик.
P.P.P.P.S Кстати - "западные подходы" - на западе то работают?
P.P.P.P.P.S Почему вообще возник этот вопрос? Да потому, что программирование в отличии от техники (http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0) или фармацевтики (http://ru.wikipedia.org/wiki/Good_Manufacturing_Practice (у меня мама кстати GMP плотно занимается - http://pharmpersonal.ru/publs/statji/arxiv/podgotovka-personala-ne-problema.html http://www.gmp-club.com/ru/about/gratitude.html хотя сейчас уже и не в рамках СКИФ)) - это "изотерика"... Работает - "и ладно" - практика - критерий истины.. Способы поверки - неочевидны... Пока по крайней мере...
На закуску - http://ru.wikipedia.org/wiki/ISO_9000
"Регламенты и инструкции" - МОЖНО написать. Но КАК "заставить" ВСЕХ им следовать? Чтобы не получалось как на "слайде" в начале поста...
Кто-то НЕ ЗАХОЧЕТ в силу своего положения, а кто-то "обидится" - потому что - "гений"..
И главное - КАК не ОШИБИТЬСЯ в НАПРАВЛЕНИИ "куда идти"? Чтобы не получалась "методология ради методологии", а "тесты - ради тестов", а "инструкция - ради галочки"...?
"А "заставишь" - в инструкциях и регламентах ВСЕГО не предусмотришь... И тогда, на любое отступление все будут спрашивать "что делать?"
Я долго думал об этом.
И не раз ловил себя на мысли, что все "продвинутые западные практики" в БОЛЬШИНСТВЕ своём основаны на "демократизме" и "разговоре на равных". А также на вовлечённости "заказчика" (и прочих заинтересованных лиц, в частности и разработчиков) в процесс.
Так вот сколько я видел в своей практике - У НАС (в России) - такого - НЕТ.
Ну НЕ ЧИТАЮТ заказчики диаграммы. И НЕ ДЕТАЛИЗИРУЮТ требования. НИГДЕ, в России. Я лично - такого не видел. И не участвуют в приёмке.
Заказчиками выступают, либо "сильно занятые люди", либо "очень творческие", которым "не до мелочей".
Я это видел кстати ОЧЕНЬ и ОЧЕНЬ давно, когда писал АРМ для канцелярии полка милиции. Году в 94-м.
УМНЫЕ люди пишут - "надо привлекать к разработке stakeholder'ов и выяснять у них ВСЕ детали, чтобы они становились частью команды разработчиков". Я что-то не так понимаю? Может быть. Но я ТАКОГО в своей практике - НЕ ВИДЕЛ. Stakeholder'ам ИНТЕРЕСНО общаться с разработчиками - ТОЛЬКО пока "идея кипит и брызжет". Как только появляются "тысячи нудных и неудобных мелочных вопросов" - интерес - ПРОПАДАЕТ. Что - ЕСТЕСТВЕННО. Интересно же красить "крупными мазками", а детали.. В деталях же - дьявол зарыт... А он - неинтересен.
Это с одной стороны.
А с другой - все эти практики предполагают "командную работу", когда опять же - ВСЕ ВОВЛЕЧЕНЫ в процесс. И КАЖДЫЙ может чем-то поступиться в угоду общему делу. Но какая командная работа может быть, когда у нас - "каждый второй" - гений (это типа самоирония и сарказм в одном флаконе)? Какое "общее дело", если "я лично это вырастил"?
Code Review и указание на необходимость рефакторинга - "это удар по самолюбию". Именно поэтому я на эти темы в последнее время стараюсь говорить "осторожно" (насколько я вообще способен к такой осторожности).
Да и потом. Мы же можем "писать код без ТЗ вовсе". Не нужны нам такие мелочи как ТЗ. Нам так "интереснее". А ТЗ - "отнимают время". А тесты - "тем более". Знакомо?
То есть с ОДНОЙ стороны - все "западные практики" предполагают некий "демократизм" на этапе ОБСУЖДЕНИЯ, а с другой - "собранность и САМОКОНТРОЛЬ" - на этапе РЕАЛИЗАЦИИ. Ни того, ни другого я в России что-то не наблюдаю.
Я конечно передёргиваю (и никого конкретного не имею в виду). Может кстати и "на западе" так же?
Но я просто пытаюсь передать ОЩУЩЕНИЯ. Возможно я неправ. Как любит говорить один мой знакомый - "с этой мыслью надо переспать"...
Тут ИМЕННО дело в "ощущениях", а не в КОНКРЕТНЫХ фактах.
Просто я читаю книги УМНЫХ людей, а по факту - вижу "всё наоборот". И это (что самое странное) - кажется - ОЧЕНЬ естественным. Мол - "ваши западные практики" - нам не указ.
То ли дело в менталитете, то ли в исторической "тоталитарной системе" (хотя это бред по-моему).
То ли я лично - идеализирую "западные практики".
И я не говорю о той организации в которой работаю я. Я говорю о "настроениях вообще". Я много общаюсь с людьми из других организаций. И вижу, что практики "не ложатся" - не по причинам "непонятости" или "неудобности", а именно по причинам "филосовской" несовместимости.
Разрыв очень большой между "технарями" и "генераторами идей".
В итоге приходится "изобретать свои практики". А может это и правильно... Всё должно расти на СВОЕЙ почве.
P.S. Я думал об это же ещё 17-ть лет назад когда работал в Diasoft. Отчасти поэтому я оттуда и ушёл. Может я чего-то так и не понял...
P.P.S Почему-то многие у нас в стране не готовы к "парадигме конвейера" для программной разработки. Это я вижу по вопросам, которые мне задают. Просто - если "конвейер", то вопрос не может "ждать две недели". Или ТЗ - не проработано. У нас в организации кстати - "конвейер". По большей части. Не без проблем, но всё же...
P.P.P.S Просто например вопросы "а зачем тестирование" - повергают меня лично в шок. Хочется спросить - "а зачем методы поверки в технике"?
P.P.P.P.S Не сочтите кстати, что я "брюзжу" (что мне свойственно). Наоборот. Я пытаюсь конструктивно посмотреть на реалии. И делать из них выводы. Глупо же обижаться на дождь, но можно например взять зонтик.
P.P.P.P.S Кстати - "западные подходы" - на западе то работают?
P.P.P.P.P.S Почему вообще возник этот вопрос? Да потому, что программирование в отличии от техники (http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0) или фармацевтики (http://ru.wikipedia.org/wiki/Good_Manufacturing_Practice (у меня мама кстати GMP плотно занимается - http://pharmpersonal.ru/publs/statji/arxiv/podgotovka-personala-ne-problema.html http://www.gmp-club.com/ru/about/gratitude.html хотя сейчас уже и не в рамках СКИФ)) - это "изотерика"... Работает - "и ладно" - практика - критерий истины.. Способы поверки - неочевидны... Пока по крайней мере...
На закуску - http://ru.wikipedia.org/wiki/ISO_9000
"Регламенты и инструкции" - МОЖНО написать. Но КАК "заставить" ВСЕХ им следовать? Чтобы не получалось как на "слайде" в начале поста...
Кто-то НЕ ЗАХОЧЕТ в силу своего положения, а кто-то "обидится" - потому что - "гений"..
И главное - КАК не ОШИБИТЬСЯ в НАПРАВЛЕНИИ "куда идти"? Чтобы не получалась "методология ради методологии", а "тесты - ради тестов", а "инструкция - ради галочки"...?
"А "заставишь" - в инструкциях и регламентах ВСЕГО не предусмотришь... И тогда, на любое отступление все будут спрашивать "что делать?"
И получим "ручное управление"?"
Комментариев нет:
Отправить комментарий