Комментарии 36
Все Agile-методологии выглядят просто потрясающе: на бумаге, в книжках, в презентациях, на видео.
Но в один прекрасный момент ты осознаешь себя сидящем на 4х часовом митинге, рядом с другими, такими же программистами с грустными глазами и мы все вместе раскрашиваем цветные бумажки, играем в карты и голосуем за фичи "ногами", просто потому что так "веселей".
Какая по-вашему идеальная методология?
Остальное не особо профитное из моего опыта. Оценка задач, а в особенности ПользовательскихИсторий(плохая проработка задачи) — это пальцем в небо (ну когда задачи не точь в точь близнецы прямо). А с этого момента начинается крах подхода, ИМХО.
Я только за аджайл, и считаю его передовой методологией сегодня.
Но прочитав комментарий PkXwmpgN я подумал, может я что-то пропустил, и бывают методологии без выматывающих митингов и нелепых действий?
Немного уточню: митинги и дурацкие ритуалы можно привнести в любую методологию разработки, к сожалению.
Почти каждый день минут 20 на всех с утра что делал, что будешь. Мне, как аналитику в проекте, очень полезно понимать чем живет команда в данный момент.
Спринт 4 недели, ретро примерно час-полтора, опять же по проблемам вырабатываем пути улучшения и пишем на доске перед глазами.
Планированием занимается руководитель, совещаясь с причастными. Это сильно лучше, чем по началу с картами. Вот там прогеры и тестировщики «помирали», а я точнее чем они оценивал их же задачи =)
Извините за токсичность, но это все равно, что сказать: "Я только за КАМАЗ! Лучшая машина!". Методология выбирается из условий, а не наоборот. Если вам надо возить грузы, тогда, конечно, КАМАЗ или другой грузовой автомобиль. Но покатать жену по магазинам проще на легковом автомобиле.
Если заказчику неудобно постоянно с вами контактировать или он хочет рассчитать бюджет проекта заранее (конечно же, заказчик точно знает, что он хочет получить на выходе, ТЗ на тот момент уже готово), то о каком Agile тут может идти речь?
Вообще, уже было давно справедливо замечено, что Agile работает не во всех случаях и не у всех команд. Многие внедряют Agile квадратно-гнездовым методом, из серии, «А теперь, в дополнение к delivery, у нас еще будут stand up, planning и retrospecitve, ура!», а на самих этих евентах ничего не происходит, на planning — как сказал PO или SM, так и будет, на retrospective постоянно ищут «кто нафакапил в этот раз», вместо того чтобы думать как не факапить в будущем. В общем, если у вас не работает Agile, может быть вы просто не умеете его готовить? ;)
Поддержу.
Особенный случай — это когда инициатива внедрения аджайл исходит от заказчика. Во всех виденных мною случаях это значит daily meeting и все.
Так что, скорее, метафорически, моя мысль должна звучать так:
1) «если вы пьете таблетку головной боли, когда у вас понос, наверное вы что-то делаете не так»
2) «если вы пьете таблетку от головной боли не руководствуясь инструкцией, головная боль может не пройти»
Мне кажется, проблемы начинают возникать, когда происходит упрощение и подмена ожидаемого результата. И это вообще везде, не только в программировании.
Например, наша «правоохранительная» система (жаль, не бывает заглавных кавычек). Их задача, конечный продукт — это порядок, защита невиновных, поиск виновных, справедливость. Вместо этого для них конечный результат упростили и подменили «палками» — раскрываемостью, количеством задержанных и т.п. Теперь, вместо поиска справедливости, как в книгах о Шерлоке Холмсе и Эркюле Пуаро, «детективы» достигают других результатов — количественных. Поймать первого попавшегося, повесить на него пусть мелкую статью и в конце недели сдать стейкхолдерам десяток таких «юзер стори» гораздо выгоднее, чем ухватиться за одно тяжёлое дело и раскрыть его или, упаси бог, стараться изо всех сил, но НЕ раскрыть.
То же самое можно сказать и о медицине, и о депутатах и вообще обо всём. В том числе и о проектах в программировании. Когда задача — не получить на выходе готовый полезный продукт, а заработать пойнты, сдать 4-6 юзер сториз (не дай бог, меньше, вы — самое слабое звено!!!), провести три митапа и пять спринтов — тогда так и получается,
Иными словами, неумение завязать мотивацию сотрудника на тот конечный результат, который нужен вот этой мифической Пэт из видеоролика. Когда-то я получал деньги за сидение в офисе. Я гораздо эффективнее работаю из дома, но директору почему-то нужно было, чтобы все сидели в офисе. В результате продукт мы выдавали так себе, зато исправно получали зарплату. Когда я болел, я приходил в офис просто посидеть и почитать книгу — чтобы получить зарплату. Сейчас мне платят за часы. Поэтому любую задачу я выполняю максимально долго, на 15-минутную задачу запишу хотя бы пару часов, чтобы получить больше денег. Возможно, когда-то мне будут платить за продукт, но до этого пока что никто из моих работодателей не додумался.
Сюда же относится и любовь к внедрениям. Когда опять же, вместо конечного нужного продукта, цель — сделать на самых последних иннонанотехнологиях, чтобы все рты раскрыли. Когда руководитель проекта на вопрос — «Каков результат?» отвечает не «Мы получили продукт», а «Мы работает по Agile». Это прям такой подвид людей — Homo sapiens mnogostrashnyhslovznayus. Когда для хранения настроек маленькой локальной программки начинают прикручивать NoSQL, а команда из одного разработчика и одного руководителя закупаются досками, разноцветными маркерами, магнитными смайликами и стикерами.
Поэтому, тут, скорее, проблема не в Аджайле, а в непонимании, «чё надо?» наверху и, как следствие, неумение объяснить «чё надо» внизу. Здесь больше вина многих адептов Аджайла, которые, сами не понимая, как отвечать на сложный вопрос «Как получить хороший продукт дёшево и качественно?», начинают всё упрощать до пойнтов, весёлых-грустных смайликов и количества юзерсториз в неделю.
— Ретроспектива не проводится. (Вернее занимает 5 минут при планировании следующего релиза)
— Планирование: долгосрочное — на 1 доставку (обычно около 2х месяцев). Краткосрочное — на этапе разбора задач на спринт
— Спринты — 2 недели.
— Сбор требований и демо заказчику проводит Бизнес-аналитик (в этой модели он для команды Product Owner)
— Стендапы — каждый день или 1 раз в 2 дня (зависит от размера команды и интенсивности работы)
Преимущества такого подхода:
— Минимизируется время совещаний.
— Каждый занимается своим делом (т.е. программисты не тратят время на демо и не общаются с заказчиком напрямую)
Недостатки данного подхода:
— Нужен хороший бизнес-аналитик, чтобы взаимодействие не превращалось в «глухой телефон»
— Чуть меньше виден результат работы для программистов (т.к. они не видят/слышат реакцию заказчика на сделанные изменения). Хотя для меня лично лучший мотиватор — это сданный в срок проект и премия за сдачу проекта.
И самое главное: любая методология потерпит крах, если использовать её с целью «заставить» команду работать (часто с применением репрессивных механизмов). Agile нужен, чтобы иметь чёткую модель взаимодействия в команде и скоординировать работу.
Чтобы этого не происходило — у системы должен быть архитектор, который должен видеть систему целиком, а не просто набор фич.
Хороший пример agile-ада — это интерфейс Facebook (а вернее то, как там сделаны настройки) есть меню настроек, есть настройки каждого раздела, есть настройки каждого элемента. Вроде всё красиво и функционально, но абсолютно неинтуитивно для пользователя. Т.е. фичи реализованы, а системного подхода нет.
В идеальном мире, который тут описан якобы все фичи и изменения должны идти от самих пользователей, но я, увы, этого не наблюдаю в большинстве случаев.
Ну это уже проблемы менеджера, а не разработчиков, и уж никак не методологии.
Там появляются технические зависимости от других команд, планирование больше невозможно провести на уровне PO, это превратится в митинги с большим количеством участников, оценки будут скакать в зависимости от того насколько подкоманда знакома с модулем, упадет предсказуемость или же подкоманды будут стремиться к технической изоляции, что приведет к разному стилю в разных модулях и бесконечному перекидывает багами.
На мой взгляд, гибкий процесс разработки сам по себе хорош.
Проблемы с ним возникают из-за плохого внедрения.
В методологии есть приемы и техники для каждой роли, и каждый из них дает полномочия и рычаги одной роли, и накладывает обязательства на другую.
Например, ежедневные митинги высоко котируются заказчиком, поскольку дают ему больше осведомленности о процессе, и накладывают обязательства на разработчика по поддержанию определенной скорости разработки и графика работы.
Другой пример: фиксированный объем спринта дает больше свободы разработчикам (они могут работать в более свободном темпе, например, растянуть задачи равномерно на спринт, или напрячься, но освободить день или два), и накладывает ограничения на стейкхолдеров и владельца продукта (вынуждая их подавлять позывы "АААА ПРОСТОЙ РЕСУРСА!!!!!1").
В принципе, любая часть методологии так или иначе "выгодна" одной из ролей, и "невыгодна" другой. ("Выгодна" в кавычках, поскольку цель у команды одна, и выгода одна тоже, но количество усилий и действий может сильно различаться в зависимости от внедренных частей аджайла).
Так вот, к чему я веду: чтобы аджайл внедрился успешно, нужен баланс обязательств и привилегий. Однако, на практике в 90% случаев есть перекос, и угадайте, в чью сторону (посильнее нагрузить разработчиков, и дать побольше инструментов контроля заказчику). В достижении конечной цели это мешает всем, но с точки зрения морали на проекте страдают сильнее всего исполнители, заказчики же получают иллюзию контроля (Опять же, это именно иллюзия, разработчик при желании сможет выкроить себе нужно количество свободного времени, и проверить факт, что он намеренно затянул разработку, невозможно.).
Хуже того, наиболее важные части, такие как приоритезация бэклога, фиксированные спринты, минимизация регрессии при выборе фич, добавление только фич, которые можно использовать по окончании спринта — это все обычно отбрасывается как "неважное" (не дающее дополнительных рычагов менеджменту). Превращение стенд-апов из инструмента координации и информирования в отчетность и инструмент контроля — из той же серии.
В итоге внедряется особый, галерный "аутсорсинговый" вариант аджайла, который справедливо воспринимается разработчиками как меньшее, конечно, по сравнению с совковым менеджментом, зло, но все же с изрядным скептицизмом.
Другие методологии, правда, тоже не лучше.
ручном регрессивном тестировании
правильно «регрессионном»
«автоматическим тестированием»
правильно «автоматизированным»
Очень ждал увидеть в статье ограничения применимости. Когда нужно применять гибкие методологии, а когда их применять ни в коем случае нельзя. Аналогично — ограничения на размер и состав команды.
Фантастика! Мы придумали слово Agile, как название для бесцельного времяпровождения: они там (кто-то) появятся и будут (что-то) там делать, работать, заказы будут прям ломиться в двери, перегруз.
Какая бабушка, какие минуты, она и думать об этом не захочет? Смысл? О чём вообще речь конкретно, что вы собираетесь перегружать? У меня, например, есть идея, и? Вы сами лично, для начала, готовы работать?.. Думаю, уже перегружены. :)
Как объяснить бабушке, что такое Agile за 15 минут с картинками