Comments 15
Поздравляю, вы переизобрели инкрементную модель разработки, которая, по сути, является улучшенным водопадом, тем самым, которым вас так пугали в процессе принятия Agile веры.
Попробуйте в начало этих месячных циклов также добавить качественное проектирование, вместо бесконечных разговоров с заказчиком на демках — увеличение скорости разработки вас приятно удивит.
Ну чё сразу так приземлять?:) Применять к программированию инженерный подход с качественным проектированием, ведь так хочется и дальше радоваться розовым единарогам и постоянно митапить.:) И сколько можно изобрести ещё разных походов, аджайлоскармоводопадситерацией:)
Статья конечно дно, но agile смог продать боссам простую вещь - недостаточно нанять специалистов надо еще и регулярно контролировать что получилось - для любого изделия, отличного от массового производства. Реально, это его самое большое достижение.
надо еще и регулярно контролировать что получилось
Я понимаю, что вы хотите сказать, но ваше выражение мне кажеться больше громким, чем имеет место быть. И в «старом» проект-менеджменте этого контроля тоже с лихвой. Например в PRINCE2 — это контроль границ стадий. Всё упирается в то — кто это делает и как? Не важно по-старинке или в agile.
Конечно, все это было. AGILE обернул старые методики в красивую обертку, а приспешники смогли успешно продать это бизнесу. Особенность человеческой психологии - знания, за которые заплатили, имеют большую значимость чем бесплатные. Но лучше так, чем управлять по наитию.
Без сарказма, я ему за это благодарен.
Благодаря извращенному толкованию Agile многие менеджеры теперь думают, что для решения задач не нужен анализ, проектирование и планирование — достаточно всем вместе обсудить что-то на созвоне.
Это только упрощает жизнь управленцам, которые привыкли работать по наитию. Соблюдать никакие регламенты и процессы не нужно — можно хоть каждый день свои внезапные догадки вбрасывать в рабочую команду, в зависимости от настроения.
А благодаря извращенному толкованию СКРАМ, я стал свидетелем как в одной компании решили что ненужны архитекторы, тех.лиды и тим. лиды - только самоорганизующиеся команды. Скорость разработки ощущает отрицательный рост.
Только это не одна-две компании - это трэнд повсеместный. Ты как менеджер будешь лузером, если не будет говорить и переставлять всё на agile. И архитекторы - ну просто не вписываются в эту еонструкцию. Со своими желаниями, 'долго' и усиленно продумывать всю архитектуру или модель базы данных. Всё хотят - тяп ляп и в продакшн.
Контроль качества, о котором вы вероятно говорите, достигается с помощью QA инженеров, которые буквально следят за тем, что мы идём верным курсом: цели актуальны, методы достижения эффективны, требования выполняются.
Agile тут ни при чем, обеспечением качества можно и нужно заниматься в любой модели разработки.
Если прочитать про водопад http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
"Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps" (К сожалению, для приведенного процесса итерации разработки никогда не ограничиваются последовательными шагами) об итеративности уже тогда говорили.
И вообще в документике "сквозит" аджайлом, и много где написано, что не делайте больше, чем надо. При этом надо еще понимать что бумажка 1970г создана на основе разработки до этого 1970г.
Все что ниже гугли по быстренькому:
примеры компов второй половины 60х годов
https://en.wikipedia.org/wiki/SDS_9_Series
https://en.wikipedia.org/wiki/Honeywell_316
При этом надо понимать что никаких intellisense, CI, testing framworks , дебагеров и прочего не было, по этому к процессу разработки готовились куда тщательнее, что вполне разумно.
Еще кстати Agile/Scrum апологеты очень любят про избыточную документацию, при этом если посмотреть на любой SDK, то чем лучшге он документирован, чем больше примеров, тем проще писать код.
Решил копнуть про языки https://en.wikipedia.org/wiki/History_of_programming_languages
скорее всего писали на FORTAN'е и вот вам дают кусок какого-то когда, и хрен пойми чего он делает, при том, что там либо что-нить математическое либо machine level. Как в таком разобраться без доков, а если еще и модуль такой дадут, так он к тому же еще и ресурсы жрет и непонятно сколько.
Agile апологеты опять таки забывают про Rational Software и их RUP и UML, на мой взгляд наиболее полная формализация процесса разработки с единым языком UML, где на каждом этапе ключевую или специфичную инфу можно переложить в графические фигуры.
Весь этот Agile (XP, Scum, Kanban, Lean, LeSS) очень умело проданный продукт, для новичков, которые не знают истории разработки компов и софта. Конечно все эти подходы объединяют полезные практики, которые могут быть вполне полезны.
Причиной популярности agile и процессам послужил резкий рост производительности в конце 90х и начале нулевых и резкое удешевление персональных компьютеров, сюда же распространение винды и формоклепа от борланда позволило практически кому угодно начать программировать "с нуля", в отличии от ситуации до 90х, когда компы стояли либо на заводах, либо в НИИ, и никто там никакой Agile не купит.
Как Agile помогает реализовывать качественные проекты в срок
и что самое интерессно — автору совсем не видится противоречие в своих словах. Ведь проект в срок — это значит известны все требования и план реализации по времени и ресурсам. А если так, то это всё это не имеет ничего общего с agile.
Вместо того, чтобы коммититься на бюджет сроки и объём, на весь проект, мы будем двигаться циклами по 2-3 месяца и объем работы на цикл жестко не фиксировать.
Нужен курс, «Как убедить клиента внести предоплату за неопределенный объём работы».
Никак.
Agile - это не фреймворк, не алгоритм работы и не инструкция. Это в первую очередь манифест, который показывает альтернативную точку зрения на взаимоотношение между командой, проектом и заказчиком.
Вы же пытаетесь показать что Agile это какой то а алгоритм работы, который приведет вас к счастью, но это не так.
Как Agile помогает реализовывать качественные проекты в срок?