Как стать автором
Обновить

Как объяснить бабушке, что такое Agile за 15 минут с картинками

Время на прочтение7 мин
Количество просмотров1.2M
Всего голосов 72: ↑63 и ↓9+54
Комментарии36

Комментарии 36

Все Agile-методологии выглядят просто потрясающе: на бумаге, в книжках, в презентациях, на видео.
Но в один прекрасный момент ты осознаешь себя сидящем на 4х часовом митинге, рядом с другими, такими же программистами с грустными глазами и мы все вместе раскрашиваем цветные бумажки, играем в карты и голосуем за фичи "ногами", просто потому что так "веселей".

Какая по-вашему идеальная методология?

Дак не может быть этой самой, идеальной. В Аджайле есть приятные моменты, для меня это скорость обратной связи и вообще нацеленность на неё. Наличие ответственного за продукт.
Остальное не особо профитное из моего опыта. Оценка задач, а в особенности ПользовательскихИсторий(плохая проработка задачи) — это пальцем в небо (ну когда задачи не точь в точь близнецы прямо). А с этого момента начинается крах подхода, ИМХО.

Я только за аджайл, и считаю его передовой методологией сегодня.
Но прочитав комментарий PkXwmpgN я подумал, может я что-то пропустил, и бывают методологии без выматывающих митингов и нелепых действий?

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

Забавно, но мы как то быстро проехали этап выматывающих митингов.
Почти каждый день минут 20 на всех с утра что делал, что будешь. Мне, как аналитику в проекте, очень полезно понимать чем живет команда в данный момент.
Спринт 4 недели, ретро примерно час-полтора, опять же по проблемам вырабатываем пути улучшения и пишем на доске перед глазами.
Планированием занимается руководитель, совещаясь с причастными. Это сильно лучше, чем по началу с картами. Вот там прогеры и тестировщики «помирали», а я точнее чем они оценивал их же задачи =)

Извините за токсичность, но это все равно, что сказать: "Я только за КАМАЗ! Лучшая машина!". Методология выбирается из условий, а не наоборот. Если вам надо возить грузы, тогда, конечно, КАМАЗ или другой грузовой автомобиль. Но покатать жену по магазинам проще на легковом автомобиле.

Если заказчику неудобно постоянно с вами контактировать или он хочет рассчитать бюджет проекта заранее (конечно же, заказчик точно знает, что он хочет получить на выходе, ТЗ на тот момент уже готово), то о каком Agile тут может идти речь?

А по-вашему существует идеальная методология?
Лично мне близка точка зрения Cord, изложенная здесь.

Нет идеальной методологии. Идеальная методология как таблетка от всех болезней. Выбор методологии должен определяться исходя из конкретных потребностей проекта и даже изменяться в течении жизненного цикла проекта (если проект не короткосрочный), если у проекта меняются приоритеты.
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется, ключевая особенность Agile (по русски правильнее говорить не «Гибкий» а «Адаптивный») как раз, в адаптации, в постоянном фокусе на улучшении (кстати, ничего не нашел про ретроспективу в статье, а жаль). В случае, как вы описали, скорее всего именно момент адаптации и постоянного улучшения процесса не учитывается полностью.
Вообще, уже было давно справедливо замечено, что Agile работает не во всех случаях и не у всех команд. Многие внедряют Agile квадратно-гнездовым методом, из серии, «А теперь, в дополнение к delivery, у нас еще будут stand up, planning и retrospecitve, ура!», а на самих этих евентах ничего не происходит, на planning — как сказал PO или SM, так и будет, на retrospective постоянно ищут «кто нафакапил в этот раз», вместо того чтобы думать как не факапить в будущем. В общем, если у вас не работает Agile, может быть вы просто не умеете его готовить? ;)

Поддержу.


Особенный случай — это когда инициатива внедрения аджайл исходит от заказчика. Во всех виденных мною случаях это значит daily meeting и все.

НЛО прилетело и опубликовало эту надпись здесь
Я наверное, не совсем верно выразился, еще раз подчеркну, что я не считаю Agile «универсальной синей таблеткой».

Так что, скорее, метафорически, моя мысль должна звучать так:
1) «если вы пьете таблетку головной боли, когда у вас понос, наверное вы что-то делаете не так»
2) «если вы пьете таблетку от головной боли не руководствуясь инструкцией, головная боль может не пройти»

К почти годичному юбилею Вашего комментария, вставлю свои пять копеек :)

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

Например, наша «правоохранительная» система (жаль, не бывает заглавных кавычек). Их задача, конечный продукт — это порядок, защита невиновных, поиск виновных, справедливость. Вместо этого для них конечный результат упростили и подменили «палками» — раскрываемостью, количеством задержанных и т.п. Теперь, вместо поиска справедливости, как в книгах о Шерлоке Холмсе и Эркюле Пуаро, «детективы» достигают других результатов — количественных. Поймать первого попавшегося, повесить на него пусть мелкую статью и в конце недели сдать стейкхолдерам десяток таких «юзер стори» гораздо выгоднее, чем ухватиться за одно тяжёлое дело и раскрыть его или, упаси бог, стараться изо всех сил, но НЕ раскрыть.

То же самое можно сказать и о медицине, и о депутатах и вообще обо всём. В том числе и о проектах в программировании. Когда задача — не получить на выходе готовый полезный продукт, а заработать пойнты, сдать 4-6 юзер сториз (не дай бог, меньше, вы — самое слабое звено!!!), провести три митапа и пять спринтов — тогда так и получается, рано или поздно очень скоро окажется, что мы все сидим и разукрашиваем бумажки.

Иными словами, неумение завязать мотивацию сотрудника на тот конечный результат, который нужен вот этой мифической Пэт из видеоролика. Когда-то я получал деньги за сидение в офисе. Я гораздо эффективнее работаю из дома, но директору почему-то нужно было, чтобы все сидели в офисе. В результате продукт мы выдавали так себе, зато исправно получали зарплату. Когда я болел, я приходил в офис просто посидеть и почитать книгу — чтобы получить зарплату. Сейчас мне платят за часы. Поэтому любую задачу я выполняю максимально долго, на 15-минутную задачу запишу хотя бы пару часов, чтобы получить больше денег. Возможно, когда-то мне будут платить за продукт, но до этого пока что никто из моих работодателей не додумался.

Сюда же относится и любовь к внедрениям. Когда опять же, вместо конечного нужного продукта, цель — сделать на самых последних иннонанотехнологиях, чтобы все рты раскрыли. Когда руководитель проекта на вопрос — «Каков результат?» отвечает не «Мы получили продукт», а «Мы работает по Agile». Это прям такой подвид людей — Homo sapiens mnogostrashnyhslovznayus. Когда для хранения настроек маленькой локальной программки начинают прикручивать NoSQL, а команда из одного разработчика и одного руководителя закупаются досками, разноцветными маркерами, магнитными смайликами и стикерами.

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

Бывает и наоборот, когда начальство занимается "мотивацией" сотрудников, в ущерб постановке процесса. Всего должно быть в меру.

Лучшее применение Agile-подобной методологии для меня следующее:
— Ретроспектива не проводится. (Вернее занимает 5 минут при планировании следующего релиза)
— Планирование: долгосрочное — на 1 доставку (обычно около 2х месяцев). Краткосрочное — на этапе разбора задач на спринт
— Спринты — 2 недели.
— Сбор требований и демо заказчику проводит Бизнес-аналитик (в этой модели он для команды Product Owner)
— Стендапы — каждый день или 1 раз в 2 дня (зависит от размера команды и интенсивности работы)

Преимущества такого подхода:
— Минимизируется время совещаний.
— Каждый занимается своим делом (т.е. программисты не тратят время на демо и не общаются с заказчиком напрямую)

Недостатки данного подхода:
— Нужен хороший бизнес-аналитик, чтобы взаимодействие не превращалось в «глухой телефон»
— Чуть меньше виден результат работы для программистов (т.к. они не видят/слышат реакцию заказчика на сделанные изменения). Хотя для меня лично лучший мотиватор — это сданный в срок проект и премия за сдачу проекта.

И самое главное: любая методология потерпит крах, если использовать её с целью «заставить» команду работать (часто с применением репрессивных механизмов). Agile нужен, чтобы иметь чёткую модель взаимодействия в команде и скоординировать работу.
Agile это не методология, а прилагательное. То, что американцы называют «проворный», «гибкий» (дословный перевод agile), русские возвели в культ и назвали методологией. То же самое, как если бы русское выражение «эффективный менеджмент» какие-нибудь испанцы возвели в культ и хвастались, что следуют методологии «Эффективный». Agile manifesto это не о том, каким правилам следовать, а о том, как достигнуть этой характеристики, сборник практических советов и не более. Тошно читать такие статьи, честное слово.
НЛО прилетело и опубликовало эту надпись здесь
Возможно меня многие не поддержат, но смотря на современные продукты иногда возникает ощущение, что подобные подходы к разработке далеки от реальности, а применимо все это только в идеальном каком-то мире. Что фичи (как тут сказано) делаются ради фич. Когда делают не то, что реально нужно и просят пользователи, а то, что скажет менеджер продукта.
Поддержу вас в вашем взгляде. Часто после разбивки проекта на фичи, вся команда фокусируется на разработке этих самых фич, но не думает о том как эти фичи будут интегрированы между собой.
Чтобы этого не происходило — у системы должен быть архитектор, который должен видеть систему целиком, а не просто набор фич.
Хороший пример agile-ада — это интерфейс Facebook (а вернее то, как там сделаны настройки) есть меню настроек, есть настройки каждого раздела, есть настройки каждого элемента. Вроде всё красиво и функционально, но абсолютно неинтуитивно для пользователя. Т.е. фичи реализованы, а системного подхода нет.
Скажу больше, особенно сильно возникает такое ощущение, когда привычный всем интерфейс зачем-то меняют, причем эти перемены не несут в себе каких-то кардинально новых возможностей, а скорее перемены ради перемен. Создается ощущение, что программистов нечем занять, и чтоб не сокращать штат, вводится что-то подобное…
В идеальном мире, который тут описан якобы все фичи и изменения должны идти от самих пользователей, но я, увы, этого не наблюдаю в большинстве случаев.
В последнее время интересами пользователя никто не интересуется — все пилят фичи…
То что обновление приложения нельзя отключить уже стало нормой (хотя я никак к этому не привыкну).
Но сегодня, к примеру, мой скайп решил установить обновление и перезагрузиться ВО ВРЕМЯ звонка.

У меня скайп стабильно 2-3 раза в неделю самопроизвольно запускается автологинится и пытается обновиться. Тоже так себе поведение.

Ну это уже проблемы менеджера, а не разработчиков, и уж никак не методологии.

Раздел «несколько команд» очень эпичный, я никогда такого не видел и не представляю как это может у кого-то работать.
Там появляются технические зависимости от других команд, планирование больше невозможно провести на уровне PO, это превратится в митинги с большим количеством участников, оценки будут скакать в зависимости от того насколько подкоманда знакома с модулем, упадет предсказуемость или же подкоманды будут стремиться к технической изоляции, что приведет к разному стилю в разных модулях и бесконечному перекидывает багами.

На мой взгляд, гибкий процесс разработки сам по себе хорош.
Проблемы с ним возникают из-за плохого внедрения.


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


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


Другой пример: фиксированный объем спринта дает больше свободы разработчикам (они могут работать в более свободном темпе, например, растянуть задачи равномерно на спринт, или напрячься, но освободить день или два), и накладывает ограничения на стейкхолдеров и владельца продукта (вынуждая их подавлять позывы "АААА ПРОСТОЙ РЕСУРСА!!!!!1").


В принципе, любая часть методологии так или иначе "выгодна" одной из ролей, и "невыгодна" другой. ("Выгодна" в кавычках, поскольку цель у команды одна, и выгода одна тоже, но количество усилий и действий может сильно различаться в зависимости от внедренных частей аджайла).


Так вот, к чему я веду: чтобы аджайл внедрился успешно, нужен баланс обязательств и привилегий. Однако, на практике в 90% случаев есть перекос, и угадайте, в чью сторону (посильнее нагрузить разработчиков, и дать побольше инструментов контроля заказчику). В достижении конечной цели это мешает всем, но с точки зрения морали на проекте страдают сильнее всего исполнители, заказчики же получают иллюзию контроля (Опять же, это именно иллюзия, разработчик при желании сможет выкроить себе нужно количество свободного времени, и проверить факт, что он намеренно затянул разработку, невозможно.).


Хуже того, наиболее важные части, такие как приоритезация бэклога, фиксированные спринты, минимизация регрессии при выборе фич, добавление только фич, которые можно использовать по окончании спринта — это все обычно отбрасывается как "неважное" (не дающее дополнительных рычагов менеджменту). Превращение стенд-апов из инструмента координации и информирования в отчетность и инструмент контроля — из той же серии.


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

ручном регрессивном тестировании

правильно «регрессионном»

«автоматическим тестированием»

правильно «автоматизированным»

Очень ждал увидеть в статье ограничения применимости. Когда нужно применять гибкие методологии, а когда их применять ни в коем случае нельзя. Аналогично — ограничения на размер и состав команды.
Грамотная статья с простыми объяснениями важных вещей!
Статья скорее не про Agile, а про Scrum и XP.
Извините, но название статьи не соответствует контенту статьи. Не нужно приплетать Agile mindset к методологии разработки SCRUM и вносить путаницу.
Ну вы не приплетаете, а вот другие приплетают — погуглите, хотя бы, как взаимосвязаны эти две вещи. Строго говоря, Agile — это манифест, он так в оригинале и называется (в той его версии, в которой он сейчас существует), то есть это просто некое заявление о том, что нужно и можно преследовать в работе командой. А Scrum — это конкретно методология, следующая принципам, объявленным в Agile Manifesto. Собственно, Швабер, который серьезно вложился в формализацию манифеста, а заодно и подписал его с другими 16 разработчиками, впоследствии написал книгу Agile software development with Scrum (в соавторстве с каким-то еще чуваком).
НЛО прилетело и опубликовало эту надпись здесь

Фантастика! Мы придумали слово Agile, как название для бесцельного времяпровождения: они там (кто-то) появятся и будут (что-то) там делать, работать, заказы будут прям ломиться в двери, перегруз.
Какая бабушка, какие минуты, она и думать об этом не захочет? Смысл? О чём вообще речь конкретно, что вы собираетесь перегружать? У меня, например, есть идея, и? Вы сами лично, для начала, готовы работать?.. Думаю, уже перегружены. :)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий