ebanoe.dev
0
legacy_Жук··0 переглядів

Телега за Agile и Waterfall

Пишет Толстый Хрюк: «Не нашёл темы, в которой можно оставить коммент, да во всех можно! Да и эта тема достойна отдельной статьи.

Есть Agile, а есть Waterfall
Agile обычно описывают, как гибкую разработку, способную удовлетворить все желания клиента. Это и XP и Scrum, и Канбан, Agile — общее название этих методологий. А Waterfall, — как строительство дачного сортира, когда сначала (зачем-то) рисуют план, потом закупают материалы, потом сколачивают. И ничего больше сортира построить так нельзя.

Последнее, кстати, имеет почву: многие строительства используют Agile. Да строительство — тоже проект, как и софт. Только вот на таких стройках работают одни джамшуты (не в смысле таджики, а в смысле похожие на Джамшута), и джамшуты же и управляют.

Тут становится интересно, неужели, к примеру, Cicklum — джамшуты от софта?

Но сначала разберемся, что такое на самом деле Waterfall и Agile
Waterfall может обеспечивать потребности потребителя. Так была написана, например, Win98. Да эта ваша Win10 AE тоже на Waterfall. И эти программы (а скорее, программные комплексы) явно не назовешь сортирами.

В чем же отличие Agile? В том, что эта методология сразу предполагает изменение требований в процессе разработки.

Но если она такая удобная, почему винду писали не на ней? Ответ: она дороже. И в плане консультантов, и в плане накладных расходов: на переделку, обычно. Также, не всегда, но часто, качество хуже. Например, программа на Agile часто не выдерживает тайминга, требований дизайна и безбажности.

Когда же она выдерживает? Когда кто-то, а лучше все, в команде применяют элементы Waterfall! То есть, переписывают требования, добавляют требования по таймингу, дизайну и безбажности, исходя из ожиданий пользователя, а не розовых фантазий разработчиков, напоминающих стихотворение Маяковского «Облако в штанах».

Почему же на Waterfall нельзя писать, как на Agile? Потому что нервы мои, не знаю, как ваши, не железные, и, когда из-за очередного бзика приходится выкидывать написанный абсолютно нормальный код, происходит взрыв. Хорошо хоть всё время оплачивают.

А почему все не пишут на Waterfall? И тут я возвращаюсь к джамшутам. Для того, чтобы хотя бы примерно оценить техническое описание (это среднее из последовательности Описание-Техническое Описание-Техническое Задание) и понять сможешь ли ты его сделать, нужно обладать определенным уровнем. И джамшут, просто физически, не может работать по Waterfall.

Кстати, заметили, что я не привел в пример Win95 и Win8? Потому, что их делали по Agile. Ведь у каждого разработчика есть предел. И я, так любящий Waterfall, свою главную программу писал по Agile. Вот так-то.

Кстати, такие вещи, как TDD (Test-Driven Development) и постоянный рефакторинг, не имеют отношения к методологии Agile или Waterfall. Это просто качество кода.

Всем добра. А некоторым компаниям — буддистского перерождения».

Прислал Толстый Хрюк

З архіву ebanoe · Опубліковано 23 березня 2018 р.

Коментарі (93)

Сортування:ТопНовіСтарі
  • legacy_Капитан_одноместной_лодки

    Две жалобы за сегодня — это слишком. Неужели никаких сплетен нет, типа айтишник украл электроинструмент у строителей, взломал вендинг или спёр сыр в супермаркете?

  • legacy_Тупой_педалер

    Небо — голубое. Трава — зеленая. Быстро решительно сунуть себе в жопу хуй заказчика и упасть в обморок, лишьбы сделать — Agile. Красиво элегантно один охуенный минет заказчику — Waterfall.

    • legacy_СупаЛид

      Просто вы лохи и омежки, которых нагибают все, кому не лень. Хорошая agile-команда всегда имеет право сказать «нет» ебанутому требованию и не брать его в беклог. И, блять, найдите толковых аналитиков, чтоб куски кода не выкидывать.

      • legacy_Зигмунд_Фройд

        И может пойти искать новую работу. Всей командой.

        • legacy_СупаЛид

          Я же и говорю — терпилы и омежки. Что сказали, то и делают. А грамотно требования собрать и согласовать не пробовали? Про MVP не слышали? Заказчик обычно вообще не рубит, что ему КОНКТРЕТНО надо, просто надо и всё. Ну так и предложите нормально решение, которое покрывает потребности. Но нет, нам этого не надо, мы же — кодери. Разобраться в бизнес процессах, опросить конечных пользователей/стекхолдеров, прототипы запилить, использовать лучшие практики и готовые решения, следить за тенденциями в бизнес-сфере — да нуууу, это какое-то говно для офисных планктонов. Мы — титаны кода! Мы хуярим говнокод по говнотребования говноменеджеров годичной давности, а потом удивляемся, что нас ебут постоянно. И не методология тут виновата, просто вы работаете в говнокомпании с никаким руководством.

          • legacy_Зигмунд_Фройд

            Ты ещё объясни заказчику, что юнит тесты писать надо, ага.

            • legacy_СупаЛид

              И объяснял. И про юнит, и про отдельных тестеров, за которых платить надо, и про то, почему мы просим клиента самого тестировать перед коммерческим релизом, и то, почему мы не устраняем баги бесплатно, если клиент не тестирует сам, и про то, что после запуска команда еще 2 недели остается на проекте и это время оплачивается. Просто надо разговаривать и объяснять на понятном клиенту языке, а не стоить из себя хер пойми что или сидеть, засунув язык в жопу.

              • legacy_Зигмунд_Фройд

                Повезло с клиентом.

              • legacy_Зигмунд_Фройд

                И как, время и бюджет на юнит-тесты утвердили?

          • legacy_Am_Dm

            СупаЛид, ты только что детально описал идеальную работу для тех, кто «знания обширны, но поверхностны», другими словами, для тех 95%, которые по-настоящему делать нихуя не умеют и не собираются уметь.
            Не получать четких однозначных задач от заказчика — это значит иметь постоянную возможность «не так понять» Эти вечные уточнения — зелёная улица для работы абы как, один хер переделывать, никто и вникнуть не успеет. И самое сладкое — этот процесс может тянуться годами, а зарплата капает. Кого ебёт качество конечного продукта, за который больше ничего не отломится?
            Тебя на костре бы сожгли за критику всего этого. Спасает только то, что спички им делают такие же дауны и они тоже «требуют доработки»

          • legacy_Зигмунд_Фройд

            Разобраться в бизнес процессах, опросить конечных пользователей/стекхолдеров — это работа для БА и/или архитекта.

            Cледить за тенденциями в бизнес-сфере — зачем? Ты долю имеешь с продукта? Или думаешь, что заказчик оценит?

            То есть, этим всем девелопер должен заниматься? Зачем тогда нужны ба, аркитекты, тестеры и прочие пмы?

            Какой MVP, если обычно идёт поддержка продукта. Или добавление фич, которые хочет заказчик. Всё и сразу никогда не делают, это даже идиот понимает.

            Какой-то сферический проект в вакууме, на котором ОП совладелец или имеет некислые бонусы. Тогда да, ему есть смысл жопу рвать.

  • legacy_f4091876df6a5d39e6690b7395a95399

    Оооокститесь, Fuckup Driven Development это наше все

  • legacy_Алексей

    Не понимаю, чего все разпизделись. Мне как говнокодеру, никогда не слышавшему про все эти термины, интересно читать подобные статьи, чтобы хотя бы иметь представление чем там живут гребцы на галерах.

  • legacy_Зигмунд_Фройд

    Не пеши больше.

    • legacy_Админ

      не соси больше. хотя ладно, соси.

      • legacy_Зигмунд_Фройд

        Что, не можещь прекратить сосать? Даже самоуговоры не помогают? Дебе к доктору надо.

  • legacy_devnull_1

    Тут становится интересно, неужели, к примеру, Cicklum — джамшуты от софта?

    Блять, прям новость — вспышка. Статья ниачем.

  • legacy_Зигмунд_Фройд

    Кстати, заметили, что я не привел в пример Win95 и Win8? Потому, что их делали по Agile.

    Да ну.

    https://ru.wikipedia.org/wiki/Microsoft_Solutions_Framework

    Аджайл Манифест вышел в 2001

    • legacy_Зигмунд_Фройд

      Первая версия MSF появилась в 1994 году.

      • legacy_Ревун

        Мне тоже понравилось что по мнению автора, агиле начали использовать еще до того как оформили основные принципы методологии. Он бы еще разработку DOS в агиле записал )))

  • legacy_Зигмунд_Фройд

    Кстати, такие вещи, как TDD (Test-Driven Development) и постоянный рефакторинг, не имеют отношения к методологии Agile или Waterfall. Это просто качество кода

    Лососни тунца:

    https://www.vectorcast.com/blog/2017/06/comparing-waterfall-testing-and-test-driven-development

    • legacy_Зигмунд_Фройд

      Ставь дизлайк, если лососнул.

  • legacy_Cogniance_HR

    Мы начисляем зарплаты по Agile а платим по Waterfall, если вы понимаете о чем я.

  • legacy_Мимо_Scrum_Master

    Рассказал как в лужу пёрнул.

    А теперь на пальцах:

    Хочешь сделать БЫСТРО, ДЕШЕВО и С МИНИМАЛЬНЫМИ РИСКАМИ — это Agile.

    Хочешь делать продукт для тех кто им будет пользоваться — это Agile.

    Хочешь построить мост через Днепр — это Waterwall.

    Хочешь перечитывать и составлять тонны макулатуры — это Waterwall.

    По сабжу в чистом виде юзать и ту и эту методологию будут разве что аутисты, под каждый бизнес процесс нужно подбирать максимально результативный набор практик.

    • legacy_Зигмунд_Фройд
      • legacy_Мимо_Scrum_Master

        а это себе в жопу засунь

    • legacy_Селезень_аргентинской_озерной_утки

      так и есть.

    • legacy_местный_1

      >>>Хочешь построить мост через Днепр — это Waterwall.

      это раньше было. сейчас в Днепре мост через Днепр по эджайлу чинят.