Комментарии 26
А ещё его можно подвергать стресс-тестированию. Многократно и не особо заморачиваясь.
Со зданиями такое не прокатит: вряд ли кто каждый раз будет с микроскопом проходиться по каждому сварному шву в конструкции, а также исследовать, распахнётся ли дверь или окно при ударе с разгону. =)
это бытовой самообман без точной мат.оценки, которой в обычных проектах наверное никто не занимается
> вряд ли кто каждый раз
а здесь есть снипы и уголовная ответственность. А вообще, любопытная мысль о том, как бы изменилась программная индустрия с вводом хоть какой-то зримой ответственности за объективно заведомо кривой код/интерфейс, приведший к значимому общественному инциденту. Вот для примера давайте рассмотрим фейсбук....:)
мат.оценка (code coverage) обычно включается параметром/плагином проверялки или через gcov. Впрочем целесообразность 100% покрытия это уже другой вопрос. Где-то на хабре про это уже писали.
> Вот для примера давайте рассмотрим фейсбук....:)
для примера лучше брать не фейсбук. для примера лучше брать софт из боинга 737.
и, да, уголовная ответственность за написание лажи в критически важной для жизни области — идея интересная.
Требования — меняются. Поэтому нельзя работать так, будто требования не меняются.
Давайте разрабатывать небольшими кусками, и считать, что на этих небольших кусках требования не меняются.
Короче, «продифференцируем» разработку ПО, и найдем минимальную часть требований, которую можно сделать waterfall'ом. Тогда, в случае если путь по которому мы должны идти — поменялся — мы поменяемся вместе с ним, и потеряем максимум этот небольшой кусочек, а не узнаем об этом закончив проект.
Я просто не понимаю, почему для идеи, «если что-то нельзя аппроксимировать линейно, давайте посчитаем линейными малые кусочки и получим почти ту кривую что нам нужна», сделали:
1) Манифест.
2) Пропаганду в формате «Это спасение вашего проекта».
3) Специальных тренеров.
И более того, приправили очень спорными, совершенно неоднозначно понимаемыми вещами формата:
- «Best architectures, requirements, and designs emerge from self-organizing teams» — Где вообще существует self-organizing team в природе? Хоть один проект, у истоков которого не стоял 1 человек, который все организовал, а «самоорганизованная команда». Нет, конечно, если такую найти, она действительно будет поставлять нам все самое лучшее. Но я таких не встречал. Иначе зачем вообще нужны эти лычки, «сеньор», «лид», «архитектор», «директор компании», если все, волшебным образом «самоорганизоваться» должны?)
- «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 лет не утонув в легаси.
Теперь о рыцарях в желтых доспехах: архитектура ущербна, код г-но, как и реакция на потребности. Но система настолько гибкая, что заказчики танцуют джингу, осознав ее бизнес-ценность.
Бюджет известен только ориентировочно. Потому что, как сказано, требования меняются. Состав команды может измениться в любой момент по причинам, которые не всегда от Вас зависят. На гибкость системы всем наплевать, не за нее деньги платят. И если оторваться от разработки, то становится очевидным, что любые решения всегда приходится принимать при недостатке данных, это жизнь, и здесь как раз и нужен опыт и профессионализм. Реальность не всегда идеальна.
Я о подготовке проекта в условиях не полностью сформулированных требований к результату.
Со временем приходишь к мысли, что единственный показатель успешности сложной системы — простота исправления ошибок в ней
Изменение требований к проекту — ключевая проблема разработки ПО