|
О вреде Agile
|
|||
---|---|---|---|
#18+
(См. также https://zen.yandex.ru/media/id/5dca6a6713aa6c3a6247ec12/o-vrede-agile-5de7c283fbe6e700b04a7103) В последние годы много говориться о революции в управлении разработкой ИТ Систем на основе Agile методологий. Считается, что причастность той или иной методологии к Agile определяется соответствием основным принципам Agile, изложенным в манифесте (12 пунктов, см. https://ru.wikipedia.org/wiki/Agile_Manifesto). Изложенные принципы слишком общи и подходят, в принципе, к любым методологиям разработки информационных систем, даже к тем, с которыми часто борются приверженцы Agile. Вскоре после публикации манифеста Agile начали появляться методологии, претендующие на Agile. К примеру, новая/старая XP (Extreme Programming), Scrum и Kanban «всплыли» из далекого прошлого. Почему-то, появившееся методологии приверженцами и апологетами начали часто называть проектными. Наверное «проект» – модное и распространенное слово, огромное поле деятельности для различных методологий, которые необходимо «занять». Термин Agile стал модным, приверженность Agile стало правилом «хорошего» тона. О необходимости использования Agile методик заговорили на «высоком» государственном уровне (правда не ИТ специалисты). Если исходить из определения проекта – уникальный продукт на выходе, ограниченность по времени, ресурсам ( https://ru.wikipedia.org/wiki/Проект_(в_управленческой_деятельности)). Появившиеся методологии как правило не говорят ничего определенного об уникальном продукте на выходе, кроме того, что понимание продукта будет формироваться в процессе разработки и периодических демонстраций Заказчику. По поводу ресурсов – ничего определенного. В процессе разработки будем уточнять. По поводу временных ресурсов – никаких временных рамок. Все это означает что методологии по любым определениям понятия «проект» не являются проектными. Заказчика по проектам (если это не «свои» люди) это касается очень существенно. Заказчик хочет иметь не отдаленное представление по следующим вопросам: • Что он получит? • Когда он это получит? • Сколько это будет стоить? При серьезном подходе Заказчик, разумеется, «отметет» подобного рода Agile технологии. Если Extreme Programming предполагает непрерывную разработку и непрерывное неформальное взаимодействие программистов (2х) с Заказчиком (включая демонстрации, тестирование), то Scrum и Kanban предполагают частые итерации, в которых участвует условный заказчик (Product Owner – может бизнес аналитик, может системный аналитик, может архитектор, может проектировщик, …) и разработчики (как правило программисты). Количество итераций не оценивается, в каком порядке будут имплементироваться требования заказчика (BackLog), как быть с общесистемными требованиями (способность расширению возможностей систем, развитию программной и аппаратной составляющей, сопровождаемость, масштабируемость, устойчивость к сбоям, обеспечение непрерывности бизнеса, …) – остается в «воздухе». К проектным методологиям можно отнести масштабируемый Scrum-Kanban – методология SAFe ( https://habr.com/ru/post/433934/). Отношусь к этой методологии симпатией, но необходимо учесть следующие особенности: • Методология не получила широкого распространения; • Методология ничем не отличается от типовых проектных методологий, относящихся апологетами Agile к не Agile методологиям. Основа большинства Agile методологий – итеративная разработка (если не считать пример с Extreme Programming с практически непрерывными итерациями). Обычно Agile лекторы (коучеры – новое «крутое» слово) начинают с того, что все прежние проектные методологии устарели так как основываются на водопадной модели: без итераций и предоставления заказчику промежуточных версий, с последовательными этапами – бизнес анализ, анализ требований, архитектура, дизайн, программирование, тестирование, развертывание, внедрение. На вопрос – какие методологии Вы имеете в виду – ответа нет. Знания в области технологических процессов ИТ у коучеров (по крайней мере у тех которых встречал) очень неглубокие – в основном только то что преподают. Даже если сделать краткий обзор предшествующих методологий (например, https://habr.com/ru/post/244003/), то получается, что все они были итеративными, предполагали демонстрацию промежуточных версий систем Заказчику, внесение корректив в дальнейшие планы по проекту. В чистом виде «водопадных» фактически не было. В отличии от типовых Agile, они, как правило, охватывают все процессы (области знаний) связанные с разработкой программно-аппаратных систем, начиная с управления проектами, включая бизнес и системный анализ, архитектуру, дизайн, программирование, тестирование, развертывание, внедрение, управление конфигурацией и изменениями, …. Примеры методик: • публикация доктора Уинстона У. Ройса «Managing the development of large software systems» 1970г. (управление разработкой крупных программных приложений) – часто называют основой «водопадной» модели, но в доработанной им же версии методология приобрела черты итерационой. • Rapid Application Development (1991г) – итерационная методология. • MSF начало 1993 (Microsoft Solution Framework) - итерационная методология • Dynamic Systems Development Method (1994) - итерационная методология. • Oracle CDM/PJM (1990е) • RUP 2001 (Rational Unified Process, IBM) - итерационная методология. • PRINCE2 (PRojects IN Controlled Environments – Стандарт управления проектами в Великобритании с 2013г.) - итерационная методология. • ITIL (библиотека инфраструктуры информационных технологий - 5 томов) – охватывает все аспекты ИТ с ориентацией на сервисный подход к ИТ, в том числе и управлению проектами. Сбором и обобщением информацией об ИТ проектам занимается PMI (Американский институт по изучению вопросов и проблем управления проектами). Это огромное количество публикаций, связанных с управлением проектами. Наиболее известная – PMBOOK (база знаний по управлению проектами), которая периодически обновляется, SEBoK (база знаний по системной инженерии). Что дает нам Agile взамен? Это несколько страниц описания процесса SCRUM или Kanban, или XP (c SAFe сложнее). Но ведь это «здорово». Коучер дает нам понять, что «предки» теперь не нужны. Они накопили огромные знания и опыт как в области управления проектами, так и в других сложных отраслях знаний – бизнес и системный анализ, архитектура, проектирование, программирование, тестирование, развертывание (deployment), …. Догнать их в знаниях и опыте очень трудно и долго. Но есть простое решение – Agile – 3 странички текста, и вы на «вершине». Соблюдайте ежедневные и еже итерационные ритуалы и все будет отлично. Agile – значит «живая» методология – быстрая и эффективная. Автоматически подразумевается, что все остальные просто не нужны. Проблема в том, что знания, в области управления проектами, также как и в других областях ИТ отражают объективные аспекты ИТ. Это значит, что эти ИТ аспекты существуют вне зависимости от того знаем мы их или нет. Так же как законы физики (например, закон сохранения энергии, закон Ома, законы термодинамики, …). Примеры критических аспектов по управлению проектами (PMBOOK, CMM): • Управление рисками; • Управление областью охвата; • Управление временем; • Управление ресурсами; • Управление качеством (см. также CMMI); • Управление коммуникациями; • Управление закупками. Все это критически важные аспекты управления проектами, требующие больших специальных знаний. В Бизнес и системном анализе (BABOOK): • Коммуникация с Заказчиком; • Выявление заинтересованных участников; • Анализ бизнес-потребностей и проблем; • Выявление бизнес требований; • Моделирование бизнес-процессов; • Проектирование системных требований с учетом как функциональных требований, так и нефункциональных требований, архитектурных, нормативных, организационных и других ограничений. • Обеспечение качества системных требований (непротиворечивость, не содержать реализацию, функциональная полнота, проверяемость, …). • Управление требованиями (хранение, версионирование, атрибуты требований, поиск, управление целостностью требований, …); Архитектура (много публикаций и фреймворков, например TOGAF – международный архитектурный стандарт, SEBoK, RUP, …): • Архитектурные шаблоны; • Архитектурные фреймворки и технологии; • Методики проектирования: структурные, объектные, компонентные, аспектные; • Методики максимизации повторного использования компонент; • Моделирование архитектурных представлений; • Архитектурный репозиторий (база данных и управление модельными объектами); • Организация процессов разработки «от архитектуры» (architecture driven development). • Проектирование реализации функциональных и нефункциональных требований – решения по разработке гибких, легко модифицируемых систем, масштабируемых систем (по пользователям и нагрузке), устойчивых к сбоям, обеспечивающих гарантированную непрерывность работы, …. Много по тестированию: • Проектирование тестовых кейсов; • Организация регрессионного тестирования; • Организация многоуровневого процесса тестирования в релизах: модульное-функциональное, интеграционное, системное. Много по развертыванию: • миграция данных, • организация развертывания систем • Установка версий и патчей; • Проведение тестов; • Обработка запросов от Заказчика (дефекты, запросы на изменения) • Обучение • И многое другое Конфигурация и изменения: • Управление изменениями; • Хранение версий и релизов системы; • … Коучеры Agile обычно игнорируют эти аспекты. Мое впечатление – они просто ничего этого не знают. Ничего против предлагаемых Agile методик, в принципе, не вижу. Они просто предлагают решение очень узкого круга задач в рамках типового проектов – организация микро-релизов группами программистов (это максимум 10% всех аспектов разработки систем, скорее существенно меньше). Это типично в следующих случаях: • Сопровождение уже существующих систем – периодическое устранение дефектов и мелкие доработки; • Организация работ групп программистов на различных стадиях проекта по реализации подготовленных на итерации требований и архитектурных решений. Другой аспект Agile методик – это ритуалы. Типичные ритуалы – доски со стикерами, ежедневные собрания, собрания по результатам итераций. Не думаю, что это «гениальные» изобретения. Все комплексные методики предполагают организацию процессов в итерациях. Обычно они дают множество рекомендаций на основе большого опыта проектной деятельности. На основе этого опыта подбираются оптимальные методики проведения итераций с учетом свойств проектов (включая масштаб, критичность, …) внутренней культуры организации, развитостью ИТ (см CMMI). В RUP, например, для этого есть роль Process Engineer. Теперь – мой личный опыт. Существенные проекты, которые реализовывались по Agile методологиям в крупных, значимых организациях – это провал! Основные проблемы: • Быстрое программирование без мало-мальски уточненных, качественных с точки зрения системного и бизнес анализа (как области знаний) приводит к большому объему изменений, как следствие общая продолжительность разработки не сокращается, а увеличивается. Тут важно понимать существенный факт – стоимость разработки требований и архитектуры существенно ниже стоимости разработки. Ошибка в требованиях приводит к существенному увеличению стоимости разработки – это закономерность, аналогичная законам физики. Отсутствие серьезного, методичного отношения к бизнес и системному анализу, архитектуре приводит к удлинению по времени, повышению стоимости разработки, существенному увеличению проектных рисков. • Архитектура в принципе плохо развиваема, не гибка (для большинства изменений необходимы «заплатки»), мало или нет повторно используемых компонент (существенно удорожает разработку), плохо масштабируется, плохо с устойчивостью, непрерывностью бизнес-процессов, плохо с информационной безопасностью. Насмотрелся архитектурных «ужасов» в системах большой государственной важности. • Архитектура систем понятна только разработчикам, причем разным разработчикам по разным аспектам. Низкая взаимозаменяемость. Со временем (причем очень скоро) разработчики сами перестают контролировать архитектуру. Отсюда большие затраты на сопровождение, модификацию, развитие, большие риски сбоев после внесения изменений. В дополнение – мой опыт работы в Германии в компании Telesens AG (Кельн 1999-2000г). Сначала работал программистом в группе (C++ Sun Solaris, Oracle) в проекте по разработке биллинговой системы для Deutche Telecom. Потом назначили руководителем группы программистов. Были распространены 2-а типа команд: • В команде – все программисты, включая руководителя; • В команде – 1-2 проектировщика программных компонент (использовали UML Rational Rose). Как результат в командах с проектировщиками – скорость разработки выше, выше качество (меньше дефектов, гибкость, повторная используемость кода, …), лучше сопровождаемость (есть документация, есть знание программиста и проектировщика). Иногда удивлялись – почему скорость разработки выше, ведь «чистых» программистов меньше? Трудно ответить, наверное это объективный закон, я думаю мы все его знаем – закон Адама Смита – разделение труда (мануфактура в которой работали 10 человек и производили булавки, причем каждый делал булавки целиком, в другой команде работу разбили на 10 отдельных операций, которые выполняло такое же количество людей (каждый только свою операцию), как результат производительность повысилась в разы). Разделение труда, как горизонтальное (разработчики разбиваются по подсистемам), так и вертикальное (специализация – управление проектами, бизнес и системные аналитики, архитекторы, проектировщики, тестировщики, специалисты по развертыванию) обязательно должно привести к росту эффективности ИТ. Важно учесть, что каждая из специализаций требует больших знаний и профессионализма. Полагаться, на то, что «его величество» программист решит все проблемы, на мой взгляд, наивно. Кстати к программистам отношусь очень уважительно. Непрерывно работал программистом более 10 лет (на большинстве распространённых языках программирования, на многих технологических средах), считаю себя таковым и сейчас (как и десантников – программистов «бывших» не бывает). Выводы: выводов Нет. Остается вопрос - Agile – Зачем? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 12:53 |
|
О вреде Agile
|
|||
---|---|---|---|
#18+
Текст большой, но по факту является сборником извращённых представлений о гибкой разработке (agile) сходу замечания: - "коучер" - это не модный, а абсолютно безграмотный термин, а если его переписать, используя привычный термин "коуч", - получим бессмысленное словосочетание - никто не говорит о том, что agile это дёшево. Agile - это нередко дорого, но неизменно направлено на получение на выходе более качественного продукта в более краткие сроки - в крупных компаниях "модное" слово agile нередко используют для того, чтобы запудрить мозги заказчику, у руководителей нет опыта, нет знаний, и в этом случае agile действительно используется для получения быстрых денег, закрытием мифических этапов, а дальше хоть трава не расти Сам по себе подход гибкой разработки имеет место быть, а во многих случаях это единственно правильный подход, ценности манифеста разрабатывались не зря. В конце концов, последние издания книг того же Вигерса, скорректированы с учётом развития подходов гибкой разработки, добавлены соответствующие главы. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2020, 15:35 |
|
О вреде Agile
|
|||
---|---|---|---|
#18+
Дмитрий Морочко Выводы: выводов Нет. Остается вопрос - Agile – Зачем? Дзен головного мозга детектед. Написать какую-то хрень и потом её везде пиарить. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2020, 12:42 |
|
О вреде Agile
|
|||
---|---|---|---|
#18+
Дмитрий Морочко, коллега, то что сейчас называют Аджайлом-лишь один из вариантов разработки ПО. это как инструмент- есть топор, продольная пила , ножовка, и любым из инструментов при желании и упорстве можно сделать какую нить табуретку. проще конечно применяя все три сразу в зависимости от материала поэтому сейчас прожект манагеру и тимм лиду надо знать все ти инструменты, чтобы выбрать нужны(е) в зависимости от задачи, доверия запзчика, имеющейся команды и прочее. про матрицу стейси посмотрите, но там не хватает оси заказчик и в реальном скраме архитектура также прорабатывается, есть архитектурные спайки, есть спринт зеро, управлять рисками можно через бэклог нефункциональных требований и прочее каждой твари есть место под солнцем. в пмбуке четвертом уже был аджайл, только назывался методом набегающей волны, помните? имхо надо не парится а делать с оглядкой на запзчика, при нужном опыте можно и аджайлом назвать а делать ватерфолл, и наоборот. хотят аджайл, ватерфол - по барабану, - важен опыт рук проекта и команда ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2020, 19:10 |
|
О вреде Agile
|
|||
---|---|---|---|
#18+
mma_s важен опыт рук проекта и команда самурай без меча подобен самураю с мечом, но без меча... mma_s хотят аджайл, ватерфол - по барабану, - важен опыт рук проекта и команда если всё "по барабану", нафига козе баян? может просто зарезать барана над жертвенным ноутбуком, в надежде, что проект к утру будет выпущен в продакшен? и кто может "хотеть" аджайл? кому-то захотелось новую погремушку? а если хотят, чтобы на голове стояли и после каждого коммита петухом кричали и били в гонг? ахах... просто жесть. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.03.2020, 04:11 |
|
О вреде Agile
|
|||
---|---|---|---|
#18+
hVostt, важен опыт рук. проекта и команда а методология , как ее выбирать, как ее называть зависит от многих факторов, в т.ч. степени зрелости заказчика, доверия, опыта совместной работы ,его ангажированности по отношению к словам аджайл и ватерфалл, и т д и от задачи/проекта разумеется тоже зависит, матрица Стейси- один из упрощенных примеров такая вот жесть, если это так называется. если для успеха проекта кому то в кач ве плацебо нужно каких то там животных или древние ритуалы- можно это рассмотреть. главное результат, и не всегда РП или владелец продукта может себе позволить роскошь учить окружающих ЛПР Евангелист-тот пусть учит, но это другая история Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 10:08 |
|
О вреде Agile
|
|||
---|---|---|---|
#18+
Дмитрий Морочко, tl;rd. Зачем? А даже если бы осилил, а что конкретно обсуждать? Что аджайл не нужен? Так можно было так и написать. Хотя, вот работа нашей ис зависит от законов РФ и да, у нас аджайл, хотим мы того или нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 10:24 |
|
О вреде Agile
|
|||
---|---|---|---|
#18+
mma_s важен опыт рук. проекта и команда да там куда ни плюнь, всё "важен". mma_s а методология , как ее выбирать, как ее называть зависит от многих факторов куда ни плюнь, от всего "зависит". mma_s если для успеха проекта кому то в кач ве плацебо нужно каких то там животных или древние ритуалы- можно это рассмотреть. главное результат, и не всегда РП или владелец продукта может себе позволить роскошь учить окружающих ЛПР но ведь отсутствие результата -- тоже результат ) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2020, 04:51 |
|
О вреде Agile
|
|||
---|---|---|---|
#18+
имхо, меня ритуалы особо насторожили, со стороны смахивает на секту, а коучи невероятно похожи на тренеров по лидерству и прочей фигне, с горящими глазами, заряженные на маркетинговое проталкивания этого под любым соусом с дальнейшем разочарованием и выгоранием, когда вся эта спесь натыкается на объективную реальность. На счет проектирования, лично мне в 1000 раз проще писать, когда у меня есть перед глазами чёткая архитектура и проект, которому я буду следовать. Это вносит порядок и облегчает процесс разработки, так как на меня ложиться только работа связанная с кодом, я могу сосредоточиться на его качестве. А когда четкого проекта нет, приходится делать какой то скелет, прототипы, в которых обязательно будут какие то недоработки, мытарство от одного к другому, и еще ничего когда размер проекта средний и можно всё это удерживать в голове, а если проект большой то он будет обречён на провал или на боли и страдания. Всегда топил за то, что лучше пусть народу будет меньше, чем нанимать 100500 студентов и говнякать и лепить от балды, предпочту работать в команде на 5 человек (профессионалов), даже если в ней программистом буду я один, но всё будет спроектировано, продумано на этапе аналитики и качественно проверено. Уверен, что в такой команде прогресс будет куда более явным и легко достижимым, чем куча кода накиданная лопатой. Жаль, что по факту, компании стремятся набрать людей по объявлению и заткнуть ими все дыры. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2020, 09:30 |
|
О вреде Agile
|
|||
---|---|---|---|
#18+
Roman Mejtes На счет проектирования, лично мне в 1000 раз проще писать, когда у меня есть перед глазами чёткая архитектура и проект, которому я буду следовать. Это вносит порядок и облегчает процесс разработки, так как на меня ложиться только работа связанная с кодом, я могу сосредоточиться на его качестве. А когда четкого проекта нет, приходится делать какой то скелет, прототипы, в которых обязательно будут какие то недоработки, мытарство от одного к другому, и еще ничего когда размер проекта средний и можно всё это удерживать в голове, а если проект большой то он будет обречён на провал или на боли и страдания. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2020, 15:40 |
|
О вреде Agile
|
|||
---|---|---|---|
#18+
Roman Mejtes предпочту работать в команде на 5 человек (профессионалов), даже если в ней программистом буду я один, но всё будет спроектировано, продумано на этапе аналитики и качественно проверено. Уверен, что в такой команде прогресс будет куда более явным и легко достижимым, чем куча кода накиданная лопатой А остальное всё чудесным образом появляется - и продумано всё, и запрограммировано. И лопата тогда нужна только для того, чтобы бабло грести. Замечательная сказка для детей. Как и сказка про гениальных аналитиков, которые предвидят все детали работы пользователей создаваемого ПО, детализируют тысячи юзкейсов и дают в разработку. Сказка, в которой "гибкая разработка" действительно выглядит глупостью - ведь мокапы и юзкейсы на бумажках исправлять гораздо проще, чем переписывать код. Пусть гениальный аналитик поработает, и программистам ничего не понадобится переписывать. Счастье. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2020, 10:25 |
|
|
Start [/forum/topic.php?fid=37&tid=1555240]: |
0ms |
get settings: |
31ms |
get forum list: |
11ms |
check forum access: |
8ms |
check topic access: |
8ms |
track hit: |
196ms |
get topic data: |
30ms |
get forum data: |
6ms |
get page messages: |
645ms |
get tp. blocked users: |
3ms |
others: | 345ms |
total: | 1283ms |
0 / 0 |