Т.е. ебучий ватерфолл круче всего, ага?
23.04.2021, 10:59
Ага, а Скрам и Канбан - это частные реализации методологии Аджайл. В общем автор (не переводчик, если все правильно переведено конечно) еще тот надмозг, слышал звон, да не знает где он.
ловите хипстера
Методологией аджайл называет только те кто впаривает курсы/сертификацию/консультантов по скраму-сраму и прочим.
Есть "Agile manifesto" т.е. ценности и принципы. А поскольку перенять "ценности" через слепое повторение ритуалов и атрибутику невозможно, то как правило внедрение скрама(или любой другой херни) заканчивается как построение коммунизма.
Стоит глянуть "Land than scrum forgot" от одного из авторов оригинального манифеста аджайл.
Есть "Agile manifesto" т.е. ценности и принципы. А поскольку перенять "ценности" через слепое повторение ритуалов и атрибутику невозможно, то как правило внедрение скрама(или любой другой херни) заканчивается как построение коммунизма.
Стоит глянуть "Land than scrum forgot" от одного из авторов оригинального манифеста аджайл.
Ну, и именно у нас это нижуя не работало по книжке, а работало "по правде"! (говорю как один из организаторов Аджайл самит в Гданьске, ох и постебались мы с настоящих уверовавших) :)
Ватерфолл это скорее то что согласовали полет на марс, а потом оказалось что бюджета не хватает и вообще клиент подумал что на луне интереснее, но У НАС БЛЕАТЬ УЖЕ АРХИТЕТКТУРА СОГЛАСОВАНА ВСЕ СОГЛАСОВАНО ВОТ ВАШИ ПОДПИСИ ЧЕРЕЗ 20 ЛЕТ НА МАРСЕ ПОСЛЕ СДАЧИ ОБСУДИМ ДОРАБОТКИ.
Дядя, а ты правда разработчик, или попиздеть пришел?
Изначально задача бизнеса и есть максимально абстрактная - сделать что-то. В одно предложение. Потом эта идея детализируется, обрастает подробностями, вырабатывается архитектура и так далее. И по идее "водопада", которую, кстати, даже автор термина не предлагал использовать, прорабатывается детальная архитектура, и только потом, после утверждения ТЗ, ее реализует программист. Проблема только в том, что либо архитектуру придумывает не разработчик, и потом этим ТЗ можно только подтереться, либо разработчик, и тогда непонятно, с какого хера тогда он это сразу не закодил.
"Пидорский" аджайл как раз решает эту проблему разрыва между проектировщиком и исполнителем. Исполнитель участвует в проектировании, и при явной лаже может на это повлиять. Кроме того, из-за параллельного проектирования и исполнения значительно сокращаются сроки.
Суть разработки как раз в проектной деятельности, а не в том, чтобы закодить код. И если тебе кто-то в идеальном мире дал дал ТЗ, по которому не надо думать, то он уже сделал 90% работы. И тогда зачем здесь ты?
Изначально задача бизнеса и есть максимально абстрактная - сделать что-то. В одно предложение. Потом эта идея детализируется, обрастает подробностями, вырабатывается архитектура и так далее. И по идее "водопада", которую, кстати, даже автор термина не предлагал использовать, прорабатывается детальная архитектура, и только потом, после утверждения ТЗ, ее реализует программист. Проблема только в том, что либо архитектуру придумывает не разработчик, и потом этим ТЗ можно только подтереться, либо разработчик, и тогда непонятно, с какого хера тогда он это сразу не закодил.
"Пидорский" аджайл как раз решает эту проблему разрыва между проектировщиком и исполнителем. Исполнитель участвует в проектировании, и при явной лаже может на это повлиять. Кроме того, из-за параллельного проектирования и исполнения значительно сокращаются сроки.
Суть разработки как раз в проектной деятельности, а не в том, чтобы закодить код. И если тебе кто-то в идеальном мире дал дал ТЗ, по которому не надо думать, то он уже сделал 90% работы. И тогда зачем здесь ты?
"Исполнитель участвует в проектировании, и при явной лаже может на это повлиять"
это и вотерфолле может и должно присутствовать.
"значительно сокращаются сроки"
ни фига. больше времени тратится на всякую организационную херню, которая в нормальной команде просто не нужна.
"Суть разработки как раз в проектной деятельности, а не в том, чтобы закодить код"
што? как появится результат, если не кодить код?
и я тебе больше скажу, хера ты запроектируешь, если не будешь кодить. результат такой проектной деятельности можно можно сразу сгружать /dev/null
это и вотерфолле может и должно присутствовать.
"значительно сокращаются сроки"
ни фига. больше времени тратится на всякую организационную херню, которая в нормальной команде просто не нужна.
"Суть разработки как раз в проектной деятельности, а не в том, чтобы закодить код"
што? как появится результат, если не кодить код?
и я тебе больше скажу, хера ты запроектируешь, если не будешь кодить. результат такой проектной деятельности можно можно сразу сгружать /dev/null
На самом деле, в каждой команде что-то своё, главное, чтобы это всех устраивало, и было эффективным. К методологии разработки, как и ко всему остальному, нужно применять здравый смысл. Если блять на митинге команда спит, а утренний стендап похож на блядский цирк, то это надо перерабатывать. Для команды из пары сеньоров и толпы мидов и джунов методология не может быть ровно такой же, как для команды сеньоров. Разработка системной хуйни отличается от разработки сайтика. Где-то вообще нужно быть у клиента на местах, а не в уютном офисе. А правило для всех одно - здравый смысл и договоренность.
Скрам и заключается в том чтобы стать аджайл через бездумные ритуалы, в этом вся суть.
Потому что абстрактные идеи из Agile manifesto сами по себе не продать(всего 4 строчки текста!), а набор ритуалов с сертификатом можно продавать много раз, т.е. разные уровни и срок годности на сертификате.
Потому что абстрактные идеи из Agile manifesto сами по себе не продать(всего 4 строчки текста!), а набор ритуалов с сертификатом можно продавать много раз, т.е. разные уровни и срок годности на сертификате.
Ну да, так и есть.
Просто я как-то работал(недолго) в конторе, в которой было насрать на здравый смысл, зато ритуалы соблюдались неукоснительно. И там очень любили митинги. Общие, для всей команды. Настолько, что бывало, что в неделю рабочих часов наберется 5-6, остальное - языкочесание и зевание на бесконечных митингах, на которые было всем насрать.
Конечно, коммуникация - штука хорошая, но блять не до такой гипертрофированной степени. Хотя, народу там было нормально - ну и збс, но без меня.
Просто я как-то работал(недолго) в конторе, в которой было насрать на здравый смысл, зато ритуалы соблюдались неукоснительно. И там очень любили митинги. Общие, для всей команды. Настолько, что бывало, что в неделю рабочих часов наберется 5-6, остальное - языкочесание и зевание на бесконечных митингах, на которые было всем насрать.
Конечно, коммуникация - штука хорошая, но блять не до такой гипертрофированной степени. Хотя, народу там было нормально - ну и збс, но без меня.
Я тебе больше скажу. Есть куча методологий и практик (RUP, CPM, CCPM, LEAN, APF, MSF, XP, PRINCE 2, PMBOOK) каждая из которых хороша в своем и затрагивает разные аспекты. Но нет методологии, которая безоговорочно была-бы лучше остальных и применима во всех ситуациях.
Более того, если посмотреть статистику, то окажется что как для Скрама так и для Ватерфолла процент проебанных проектов приблизительно одинаковый. А на маленьких проектах он вообще вырождается в ебучий Ватерфолл. Что же до больших, то там Скрам в принципе не применим.
Но то что нужно понимать, что нет «Серебряной пули» для убийства монстра. А все эти холивары сродни потасовкам адептов разных конфессий и вероисповеданий.
Более того, если посмотреть статистику, то окажется что как для Скрама так и для Ватерфолла процент проебанных проектов приблизительно одинаковый. А на маленьких проектах он вообще вырождается в ебучий Ватерфолл. Что же до больших, то там Скрам в принципе не применим.
Но то что нужно понимать, что нет «Серебряной пули» для убийства монстра. А все эти холивары сродни потасовкам адептов разных конфессий и вероисповеданий.
oh, finally
Все эти новомодные методологии лишь способ создавать видимость работы путем разбития 1 задачи на более мелкие(а хуле, больше задач сделано значит эффективнее работает, молодец). Еффективные менеджеры почему-то не понимают что от уменьшения дедлайнов скорость разработки не увеличивается, увеличиваеться только кол-во багов которые потом будет фиксить кто-то другой.
это не для увеличения скорости, а для большего контроля и ловли ошибок на ранних этапах. в скраме ты видишь промежуточный результат через две недели и можешь что-то скорректировать. в ватерфоле ты видишь итоговый результат через полгода, тогда ошибки в тз исправлять на порядок сложнее
А что мешает проверять промежуточный результат в ватерфолле каждые 2 недели?
Для этого нужно определить что именно проверять что значит надо разбивать проект на подзадаяи, а Это уже agile в его чистом виде. Сейчас работаю на таком проекте, довольно комфортно. Нет ебли с бесполезными митингами и ебнутыми дедлайнами. Дев берет таску, делает ее ровно столько сколько нужно, потом тестер ее тестит и все. Эдакие мини ватерфалы без наворотов. Но это наверное заслуга того что я работаю над финансовой системой и если девов торопить то потом можно парочку нулей недосчитаться в своем миллионе.
> надо разбивать проект на подзадаяи, а Это уже agile в его чистом виде.
Ну покажи мне где в Agile Manifesto про "разбивать проект на подзадачи". И скрам не есть аджайл, тёплое с мягким путать не надо.
Подзадачи это нормальная практика в любой разработке, никакого отношения к аджайл это не имеет.
Прекрасно работал с ватерфолом где всё разбивалось на задачи и подзадачи. И периодически следили за тем как задачи выполняются или уточняли по каким-то конкретным тикетам.
Ну покажи мне где в Agile Manifesto про "разбивать проект на подзадачи". И скрам не есть аджайл, тёплое с мягким путать не надо.
Подзадачи это нормальная практика в любой разработке, никакого отношения к аджайл это не имеет.
Прекрасно работал с ватерфолом где всё разбивалось на задачи и подзадачи. И периодически следили за тем как задачи выполняются или уточняли по каким-то конкретным тикетам.
Столкнулся со скрамом.
Собрали "команду" из рандомных чуваков - 2 мобильных разработчиков и 2 фронтендеров, забили бэклог тикетами которые никто не знает куда девать, в том числе по сложному API бэкенду на котором висит буквально всё. Бэкендера не дали.
Один манагер насмотрелся видео на ютубе о скраме и решил что теперь он всё знает о разработке лучше всех, теперь он скрам-мастер и диктует всем как надо организовывать работу.
Далее спустили сверху план сделать 4 приложения для всех платформ на год, даже менеджер офигел и проговорился что это выглядит невыполнимым. Но ни требования ни сроки никто согласовывать не собирается, мнение пользователей тоже никто не спрашивает. Один фронтендер быстро свалил, я свалил вчера.
Когда руководство видит слово Scrum - они видят волшебный секрет как заставить разработчиков пахать в 2-3 раза быстрее/больше и обязать их каждый день отчитываться что они делают.
Того мудака что это изобрёл нужно связать и засунуть в глори холл в садо-мазо гей клубе.
Собрали "команду" из рандомных чуваков - 2 мобильных разработчиков и 2 фронтендеров, забили бэклог тикетами которые никто не знает куда девать, в том числе по сложному API бэкенду на котором висит буквально всё. Бэкендера не дали.
Один манагер насмотрелся видео на ютубе о скраме и решил что теперь он всё знает о разработке лучше всех, теперь он скрам-мастер и диктует всем как надо организовывать работу.
Далее спустили сверху план сделать 4 приложения для всех платформ на год, даже менеджер офигел и проговорился что это выглядит невыполнимым. Но ни требования ни сроки никто согласовывать не собирается, мнение пользователей тоже никто не спрашивает. Один фронтендер быстро свалил, я свалил вчера.
Когда руководство видит слово Scrum - они видят волшебный секрет как заставить разработчиков пахать в 2-3 раза быстрее/больше и обязать их каждый день отчитываться что они делают.
Того мудака что это изобрёл нужно связать и засунуть в глори холл в садо-мазо гей клубе.
Если тебе дали бензопилу, но ты используешь её как топор - это не значит, что бензопила плохая. Это значит, что ты не умеешь использовать бензопилу.
В нормальных руках, скрам - это очень крутая штука, позволяющая творить с проектом лютую дичь (со стороны исходных требований), но при этом соблюдать сроки и каждый раз получать новый готовый модуль продукта.
В нормальных руках, скрам - это очень крутая штука, позволяющая творить с проектом лютую дичь (со стороны исходных требований), но при этом соблюдать сроки и каждый раз получать новый готовый модуль продукта.
Чтобы стать скрам-мастером нужно пройти 2-х дневный семинар и получить сертификат, расскажи мастером чего вообще реально стать за 2 дня?
Как эти "нормальные руки" определять от ненормальных если любой дурак за бабки и пару дней становится дипломированным мастером?
Как эти "нормальные руки" определять от ненормальных если любой дурак за бабки и пару дней становится дипломированным мастером?
Что за феерический пиздец?
Как пилить мобилу или фронт если нет бека, и дату нужно хранить обрабатывать и отдавать?
Как можно подписаться на такое и планировать сдать проект, ладно если сидеть на жопе и получать зп а потом уйти в закат? А так-то ничего плохого в аджайле нет, если проджект или продукт овнер адекватные и понимают что они хотят на марс, а не сегодня мы хотим сделать квадрокоптер, а на следующей неделе 300 тонный пилотируемый пуск на уранус. Схожая ситуация в любой другой сфере, просто не стоит работать с долбоебами.
Как пилить мобилу или фронт если нет бека, и дату нужно хранить обрабатывать и отдавать?
Как можно подписаться на такое и планировать сдать проект, ладно если сидеть на жопе и получать зп а потом уйти в закат? А так-то ничего плохого в аджайле нет, если проджект или продукт овнер адекватные и понимают что они хотят на марс, а не сегодня мы хотим сделать квадрокоптер, а на следующей неделе 300 тонный пилотируемый пуск на уранус. Схожая ситуация в любой другой сфере, просто не стоит работать с долбоебами.
Это финальная часть истории моего выгорания, не только они в этом виноваты конечно.
Долбоебизм проявился неожиданно и очень быстро расцвёл.
Ты путаешь Agile со Scrum-ом.
Если адекватные то они будут решать конкретные проблемы, а не надеятся что какая-то чудо-штука решит всё за них.
Долбоебизм проявился неожиданно и очень быстро расцвёл.
Ты путаешь Agile со Scrum-ом.
Если адекватные то они будут решать конкретные проблемы, а не надеятся что какая-то чудо-штука решит всё за них.
Аджайл это методология, скрам/канбан просто разные итерационные подходы построенные на аджайл манифесте (это в сферическом вакууме). Комментировал в основном вот эту часть
> Собрали "команду" из рандомных чуваков - 2 мобильных разработчиков и 2 фронтендеров, забили бэклог тикетами которые никто не знает куда девать, в том числе по сложному API бэкенду на котором висит буквально всё. Бэкендера не дали.
Так как сам пишу кодец, ничего плохого ни спринтах ни даже в канбане не вижу. Главный вопрос вменяемого тз и видения проекта, без этого лазить в проект такое себе удовольствие.
> Собрали "команду" из рандомных чуваков - 2 мобильных разработчиков и 2 фронтендеров, забили бэклог тикетами которые никто не знает куда девать, в том числе по сложному API бэкенду на котором висит буквально всё. Бэкендера не дали.
Так как сам пишу кодец, ничего плохого ни спринтах ни даже в канбане не вижу. Главный вопрос вменяемого тз и видения проекта, без этого лазить в проект такое себе удовольствие.
> Так как сам пишу кодец, ничего плохого ни спринтах ни даже в канбане не вижу.
Да везде спринты(или дедлайны), софт для управления задачами и обсуждения/совещания. Это норма и без всяких модных слов.
Аджайл это "core values" - https://www.agilealliance.org/agile101/the-agile-manifesto/
Обсуждение https://www.scrum.org/forum/scrum-forum/6117/agile-methodology-or-framework-or-philosophy
> meth·od·ol·o·gy - a system of methods used in a particular area of study or activity.
> Главный вопрос вменяемого тз и видения проекта, без этого лазить в проект такое себе удовольствие.
Я и не лез. 3 других фронтендера туда слазили в добровольно-принудительном порядке, за месяц все разбежались.
Да везде спринты(или дедлайны), софт для управления задачами и обсуждения/совещания. Это норма и без всяких модных слов.
Аджайл это "core values" - https://www.agilealliance.org/agile101/the-agile-manifesto/
Обсуждение https://www.scrum.org/forum/scrum-forum/6117/agile-methodology-or-framework-or-philosophy
> meth·od·ol·o·gy - a system of methods used in a particular area of study or activity.
> Главный вопрос вменяемого тз и видения проекта, без этого лазить в проект такое себе удовольствие.
Я и не лез. 3 других фронтендера туда слазили в добровольно-принудительном порядке, за месяц все разбежались.
А как же "Кабанчиком"?
Да что б они были здоровые и отдохнувшие те, кто для приема каждого нового сотрудника, даже на замену уволившегося, требуют... серебряную пулю!
Чтобы написать коммент, необходимо залогиниться
