Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
А вот можно описать грань между 1 Do & Fix и последним. Потому как план то есть, но мы идем маленькими шагами к этому плану, тоже самое и в первом пункте план есть, мы просто не понимаем как его реализовать.
(1) — очень хитрый вопрос.
Я бы сформулировала ключевые практические отличия Agile от Do & Fix примерно так:
1) Гибкие методы — про обучение и рефлексию. По итогам очередного шага мы останавливаемся и рефлексируем: что мы сделали так, что не так, и как нам дальше работать лучше? И, черт возьми, не просто фиксируем, а применяем на практике на следующем шаге!!!!
2) Для ответа на вопрос стоит почитать и поосмыслять .
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
И особенно внимательно нижнюю строчку:
То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.
Потому что если мы правую часть откидываем в принципе, мы как раз и получаем Do&Fix.
Таким образом, мы можем взять манифест в качестве своеобразного чеклиста:
— Главным фокусом внимания для нас являются люди и взаимодействие?
— На этом фоне уделяем ли мы внимание процессам и инструментам?
— Мы стремимся в первую очередь производить работающий продукт?
— При этом, заполняем ли мы необходимую документацию?
— Готовы ли мы к сотрудничеству с заказчиком (вместо приглашения юриста для объяснения, что мы ничего не обязаны)?
— На этом фоне, относимся ли мы уважительно к контрактным обязательствам?
— Готовы ли мы к изменениям?
— Есть ли у нас первоначальный план, и отталкиваемся ли мы от него при изменениях?
Если мы на все вопросы ответили «Да» — то можно говорить, что у нас гибкие методы управления проектами. Если каждый применяет какие попало инструменты, документация не соответствует продукции, контракт «для галочки», сроки точно сорваны под предлогом изменений — простите, но это Do & Fix.
P. S. Я специально довожу ситуацию до абсурда, понятно, что на практике — дьявол в деталях. Но работающий Agile я видела, да.
Не люблю слова, которые не отражают суть, а дают лишь общую концепцию. «Рыночная экономика» и «капитализм», по сути одно и тоже, зато «рыночная экономика» не так запятнана как «капитализм». чем Agile отличается от «тяп-ляп»? Позитивным восприятием последнего? Может быть у меня не было опыта автоматизации по концепции Agile, и я не смог прочувствовать что это. Но обычно изучаются бизнес-процессы предприятия, потом дело настраивается в тестовой конфигурации, тестируется, так до определенной точки, когда основной функционал отлажен и можно пересаживаться на рабочую базу. Ну или можно просто посадить пользаков работать в чистую базу, и по-тихоньку настраивать, это наверное и есть Agile.
А если заказчик сам не знает чего хочет, и в середине проекта, когда пользователи уже забили НСИ, решил… ну скажем — учитывать оплаты по заказам, а не в разрезе договора (в УТ 11), а клиентская база огромная, то есть надо не только настроить правильно конфигурацию, но и перенести оплаты на заказы клиентов. Чем это не «тяп-ляп»?
(3) Я чуть выше ответила, в чем в данном случае отличия между «рыночной экономикой» и «капитализмом»… Видимо, подробнее напишу отдельный материал. Скажем так, если вы будете изучать все бизнес-процессы предприятия, прежде чем начинать настраивать, то вы рискуете это делать до морковкиного заговенья, а полученный результат будет не факт, что подходящим.
Agile — это когда вы выделяете какой-то логически законченный небольшой кусок, его анализируете, тестируете, в процессе тестирования 8 раз переделываете, потому что заказчик понял, что всё не так, потом навинчиваете на рабочую базу, и берете следующий кусок — и так по кругу.
Шансы, что результат устроит заказчика в среднем выше. Хотя подход применим не всегда, тоже спорить не буду.
(4) Подскажите, а в указанном варианте прототип делали? В смысле, тестовую версию, как будет выглядеть на «условных» данных заказчику показывали, до того как пользователи уже справочники стали заполнять, и он ее одобрил?..
(7)
Kosstikk — спасибо большое за комментарий по делу.
По моему опыту, очень часто волна сопротивления бывает еще и от заказчика, который, во-первых, ждет на старте четкого контракта на весь объем работ, во-вторых, не всегда готов к тесному сотрудничеству в процессе.
Все случаи попытки использовать эту хрень, о которых я знаю либо лично наблюдал, приводили в лучшем случае просто к проблемам на всех уровнях, а в худшем — к катастрофе, провалу проекта и даже закрытию фирмы.
По имеющейся у меня информации, именно внедрение этой хрени в 1С привело к чудовищным косякам и проблемам релиза 8.3.7, и последующему бардаку с релизами обновлений фрагментов платформы в продакшен.
Поэтому, какие бы красивые презентации, умные доклады и элегантные концепции нам не втюхивали, я могу сказать только одно, чисто по опыту: нафиг надо.
Вообще, замечу, некоторые поклонники «сферических коней в разработке» довольно лихо и регулярно собирают плюсы за свои статьи, далёкие от реальности, а стоит попытаться перейти к конкретике и делам нашим скорбным, так сторонние советчики сливаются, а свои коллеги чешут репу и говорят, да ну её нафиг. Потому что реальность разработки — это только и исключительно экстремальный костыльный кодинг, и другого не будет — не потому даже, что мы такие, а потому, что жизнь и заказчики таковы)
Автор, а что, можете привести вот прямо пруфлинк на коллектив, хотя бы вполовину успешно применяющий эту хрень?
(6) показывали, все было норм. а потом генеральный решил внедрить KPI по оплаченным заказам. вполне в духе Agile.
(7) на словах это красиво, вы не берете в расчет человеческий фактор на стороне заказчика. на деле — мне бы сказали, что я срываю сроки проекта.
(9) +100500
это все откуда-то из области бизнес-тренингов. концепция красивая, а получается как всегда.
(9)
Yashazz — вы удивитесь, но я вот прямо почти с вами соглашусь. Я тоже знаю попытки внедрения Agile, по итогам которых получалась феерическая фигня. По разнообразным причинам и с разнообразными последствиями…
Из самых простых причин провалов — упомяну одно из ключевых ограничений: Agile работает только в команде мотивированных профессионалов. То есть если у вас не профессионалы, и не мотивированные — работать не будет. Ну, и следующий момент — попытка внедрить Agile на судне, которое уже начало тонуть — ну, в-общем, тоже затея спорная…
(9)
Могу. Как минимум, взимодействовала с успешно работающими по Agile командами в Яндексе, командами в Газпроме, командами в Ростелекоме. С небольшими внедренческими командами тоже работала (названия не готова приводить без их разрешения). В одном случае, после того как одна из команд разработчиков начала работать по SCRUM, ее эффективность настолько превысила эффективность остальных команд, что встал вопрос, а зачем вообще остальные едят деньги инвесторов?..
да, пруфлинк на «правильное внедрение в Agile стиле» в студию. а то как всегда холопы в Россиюшке — увидели где-то в розовых заграничных интернетах красивое непонятное слово, ну практически заклинание, и давай его форсить везде. это же не инструкция «как надо делать», а скорее расплывчатая рекомендация. какой от нее толк в реальных условиях? так что… дизлайк, отписка.
и если можно в конкретных цифрах насколько повысилась производительность, а не в «3-4 раза».
(11)
Да, одно из условий работающего Agile моментов — заказчик должен быть готов к отсутствию определенности по срокам и содержанию финального релиза на старте. Если не готов — не взлетает… (На самом деле, в водопаде тоже скорее иллюзия определенности по срокам и содержанию — но там эту иллюзию все старательно поддерживают).
Выше привела примеры команд, с которыми я имела дело.
Мария, пруфлинк это не упоминание бренда или названия компании. Это ссылка на конкретные отзывы других, желательно непредвзятых, людей, которые оценивают эффект (и тактический, и стратегический) как положительный. А то я тоже могу сказать, что как только плюнули на все эти скрамы-канбаны в проекте, допустим, Минсельхоза, всё сразу продвинулось)
самый главный вопрос в ваших скрамах и эджайлах — кто заставит сторону заказчика следовать этой концепции? почему человеки, которые по сути заказывают разработку, платят за нее, будут меняться, просто потому что этого захотел разработчик? как можно быть «правильным» в одном невзаимном направлении?
(18)
да, в объеме тех же продаж. раз цифры не очень показательны, значит и метод «не очень показателен». вот вам и практика.
(20) oleganatolievich, отвечаю по пунктам:
Никто.
Нипочему.
Никак.
Agile применим тогда и только тогда, когда обе стороны к нему готовы и готовы его применять. Это, к сожалению (или к счастью?), не универсальная методология. Но когда получается — все стороны оказываются в выигрыше.
(22) и я о том же. заказчик обычно хочет все и сразу и никто его в этом не переубедит.
(19) Yashazz
Вот прямо подборку подписанных отчетов — с оценкой эффекта в деньгах — не покажу. У меня ее нет.
И если вы считаете, что «все эти скрамы-канбаны» вашему проекту только помешают — я буду последним, кто будет вас отговаривать, честное слово. Я вообще никого за советскую власть (простите, за рыночную экономику), не агитирую. И если вы расскажете про опыт продвижения проекта Минсельхоза без Agile — буду очень признательна, если вы поделитесь своим личным опытом — ибо он бесценен, и, возможно обогатит мои представления про те ситуации, когда Agile только мешает…
Но факт, что многие команды, у которых получилось, оценивают результат, как позитивный — имеет место быть.
Вот, например, интересное исследование именно по российским компаниям, где рассказано про цели внедрения Agile и их продвижение — и как оценивают компании, насколько целей реально удалось добиться:
(23) Да, совершенно верно. В ситуации, когда заказчик хочет все и сразу и переубедить его не представляется возможным, вам придется работать по водопаду.
(8) тут как раз имел ввиду руководство вцелом как со стороны исполнителя, так и со стороны заказчика.
Проектная группа заказчика, понимая, конкретику работ — понимает сферичность каскада, а руководитель от лица заказчика, как Вы правильно заметили, хочет получить подробный план на старте )
(23) желание заказчика в данном случае диктует правила.
Есть ситуации, когда заказчик готов переплатить в 5 раз за водопад, это правда и это их выбор. Получить четкий фиксированный результат. Их очень много. И, на моей практике, разработчик выставляет встречные условия по фиксации конфигурации (ни каких вам обновлений впринципе). Водопад.
Есть ситуации, когда заказчик хочет платить по минимуму, обычно это заканчивается аутстафом либо взятием программиста в штат. Do fix.
Этих ситуаций — большинство..
Agile — это компромисс между четкостью и эффективностью. Agile — это отношения в первую очередь. Да, в бизнес разработке он очень сложно применим. Я бы больше рассматривал проекты постоянно совершенствующихся систем, где все работает, но хотят сделать еще удобнее/быстрее/лучше/по-новому/закрыть новые области автоматизации, чтобы получить большую эффективность работы системы. Сложно предствить Agile не внутри одной компании, т.к. грани взаиморасчетов/результата/доверия — не будут рассматриваться с одинаковой позиции заказчиком и исполнителем.
В коммерции нет чистого Agile, он либо разворачивается внутри отдела 1С, если он есть у компании, либо это примерно так: Заказчик <-> (водопад с вилкой) <- > Исполнитель (команда Agile). Ситуаций Заказчик <-> Agile <-> Исполнитель — минимум.. т.к. это больше инвестирование, а не сделка )
(27) Kosstikk — соглашусь с вами. Для меня Agile — это тоже прежде всего про доверие. В моем окружении продуктивная работа по Agile за пределами одной компании возникала в ситуации, когда уже установлено доверие между заказчиком и исполнителем, и на этом фоне обе стороны искренне искали лучшие решения. И даже когда в большинстве случаев сотрудничество получалось — все равно, иногда были ситуации, когда заказчик начинал пытаться прогибать исполнителя под себя, и ситуация скатывалась опять к жестким условиям контракта «шаг вправо, шаг влево…»
(29) Yashazz — рада, что вы так легко со всем разобрались. Желаю вам и впредь не вестись на красивые сказки и всякую прочую бизнес-консультантскую лабуду, и вести проекты так, как вы привыкли.
(30) Причём здесь «я привык»? Я вообще привык работать в одиночку. А вот кучу проектов, которые завалили те, кто повёлся и те, кто сказки рассказывал, это я наблюдал во всех видах. И в отличие от Вас, готов предоставить контакты людей, которые весьма предметно и конкретно скажут, где и как всё стало плохо после внедрения подобной хрени.
господи, сколько воды… аджайл — это как идеальный газ, его не бывает в природе. решает человеческий фактор по итогу. ну… типа вы не работали с реальными заказчиками автоматизации бизнеса на 1С по России / СНГ? вроде взрослые люди…
(32) oleganatolievich — бывает. Хотя реже, чем стандартная схема работы. На самом деле, на практике чаще встречаются так называемые «гибридные» модели — когда в проекте сочетаются элементы нескольких подходов. Я и в сфере автоматизации бизнеса, и даже в сфере госуправления (когда консультировала муниципальные/региональные органы власти) встречалась с успешно применяемыми принципами гибкого управления. Как правило, при грамотном применении результат с гибким подходом лучше, чем с жестким.
(32)
посмотрите пожалуйста, если не верите, что в 1С бывает Agile ))
(34) Спасибо, Kosstikk, наглядное видео.
На самом деле, мой опыт тоже показывает, что внедрение продукта заказчику по Agile тоже возможна при условии определенного уровня доверия, хотя и не всегда всё просто и гладко.
Интересно будет через некоторое время подвести результаты опроса на Инфостарте… Пока на первом месте — в 37% компаний — подход «Do & Fix» — «Думать некогда, прыгать надо!»… Спасибо за честность… А вот «Водопад» без итераций самый последний по частоте — недобрал 12%…
Коллеги, подключайтесь, голосуйте — где какие подходы к проектному управлению применяются?
(2)
Надо границу провести, где много общения, а где мало. А то тут вон специалисты общались, общались, а по факту без документов не могут 2 слова связать. Когда дело дошло до конкретике, выяснилось, что они много общались и шли по не правильному пути. Грустно очень, но когда дело касается денег, сразу вспоминаешь про бумажки. Я ж им диктовал как правильно писать, а они… Эх…
А ещё они уверены, что сделали что-то рабочее. Автоматизаторы, блин
(36) Дык как можно голосовать, если там только ваши конкретные методики? Оно ж вроде как без вариантов — нет нужного пункта.
Можно чуть подробней про эти методики? А то все описания уж очень сильно смахивают на шарлатанство — мало конкретики и очень много пустословия. Простите за грубость, но в обществе не существует равенства и доверия (доказано практически и теоретически). В общем это напоминает секту какую-то. Ну и скрывать не буду, все видимые результаты внедрений таких методик выглядят… мягко говоря гаденько — название есть, а в конторе бардак полный.
И оценка изменений, как мне кажется, тоже очень странный пункт, ведь многие направления очень хорошо формализуются. Например, «до внедрения чего либо, обслуживал учёт компаний большой ИТ-отдел и 3 сторонние конторы, после внедерения один человек». Мне кажется это очень показательно. Уверен, что и у Вас есть что-то подобное. Похвастайтесь и люди заинтересуются. А иначе… а иначе остаётся осадок недосказанности.
(39)
Пытаясь обобщать, трудно приводить конкретику.
Если хочется конкретики, вот вам, пожалуйста, Профкейс 2.0 доступный франчайзи — см. 1С:ТСВ — как пример водопадной методологии, 1С:ТКВ — как пример итеративной, 1С:ТБР как пример гибкой.
По результатам опроса Инфостарта, порядка 2/3 франчайзи используют.
Как-то так…
(40) Добрый день (это неуважительно, раз у меня день, но так уж воспитан). Тут уж признаю свою ошибку — не сообразил сразу, что ориентация на франчей. Там чуть-чуть другой принцип, т.к. мотивация идёт от продаж, а не от того, что бы заказчику было хорошо. Это сразу всё расставляет на свои места. И не подумайте, это не плохо, а наоборот.
А про ТКВ и ТБР не слышал. Честно-честно не слышал. Есть повод узнать.
И да, не забывайте, что Вы рекламируете технологию, а я всего лишь как ленивый кот — «а нас и тут неплохо кормят» (это шутка, а не издёвка)
мне понравилась метафора по поводу управления парусной яхтой и методологиями управлением ИТ-проектами. Однако у меня, немого иной взгляд на эти вещи.
Если лодку ведет команда ботаников под управлением сертифицированного Coastal Skipper, то это и будет иджайл. А если команда находится в мозолистых руках яхтенного капитана советской парусной школы, который прошел путь от яхтенного рулевого второго класса и за спиной которого многие тысячи зачетных миль и задница давно обросла ракушками, то это и будет старый добрый водопад. Сейчас попытаюсь объяснить почему.
Основой сего действа считается Хорошая морская практика и Высокая морская культура. Это не только «считать себя ближе к опасности», но и заранее предпринимать все необходимое для обеспечения безопасности плавания. Это надо понимать так, что если судом будет установлено что гибели людей можно было бы избежать, если бы кэп заранее подстелил соломку, то кэп сядет. Кроме того, у них есть раздел — Особые случаи плавания, когда экипаж отрабатывает действия в нештатных ситуациях — человек за бортом, посадка на мель, пробоина, пожар на борту, потеря рангоута, потеря руля.
Однако возвращаясь к нашим баранам — проектные риски не такие страшные как гибель экипажа и потеря яхты, почему бы не рисковать?