![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rЭто пост скопирован с поста в LJ вручную из-за проблем с автоматическим переносом.
Из дискуссии под предыдущим постом выяснилось, что ИТ специалисты не очень хорошо представляют разницу между плотом и лодкой. Надо, видимо, запретить в блоге упоминать физику, чтобы не объяснять, почему переход от «легче» к «тяжелее» не может осуществляется поперечным наклоном корпуса. Как уже сказано, практика учит не полагаться на априорное наличие знаний на уровне начальной школы и сперва разбираться с определениями.
Зачем используют UML? В основном потому, что так требуют сетрификаторы. А сертификаты, в свою очередь, требуют клиенты и госорганы.
Хоть в документах и прописано, что дизайн перед кодированием улучшает качество, на самом деле в реальной жизни это совсем не так. В результате, основным этапом UML-моделирования является постдокументация.
Когда софт написан и почти оттестирован, наступает время строить левую и правую ветви V-модели. И тут-то выясняется, что технологий извлечения дизайна и требований из кода просто не существует, и всё надо делать руками. В лучшем случае удаётся поднять в тул диаграмму классов.
Потенциально рынок огромен, но автоматизация безумно сложная, потому что каждый делает по-своему. Особенно это касается форматирования и классификации информации.
Интересно, что по терминам Design Archeology или Requirements Archeology Гугл ничего не выдаёт. А это именно то, чем люди на самом деле занимаются. Reverse Engineering встречается, но описывает в основном другие процессы и в той же V-модели поставлен почему-то в начало цикла улучшения софта, а не в финальную стадию перед сдачей.
Пока все модели процессов врут, применимость их на реальных проектах ограничивается очковтирательством. Как было сказано на междусобойчике теоретиков процессов разработки, у нас ещё нет модели, выдерживающей авралы. Ну да. Просто потому, что в критической ситуации факты начинают лезть из всех щелей.
Впрочем, такая модель была бы опасна, потому что менеджмент при получении реальной информации вместо проведения контрмер банально впадает в панику и блокирует своими безумными приказами любые возможности улучшения ситуации.
Исключения бывали, но очень редко. Да и то в основном это касается не отсутствия испуга, а адекватности действий.
Про постдокументацию
Из дискуссии под предыдущим постом выяснилось, что ИТ специалисты не очень хорошо представляют разницу между плотом и лодкой. Надо, видимо, запретить в блоге упоминать физику, чтобы не объяснять, почему переход от «легче» к «тяжелее» не может осуществляется поперечным наклоном корпуса. Как уже сказано, практика учит не полагаться на априорное наличие знаний на уровне начальной школы и сперва разбираться с определениями.
Зачем используют UML? В основном потому, что так требуют сетрификаторы. А сертификаты, в свою очередь, требуют клиенты и госорганы.
Хоть в документах и прописано, что дизайн перед кодированием улучшает качество, на самом деле в реальной жизни это совсем не так. В результате, основным этапом UML-моделирования является постдокументация.
Когда софт написан и почти оттестирован, наступает время строить левую и правую ветви V-модели. И тут-то выясняется, что технологий извлечения дизайна и требований из кода просто не существует, и всё надо делать руками. В лучшем случае удаётся поднять в тул диаграмму классов.
Потенциально рынок огромен, но автоматизация безумно сложная, потому что каждый делает по-своему. Особенно это касается форматирования и классификации информации.
Интересно, что по терминам Design Archeology или Requirements Archeology Гугл ничего не выдаёт. А это именно то, чем люди на самом деле занимаются. Reverse Engineering встречается, но описывает в основном другие процессы и в той же V-модели поставлен почему-то в начало цикла улучшения софта, а не в финальную стадию перед сдачей.
Пока все модели процессов врут, применимость их на реальных проектах ограничивается очковтирательством. Как было сказано на междусобойчике теоретиков процессов разработки, у нас ещё нет модели, выдерживающей авралы. Ну да. Просто потому, что в критической ситуации факты начинают лезть из всех щелей.
Впрочем, такая модель была бы опасна, потому что менеджмент при получении реальной информации вместо проведения контрмер банально впадает в панику и блокирует своими безумными приказами любые возможности улучшения ситуации.
Исключения бывали, но очень редко. Да и то в основном это касается не отсутствия испуга, а адекватности действий.
(frozen) Важные цитыты из комментариев
Date: 2018-12-29 03:05 pm (UTC)На больших системах, если дизайн не идёт совместно с созданием прототипов или, вообще, кодированием, всё получается гораздо хуже, чем было бы просто программированием. Потому что вместе с ошибками разработки в код тащат ошибки дизайна, что приводит потом к бесконечному латанию дыр. Не говоря уже о распылении ответственности.
Так что, победный рост agile - это не замутнение мозгов, а закономерность.
...
Если дизайн делают те же люди, что и программируют, то проблем на порядок меньше.
...
Это редко бывает. Сейчас модно, когда одни люди рисуют картинки, а другие пишут код. Причём, вторые первым о том, что на картинках ляпы, не сообщают, а просто кодируют, как считают нужным.
...
Когда я работал наёмным, тоже выбирал адекватные команды. А как стал консультантом, это стало пофиг, потому что задача удовлетворять желание клиента, а не учить его жизни.
...
На моей памяти адекватно проверить дизайн могли или очень технические заказчики, или вообще отделы ИТ, просто заказавшие часть работ субподрядчикам. Все остальные могут работать только с текстом техзадания, да и то не очень успешно.
...
Когда деньги перекладываются из одного кармана в другой, правила игры несколько иные.
Помнится, в одной такой конфигурации менеджер квазизаказчика говорил менеджеру квазиподрядчика:
- Вы делаете для нас техзадание. Мы должны ставить условия и говорить, что нам нужно. Вы должны спрашивать и понимать. Так какого хрена за прошедшие три месяца вы ни разу у нас не появились? Как оно вообще может быть "почти готово"?
На что тот отвечал:
- Ну да. Нехорошо получилось. В следующий раз будем больше общаться.
Внешний подрядчик вылетел бы в момент, да ещё с оплатой пенальти.
Или знакомый группой в десять человек делал замену провалившемуся продукту, постоянно страдая от задержек с оплатой, в это время концерн регулярно снабжал деньгами стоголовый отдел индусов, проваливших сроки в два раза и выдавших в результате совершенно негодную фигню, которую знакомый и должен был заменить.
...
Сейчас чаще применяют матричную структуру, где каждое подразделение делает свой этап и отчитывается о его завершении, после чего дальнейшая судьба проекта их не волнует. Тем более, если кодирование, как это сейчас модно, сплавляют в Бангалор.