Открыть список
Как стать автором
Обновить

Комментарии 26

Если бы программы делали так же как строят дома, то кучу ошибок и багов мы бы не видели. С другой стороны не удивили бы мы и такого бурного развития индустрии, которое построено на том, что модификация программы относительно дешевая.
Похоже вы не имели дело со строительством квартиры. Там столько косяков вылазит, что даже начинаешь гордиться за качество ИТ проектов. Любая сложная система имеет кучу косяков, важно лишь не зафейлить пару основных параметров отвечающих за работоспособность.
«а если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию»
Прелесть создания ПО в том, что его функциональность можно обложить тестами (порой даже с покрытием близким к полному).
А ещё его можно подвергать стресс-тестированию. Многократно и не особо заморачиваясь.
Со зданиями такое не прокатит: вряд ли кто каждый раз будет с микроскопом проходиться по каждому сварному шву в конструкции, а также исследовать, распахнётся ли дверь или окно при ударе с разгону. =)
> порой даже с покрытием близким к полному

это бытовой самообман без точной мат.оценки, которой в обычных проектах наверное никто не занимается

> вряд ли кто каждый раз

а здесь есть снипы и уголовная ответственность. А вообще, любопытная мысль о том, как бы изменилась программная индустрия с вводом хоть какой-то зримой ответственности за объективно заведомо кривой код/интерфейс, приведший к значимому общественному инциденту. Вот для примера давайте рассмотрим фейсбук....:)
> это бытовой самообман без точной мат.оценки.
мат.оценка (code coverage) обычно включается параметром/плагином проверялки или через gcov. Впрочем целесообразность 100% покрытия это уже другой вопрос. Где-то на хабре про это уже писали.

> Вот для примера давайте рассмотрим фейсбук....:)
для примера лучше брать не фейсбук. для примера лучше брать софт из боинга 737.
и, да, уголовная ответственность за написание лажи в критически важной для жизни области — идея интересная.
Думаю, что к этому неизбежно придут, как пришли к снипам и госконтролю в строительстве. Проблема пока в том, что некому этот контроль/оценку осуществлять. Ни субъекта ни методов. Государство в этом вопросе слишком неуклюже, или вляпывается в какие-то смешные скандалы, или по факту оказывается не при делах. Корпорации «внутри себя» не объективны. Различные «ассоциации производителей» возможно находятся на острие процесса. Но они тоже в конечном итоге действуют в интересах соучредителей. Вопрос открытый, дикое поле.
Эта статья в формате .zip:
Требования — меняются. Поэтому нельзя работать так, будто требования не меняются.
Давайте разрабатывать небольшими кусками, и считать, что на этих небольших кусках требования не меняются.
Короче, «продифференцируем» разработку ПО, и найдем минимальную часть требований, которую можно сделать waterfall'ом. Тогда, в случае если путь по которому мы должны идти — поменялся — мы поменяемся вместе с ним, и потеряем максимум этот небольшой кусочек, а не узнаем об этом закончив проект.

Ой, agile и шум вокруг него это вообще больное.
Я просто не понимаю, почему для идеи, «если что-то нельзя аппроксимировать линейно, давайте посчитаем линейными малые кусочки и получим почти ту кривую что нам нужна», сделали:
1) Манифест.
2) Пропаганду в формате «Это спасение вашего проекта».
3) Специальных тренеров.

И более того, приправили очень спорными, совершенно неоднозначно понимаемыми вещами формата:
  1. «Best architectures, requirements, and designs emerge from self-organizing teams» — Где вообще существует self-organizing team в природе? Хоть один проект, у истоков которого не стоял 1 человек, который все организовал, а «самоорганизованная команда». Нет, конечно, если такую найти, она действительно будет поставлять нам все самое лучшее. Но я таких не встречал. Иначе зачем вообще нужны эти лычки, «сеньор», «лид», «архитектор», «директор компании», если все, волшебным образом «самоорганизоваться» должны?)
  2. «Close, daily cooperation between business people and developers»
    «Face-to-face conversation is the best form of communication (co-location)»
    — кажется, все те ребята, которые строят замки ПО в своем мозгу уже высказались на тему того, когда их рушат через Face-to-face и митинги.
«Хочешь разбогатеть — придумай свою религию» (Л.Рон Хаббард)
:-)
Если уровень культуры компании позволяет, почему бы и нет.

Вы, безусловно, правы, в этом и есть значительная польза от гибких методологий — разбить проект на маленькие "водопады" и добавить сверху по вкусу плюшки в виде взаимозаменяемости команд/разработчиков. Но стоит ли сразу начинать работу, принимая, что мы можем "потерять небольшой кусочек"? А если мы потеряем не один а два? А если десять? Да, требования меняются. Да, мы не знаем, что именно будем разрабатывать через два месяца. Но это никак не отменяет необходимости первоначального плана и структурированных требований к системе. Да, они изменятся. Но они должны быть.

А кто мешает к водопаду добавить элементы аджайла?
И каждую веху начинать с анализа изменений. И, при необходимости, перепланирования.

С другой стороны, при проектировании системы не заложить в нее возможность адаптации под меняющиеся требования — верх некомпетентности. По крайней мере в последние лет 20.

Только давайте не будем изображать из себя рыцарей в белых одеждах, которые смотрят наперёд, системы которых масштабируемы и гибки к изменениям, код красив, а бизнес-ценность настолько велика, что заказчики танцуют на столах джигу. Не всегда есть на это бюджет, а главное — ну нет такого количества квалифицированных сотрудников. Ведь профессиональный уровень Ваших команд все равно всегда, всегда будет ниже медианы уровня входящих в них разработчиков.

Бюджет известен?
Квалификации задействованной команды?
Вы обязаны учитывать не только эти ограничения при подготовке любого проекта.

Потребность в адаптивности архитектуры проявляется не сразу, особенно с точки зрения конечного потребителя. Но, если заложить ее изначально, продукт проживет больше 5-7 лет не утонув в легаси.

Теперь о рыцарях в желтых доспехах: архитектура ущербна, код г-но, как и реакция на потребности. Но система настолько гибкая, что заказчики танцуют джингу, осознав ее бизнес-ценность.

Бюджет известен только ориентировочно. Потому что, как сказано, требования меняются. Состав команды может измениться в любой момент по причинам, которые не всегда от Вас зависят. На гибкость системы всем наплевать, не за нее деньги платят. И если оторваться от разработки, то становится очевидным, что любые решения всегда приходится принимать при недостатке данных, это жизнь, и здесь как раз и нужен опыт и профессионализм. Реальность не всегда идеальна.

При гибкой архитектуре себестоимость изменений значительно ниже. И чем больше у вас разных «изменений», тем это заметнее. А заказчика информировать совсем не обязательно.

Я о подготовке проекта в условиях не полностью сформулированных требований к результату.

Вот к результату требования как раз есть всегда. И даже если они выглядят "чтобы было хорошо", то это Ваша задача как менеджера выяснить "что такое хорошо, а что такое плохо". Гибкая архитектура — это прекрасно. Но дорого.

«Чтобы было хорошо» — не требование к результату (по крайней мере по SMART-у). И удовлетворяется это совсем другим способом, к которому ни архитектура, ни качество кода вообще не имеют никакого отношения.

Я позволю себе закончить на этом неожиданную полемику.

Недостаток данных уже давно можно восполнить просто «погуглив», или попив «чаю» с коллегами/друзьями. Пальцем в небо тоже можно, если вашему заказчику не важен результат.

Великолепно! Я уверен, что человек, который способен "нагуглить" расклад сил среди лиц, влияющих на решение заказчика, планы инвесторов, неожиданный уход сотрудника в декрет, результаты ещё не проведённого custdev, а также прочие моменты, связанные с "недостатком данных" способен на многое.

Собрать информацию о заказчике, его ЛПР и заинтересованных — одна из основных задач при подготовке проекта. Как и быть в курсе состояния собственной компании. Если «менеджер» на это не способен, пора признавать профессиональную некомпетентность.

Со временем приходишь к мысли, что единственный показатель успешности сложной системы — простота исправления ошибок в ней

Скорее простота изменений, в том числе для исправления ошибок.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
miran.ru
Численность
51–100 человек
Дата регистрации

Блог на Хабре