Comments 19
Что-то в яндексе применяют кроме agile и непрерывной интеграции?
Яндекс очень большой — в том или ином смысле применяются все описанные практики
Мне чисто интересно: а водопадный процесс вообще эффективен в сравнении с agile? Или он просто существует потому, что есть команды с маленьким опытом, которым трудно выйти на процессы с короткими релизами или непрерывной интеграцией? Типа, "мы слышали про комбайн и трактор, но в нашем селе всë ещë пользуются плугом, поскольку нет ни одного механика, но зато в каждом дворе - по кобыле"?
Вы не знаете что такое водопадный процесс.
Можно работать в водопадном процессе с горизонтом планирования в один месяц: составил документацию за неделю и приступили к реализации за 2 недели, ещё неделя на интеграцию, тестирование и исправление.
Скрам это когда у нас группа проектная без управленца, есть бизнес, который приносит задачи и есть группа, которая сама через скрам процессы управляет сама собой. Сбоку есть некий ментор, который следит, что процесс соблюдается, процесс, но не наполнение его. Там нет тимлидов и менеджеров, все разбираются во всем сами. Только в конце есть принимающий или не принимающий бизнес.
А то в чем вы, наверное, работаете это ватерфол, просто с итерациями в 2 недели и атрибутами скрама. Тоже решение, если подходит.
В теории скрам хорошо работает у «свободных каменщиков»-фрилансеров, собрались, сделали и разошлись, но на практике у нас получилось только в аутсорсе, где работает много людей на пол ставки.
Трактор - это когда у нас колхоз без барина. Есть партия, которая приносит план, и есть крестьяне, которые управляют сами собой. Сбоку есть некий комиссар, который следит, что план выполняется. План, но не традиции. Там нет дворянства и барщины, все разбираются во всем сами. Только в конце есть принимающая или не принимающая партия.
А то с чем вы, наверное, работаете это плуг, просто достаточно современный и не хуже трактора. Тоже решение, если подходит.
А если серьëзно, то ваш комментарий очень и очень далëк от понимания процессов. Во-первых, Agile и Scrum - это разные вещи. Scrum - это подход, который может использоваться в методологии Agile. Во-вторых, тот кто вам сказал, что в Agile нет тимлида и овнера, очень сильно вас обманул. Самоуправление команды - это микроменеджмент. Этим не занимается даже бизнес в ватерфлоу. На мой взгляд, ватерфлоу - это вообще отсутствие микроменеджмента и, в большинстве случаев, эта схема работает, пока не упирается в более или менее объëмный и сложный проект. Тогда выясняется, что под ватерфлоу имеется ввиду неотлаженный процесс, а под критикой Agile - нежелание его менять.
Все о чем я написал относится конкретно к скрам, а не ко всему аджаил.
В аджайле есть еще: бережливое производство, канбан, fdd, bdd, Dynamic Systems Development Method, и т.д.
Это разрозненные и часто противоречащие друг другу техники, поэтому невозможно описать весь аджаил. Например, канбан это управление процессами, ритм работы, а скрам управление продуктом, что в скрам обязательно - не обязательно в канбан.
Понимаете о чем я, да?
В скрам нет тимлида, все равны, Scrum Alliance прочитайте, владелец есть, комиссар есть, а менеджера нет. А в канбане обязан быть (менеджер поставки).
Думаю, что вы запутались.
И как всë, что вы писали мне о скраме соотносится с тем, что я изначально писал про Agile?
Аджаил это набор техник в который входит скрам, это не две разные вещи.
Аджайл - это механика. Ты поставляешь код короткими итерациями. Но это требует дисциплины: покрытие тестами, соответствие стандартам, описываемым статическими анализаторами. Это несколько больше, чем "напишем сайт любой сложности", коллега. Хотя, вот та хрень в кавычках - это то, что подходит под ватерфолл процесс. Чуть больше - это яйца в кулак и изучать гибкие методологии. Отставить кофе в 9 утра. Отчитываться за код каждые два часа, и раз в день - на Дэйли. Готовность релиза каждый час. Это не грëбаной фриланс. Это продуктовая разработка.
Объясню проще: вы поставляете метод класса, коллега. Я делаю ревью. Это возможно раз в пол часа. Я нахожу сотню причин не пропускать ваш код. Он не может быть переписан за пять минут? Я его не пропущу. Он не покрыт тестами? Я его не пропущу. Он не соответствует стандартам линтера? Я его не пропущу. Мой коллега, который пишет код, который проходит эти проверки, сдаëт по пять задач в день и по функционалу в неделю. Он работает 8 часов. Он растит детей. Он занимается спортом, ходит в кино, сидит в кафе с семьëй. Он закрывает по майлстоуну в месяц. И вы мне рассказываете про то, что плуг круче трактора. Ой, сорри, про то, что водопадка круче гибкой методологии, коллега. Займитесь собой! Если у вас жëсткая привязка к релизу и между релизами нет контроля, то я вам сочувствую.
Аджайл не механика, а группа методологий.
Ватерфол это планирование и сдача в день X, если вы про итеративную разработку, то наверное, про скрам и канбан.
Тесты, линтеры, ревью и любые другие практики можно применить в любой методологии.
Вероятно для вас аджаил это скрам и в том формате, в котором много лет работаете.
Глобальная разница между ватерфолом и скрамом это время доставки продукта, это влияет на качество подготовительных и приемочных работ. Скрам это много маленьких ватерфолов в котором сократили проектирование и внедрение, параллельно выполняя все возможные процессы и присыпали сверху скрамм процессы.
В скраме из-за жесткой привязки к спринтам в 2-4 недели не уделяют много время определению требований, написанию заранее приемочных тестов и связи всех модулей, проектированию, а делают итерациями или часто одновременно и разработку и проектирование. Из-за этого накапливается набор ошибок, несоответствий, которые исправляют в тех долг спринтах. А так как каскад подразумевает переход к разработке после того как есть прототипы, макеты, критерии/требования и документации у всего модуля или проекта, то таких ошибок меньше.
Там где важна скорость и выход в тестирование гипотез - берез скрам, там где важен процесс и точность срока поддержки - берем канбан, где важна надёжность и законченность берем ватерфол.
Вероятно, возможно... Вы так жаждете угадать мой рабочий процесс? Может, вам воспользоваться хрустальным шаром?
Что касается остального, то вы, хотя бы, представляете что такое непрерывная интеграция и непрерывная поставка? Магистральный процесс? У вас какое-то странное понимание Agile и нездоровая мания сводить всë к Scrum.
Методология - по сути своей -это и есть набор методов или механика. То есть, набор механизмов. В нашем деле метод и механизм созвучны по смыслу.
Изначально, Agile создавался и описывался, как методология работы в условиях недостаточного планирования (например, часто меняется ожидание конечного результата). Но, важнее то, что представляет собой Agile сейчас.
Во-первых, итерация в Agile сегодня - это не маленький водопадный процесс, хотя в официальном определении итерации присутствуют всё фазы, характерные для водопадки. Просто дело в том, что за время существования гибких методологий, разработчики стремились оптимизировать большую часть процессов, не связанных напрямую с кодингом и, частично, тестированием. Поэтому, сейчас каждая итерация аджайл содержит автоматизированные этапы. Это, частично тестирование и полностью - интеграция. Поэтому, продукт, создаваемый в Agile, должен быть готов к развëртыванию (или интеграции) в любое время. Это главное отличие современного Agile от водопадки, на мой взгляд.
Ещë один важный момент - это проектировка. А точнее, документация. Agile частично автоматизирует документацию. Точнее, требует еë автоматизации. И ещë одна особенность: зачастую, анализ и проектирование выносятся за пределы итераций - в отдельные сессии проектирования. Дело в том, что Agile, как ни странно, не запрещает создавать основательную проектную документацию до начала разработки. Гибкая методология даже не препятствует работе по жëсткому сценарию. Но только, если исключить из применяемых механизмов Scrum с его фэйс-ту-фэйс проектированием и бережливую разработку, ограничивающую работу аналитиков и инженеров. Ну и ещë пару методов, относящихся к замене проектировки быстрым моделированием.
Сам Agile можно охарактеризовать, как подход, позволяющий поставлять код непрерывно, короткими итерациями. Когда-то это решало проблему неявного ТЗ или его отсутствия. Сейчас, благодаря автоматизации, его можно использовать, в том числе, для проектов с развитой проектной документацией. По сути, большая часть методов, применяемых в Agile, направлена на автоматизацию отдельных этапов развëртывания, тестирования, документации. Но, для обеспечения подобной автоматизации на должном уровне, как и скорости разработки, либо изменяемости продукта, приходится применять такие подходы, как, например, TDD, экстремальное программирование, FDD.
Если посмотреть на манифест Agile внимательно, то можно выяснить следующее:
То, что работающий продукт важнее исчерпывающей документации, не означает, что документация не может быть исчерпывающей. Просто продукт, и вправду, важнее всегда.
То, что сотрудничество с заказчиком важнее согласований условий контракта, не означает, что вы не можете согласовывать эти условия сколь угодно долго. Agile позволяет создавать легко изменяемый продукт. Вы можете прийти к необходимости согласовать изменения, или никогда не выйти на эту необходимость. Однако, изменяемый продукт лучше неизменного, поскольку практика показывает, что в изменениях нуждается почти 100% рабочего ПО со временем.
Единственное важное препятствие для Agile - готовность заказчика тесно сотрудничать с разработкой. В остальном, ничто вам не мешает создавать изменяемый продукт короткими итерациями, но иметь при этом отдельную сессию проектирования и жëстко согласованный план релиза. Agile является гибким не только в отношении требований, но любых внешних факторов.
Всё я проиграл, Аджаил лучшая методология.
Вы так пишете, будто вотерфолл - это плохо.
А он отлично подходит к ситуациям, когда ТЗ чётко определено, используется хорошо обкатанная и знакомая технология, и гибкость при разработке не нужна. С ходу могу назвать аэрокосмическую индустрию, но думаю много где применяется.
Когда кодовая база - большая - плохо. Вообще, водопадка актуальна в некоторых случаях. И я часто вижу, что еë пихают туда, куда не надо. Одна из наибольших ошибок при некорректном выборе водопадки - это выбор на основании наличия чëткого тз. Или понятного графика релизов. Водопадку следует выбирать, основываясь на двух параметрах:
Стопроцентно не будет тесного взаимодействия с заказчиком/бизнесом на протяжении разработки.
Небольшой планируемый размер кодовой базы.
Собственно, водопадка подходит для разработки ПО контроллеров, прикладного ПО, небольших сайтов. И вот в последнем случае, проектная разработка зачастую лезет в продуктовую со своим водопадным процессом, тогда как продуктовая разработка и постоянная автоматизация требуют непрерывной поставки изменений. Либо, часто меняются бизнес-требования и ожидания.
Также, при водопадном процессе существует иллюзия сложности разработки. У меня был опыт работы с готовым коммерческим продуктом, после которого я посмотрел на похожую разработку проектной команды, но построенную на водопадке. Команда искренне убеждена в высокой сложности своей разработки. В смысле, что такое до них типа никто не делал. И это заблуждение. Просто водопадка не позволила облегчить поставку кода и обрабатывать изменения со стороны бизнеса.
Ещë одна особенность: Agile - это надстройка над процессом, контролирующая больше аспектов. Из-за непрерывной поставки изменений, приходится многое автоматизировать и применять особые подходы. Например, экстремальное программирование, разработку через тестирование, полностью автоматизировать деплоймент, применять линтеры и т.д.. Собственно, введение этих вещей в вашу разработку, по сути, делает еë гибкой, позволяя контролировать процесс на коротких итерациях. Это меняет код, делая его тестируемым и готовым к срочным изменениям. Здесь же происходит эволюция архитектуры. Поэтому, Agile может существовать внутри водопадных релизов. Водопадка вообще не предъявляет требований к микроменеджменту разработки до момента релиза. Поэтому, когда мне говорят, что водопадка типа противопоставляется Agile, я вижу, прежде всего, разработчиков, которые не задумываются об архитектуре проекта, о тестировании. Не могут контролировать свой процесс на коротких отрезках. Им удобнее сказать, что Agile - это не их процесс, чем добиваться совершенства. И, пока разработка не сталкивается с резким ростом кодовой базы, либо, с ускоренными изменениями в бизнесе, примитивная модель без усложнения работает.
да, непрерывную пенетрацию
Вроде статья про экстремальные практики, а про правку кода на проде под нагрузкой через CLI ничего не сказано.
Экстремальные практики программирования: что, как и зачем