После года работы в Agile режиме (в нескольких их видоизменениях) осознал, что Agile НЕ может нормально работать для без автоматизированного тестирования.
Пойду доказательством от противного. Пусть мы работаем в Agile и у нас нету автоматизированного тестирования. У нас есть пять user story, которые мы делаем. Внутри каждой из них у нас есть какие-то разумные критерии по которой мы определяем, что user story сделана — они обычно включают ручное тестирование измененной/новой функциональности.
По окончанию скажем 6 Sprint’ов, мы решает, что пора выпустить новую версию и тут мы обнаруживаем, что оттестированная каждая user story не значит оттестированный весь продукт. Соответственно, мы стартуем большое регрессионное тестирование всего продукта. Исправляем баги (для них можно даже сделать отдельные user story), потом опять проходимся и делаем регрессионное тестирование (так как исправленные баги могли внести другие). Надеюсь это знакомо? Итого, нам понадобилось еще 3 Sprint’а, чтобы привести все к виду, в котором можно выпускать.
Итого, на самом деле мы похерили пару принципов из Agile
а) То что продукт постоянно близок по качеству к выпускаемому.
На самом деле, чем дольше мы работаем без release тем общее качество у него будет хуже и хуже
б) То, что заранее НЕ нужно планировать отдельные фазы (разработка/тестирование).
Теперь нам заранее надо таки планировать, что на каждые 6 sprint’ов разработки — 3 sprint’а тестирования и стабилизации.
Ой… А это случайно мы не в waterfall возвращаемся, когда мы делаем сначала разработку, а потом тестирование?
в) То, что по ходу, можно и нужно улучшать код рефакторингом.
Рефакторинг кода, становится делать опасно, так как зачастую только через месяца (во время большего тестирования) становится видно какие проблемы он добавил.
Сразу оговорюсь, может быть agile без автоматизации и лучше чем совсем уж классический waterfall. Но на самом деле он одной ногой в этом waterfall’е продолжает стоять.
P.S. Да, основная идея — автоматизировать регрессию или большую ее часть. Это позволит, во первых раньше поймать баги, которые внесены внутри user story, но которые лежат в функциональности вне ее. Во вторых — это резко сокращает период на ретестирование продукта и его стабилизацию.
А может быть проблема в том, что очень плохое взаимодействие внутри команды? Ведь обычно программисты не любят общаться друг с другом (социопатия) и их надо заставлять (мотивировать) это делать.
Кстати, кто следит за общим дизайном системы? Или при начале спринта образуется несколько независимых потоков разработки, где каждый сам себе «царь»?
Я бы сказал — это отдельные проблемы.
Даже, если следить за дизайном системы и иметь хорошее взаимодействие, это не избавляет от необходимости перетестировать систему и исправлять баги, которые появились в результате вне user stories.
Чтобы такого не происходило, релиз должен выпускаться в результате каждого спринта, а не два раза в год. Если это невозможно, по маркетинговым соображениям, следует изменить маркетинг, например? организовать early evaluation program, или же отказаться от Agile.
Маркетинговые соображения тут в целом не причем.
Проблема возвращается как раз к преславутому перетестированию продукта.
Даже если мы сделали 5 user story, то без перетестирования мы не можем быть уверенными, что продукт в целом остался в разумной мере рабочим.
Делать полное или частичное, но большое перетестирование каждый спринт — это нереально, для любого достаточно крупного продукта.
А почему в пределах одной итерации не может быть waterfall?
В целом может быть. Вообще, agile это куча маленьких waterfall’ов (размером с user story).
Проблема в том, что в маленький waterfall не вмешается ручное перетестирование средних/крупных продуктов.
Плесну масла в огонь. 🙂
1. В каждой юзер-стори _должно_ быть заложено время на проверку не только самой юзер стори, но и всего, что с ней так или иначе связано. Вобщем-то любой более-менее опытный product owner или тим лид должен быть в курсе.
Для изменений «цепляющих» существующий функционал слишком широко, чтобы включить полную регрессию см пункт 2.
2. Проводить регрессию перед выпуском это ок. Мы работаем по Agile и выпускаем новую версию продукта примерно раз в год-полгода. Перед релизом проводим две-три недели (т.е. спринт-полтора) в регрессионном тестировании всего приложения. Так называемый «стабилизационный период».
P.S. И пункт номер 0: Слепое следование методологии как правило не приводит ни к чему хорошему. Любую методологию нужно адаптировать под конкретный набор «проект+команда».
Начну с пункта номер 0. Выдвину обратный тезис. Слепое адаптирование методологии под проект и команду как правило не приводит ни к чему хорошему. (http://victorronin.com/2009/09/18/process-ne-vlezaet-v-firmu/)
Пункт N1. Скажем так, умный product owner и team lead могут частично минимизировать риски. Но убрать необходимость регрессионого тестировани они не могут.
Ну и по поводу выпуска раз в год-полтора. Для большинства фирм — это слишком блинный срок и зачастую надо выпускать продукт раз в 3-4 месяца, чтобы не отставать от конкурентов. И вот тут наступает жопа, если нужно тратить несколько спринтов на стабилизацию.
Кстати, я удивлен насколько короткий у вас стабилизационный период.
Ну до месяца включительно он может быть. В зависимости от того, как долго разрабатывали новую версию.
По поводу убрать необходимость: Ну, а её и не надо убирать. Куда ж без регрессии-то. 🙂
По поводу п. №0: Слепое адаптирование это оксюморон. Типа «прицельная стрельба вслепую».
Я говорил о том, что нужно брать от методологии лучшее, а не слепо следовать. Так же как сборная солянка наиболее удачных идей из разных методологий тоже скорее всего работать не будет (или будет, но не так, как хотелось бы).
Собственно говоря, почему поднял эту тему, потому что на текущей работе продукт откровенно больших размеров — кучу разных модулей, дикое количество связей между друг другом и системой. Поддержка кучи 3rd party программ и интеграции с ними. И достаточно часто, винтик подкрученный в одной части программы аукается совсем в другом месте.
С убрать нееобходимость — я погорячился. То, что я сказал, что они могут уменьшить риски появления багов, но не могут уменьшить длительность регрессионного тестирования.
из поста совсем не понятно куда вы хотите вставлять автоматизацию. Автоматизировать регрессию? Это уменьшит количество спринтов «чтобы привести все к виду, в котором можно выпускать»?
Сейчас в P.S. вынету. Да, основная идея автоматизировать регрессию или большую ее часть. Это позволит, резко укоротить стабилизационный период.
Встану на сторону «дьявола». Внимание вопрос: А чего все так прутся от этого Agile, если всё равно приходится адаптировать под команду/фирму да и одной ногой (а помне, так всеми 2мя) стоит в waterfall-e ?
ИМХО, чистой воды маркетинг, но для умных людей.
Сам люблю выступать с той стороны.
Я бы сказал так… В целом, конечно agile сейчас перерекламирован. То есть много шума, результаты … ну скажем, разные.
С другой стороны, как по мне одна из проблем именно в том, что «отцы» agile скази — так как методика гибкая, адаптируйте ее под команду. Это не учитывает то, что не у всех есть опыт, знания и умения, как правильно адаптировать. Результатом зачастую получается — Agile по названию, waterfall по содержанию. Ну и получается, что все те же проблемы вылазят, что были раньше.
Я бы очень ратовал, за то, что был бы минимальный список требований Agile (которые составляли бы его ядро). Чтобы люди адаптируя не могли похерить все его преимущества.
А в целом Agile таки лучше Waterfall. Одна из самых полезных вещей в нем, что они отталкиваются от более реалистичных идей. Waterfall отталкивается от идеи, что все (требования, объемы работ и т.п) можно спрогнозировать (причем достаточно точно) и что оно потом меняться не будет. Agile — что спрогнозировать можно только приблизительно (статистически) и меняться оно таки будет активно. И естественно, отталкиваясь от более актуальных фактов, можно получать более актуальные результаты.
Спасибо за комментарий. Может показаться, что я евангелист waterfall-а 🙂 Никак нет. В agile очень много здравых вещей. И благодаря этому вашему отзыву я увидел agile с другой стороны: Будь ты хоть дважды мастер и трижды «коуч» (прости госпади) и не пропускаешь ни одного попсового тренинга, будет в команде agile или нет зависит исключительно от каждого члена этой самой команды. Но а такую команду, где каждый из участников mid-to-senior developer, днем с огнём не найдешь. Вот и получается, «Agile по названию, waterfall по содержанию»
Насчет «будет в команде agile или нет зависит исключительно от каждого члена этой самой команды».
Я бы сказал, что это все таки переход в другую плоскость обсуждения. В целом статье именно о технологической поддержке Agiel.
А вопрос команды — это уже нетехнологическая проблема (безусловно не менее больная).