Comments 39
При чем тут agile? Как отличается от обычного строительства? И серьезно, кто придумал в название компании вставить "цупис"? Это выглядит странно, имхо.
кто придумал в название компании вставить "цупис"
Тот, кто подумал, что просто называться букмекерской конторой несолидно и надо как-то завуалировать, желательно с отсылкой ко всяким гос.учреждениям, чтобы было понятно кто за ними стоит.
От обычного строительства отличается тем, что в процессе вносятся изменения в конечный продукт. Традиционно, при строительстве дома составляется план, значительно отклонятся от которого либо невозможно, либо очень дорого.
Обычный самострой при отсутствии денег. Именно таки строится большая часть частного сектора. Иногда десятилетиями.
Именно по причине того, что большая часть частного сектора строится фирмами, которые экономят на всем чем можно, включая работы, не выполняя регламенты, стройка у людей затягивается десятилетиями. Потому что через год все начинает отваливаться и постоянно все надо чинить и переделывать. У нас общая стоимость вышла в 2,5 раза больше, чем похожий проект в Тереме, просто потому что нормальные материалы стоят сильно дороже. Сотни тысяч ушли на одни саморезы, в то время как в обычной фирме вам обшивать дом будут гвоздями, которые сгниют и отвалятся.
Вы попробуйте отодрать две деревяхи, которые сколотили гвоздями и эти деревяхи "прихватились" ржавчиной. Вспотеете! Кстати, собирать каркас на саморезы - так себе затея. Как правило, используют чёрные калёные саморезы. Они прочные, но хрупкие. В какой-то момент они все разом могут сказать "тррррррруньк" и похоронят вас. Гвозди, при всём их неказистом виде, пластичны и дом, собранный на гвоздях будет живучее.
Касаемо agilе в строительстве - ОЧЕНЬ спорный момент. До начала строительства у вас должен быть ПРОЕКТ. Изменения в проект вносить можно, но надо чётко понимать, как повлияют эти правки. Если строить "летний домик" - там не особо критично, можно кроить "на лету". Но в случае нормальной стройки нормального дома для круглогодичного проживания без проекта получите лажу полную. Даже при наличии проекта строители лажают, а без проекта совсем труба будет.
В стройке есть свои технологические процессы и процессы эти последовательные (читай waterfall). Нарушение этих цепочек в краткосрочной перспективе незаметны, но на длинной дистанции вылезут большими проблемами.
Судя по фото, Вы построили каркасник. Интереса ради позовите независимого спеца, который Вам сможет технадзор организовать. С постройкой каркасников беда - их умеют ПРАВИЛЬНО строить полторы компании во всей России и ценник на правильно построенный каркасник не сильно меньше газоблока.
PS: Сам прошёл через стройку
"их умеют ПРАВИЛЬНО строить полторы компании во всей России" - вот это полностью в точку. У нас был такой спец, но он вышел на пенсию и сам не взялся полностью строить дом, да и бригаду уже распустил. Именно под его "технадзором" всё и делалось. И именно благодаря ему нас пронесло иметь дело с фирмами, потому что он довольно быстро на "тех интервью" со строителями показывал, что большинство нормально энергоэффективные каркасные дома (как строят фины) у нас строить не умеют)
P.S. не все на саморезах конечно, в основании гвозди, мой пример про обшивку.
Большая часть частного сектора строится вообще не фирмами. Начнём с этого. И затягивается вовсе не от того, что что-то отваливается по дороге, а потому что нет нормального хоть какого-то проекта и потому нет сметы. А без сметы люди не могут соотнести цену стройки и свои возможности.
Я понятия не имею, что такое терем, но зато прекрасно знаю, что в частном домостроении то, что вы отдали больше денег вовсе не значит, что вам сделали лучше. Это значит только то, что вам сделали дороже.
То, что у вас сотни тысяч ушли на саморезы, это конечно хорошо (для производителей саморезов), но гвозди при равных параметрах прочнее и долговечнее. При этом за параметр сравнения можете хоть цену килограмма брать, хоть диаметр метиза. Но работать гвоздями сложнее, чем саморезами.
я сужу по поселку, в котором поселился. Он новый, за время моего проживания тут выросло порядка 10 домой и все кроме моего строили через фирмы. Возможно по России статистика будет отличаться относительно Подмосковья))
Но печально в строительстве другое, даже у нас в поселке стоят несколько недостроев. Потому что замахнулись на дом, даже имея смету и проект, но на той или иной стадии проекта видимо что-то у них пошло не так, может деньги кончились или переехали, но в итоге стоит каркас (или коробка из блоков), в котором и жить нельзя и достраивать его через время будет бессмысленно. Т.е. люди проинвестировали, но продукт не получили.
Это та тема, которую я хотел подсветить. Люди идут в строительство по водопаду, и не дожидаются результата. Тоже самое с тысячами ИТ проектов, которые я вижу. Пытаются сразу всё предусмотреть, смету, проект посчитать, начинают с основания и не дотягивают до продукта, которым можно пользоваться. Потому что какой бы детальный не был проект или смета, непредвиденные риски всё равно возникнут. Только в agile ты допускаешь риски и работаешь с ними, а в водопаде риски убивают проект целиком.
"вы отдали больше денег вовсе не значит, что вам сделали лучше" - читается как, если вы купили немецкий премиум автомобиль, совершенно не значит что он лучше отечественного :) Что наверное имеет место быть в некоторых ситуациях...
Новые ЖК или посëлки сдаются, зачастую, без части инфры. Даже без действующих коммуникаций. Это полностью соответствует и идее Agile, и старой поговорке: Москва не сразу строилась.
С огромной долей вероятности, при водопадном процессе у вас не будет даже ведра. Кусты - за сараем.
Плюс, не факт, что вам подведут канализацию в срок, или что она будет рабочая. Если она не будет работать, вы сможете дождаться, пока все трубы вынут из земли и поменяют. Разумеется, после согласования новой проектной документации с правками. У нас к тому времени будет шамбо.
При водопаде дом, как и положено, начинают строить с коммуникаций, потом фундамент, потом несущие стены, потом потолок, крыша, утепление, облицовка.
Дом при водопаде - это, конечно, романтично, но, я полагаю, вы сильно упрощаете процесс. Насколько мне известно, малоэтажное частное строительство редко делается одним заходом. Недостроенные дома могут проходить через итерации строительства годами.
Аджайл ставит во главу угла функционал, но людям не нужен функционал, им нужен продукт ЦЕЛИКОМ.
Вам бы сначала матчасть подтянуть. Плюс, вы явно не понимаете, о чëм мы здесь говорим, поскольку со строительства и деталей процесса вы слишком резко прыгаете к функционалу программного продукта. Возможно, у вас какие-то трудности с пониманием метафор.
Что до продукта целиком, то я лично не встречал ПО, которое не требовало бы обновлений или исправлений. Обновляется всë: веб-сайты, софт на смартфоне, прошивки микроконтроллера. И вывод из этого факта прост: не существует готового ПО, которое не просило бы обслуживания или обновления. С крайне редкими исключениями, конечно, но они, скорее подтверждают правило, поскольку это устаревшее ПО, которое больше не обслуживается. А раз не бывает не обслуживаемого ПО, значит адепты-водопадники просто-напросто обманывают своих клиентов и лгут им, что достаточно просто спроектировать ТЗ и создать программу, которая будет представлять собой готовый продукт.
Программирование - это научный процесс, основной артефакт которого - услуги по автоматизации. Нет никакого готового продукта в программировании. Есть бесконечный процесс автоматизации. И водопадный процесс - рудимент, который в свою время сыграл такую же роль, как, например, оператор Goto для протоструктурирования. Сейчас водопадка - это инструмент тех, кто не понимает организацию процесса разработки. Чтобы утешать себя тем, что их процесс хоть как-то организован.
Сотни тысяч ушли на одни саморезы, в то время как в обычной фирме вам обшивать дом будут гвоздями, которые сгниют и отвалятся.
В СП 31-105 чётко указано соединение частей несущего каркаса производится с помощью гвоздей.
отличная статья! спасибо!
очень нравится стиль - это куда интереснее и познавательнее чем сухие доки
Waterfall - это утопия. Ни один программный продукт не застрахован от изменений. Изменения предполагают эволюцию. Эволюция определяется мутациями и нормой реакции. Agile - это практика эволюционной разработки и эволюционного проектирования. Чем раньше компания перейдëт на Agile, тем больше у неë шансов остаться на рынке в ближайшем будущем.
Agile - это как вкладываться в себя. Долгосрочная инвестиция в архитектуру. Приятие изменений. Думаю, ватерфоллу осталось немного времени.
А кто, простите, когда-то говорил, что waterfall предполагает на 100 процентов точное исполнение неизменного плана?
Waterfall план меняется на ура.
Ссылочку на ГОСТ или раздел PMI PMBoK, который подтверждает, что внесение изменений в проект в процессе реализации не влечёт за собой остановку разработки, предоставьте, пожалуйста.
Так. Мне кажется, мы друг друга не поняли.
Что вы подразумеваете под остановкой разработки?
Есть большой проект с поставкой технологического оборудования, у вас за полгода до самой поставки приходит информация, что срок переносится на 3 месяца позже.
По-вашему, Watrefall план останется неизменным?
Какие-то блоки могут пойти вперёд, какие-то запустятся позже, где-то съедят резервы по времени, где-то возникнет промежуточный кранч, чтобы не опоздать со сроком сдачи объекта.
Нет? По Waterfall всё останется неизменно?
Не могли бы вы вернуться к вопросу ГОСТов, ISO или PMI PMBoK? Поскольку, мы должны оперировать стандартами, описывающими каскадный процесс, а не личным пониманием технических специалистов. Когда я говорю про Agile, я могу сослаться на его Манифест, где совершенно точно и ясно сказано, что продукт имеет приоритет над документацией, но нигде не сказано, что разработка Agile обязана начинаться до формализации требований. А чем, простите, оперируете вы, говоря о водопадном процессе? Почему вы думаете, что вы говорите именно о нëм? А не, например, о смешанном процессе, или о спирали? Или, например, об инкрементальном процессе?
У Эрика Дж Брауде водопадный процесс вообще описывается, как практически не применяемый (только как часть других процессов). Так почему вы решили, что говорите о ватерфолле?
Классический вариант:
построить все внутренние стены (5 шт.),
установить все розетки (20 шт.),
поставить двери (4 шт.),
пользоваться домом.
Если под "построить внутренние стены" имеется в виду также сделать внутреннюю обшивку - гипсокартоном, или, как в вашем случае, вагонкой, то электричество надо запланировать и разводить раньше, на этапе металлопрофиля или маяков.
Внутри вагонку ничем не красили и не обрабатывали
Вот это очень зря. Со временем необработанное дерево сереет и теряет цвет. А если на него попадёт что-то красящее, то оно впитается в вагонку и уже ничем не ототрётся, даже не сошлифовать.
Что то мне подсказывает, что вклад стороннего консультанта, который уже к началу строительства был более чем сеньор и величайшим опытом, очень сильно не раскрыт в этой статье. По простому без того родственника у них бы не получилось лучше чем от застройщика. А ещё в этой статье не учитывается локальные требования контролирующих органов, не везде вот так вот можно взять и просто построить дом как хочешь без всяких там проверок. В моих пинатах даже плитка/гидроизоляция в душевой должна получить одобрение чиновника. А каждый вызов этого чинуши дело не дешёвое и ещё стой в очереди. Поэтому водопад внезапно становится существенно дешевле т.к. число таких проверок минимизировано и самое главное типовое строительство позволяет также свести к 0 вероятность косяка который чинуша потребует исправить и пройти новую проверку.
Я вам больше скажу, вот это вот - материалы у нас были лучше, даже вот смотрите саморезы там где все гвозди суют это на самом деле офигенный риск, вот этот якобы здоровый лес может быть не обработан от насекомых(наверное в России это не важно) и тогда привет весь каркас в топку - буквально, а вы уже в рамках мвп и на кухню и сан узел и ещё что-то потратились. А там где все используют гвозди вместо саморезов может оказаться требованием чинуши. И вот если у вас нет такого консультанта как у этих ребят то аджайл вас может буквально разорить.
В России частный дом не надо сдавать чинушам
Я вам как пользователь дома который принимали по правилам скажу (как раз каркасник) - хочешь что бы было нормально строй ну или хотя бы проверяй сам имеется ввиду плати деньги проверенному спецу с репутацией за проверку. Чинуши проверяют не дальше чем в требованиях, а требования скажем так сильно не поспевают вашим ожиданиям ну и само собой вы все равно за эту проверку как покупатель заплатите, только когда проверяет чиновник у вас нет выбора и нет конкуренции и поэтому цены там мама дорогая. Мне больше импонирует схема на подобии обязательной страховки/ТО, т.е. проверить надо но только что бы я сам как покупатель мог выбрать кто и что проверяет. Мне в ипотеку все равно дом страховать вот пусть страховая и проверяет и от результата проверки зависит цена страховки - застройщики сразу начнут как то учитывать что их косяки влияют на продажи из за высоких цен на страховку, а страховой не выгодно ни придираться ни игнорировать ибо это либо меньше клиентов либо большие расходы по страховым случаям.
"был более чем сеньор и величайшим опытом, очень сильно не раскрыт в этой статье." - пожалуй да, надо было подробнее сделать акцент. Без него мы бы даже не взялись за эту историю) Слишком много экспертизы и знания мелочей требуется для такого продукта...
Не совсем. Вы описали дом, который строит водопадная бригада, услышавшая слово Agile.
Дом по Agile - это когда ставится временное жильë. Потом, начинается строительство. Если оно затягивается, или выявляются проблемы на разных его этапах, вы можете купить себе квартиру, поскольку не платили за полную реализацию строительства. Можете заморозить строительство. Можете вообще отказаться от него и продать участок с недостроенным домом.
Насколько я знаю, малоэтажное частное строительство всегда производится поэтапно. Иными словами, процесс напоминает Agile.
А вот когда работает застройщик, процесс уже ближе к ватерфоллу, и то, не во всëм. В определëнную документацию вносятся изменения. Например, копали - нашли трубу. Пришлось перекладывать еë. Или, вдруг, выяснилось, что соседний колодец не может обеспечить водоотведение ещë одного дома - нужно перекапывать соседнюю улицу и менять трубы. Подорожал металл марки, используемой под швеллеры - пришлось брать металл с другими свойствами. Но, в целом, да, продукт соответствует изначальному проекту. Только вот его строительство, скорее, включало множество этапов изменений, доработок. Поэтому, трудно сказать, что водопадный процесс, в принципе, применим в реальной жизни. Нельзя учесть всë. Начать проект важнее, чем проработать его детали. Плюс, в том же многоэтажном строительстве планировка, скорее-всего, обкатывается в экспериментальном жилье прежде, чем застройщик начнëт строить дом на 500 квартир этой планировки и 600 - другой. Ну а этапы строительства - это вообще почти Scrum. Инженер объявил о начале работ с эпиком (этап строительства). Прораб взял план работ из бэк-лога на ближайший спринт. Таджики дали краткосрочные оценки реализации и приступили к работе. Только ретроспектива не проводится.
Под чистый ватерфолл я бы описал конвейер. Он не меняет свой алгоритм работы на разных этапах производства. Что-то мне подсказывает, что и ватерфолл локализовали в парадигму, думая о конвейере, а не о строительстве. Потому, что Agile - это не тогда, когда мы отказываемся от документации. Если внимательно прочитать манифест Agile, то можно выяснить, что продукт дороже документации, но никто не запрещает сначала делать документацию. Соответственно, Agile не предполагает, что нужно постоянно общаться с заказчиком ради выяснения требований. Или, что нужно сделать продукт, который в деталях соответствует документации. Agile - это, скорее, о двух вещах: вы начинаете работу по возможности, до финального согласования, и вы можете менять приоритет работы, если сталкиваетесь с проблемами. Также, важна ретроспектива на каждом этапе, который вызвал проблемы. Например, выяснилось, что вы не можете сделать водоотведение, не перекопав улицу. В этом плане, ватерфолл предлагает полностью остановить процесс и пересмотреть его, если появились отклонения. Что в реальной жизни соответствует конвейеру, а не стройке. Отсюда можно сделать вывод о том, что ватерфолл актуален на маленьких временных отрезках. Например, пока производится партия майонеза, или партия автомобилей. Но совершенно не подходит для более долгосрочных проектов, реализацию которых нельзя полностью автоматизировать или предсказать краткосрочные изменения.
Вот собственно здесь изначально видна основная ошибка которой оправдывают отказ от водопада, а именно, почему то перед началом проектирования не проводится обследование территории и выработка технических условий для реализации данного проекта. А потом удивляются почему вдруг на пути канализации оказался кабель на 10 киловольт и там по идее не то что строить чего то нельзя, да там просто плюнуть на землю чревато потерей здоровья.
В книге Кристофера Александера (той самой, с которой начались шаблоны проектирования в программировании) про шаблоны проектирования в строительстве он говорит, что дом должен жить - достраиваться и перестраиваться в соответствии с меняющимися потребностями хозяев. Тоже можно притянуть в качестве Agile.
Кажется, вот отличный рассказ про эджайла и строительство.
Ценность проделанного анализа
Вы подняли очень интересную тему сравнения строительства и программирования. Действительно, между этими двумя областями можно провести немало параллелей и аналогий.
Проектирование и архитектура: В строительстве проектирование здания аналогично проектированию архитектуры программного обеспечения. В обоих случаях необходимо продумать структуру, компоненты, их взаимодействие и обеспечить соответствие требованиям и ограничениям.
Строительные нормы и стандарты кодирования: Строительные нормы и правила (СНиПы) можно сравнить со стандартами и best practices в программировании. Они обеспечивают качество, безопасность и соответствие отраслевым требованиям.
Строительные материалы и технологии: Выбор строительных материалов и технологий аналогичен выбору языков программирования, фреймворков и библиотек. От правильного выбора зависит эффективность, надежность и возможность дальнейшего развития проекта.
Строительный опыт и программный продукт: Накопленный опыт строительства, знания и навыки специалистов можно сравнить с созданием программного продукта. В обоих случаях важны экспертиза, умение решать проблемы и способность создавать качественный результат.
Итеративность и гибкость: Применение Agile в строительстве, описанное в статье, подчеркивает сходство с итеративной разработкой ПО. Возможность вносить изменения, реагировать на меняющиеся требования и постоянно улучшать процесс актуальны для обеих областей.
Коммуникация и командная работа: Успех строительного проекта, как и разработки ПО, во многом зависит от эффективной коммуникации и слаженной работы команды. Умение сотрудничать, обмениваться информацией и решать проблемы сообща является ключевым фактором успеха.
Безусловно, между строительством и программированием есть и существенные различия, такие как материальность результата, масштабы проектов, нормативные требования и др. Однако, на концептуальном уровне, многие принципы и подходы оказываются схожими.
Статья, на мой взгляд, поднимает интересную тему возможности переноса гибких методологий разработки ПО в другие сферы, такие как строительство. Хотя выводы автора требуют дополнительного обоснования и исследований, сама идея заслуживает внимания и может стимулировать поиск новых подходов к управлению сложными проектами в различных областях.
Если проводить аналоги строительство- программирование, то все ли автор сделал эффективно даже с точки зрения программирования?
Если рассматривать действия автора с точки зрения аналогии между строительством и программированием, можно отметить несколько моментов, которые вызывают вопросы относительно эффективности его подхода:
Недостаточное планирование: В статье не упоминается о тщательном планировании проекта, что является ключевым аспектом как в строительстве, так и в разработке ПО. Отсутствие четкого плана и архитектуры может привести к хаотичности, переработкам и проблемам в долгосрочной перспективе.
Чрезмерная гибкость: Хотя гибкость и возможность вносить изменения важны, чрезмерная гибкость может привести к потере контроля над проектом. В программировании это может выражаться в постоянном изменении требований без учета последствий для архитектуры и кода.
Недостаточное тестирование: В статье не упоминается о проверке качества работ или тестировании "строительного продукта". В программировании тестирование является неотъемлемой частью процесса разработки для обеспечения качества и надежности продукта.
Отсутствие документации: Нет информации о документировании процесса строительства, решений и изменений. В программировании документация кода, архитектуры и решений важна для поддержки, развития и передачи знаний.
Недостаточное внимание к рискам: Автор не упоминает о управлении рисками, которые неизбежны в любом сложном проекте. В программировании управление рисками помогает предвидеть и смягчать потенциальные проблемы.
Отсутствие метрик и измерений: В статье не приводятся количественные показатели эффективности применения Agile в строительстве. В программировании метрики помогают оценить прогресс, качество и эффективность процесса разработки.
Конечно, эти замечания основаны на ограниченной информации, представленной в статье, и автор мог учитывать эти аспекты, но не упомянул о них явно. Тем не менее, с точки зрения аналогии с программированием, описанный подход может быть улучшен за счет более тщательного планирования, управления рисками, обеспечения качества, документирования и измерения результатов.
Эффективное применение гибких методологий, как в программировании, так и в строительстве, требует баланса между гибкостью и дисциплиной, итеративностью и стратегическим планированием, скоростью и качеством. Поиск этого баланса и адаптация практик под конкретный проект являются ключевыми факторами успеха.
Agile, Waterfall или классической системы строительства???
Agile
Итеративный и инкрементальный подход
Короткая продолжительность спринтов (обычно 2-4 недели)
Гибкость и адаптивность к изменениям
Высокий уровень вовлеченности заказчика
Waterfall
Последовательный подход
Четкие фазы (сбор исходных данных, проектирование, строительство и т. д.)
Меньшая гибкость и адаптивность к изменениям
Меньший уровень вовлеченности заказчика
Классическая система строительства
Похожа на Waterfall, но с более детальным планированием и контролем
Длительные фазы проектирования и строительства
Низкая гибкость и адаптивность к изменениям
Лучший подход при прочих равных условиях
Если владелец проекта одинаково эффективно владеет всеми тремя техниками, то при прочих равных условиях (ресурсах и времени) Agile, скорее всего, даст лучший результат.
Причины:
Гибкость и адаптивность: Agile позволяет быстро реагировать на изменения в требованиях или условиях проекта, что может привести к экономии времени и ресурсов.
Ранняя обратная связь: Итеративный характер Agile обеспечивает раннюю обратную связь от заказчика, что позволяет вносить коррективы на ранних этапах проекта.
Более высокое качество: Постоянное тестирование и интеграция в Agile помогают выявлять и устранять проблемы на ранних этапах, что приводит к более высокому качеству конечного продукта.
Однако следует учитывать следующие факторы:
Размер и сложность проекта: Для небольших и несложных проектов Waterfall или классическая система строительства могут быть более подходящими из-за их более предсказуемого характера.
Уровень вовлеченности заказчика: Agile требует высокого уровня вовлеченности заказчика на протяжении всего проекта. Если заказчик не может или не хочет активно участвовать, Agile может быть не лучшим выбором.
Опытная команда: Успешное внедрение Agile требует опытной команды, которая хорошо разбирается в методологии и может работать в быстро меняющейся среде.
В целом, Agile является более гибким и адаптивным подходом, который может привести к лучшим результатам, особенно для проектов с высокой степенью неопределенности или частыми изменениями. Однако важно учитывать конкретные обстоятельства проекта и опыт команды перед выбором методологии.
Сравнение Agile, Waterfall и классической системы строительства
Agile
Итеративный и инкрементальный подход
Короткая продолжительность спринтов (обычно 2-4 недели)
Гибкость и адаптивность к изменениям
Высокий уровень вовлеченности заказчика
Waterfall
Последовательный подход
Четкие фазы (сбор исходных данных, проектирование, строительство и т. д.)
Меньшая гибкость и адаптивность к изменениям
Меньший уровень вовлеченности заказчика
Классическая система строительства
Похожа на Waterfall, но с более детальным планированием и контролем
Длительные фазы проектирования и строительства
Низкая гибкость и адаптивность к изменениям
Лучший подход при прочих равных условиях
Если владелец проекта одинаково эффективно владеет всеми тремя техниками, то при прочих равных условиях (ресурсах и времени) Agile, скорее всего, даст лучший результат.
Причины:
Гибкость и адаптивность: Agile позволяет быстро реагировать на изменения в требованиях или условиях проекта, что может привести к экономии времени и ресурсов.
Ранняя обратная связь: Итеративный характер Agile обеспечивает раннюю обратную связь от заказчика, что позволяет вносить коррективы на ранних этапах проекта.
Более высокое качество: Постоянное тестирование и интеграция в Agile помогают выявлять и устранять проблемы на ранних этапах, что приводит к более высокому качеству конечного продукта.
Однако следует учитывать следующие факторы:
Размер и сложность проекта: Для небольших и несложных проектов Waterfall или классическая система строительства могут быть более подходящими из-за их более предсказуемого характера.
Уровень вовлеченности заказчика: Agile требует высокого уровня вовлеченности заказчика на протяжении всего проекта. Если заказчик не может или не хочет активно участвовать, Agile может быть не лучшим выбором.
Опытная команда: Успешное внедрение Agile требует опытной команды, которая хорошо разбирается в методологии и может работать в быстро меняющейся среде.
Что думаете Вы?
Как построить дом по Agile. Пример успешного применения гибкой методологии для самого классического Waterfall-проекта