Комментарии 17
Я думаю, очень трудно оценить вклад агильной или иной методологии в успех или неуспех проекта, поскольку нет простых и надёжных методов сравнения а уж тем более измерения. Когда ищутся новые лекарства для лечения людей, проводится огромное количество экспериментов сначала на животных а потом на людях. По результатам этих измерений на основе сложных математических моделей принимается решение о полезности кандидата на лекарство, о дозах и рекомендуемой терапии.
Продолжая аналогию между больными людми и «больными» проетами — ИТ индустрия пока не может серьёзно подбирать «лекарства» и оценивать их действие. Поэтому приходится полагаться на мнение авторитетов, которые говорят вроде бы умные слова, правда при этом часто противоречат друг другу и себе.
Поэтому в каждом проекте приходится на уровне «инженерной прикидки» оценивать возможнве решения.
Лично я понял, что окружающий шум очень плохо влияет на мою производительность. Разработчики, тестеры, архитекторы могут сидеть вместе (если их немного в одной комнате и они ведут себя тихо). А вот много телефонирующие менаджеры и работники млужбы поддержки должны сидеть отдельно.
И так по каждому элементу.
Логично, что производительность команды со временем растёт. Иначе что-то в проекте не так. Отчего она выросла — оттого что сотрудники вработались в тему и сработались друг с другом или оттого что в это время внедрили методолгию XYZ — большой вопрос,
Продолжая аналогию между больными людми и «больными» проетами — ИТ индустрия пока не может серьёзно подбирать «лекарства» и оценивать их действие. Поэтому приходится полагаться на мнение авторитетов, которые говорят вроде бы умные слова, правда при этом часто противоречат друг другу и себе.
Поэтому в каждом проекте приходится на уровне «инженерной прикидки» оценивать возможнве решения.
Лично я понял, что окружающий шум очень плохо влияет на мою производительность. Разработчики, тестеры, архитекторы могут сидеть вместе (если их немного в одной комнате и они ведут себя тихо). А вот много телефонирующие менаджеры и работники млужбы поддержки должны сидеть отдельно.
И так по каждому элементу.
Логично, что производительность команды со временем растёт. Иначе что-то в проекте не так. Отчего она выросла — оттого что сотрудники вработались в тему и сработались друг с другом или оттого что в это время внедрили методолгию XYZ — большой вопрос,
Agile подходит для компаний, которые не считают денег на разработку. Как я слышал от ПМ'ов, agile-подход позволяет быстро выкатить и продать продукт, состоящий преимущественно из костылей. Данный продукт затем 2 или 3 раза переписывается с нуля. Это требует дополнительных денежных трат, но их не считают.
Само собой атомную электростанцию с таким подходом не построить, но какой-нибудь сервис в банке вполне реально.
Само собой атомную электростанцию с таким подходом не построить, но какой-нибудь сервис в банке вполне реально.
Первые атомные станции примерно так и строились :)
Не слушайте таких ПМов, они совершенно не умеют в Agile. Плоды чего и пожинают.
Жуть какая. Костыли скорее являются следствием давления сроков и некомпетентности.
Делать все по уму долго и, к тому времени как закончите, продукт может быть уже не востребован или все сливки соберет конкурент. Первая версия продукта — это костыль на костыле и костылем погоняет, но приносит деньги. Потом, когда все грабли найдены, продукт переписывают уже с учетом их.
Я не защищаю и не нападаю на Agile, а лишь передаю слова людей, которые отвечают за разработку подобных продуктов.
Я не защищаю и не нападаю на Agile, а лишь передаю слова людей, которые отвечают за разработку подобных продуктов.
Так, не теряем нить беседы. Вы сказали — agile для быстрого создания продукта на костылях. Я сказал, что дело не в agile.
Далее вы пишете
Agile не упоминается.
Далее пишете еще предложение никак не аргументирующее ваше первое сообщение.
Я пока не понял почему вы писали, что agile для быстрого накастыливания? Я связи не вижу совсем. Прототип на выкидывание можно и по каскадной модели разработать.
Я считаю, что agile это как раз инструмент, который позволяет поддерживать качество продукта на высоком уровне т.к. позволяет, хотя бы благодаря тем же ретроспективам, увидеть проблему, донести ее до заинтересованных лиц и принять решение по ее исправлению. Но с другой стороны и в каскадной модели это может быть сделано… но обычно в водопаде не проводятся регулярные ретроспективы и потому отдача технического долга становится индивидуальной ответственностью, а не системой.
Далее вы пишете
Делать все по уму долго и, к тому времени как закончите, продукт может быть уже не востребован или все сливки соберет конкурент. Первая версия продукта — это костыль на костыле и костылем погоняет, но приносит деньги. Потом, когда все грабли найдены, продукт переписывают уже с учетом их.
Agile не упоминается.
Далее пишете еще предложение никак не аргументирующее ваше первое сообщение.
Я пока не понял почему вы писали, что agile для быстрого накастыливания? Я связи не вижу совсем. Прототип на выкидывание можно и по каскадной модели разработать.
Я считаю, что agile это как раз инструмент, который позволяет поддерживать качество продукта на высоком уровне т.к. позволяет, хотя бы благодаря тем же ретроспективам, увидеть проблему, донести ее до заинтересованных лиц и принять решение по ее исправлению. Но с другой стороны и в каскадной модели это может быть сделано… но обычно в водопаде не проводятся регулярные ретроспективы и потому отдача технического долга становится индивидуальной ответственностью, а не системой.
Совершенно верно. Agile — это когда вы строите для клиента дачу. Можно начать с возведения сортира, затем пилить баню, забор, сарай, потом приступить к дому, затем пристройку, потом домик для гостей — все по необходимости, и главное, чтобы народ был занят. А вот многоэтажку таким методом построить уже проблематично.
Нет, неверно.
Agile не означает отсутствие стратегического плана и беспорядочную работу.
Agile не означает отсутствие стратегического плана и беспорядочную работу.
Сам по себе Agile этого не подразумевает. Но если у вас нет четкого понимания что нужно заказчику (у него, кстати, тоже нет понимания), то в таких случаях и применяется Agile-подход к разработке.
Не согласен.
Какой бы не использовался фреймворк/методология, без конкретного стратегического плана вы никуда далеко не уедете.
Наличие стратегии никак не влияет на использование agile. Наоборот, agile позволяет протестировать в боевых условиях небольшими итерациями каждый шаг стратегии. Просто в таком случае не нужно бояться менять план, убирая уже ненужное и добавляя новые вехи.
Какой бы не использовался фреймворк/методология, без конкретного стратегического плана вы никуда далеко не уедете.
Наличие стратегии никак не влияет на использование agile. Наоборот, agile позволяет протестировать в боевых условиях небольшими итерациями каждый шаг стратегии. Просто в таком случае не нужно бояться менять план, убирая уже ненужное и добавляя новые вехи.
Видите ли, снести деревянный сортир на дачном участке и поставить новый железный не составит большого труда. А вот снести целый этаж в уже работающем здании, или поднять везде потолки — будет большой проблемой, равно как и надстраивать этажи в середине, особенно когда у вас вместо фундамента — кирпичи, оставшиеся с первой итерации. И как бы в этом случае клиент не очень намерен платить за различного рода переделку, редизайн и все такое — он всегда хочет видеть новый функционал. Так что объем работ изначально должен быть оценен и составлен более-менее подходящий план (а клиенту сообщена цена), и первая итерация — это возведение каркаса всего проекта, которая всегда будет достаточно долгой, и которая всегда необходима прежде, чем проект начнет наполняться реальным функционалом.
Отчасти верно. Строительство дома это, конечно, интересная аналогия, но не полностью подходящая к разработке ПО.
Во-первых, в разработке ПО есть такое понятие как гибкость.
Во-вторых, заказчик всегда меняет требования, а agile лишь явно говорит «это неизбежно, будь готов!».
И опять таки agile не имеет отношения к костылями и качеству продукта. Он не противоречит качеству кода никак. Он просто позволяет делать качественный продукт в условиях неопределенности.
Во-первых, в разработке ПО есть такое понятие как гибкость.
Во-вторых, заказчик всегда меняет требования, а agile лишь явно говорит «это неизбежно, будь готов!».
И опять таки agile не имеет отношения к костылями и качеству продукта. Он не противоречит качеству кода никак. Он просто позволяет делать качественный продукт в условиях неопределенности.
Software vs Hardware (в самом широком смысле и Software, и Hardware)
В чем их главное отличие?
Software (soft) — нечто мягкое, виртуальное, неосязаемое. Внести изменения в Software, и получить обратную связь можно очень быстро.
Поменять что-то в Hardware — существенно дольше, и обычно дороже.
На этом строится разница в подходах развития. В Software просто реализуем и смотрим результат. В Hardware предварительно оцениваем, и пытаемся понять косвенно, идея стоящая или нет.
Сухой итог. Да, 9-этажку нельзя построить мелкими итерациями — построили первый этаж, заселились, начали строить 2-й, заселились и т.д.
А вот какое-нибудь приложение выпускать в production мелкими итерациями — запросто.
В чем их главное отличие?
Software (soft) — нечто мягкое, виртуальное, неосязаемое. Внести изменения в Software, и получить обратную связь можно очень быстро.
Поменять что-то в Hardware — существенно дольше, и обычно дороже.
На этом строится разница в подходах развития. В Software просто реализуем и смотрим результат. В Hardware предварительно оцениваем, и пытаемся понять косвенно, идея стоящая или нет.
Сухой итог. Да, 9-этажку нельзя построить мелкими итерациями — построили первый этаж, заселились, начали строить 2-й, заселились и т.д.
А вот какое-нибудь приложение выпускать в production мелкими итерациями — запросто.
Тут выше упоминался банк.
Представьте, что вы банк. Какой стратегический план вы ожидаете для банка?
Что в нем должно быть такого, чего нет у других?
Уже известно, что клиенты хотят пользоваться сервисами банка через мобилки.
Клиенты хотят сервисы банка 24/7.
Клиенты хотят безопасности и простоты.
Как эти постулаты из стратегического плана помогут в разработке и внедрении конкретного кредита или депозита? Или приложения?
Мир меняется стремительнее, чем некоторое время назад. Стратегический план предполагает планирование на срок более 3 лет. Сейчас за 3 года меняется все насколько сильно, что все что ты напланировал 3 года назад, сегодня уже просто вызывает смех.
Если я вас не убедил.
Попытайтесль нагуглить стратегический план того же Гугла, или приснопамятного Амазона, Алиэкспресса, и т.д.
Если убедил, то возникает вопрос, а как развиваться, в условиях неопределенности. И вот тут ответ. Развивайтесь итеративно (agile style), следуя вашим ценностями (только ценности остаются долгосрочными).
Представьте, что вы банк. Какой стратегический план вы ожидаете для банка?
Что в нем должно быть такого, чего нет у других?
Уже известно, что клиенты хотят пользоваться сервисами банка через мобилки.
Клиенты хотят сервисы банка 24/7.
Клиенты хотят безопасности и простоты.
Как эти постулаты из стратегического плана помогут в разработке и внедрении конкретного кредита или депозита? Или приложения?
Мир меняется стремительнее, чем некоторое время назад. Стратегический план предполагает планирование на срок более 3 лет. Сейчас за 3 года меняется все насколько сильно, что все что ты напланировал 3 года назад, сегодня уже просто вызывает смех.
Если я вас не убедил.
Попытайтесль нагуглить стратегический план того же Гугла, или приснопамятного Амазона, Алиэкспресса, и т.д.
Если убедил, то возникает вопрос, а как развиваться, в условиях неопределенности. И вот тут ответ. Развивайтесь итеративно (agile style), следуя вашим ценностями (только ценности остаются долгосрочными).
Во-первых, в разработке ПО есть такое понятие как гибкость.
Да, в отличии от инженерного дела разработка ПО не ограничена жестко законами физики, поэтому позволяет девелоперам творить любую фигню — машина все проглотит. Тем не менее, базовые принципы построения проекта никто не отменял.
Он просто позволяет делать качественный продукт в условиях неопределенности.
А как вы себе представляете неопределенность? Продукт призван решать определенные задачи, для этого создаются определенные решения. Единственная область, где я вижу более-менее оправданное использование agile — это типичный веб-проект: страничка, сервер и база данных. Клиент пока не знает что конкретно ему нужно, но вы пока начните, сделайте форму логина, потом утвердим дизайн, определимся с функционалом, добавим пунктиков в меню, табличек в БД, etc… Архитектуры — ноль, зависимости слабые, объем работы скалируется и хорошо делится. Типичная дача.
Статью можно было назвать так «Почему Экскаватор не работает и что с этим делать»
Аджайл — это инструмент, если инструментом неправильно пользоваться то он и не принесет никакого профита, а только навредит. Есть замечательная басня Крылова очень актуальная сейчас, что то там про одно животное и приспособление для улучшения зрения.
Находим или вспоминаем уроки по скраму, и обнаруживаем что таймбоксы мы забыли или посчитали их ненужными.
Идеальный ПМ в аджайле как-бы не определен, ну может быть это Product Owner, он может представлять интересы заказчика и замещать его как типа его представитель, работать вместе с аналитиками и дизайнерами и формировать беклог продукта. Открываем опять учебники, и еще одна важная роль, это скрам-мастер без которого даже не стоит вводить аждайл подход, который следит за правилами нарушение которых ведет к бедам типа расхода времени (из за не соблюдения таймбоксов). Он не менеджер и не надзиратель, а тренер и мотиватор, причем он одинаково помогает и овнеру формировать требования и команде понять, декомпозировать и работать с требованиями заказчика. Если его нет аджайл будет убыточным.
Самый супер тренер или скрам-мастер не поможет если не подобрана квалифицированная команда. Аджайл (тренер) нам не помог поэтому он плохой, а может нет игроков способных вытянуть проект.
Если есть проф. скрам мастер и профессиональная команда индивидуално высококвалифицированных специалистов, то он все равно не заработает, если не будет одной важной вещи. Команда должна хотеть научится работать с аджайлом и слушать тренера. А если этого нет, то опять же это не аджайл не работает, а люди не хотят.
Итого, мы узнали, что модно и круто копать котлованы экскаватором, взяли его, пнули по колесу дернули ручку, пролистали бегло скучную и длинную инструкцию, все таки вырыли яму лопатами, и всем рассказываем потом, что экскаватор — это какой-то неэффективный, модный тренд, который не работает.
Аджайл — это инструмент, если инструментом неправильно пользоваться то он и не принесет никакого профита, а только навредит. Есть замечательная басня Крылова очень актуальная сейчас, что то там про одно животное и приспособление для улучшения зрения.
Увлечение личными встречами тоже имеет свои негативные последствия
Находим или вспоминаем уроки по скраму, и обнаруживаем что таймбоксы мы забыли или посчитали их ненужными.
Менеджер vs Надзиратель. «идеальный PM» должен быть на стороне команды, помогать каждому ее участнику разобраться в целях и задачах проекта
Идеальный ПМ в аджайле как-бы не определен, ну может быть это Product Owner, он может представлять интересы заказчика и замещать его как типа его представитель, работать вместе с аналитиками и дизайнерами и формировать беклог продукта. Открываем опять учебники, и еще одна важная роль, это скрам-мастер без которого даже не стоит вводить аждайл подход, который следит за правилами нарушение которых ведет к бедам типа расхода времени (из за не соблюдения таймбоксов). Он не менеджер и не надзиратель, а тренер и мотиватор, причем он одинаково помогает и овнеру формировать требования и команде понять, декомпозировать и работать с требованиями заказчика. Если его нет аджайл будет убыточным.
Agile-принципы != KPI
Самый супер тренер или скрам-мастер не поможет если не подобрана квалифицированная команда. Аджайл (тренер) нам не помог поэтому он плохой, а может нет игроков способных вытянуть проект.
«Неформальный» agile
Если есть проф. скрам мастер и профессиональная команда индивидуално высококвалифицированных специалистов, то он все равно не заработает, если не будет одной важной вещи. Команда должна хотеть научится работать с аджайлом и слушать тренера. А если этого нет, то опять же это не аджайл не работает, а люди не хотят.
Итого, мы узнали, что модно и круто копать котлованы экскаватором, взяли его, пнули по колесу дернули ручку, пролистали бегло скучную и длинную инструкцию, все таки вырыли яму лопатами, и всем рассказываем потом, что экскаватор — это какой-то неэффективный, модный тренд, который не работает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему Agile не работает и что с этим делать