Комментарии 38
Аджайл это ценности.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Эти ценности буквально говорят, что главное — качественный продукт кастомеру. Если ваши процессы мешают созданию продукта, то подвиньте их. Потому что «Working software is the primary measure of progress».
В хороших командах эти ценности позволяют в спорных моментах принимать правильные решения в пользу проекта.
В плохих командах эти ценности используют для защиты собственных интересов членами команды при срывах сроков и прочих проблемах.
Если представить все это как уравнение, то ценности и принципы — это коэффициент. Что умножаешь на этот коэффициент, то и получаешь в итоге, только в большем количестве.
Если команде с плохим менеджментом (менеджмент это не только менеджеры, которые ставят тасочки, это в целом культура и процессы в команде, уровень планиварония, отношение к проекту, понимание своих обязанностей), просто так взять и начать работать руководствуясь принципами гибкой разработки, то это чаще приведет к еще большему бардаку. Если в команде отсутствовало грамотное планирование, оно не появится, если просто поддержать эти ценности. Если у членов команды были проблемы с ответственностью и налаживанием процессов, то «individuals and interactions over processes and tools» будет использоваться как оправдание.
Как же придерживаться этих ценностей на практике и получать хороший результат?
Для этого можно посмотреть на вполне рабочий Scrum, который «аgile framework» — набор готовых инструментов, позволяющий работать, придерживаясь вышеуказанных ценностей. Набор описанных процессов и правил, следуя которым, вы будете делать продукт быстрее и с лучшим контролем качества, регулярнее доставлять продукт кастомеру и более гибко реагировать на изменения.
Почему Скрам позволяет работать по принципам Agile, можно понять, взглянув на его «внутренности». Там вдруг оказывается куча правил, которые нельзя нарушать, множество ограничений, ежедневные строгий контроль результата, постоянные митинги, тщательное планирование, ответственность каждого члена команды за результат. Скрам — это про хороший, внимательный к мелочам менеджмент.
Да, есть еще «пацанский» Scrum, когда команда просто переходит, к примеру, на спринты, оставив при этом все старые плохие привычки в процессах, и считает что этого достаточно. А потому статьи пишут, какие эти ваши скрамы с аджайлами говно.
Аджайл это хорошо, потому что это работа на результат. Чем слаженней команда, чем устойчивее процессы в ней и чем лучше дисциплина, тем больше подобные принципы помогают достичь желаемого результата. Потому что за гибкостью стоит слаженная работа, которая невозможна без дисциплины, хорошего менеджмента, планирования.
хорошей команде при адекватном менеджменте аджайл (плюс другие фреймворки, позволяющие сделать процесс разработки и доставки управляемым)… просто не нужны!
Или например такие вещи как увеличение фирмы/отдела. Что вы например будете делать если у вас вдруг из одной команды нужно сделать две, три, пять, десять потому что фирма растёт и растёт обьём работ?
Чтоб два раза не вставать… Вам не кажется, что автор статьи пришел из какого-то культа? Там характерные фразы про завоевание, присвоение успехов и соответственно сваливание вины за неудачи, неприятие прямо противоположной точки зрения просто потому, что она явно противоречит его принципам и т.д.
Насчет правильноги и неправильного agile… Не, ребята, так не пойдет. Методология или есть или нет. Если есть, что отвественность за неудачи лежит именно на методологии, а не на том, что «ее неправильно применили». Неправильно применили потому, что методология допускает неправильное применение.
Ответ на вопрос почему программисты не хотят больше играть в agile прост — наигрались. Мы любим играть. Это в натуре у нас — пробовать все новое. Но так-же как и у детей как только стало понятно что это и зачем — разобрать, сломать и выбросить за ненадобностью. Так и с agile — новизна ушла, магия кончилась, интерес пропал. На самом деле разработчики гораздо больше понимают в разработке ПО, чем все эти мастера, коучи и консалтеры вместе взятые. Поэтому впарить то, что не дает весомых приимуществ, очень сложно. Оно может таже в итоге выгладеть «как положено» (зомби agile), но внутри все равно будет именно тот процесс, что выбран программистами.
По всему вышесказаному, считаю, что единственая методология — отсутствие таковой. Точнее команда всегда сама выбирает как ей работать. Очень правильно все описано в оригинальном варианте «programming mother...» / «пиши код...» (русский перевод настолько искажен, что лучше его вообще не читать).
Разбивать сыгранную команду — преступно
Это может быть насколько угодно преступно, но это происходит повсеместно, даже в самых лучших фирмах. И часто действительно из необходимости и не по желанию самой фирмы. Люди болеют, увольняются, уходят на повышение и т.д. и т.п.
Фирма конечно может надеяться что сыгранная команда останется сыгранной на протяжении десятилетий, но как минимум по моему опыту каждые полтора-два года происходят какие-то изменения.
Насчет правильноги и неправильного agile… Не, ребята, так не пойдет. Методология или есть или нет.
Методология Agile как такового на самом деле очень гибкая и «разрешает» многое. Поэтому Аgile-процесс может быть кривым до невозможности и всё равно оставаться в рамках Аgile.
Ответ на вопрос почему программисты не хотят больше играть в agile прост — наигрались.
А вот тут надо говорить за себя. Я например всё ещё хочу в это играть. Потому что Agile далеко не идеален, но лучшей альтернативы я лично пока не вижу.
По всему вышесказаному, считаю, что единственая методология — отсутствие таковой. Точнее команда всегда сама выбирает как ей работать.
Извините, но это и есть Agile. И в нормальном Agile команда подстраивает процессы под себя. Но процессы всё равно есть и все в команде должны и им следовать. Ну или совместно их менять.
Знаком с компанией, в которой, по сути, разработка идёт по принципу "х**к, х**к, и в продакшн". Менеджмент гордо называет это аджайлом. Нет, есть Git, Bitbucket (правда, совсем не везде), есть код-ревью (правда, совсем не всегда), есть дев-сервера (на которых из-за специфики некоторые вещи не обкатываются)… TDD нет от слова "совсем". Кодовая база на миллионы строк кода (не считая библиотечного). Маленькая команда разработчиков, человек 6-7. Не все старожилы (самые старожилы давно куда-то улетели), не все сениоры и даже миддлы. А компания с 90-х растёт и процветает. У разработчиков работы всегда много, но почти никогда никто не стоит за спиной, допрашивая насчёт дедлайна. Никто не перерабатывает (супер-серьёзные деплои делают ночью, но это очень редко). В целом, все довольны жизнью. Такое, вообще, возможно, или они в сказку попали?
Agile Yahooтак толсто, что даже тонко.
Очень много букв :-), но, в общем, соглашусь.
Ещё добавлю фразу-вопрос одного топ-менеджера про то, зачем Agile'ом называть здравый смысл.
На мой взгляд, различные фреймворки (XP, Scrum, DSDM и т.п.) — это способы понять, о чём Agile, но беда в том, что некомпетентность всё развращает.
В основополагающих принципах Agile нет ничего нового и ранее до Agile никому неизвестного. А некоторые из них противоречат один другому согласно принципу выбери два из трех: Качественно — Быстро — Дешево.
Все ищут волшебную таблетку, которой в реальности нет и никогда не было. Думать надо самостоятельно и организовывать работу в соответствии с решаемыми задачами. Если есть для этого уже готовые подходящие методики и инструменты, их надо использовать. Только смотреть насколько они подходят именно вам, а не пихать всех подряд в прокрустово ложе одного из многих методов.
Так же используется agile.
Благими намерениями выстелена дорого в ад.
В ад похоже уже пришли.
У нас Agile — поэтому мы внесём критические правки в задачи спринта за 2 дня до релиза.
У нас Agile — средняя загрузка разработчиков по оцененому времени за спринт 600%.
У нас Agile — поэтому нет времени на документацию.
У нас Agile — и мы будем делать по 5-7 часовых встреч в день, работать — в любое остальное время.
Раньше это называлось «у нас хреновый руководитель».
П.С. По хорошему всё что Вы описали в нормальном Agile/Scrum не прокатывет потому что команда говорит на это всё четкое «нет» и делает по своему. А если команде не дают делать по своему и какой-то «руководитель» со стороны командует вам что делать, то какой это тогда Scrum?
Наверное, скоро будут флажки выпускать, и чую, у всех компаний над входом в HRрню будет висеть одинаковый набор «корпоративные ценности, стрессоустойчивость, нацеленность на результат, Agile»
PS Причём, флажки будут грязными, потому что их повесят и забудут до Дня Компании.
А о сути флажков забудут ещё в процессе крепления этих флажков.
Зайдите в крупный банк, процентов 70 любых проектов будет именно такими, заодно посмотрите на забавный жизненный цикл:
1. выпуск-без-тестов новых фич под «личную ответственность бизнеса»
2. критические ошибки на проде из-за 1 пункта
3. грязные разборки, где оказывается виновата виновата команда, потому что бизнес не мог оценить масштабов трагедии, команда должна была настоять на своём
4. смещение слишком принципиальных руководителей в замы и постановка своего человека, который будет выжимать команду
5. уходы ключевых людей из команды из-за п.4, про реальные роли которых новый руководитель не успел/не захотел узнать
6. goto 1
Нет, есть и хорошие команды, с правильными процессами и руководством, которое умеет показать бизнесу, что если мы ускоримся — будет писец, поэтому мы будем дальше работать по согласованному плану, но это явление не частое.
На мой взгляд Scrum/Agile вполне себе работают если люди хотя бы пытаются чтобы они работали. То есть я нигде не видел 100% Scrum, но я вполне себе видел варианты, когда то что было вполне себе работало. И работало лучше чем «водопад» или отсутствие любых нормальных процессов.
Многие уроки можно извлечь из таких гуманитарных наук, как позитивная психология, направленное самосовершенствование и решение-ориентированная терапияподступил ком к горлу, но комменты на удивление позитивные — никто не стал лить воду в стиле эджайл-коучей и скрам-мастеров
Единственный способ прийти к тем же ценностям, к которым пришли те 15 человек в 2001 году — это пройти путь, похожий на тот, который прошли они.
почти все маленькие частные компании в любой отрасли работают применяя гибкие методы (иногда сами того не зная)
Скорее нет, чем да. Agile — это не про «делать разные мелкие задачи», а про «делать одну крупную задачу, не имея полной проектной документации». Индивидуальный проект по изготовлению мебели, он не эджайл. Вы пришли к клиенту, согласовали проект, получили предоплату, и делаете в точности по проекту. Изготовили, отдебажили (где что не влезает или не совпадает с ожиданиями клиента), запустили в продакшен, получили оплату. Это просто короткоживущий, но ни разу не гибкий проект.
Почитайте Сазерленда (первую книгу). Он приводит пример компании, которая делает автомобили на заказ и работает по гибкой методологии. Я уже не говорю про то, что все эти практики в IT вдохновлены опытом Toyota, а Сазерленд выводит свою методику из того, чему его учили к военного летчика.
Кризис Agile. Что делать?