Как мы внедряли RUP и ISO9000 и почему нам "пришлось изобрести свой процесс" и в чём он состоит.
А также - XP, Agile и тесты и assert'ы.
И когда программисту "который всегда работает" читать об этом.
Кстати в своё время наша организация видимо потратила НЕМАЛО средств и МНОГИЕ разработчики прошли по нескольку курсов по RUP. У меня даже есть два или три сертификата.
То есть мы ОТНЮДЬ не "на коленке" подходили к внедрению.
Но! Очень многое из RUP разбивается о то, что "методология" вроде - есть, а НОРМАЛЬНЫХ инструментов - нету. Даже "родные" инструменты типа ClearQuest, ClearCase, RequisitePro и ДАЖЕ Rational Rose - оставляли желать ГОРАЗДО ЛУЧШЕГО. При этом стоили как САМОЛЁТ - на КАЖДУЮ лицензию. И покупка их IBM'ом ситуацию только усугубила.
И при всём при этом у них ещё и проблемы с русским языком и русской кодировкой. Особенно в CQ и RP.
В итоге - вместо ClearQuest (и отчасти RequisitePro) был куплен чужой продукт и СИЛЬНО ПЕРЕРАБОТАН. Фактически - УЖЕ написан свой. Вместо ClearCase - CVS и SVN. С UML - пока есть проблемы. Есть свои решения, но "недоразвитые" и компромиссные.
Ну и всё же проблема даже не в этом.
Проблема в том, что к RUP - "НЕЛЬЗЯ ПОДХОДИТЬ КАК К ДОГМЕ" (http://18delphi.blogspot.com/2013/05/uml_16.html). Это не СРАЗУ удаётся ВСЕМ понять.
Там прописаны - РЕКОМЕНДАЦИИ. Весь Development Case пытаться писать - ЛУЧШЕ ДАЖЕ НЕ БРАТЬСЯ. Не нужен он.
То же касается и ролей и взгляда на фазы.
УЖЕ - получается "свой процесс".
Ну и "человеческий фактор". Не знаю как на западе, но кое что я написал тут - http://18delphi.blogspot.com/2013/05/offtopic-rup.html и тут - http://18delphi.blogspot.com/2013/05/blog-post_22.html .
При ВСЁМ при этом - в НАШЕЙ организации получилось - БОЛЕЕ ЧЕМ НЕПЛОХО. Но НЕ RUP! А "свой процесс".
Местами даже УЛУЧШАЮЩИЙ RUP. И учитывающий и "отечественную специфику" и специфику организации.
Но местами - ещё не до конца проработанный.
При этом наиболее стандартизированы были самые узкие места - кодирование, моделирование и тестирование.
А также - УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ.
Это пожалуй САМАЯ сильная сторона "нашего" процесса. У нас любой разработчик может увидеть - ПО КАКОЙ ЗАДАЧЕ был изменён тот или иной код, с точностью до даты и строк кода. В базе знаний. В исторической перспективе. И не просто "комментарий к коммиту", а именно ПРИВЯЗКА изменений К ЗАДАЧЕ.
Управление требованиями - пока - далеко от идеала. Но тут надо отдавать себе отчёт, что практически все заказчики - "внутренние", а это накладывает определённую специфику. Далеко не всегда можно "провести формальную грань", ЗАФИКСИРОВАТЬ требования (хотя бы на время) и "подписать договор. Да и требования (как ни странно) - СИЛЬНО разнообразнее, чем к "просто коробочным продуктам". Большая технологическая цепочка, кроме "просто написания софта". Но мы работаем над этим.
Да и "продуктов" на самом деле - ДАЛЕКО не один. Взаимосвязанных. Что тоже накладывает свой отпечаток. И взаимосвязи там далеко даже не как в Word и Excel и VBA. Там зачастую бизнес-логика перетекает из одного продукта в другой. Или "входом" одного продукта служит "выход" другого. И ИНОГДА - stakeholder'ов - СРАЗУ ОЧЕНЬ МНОГО. С РАЗНЫМИ интересами. На первых порах даже с взаимоисключающими. Это не говоря об ошибках и пользовательских пожеланиях.
Да и продукт - МУЛЬТИПАРАДИГМЕННЫЙ. Не то что Word. ТИПОВ объектов с РАЗНЫМИ наборами ОПЕРАЦИЙ - ОЧЕНЬ много.
Это кстати отчасти объясняет - почему нельзя сделать продукт слёту "похожим на браузер", с его вкладками и минималистичностью интерфейса, что в последнее время является как бы "трендом". Продукт - НА ПОРЯДКИ сложнее. По смыслу своему. На порядки - профессиональнее. По наполнению и количеству РАЗНЫХ объектов.
Пока коротко скажу - как Я вижу то, что мы в итоге получили - мы получили БОЛЬШОЙ процесс "типа RUP" в рамках которого в отдельных фазах работает что-то "типа XP". Ну это - МОЙ взгляд - на совсем дилетантском уровне.
... to be continued ...
P.S. Вот тут - http://18delphi.blogspot.com/2013/07/xe4.html ОЧЕНЬ правильно
А также - XP, Agile и тесты и assert'ы.
И когда программисту "который всегда работает" читать об этом.
Кстати в своё время наша организация видимо потратила НЕМАЛО средств и МНОГИЕ разработчики прошли по нескольку курсов по RUP. У меня даже есть два или три сертификата.
То есть мы ОТНЮДЬ не "на коленке" подходили к внедрению.
Но! Очень многое из RUP разбивается о то, что "методология" вроде - есть, а НОРМАЛЬНЫХ инструментов - нету. Даже "родные" инструменты типа ClearQuest, ClearCase, RequisitePro и ДАЖЕ Rational Rose - оставляли желать ГОРАЗДО ЛУЧШЕГО. При этом стоили как САМОЛЁТ - на КАЖДУЮ лицензию. И покупка их IBM'ом ситуацию только усугубила.
И при всём при этом у них ещё и проблемы с русским языком и русской кодировкой. Особенно в CQ и RP.
В итоге - вместо ClearQuest (и отчасти RequisitePro) был куплен чужой продукт и СИЛЬНО ПЕРЕРАБОТАН. Фактически - УЖЕ написан свой. Вместо ClearCase - CVS и SVN. С UML - пока есть проблемы. Есть свои решения, но "недоразвитые" и компромиссные.
Ну и всё же проблема даже не в этом.
Проблема в том, что к RUP - "НЕЛЬЗЯ ПОДХОДИТЬ КАК К ДОГМЕ" (http://18delphi.blogspot.com/2013/05/uml_16.html). Это не СРАЗУ удаётся ВСЕМ понять.
Там прописаны - РЕКОМЕНДАЦИИ. Весь Development Case пытаться писать - ЛУЧШЕ ДАЖЕ НЕ БРАТЬСЯ. Не нужен он.
То же касается и ролей и взгляда на фазы.
УЖЕ - получается "свой процесс".
Ну и "человеческий фактор". Не знаю как на западе, но кое что я написал тут - http://18delphi.blogspot.com/2013/05/offtopic-rup.html и тут - http://18delphi.blogspot.com/2013/05/blog-post_22.html .
При ВСЁМ при этом - в НАШЕЙ организации получилось - БОЛЕЕ ЧЕМ НЕПЛОХО. Но НЕ RUP! А "свой процесс".
Местами даже УЛУЧШАЮЩИЙ RUP. И учитывающий и "отечественную специфику" и специфику организации.
Но местами - ещё не до конца проработанный.
При этом наиболее стандартизированы были самые узкие места - кодирование, моделирование и тестирование.
А также - УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ.
Это пожалуй САМАЯ сильная сторона "нашего" процесса. У нас любой разработчик может увидеть - ПО КАКОЙ ЗАДАЧЕ был изменён тот или иной код, с точностью до даты и строк кода. В базе знаний. В исторической перспективе. И не просто "комментарий к коммиту", а именно ПРИВЯЗКА изменений К ЗАДАЧЕ.
Управление требованиями - пока - далеко от идеала. Но тут надо отдавать себе отчёт, что практически все заказчики - "внутренние", а это накладывает определённую специфику. Далеко не всегда можно "провести формальную грань", ЗАФИКСИРОВАТЬ требования (хотя бы на время) и "подписать договор. Да и требования (как ни странно) - СИЛЬНО разнообразнее, чем к "просто коробочным продуктам". Большая технологическая цепочка, кроме "просто написания софта". Но мы работаем над этим.
Да и "продуктов" на самом деле - ДАЛЕКО не один. Взаимосвязанных. Что тоже накладывает свой отпечаток. И взаимосвязи там далеко даже не как в Word и Excel и VBA. Там зачастую бизнес-логика перетекает из одного продукта в другой. Или "входом" одного продукта служит "выход" другого. И ИНОГДА - stakeholder'ов - СРАЗУ ОЧЕНЬ МНОГО. С РАЗНЫМИ интересами. На первых порах даже с взаимоисключающими. Это не говоря об ошибках и пользовательских пожеланиях.
Да и продукт - МУЛЬТИПАРАДИГМЕННЫЙ. Не то что Word. ТИПОВ объектов с РАЗНЫМИ наборами ОПЕРАЦИЙ - ОЧЕНЬ много.
Это кстати отчасти объясняет - почему нельзя сделать продукт слёту "похожим на браузер", с его вкладками и минималистичностью интерфейса, что в последнее время является как бы "трендом". Продукт - НА ПОРЯДКИ сложнее. По смыслу своему. На порядки - профессиональнее. По наполнению и количеству РАЗНЫХ объектов.
Пока коротко скажу - как Я вижу то, что мы в итоге получили - мы получили БОЛЬШОЙ процесс "типа RUP" в рамках которого в отдельных фазах работает что-то "типа XP". Ну это - МОЙ взгляд - на совсем дилетантском уровне.
... to be continued ...
P.S. Вот тут - http://18delphi.blogspot.com/2013/07/xe4.html ОЧЕНЬ правильно
Комментариев нет:
Отправить комментарий