Comments 21
Я не совсем разобрался, за счет чего осуществляется fail-safe управление разработкой? Или это таки рекламный трюк?
Мне что-то слабо верится в очередной silver bullet. Как была измерена и оценена эффективность метода?
Мне что-то слабо верится в очередной silver bullet. Как была измерена и оценена эффективность метода?
Подразумевается, что фейлов быть не может принципиально.
Говоря образно, методология признает, что вся разработка — это бег с завязанными глазами по краю пропасти. У всех и всегда. Пока все остальные бегут на время, эволюция требует встать на четвереньки и долго руками ощупывать каждый шаг.
Да, и первым прийти в таком случае тоже возможно — если стать единственным выжившим.
Говоря образно, методология признает, что вся разработка — это бег с завязанными глазами по краю пропасти. У всех и всегда. Пока все остальные бегут на время, эволюция требует встать на четвереньки и долго руками ощупывать каждый шаг.
Да, и первым прийти в таком случае тоже возможно — если стать единственным выжившим.
Позвольте, т.е. фейла не может быть, т.к. не бывает фейла что-ли? Сомнительное, с точки зрения бизнеса, утверждение.
Бежать на время, не прихоть, а необходимость!
Бежать на время, не прихоть, а необходимость!
Успешный результат разве не важнее времени? Вырастить ребенка за год тоже может быть жизненно важно, иной раз даже критично — но дети растут 18 лет.
Эволюция учится у природы, а не ломает ее своими сказочными требованиями.
Эволюция учится у природы, а не ломает ее своими сказочными требованиями.
А тут бывает по-разному. Бывают задачи, когда соблюдение сроков/требований по ресурсам важнее реализации того или иного функционала.
далеко не всегда
у проекта часто есть время жизни
если время жизни проекта 2 года, а выращивать его до результата 4 — то мы просто продолбаем 2 года и выкинем результат.
у проекта часто есть время жизни
если время жизни проекта 2 года, а выращивать его до результата 4 — то мы просто продолбаем 2 года и выкинем результат.
Вообщем, у меня мнение противоречивое. Во первых, я не увидел самой методологии, просто список довольно очевидных советов (спасибо, кэп!). Тема всеобщей применимости (как и о моральной смерти каскада-водопада) не раскрыта. Существуют краткосрочные проекты, где agile подходы (а evo — очень даже agile) только вредят, а каскад в жилу (пришел, решил, увидел, запилил).
В целом, утверждение, что есть подход, работающий везде 100%, звучит так же сомнительно, как существование автомобиля, подходящего для скоростной езды по автобану и пересеченной местности, преодоления водных и воздушных препятствий, перевозки грузов и комфортного путешествия семьей из 17 человек.
В целом, утверждение, что есть подход, работающий везде 100%, звучит так же сомнительно, как существование автомобиля, подходящего для скоростной езды по автобану и пересеченной местности, преодоления водных и воздушных препятствий, перевозки грузов и комфортного путешествия семьей из 17 человек.
Не провалить сроки – да как такое может быть?
Ответ на вопрос — «никак», просто не задавайте их? Это не про бизнес явно.
Как все-таки хорошо, что Мегамозг отделили от Хабра. Теперь вся маркетинговая шелуха накапливается здесь.
Маркетинговая шелуха — это когда компании или представители компаний в красивых картинках расписывают как запилили/провалили какой-нибудь космический продукт. А когда человек пытается разобраться с темой, собственными стараниями как может, и знакомит с подходами других — это ценная информация.
И да, хорошо что Мегамозг отделили от Хабра. Теперь в хабе управление проектами стало побольше по управлению проектами, и поменьше всякого промоушена. Хотя до сих пор половина постов в хабе появляется только потому что хаб самый читаемый, а не потому что они имеют к управлению проектами какое-то отношение.
И да, хорошо что Мегамозг отделили от Хабра. Теперь в хабе управление проектами стало побольше по управлению проектами, и поменьше всякого промоушена. Хотя до сих пор половина постов в хабе появляется только потому что хаб самый читаемый, а не потому что они имеют к управлению проектами какое-то отношение.
Всем спасибо за минусы. Если это единственное, что специалисты смогли добавить по существу темы — я очень рад.
По существу темы — эволюционная разработка — не новость. Еще в компьютерре как-то статья была. Органическое программирование так называемое. Может эта концепция даст вам направление мысли.
Еще очень все напоминает «дробление проектов», подход который можно почерпнуть в книге Мак-Фарлана и Бенко про управление портфелем проектов. Онлайн эту книгу не найти, но про этот подход я немного писал в одном из своих постов. Если кратко — проект дробится на ломти, каждый из которых приносит позитивный результат.
Еще очень все напоминает «дробление проектов», подход который можно почерпнуть в книге Мак-Фарлана и Бенко про управление портфелем проектов. Онлайн эту книгу не найти, но про этот подход я немного писал в одном из своих постов. Если кратко — проект дробится на ломти, каждый из которых приносит позитивный результат.
UFO just landed and posted this here
Главное не уйти в тупиковую ветвь эволюции )
Как я понял — вы имеете непосредственное отношение именно к веб-разработке и пишите статьи применительно к этой сфере деятельности.
Вы уверены что это утверждение может быть применимо к серьезным проектам состоящим не только из статических страниц?
Сложные проекты предполагают сложные платформы/инструменты для своей реализации, там за 5-10 минут что-то разумное сделать просто не получится.
Даже самая простая задача предполагает такие шаги:
1. Описание задачи, ее регистрация в системе управления проектом (СУП) и доведение задачи до исполнителя.
2. Исполнитель вносит изменения в код, делает предварительное тестирование и вносит изменения кода в систему контроля версий (СКВ), «выкатывает» код на тестовый сервер, делает пометки в СУП по задаче, передает задачу тестировщику.
3. Тестировщик делает более детальное тестирование, и если все получилось с первого раза — отмечает задачу как проверенную в СУП и возвращает ее постановщику.
4. Постановщик производит окончательные регламентные работы в СУП по закрытию задачи.
Даже если постановщик задачи, исполнитель и проверяющий — одно лицо, то все равно эти шаги займут несколько больше чем 10 минут.
Или Evo предполагает отказаться от использования СУП, СКВ, сложных фреймворков/платформ, других инструментов, регламентов и работать по принципу «x… к, x… к и в продакшн»? Ну или я вас неправильно понял?
Вы уверены что это утверждение может быть применимо к серьезным проектам состоящим не только из статических страниц?
любой раздел, блок, пункт, страница должна иметь возможность полного исправления за 5-10 минут без перекройки всей платформыДаже незначительное изменение например формы ввода или другого взаимодействия с пользователем может повлечь серьезные изменения в программном коде как на фронте так и в серверной части. Изменение дизайна какого-либо повторяющегося на других страницах блока или элемента только на одной странице тоже как правило не возможно, т.к. влечет за собой изменения и на тех других страницах — и все это надо проверить-протестировать.
Сложные проекты предполагают сложные платформы/инструменты для своей реализации, там за 5-10 минут что-то разумное сделать просто не получится.
Даже самая простая задача предполагает такие шаги:
1. Описание задачи, ее регистрация в системе управления проектом (СУП) и доведение задачи до исполнителя.
2. Исполнитель вносит изменения в код, делает предварительное тестирование и вносит изменения кода в систему контроля версий (СКВ), «выкатывает» код на тестовый сервер, делает пометки в СУП по задаче, передает задачу тестировщику.
3. Тестировщик делает более детальное тестирование, и если все получилось с первого раза — отмечает задачу как проверенную в СУП и возвращает ее постановщику.
4. Постановщик производит окончательные регламентные работы в СУП по закрытию задачи.
Даже если постановщик задачи, исполнитель и проверяющий — одно лицо, то все равно эти шаги займут несколько больше чем 10 минут.
Или Evo предполагает отказаться от использования СУП, СКВ, сложных фреймворков/платформ, других инструментов, регламентов и работать по принципу «x… к, x… к и в продакшн»? Ну или я вас неправильно понял?
Пусть и с некоторым опозданием, но хочется добавить позитива в эту ветку обсуждения.
К сожалению, мне этот пост попался на глаза только сейчас. Полгода назад, когда всё только начиналось, я не знал слов «Эволюционное управление» и действовал скорее интуитивно. Однако, модель управления, которая в итоге получилась, очень напоминает, то что описано в статье.
Такая модель — точно не серебряная пуля. Типовые проекты делаются по другому. Если вы точно знаете что хотите получить и влияние неопределённости на ваши планы минимально — все эти танцы неуместны.
Совсем другая картина — когда ни вы, ни ваши заказчики точно не знаете что должно получиться в итоге, и имеете душевные силы признаться в этом себе и друг другу. Вот тут начинает в полный рост влиять используемый способ уменьшения неопределённостей. Я пришел к эволюционной идее после книг Талеба, он тоже рассказывает про «постепенное прилаживание», я адаптировал его идеи на программный код и управление требованиями.
К сожалению, мне этот пост попался на глаза только сейчас. Полгода назад, когда всё только начиналось, я не знал слов «Эволюционное управление» и действовал скорее интуитивно. Однако, модель управления, которая в итоге получилась, очень напоминает, то что описано в статье.
Такая модель — точно не серебряная пуля. Типовые проекты делаются по другому. Если вы точно знаете что хотите получить и влияние неопределённости на ваши планы минимально — все эти танцы неуместны.
Совсем другая картина — когда ни вы, ни ваши заказчики точно не знаете что должно получиться в итоге, и имеете душевные силы признаться в этом себе и друг другу. Вот тут начинает в полный рост влиять используемый способ уменьшения неопределённостей. Я пришел к эволюционной идее после книг Талеба, он тоже рассказывает про «постепенное прилаживание», я адаптировал его идеи на программный код и управление требованиями.
Sign up to leave a comment.
Эволюционное управление разработкой — гарантированный путь к успеху