Телега за 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. Это просто качество кода.
Всем добра. А некоторым компаниям — буддистского перерождения».
Прислал Толстый Хрюк
Коментарі (93)
Две жалобы за сегодня — это слишком. Неужели никаких сплетен нет, типа айтишник украл электроинструмент у строителей, взломал вендинг или спёр сыр в супермаркете?
Breaking news! С мест сообщают, что у капитана за щекой больше, чем одно место
пройдите нахуй, уважаемый
Камеры видеонаблюдения показали, что ты выносишь колбасу за щекой. По одной палке за каждой.
http://google.gik-team.com/?q=%D0%BC%D0%B0%D0%B3%D0%B0%D0%B7%D0%B8%D0%BD+%D1%80%D0%B5%D0%B7%D0%B8%D0%BD%D0%BE%D0%B2%D1%8B%D1%85+%D1%85%D1%83%D1%91%D0%B2
Небо — голубое. Трава — зеленая. Быстро решительно сунуть себе в жопу хуй заказчика и упасть в обморок, лишьбы сделать — Agile. Красиво элегантно один охуенный минет заказчику — Waterfall.
Просто вы лохи и омежки, которых нагибают все, кому не лень. Хорошая agile-команда всегда имеет право сказать «нет» ебанутому требованию и не брать его в беклог. И, блять, найдите толковых аналитиков, чтоб куски кода не выкидывать.
И может пойти искать новую работу. Всей командой.
Я же и говорю — терпилы и омежки. Что сказали, то и делают. А грамотно требования собрать и согласовать не пробовали? Про MVP не слышали? Заказчик обычно вообще не рубит, что ему КОНКТРЕТНО надо, просто надо и всё. Ну так и предложите нормально решение, которое покрывает потребности. Но нет, нам этого не надо, мы же — кодери. Разобраться в бизнес процессах, опросить конечных пользователей/стекхолдеров, прототипы запилить, использовать лучшие практики и готовые решения, следить за тенденциями в бизнес-сфере — да нуууу, это какое-то говно для офисных планктонов. Мы — титаны кода! Мы хуярим говнокод по говнотребования говноменеджеров годичной давности, а потом удивляемся, что нас ебут постоянно. И не методология тут виновата, просто вы работаете в говнокомпании с никаким руководством.
Ты ещё объясни заказчику, что юнит тесты писать надо, ага.
И объяснял. И про юнит, и про отдельных тестеров, за которых платить надо, и про то, почему мы просим клиента самого тестировать перед коммерческим релизом, и то, почему мы не устраняем баги бесплатно, если клиент не тестирует сам, и про то, что после запуска команда еще 2 недели остается на проекте и это время оплачивается. Просто надо разговаривать и объяснять на понятном клиенту языке, а не стоить из себя хер пойми что или сидеть, засунув язык в жопу.
Повезло с клиентом.
И как, время и бюджет на юнит-тесты утвердили?
СупаЛид, ты только что детально описал идеальную работу для тех, кто «знания обширны, но поверхностны», другими словами, для тех 95%, которые по-настоящему делать нихуя не умеют и не собираются уметь.
Не получать четких однозначных задач от заказчика — это значит иметь постоянную возможность «не так понять» Эти вечные уточнения — зелёная улица для работы абы как, один хер переделывать, никто и вникнуть не успеет. И самое сладкое — этот процесс может тянуться годами, а зарплата капает. Кого ебёт качество конечного продукта, за который больше ничего не отломится?
Тебя на костре бы сожгли за критику всего этого. Спасает только то, что спички им делают такие же дауны и они тоже «требуют доработки»
Разобраться в бизнес процессах, опросить конечных пользователей/стекхолдеров — это работа для БА и/или архитекта.
Cледить за тенденциями в бизнес-сфере — зачем? Ты долю имеешь с продукта? Или думаешь, что заказчик оценит?
То есть, этим всем девелопер должен заниматься? Зачем тогда нужны ба, аркитекты, тестеры и прочие пмы?
Какой MVP, если обычно идёт поддержка продукта. Или добавление фич, которые хочет заказчик. Всё и сразу никогда не делают, это даже идиот понимает.
Какой-то сферический проект в вакууме, на котором ОП совладелец или имеет некислые бонусы. Тогда да, ему есть смысл жопу рвать.
Оооокститесь, Fuckup Driven Development это наше все
Не понимаю, чего все разпизделись. Мне как говнокодеру, никогда не слышавшему про все эти термины, интересно читать подобные статьи, чтобы хотя бы иметь представление чем там живут гребцы на галерах.
Не пеши больше.
не соси больше. хотя ладно, соси.
Что, не можещь прекратить сосать? Даже самоуговоры не помогают? Дебе к доктору надо.
Тут становится интересно, неужели, к примеру, Cicklum — джамшуты от софта?
Блять, прям новость — вспышка. Статья ниачем.
Кстати, заметили, что я не привел в пример Win95 и Win8? Потому, что их делали по Agile.
Да ну.
https://ru.wikipedia.org/wiki/Microsoft_Solutions_Framework
Аджайл Манифест вышел в 2001
Первая версия MSF появилась в 1994 году.
Мне тоже понравилось что по мнению автора, агиле начали использовать еще до того как оформили основные принципы методологии. Он бы еще разработку DOS в агиле записал )))
Логика такая — всё, что не ватерфалл, то аджайл. А спиральный метод тогда что?
https://en.wikipedia.org/wiki/Spiral_model
Кстати, такие вещи, как TDD (Test-Driven Development) и постоянный рефакторинг, не имеют отношения к методологии Agile или Waterfall. Это просто качество кода
Лососни тунца:
https://www.vectorcast.com/blog/2017/06/comparing-waterfall-testing-and-test-driven-development
Ставь дизлайк, если лососнул.
Мы начисляем зарплаты по Agile а платим по Waterfall, если вы понимаете о чем я.
Рассказал как в лужу пёрнул.
А теперь на пальцах:
Хочешь сделать БЫСТРО, ДЕШЕВО и С МИНИМАЛЬНЫМИ РИСКАМИ — это Agile.
Хочешь делать продукт для тех кто им будет пользоваться — это Agile.
Хочешь построить мост через Днепр — это Waterwall.
Хочешь перечитывать и составлять тонны макулатуры — это Waterwall.
По сабжу в чистом виде юзать и ту и эту методологию будут разве что аутисты, под каждый бизнес процесс нужно подбирать максимально результативный набор практик.
https://en.wikipedia.org/wiki/Spiral_model
А вот это?
а это себе в жопу засунь
BOMBANULO
так и есть.
>>>Хочешь построить мост через Днепр — это Waterwall.
это раньше было. сейчас в Днепре мост через Днепр по эджайлу чинят.