Ivan Trechyokas
Как тестированию, скажу вам интересную статистику: там где были аналитики, которые-то генерировали требования и описание задач на спирт! (То есть не очень большие задачи), разработчики часто интерпретировались требования неправильно! Они даже не общались с аналитиками по этому поводу, потому что считали, что поняли все правильно. - каждая третья задача, уровень недопонимания отличается: от мелких правок, до изменения логики.
А представьте в waterfall на полгода-год. Через год оказывается, что ты неправильно понял требования и сделал не так. Тадам!
Но ведь Agile тоже не собирается параллельно строить мансарду и первый этаж.
К сожалению, ваш пример: "По крайней мере никто не сможет параллельно строить висящую в пустоте мансарду и первый этаж, не имея на руках общего проекта здания." показывает, что у вас сложилось неправильное представление об Agile. У Agile одна простая цель: делать как можно больше бизнес ценности в единицу времени. При этом после каждой итерации продукт должен быть работоспособным, полезным и лучше предыдущей версии.
В вашем же случае: мансарда не имеет ценность без пути к ней, первый этаж - тоже не имеет ценности, так как непонятна его планировка. Поэтому первым делом будет взят Заказчик дома, хорошие специалисты и будет обговорён некоторый план того, что он хочет (получит некий Backlog), и наиболее важные моменты, которые нужны нам на ближайший спринт (Product backlog). Никто не будет строить параллельно разные части дома, или менять местами причинно следственные связи в этом мире только потому, что это Agile.
Принципы Agile можно прочитать тут: http://agilemanifesto.org/iso/ru/principles.html
Картинку посмотреть, и статью прочитать о том, как разрабатывается продукт по Agie, можно прочитать тут: http://netology.ru/blog/loveagile
Кстати, от ещё одного препода есть статья про Agile. Примерно теми же словами, но с другими выводами.
Аналогично рассуждая, если в прод выехали с багами (что в общем-то не всегда плохо) и при этом команда говорит, что она тут не причём - то это тоже не Agile.
Команда отвечает за свой продукт, иначе это противоречит сути Agile. А следовательно - это раздолбайство, прикрываемое Agile.
Однако Agile в комплексных проектах приводит к потере равновесия между частотой изменений и частотой тестов
Почему же? Если так случается, то ценность поставки "работающего продукта" теряется и это уже не agile, а "фигак-фигак-и в продакшн".
Коли зашёл разговор о тестах, то мне как тестеру было бы интересно получить пару ответов:
1) "Причина проста — перевод нескольких компонентов на систему постоянной интеграции. До запуска интеграционных тестов с реальной базой данных все работало хорошо, и, конечно же, все полетело, когда данные были обновлены." (с)
- А чем эти тесты занимались раньше, как и что они тестировали до этого момента?
- Что понимается под "реальной базой данных"? Если это база с прода, то что мешало сделать копию и тестировать на ней изначально?
- Как проверялась работоспособность продукта? Ведь это основная ценность agile.
В целом крайне похоже на историю с водопадом, когда люди делали-делали, а потом начинают тестировать и понеслось...
2) "По статистике, собранной и опубликованной Puppet, лидером управления конфигураций, багов в таких обновлениях содержится в три раза меньше."
На сайте говорится "They have 24 times faster recovery times and three times lower change failure rates." - что относится к fail/success самих билдов больше, чем количеству багов в билде (если я умею английский и осознал смысл происходящего).
(ваша ссылка https://puppet.com/resources/white-paper/2016-state-of-devops-report)
Статистика в общем-то говорит о влиянии DevOps практик на результат команд, судя из названия статьи, а не сравнивает Waterfall и Agile. Насколько я понял, интернет говорит, что "DevOps + waterfall != love", и вряд ли где-то это реально работает вместе. А следовательно данная статистика скорее всего говорит о том, как разнятся данные в самих Agile компаниях, что частично подтверждается формулировкой наиболее продуктивные и наименее продуктивные в этом пункте "High-performing IT organizations deploy 200 times more frequently than low performers, with 2,555 times faster lead times."
О DevOps + waterfall:
https://techbeacon.com/devops-waterfall-dont-waste-your-time
3) "На первый взгляд, отлично, однако на самом деле работы у Quality Assurance реально прибавляется, так как при уменьшении количества проблем в три раза скорость поставки увеличивается в 200 раз. Простая математика, и результат не такой уж обнадеживающий — общее количество проблем увеличивается более чем в 60 раз. Очевидно, что при такой нагрузке служба не справляется с тестированием — пропускает серьезные ошибки, не успевает проверить работу системы в целом и прочее."
Да, работы прибавляется. Но она пропорциональна изменениям в релизе. Не уверен про уменьшение количества проблем в 3 раза - о чём я писал в п.2. Разница в скорости поставки выглядит правдоподобной.
Если говорить о проблемах в этих "небольших изменениях" - то QA в силу размера изменений достаточно быстро даёт фидбек разработчикам, которые всё ещё в контексте проблемы, что приводит к более быстрым фиксам и меньшим постэффектам, но всякое бывает и зависит от сложности кода.
Следовательно вопросы таковы:
- почему в данной моделе тестирование стало особняком от деятельности команды, так как в Agile нет отдельного этапа тестирования, там говорится о доставке продукта? Да и в Agile в команде разработки есть "член команды", там нет выделенной роли QA. Она разделена между всеми членами команды и одним "эекспертом в этой области", если он есть.
- почему число 60, являясь результатом работы QA службы, становится показателем нагрузки на неё же?
- тестеры вполне себе могли не успевать проверить сисетму в waterfall, так как на этапе разработки/интеграции у разработчиков возникали проблемы, что отъедало время тестирования. А менеджеры принимали решение провести сколько успеем, что бы войти в бюджет. Где принципиальная разница?
4) "Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов." (с)
и "Философия Agile открытым текстом говорит о том, что гарантом успешности разработки является коллективная ответственность..." (с)
- почему эти высказывания противоречат друг другу?
5) "И на самом деле каждый сделал свою работу хорошо — каждая часть по отдельности работала. Но все вместе распадалось на части и не летело."
- Почему пробелемы в коммуникациях стали проблемой только в Agile?
В Agile нет как-такого деления "своя работа" - у всей команы есть продукт "obama care", и то что никто ни разу не попробовал его запустить целиком до окончания разработки - это как раз не Agile. Ибо у них не было рабочего продукта (главная ценность и показатель прогресса в Agile) практически до конца разработки. Пока это выглядит как waterfall - каждая команда собрала требования, "реализовала свою часть хорошо", а потом оказалось, что всё не работает. Нет той пресловутой проверки "работоспособности продукта" на каждом этапе.
6) "В моей практике таких проблем не было ни в одном из многочисленных стартапов, однако случалось практически в каждом большом проекте."
Так в этом-то и дело, в маленьких проектах код проще, взаимодействия не такие страшные как в большом проекте. Там бы и "ковбойский стиль программирования" отлично бы работал.
7) "Каждая из аппликаций прошла комплексные тесты, и, тем не менее, всё сломалось в интеграционной среде, где эти системы встретились в первый раз."
Agile говорит, что проверять надо постоянно работоспособность продукта, а не работоспособность компонента.
- проблема в понимании тестирования, а не в Agile.
8) "А во-вторых, необходимость уложиться в сроки требует высокой скорости, и чтобы ее добиться, создаются автоматические тесты на уровне компонента."
- Почему вы решили, что Agile запрещает создавать тесты более высоких уровней: интеграционных и системных? Что бы добиться высокой скорости - рутинную работа автоматизируют, но то, то автоматизация заключается исключительно в unit тестах это проблема конкретной команды\ проекта\ компании. Видимо они не слушают тестеровщиков или изрядно на них экономят. Но это никак не связано в Agile напрямую, скорее как и везде "авось и без них справимся, все же код писать умеем".
9) "Имплементация больших проектов, состоящих из маленьких частей, обычно приводит к большим ошибкам. И, по сути, настоящими тестировщиками сервисов, разработанных по Agile, являются пользователи, которые начинают полноценно работать с обновленным приложением или интернет-банком, решая свои задачи."
Такое случается, когда тестирования нет или оно выполняется абы как.
- Говорит ли Agile что-нибудь о том, как и что надо тестировать?
В общем, вся статься похожа на кране забавный пример того, как кого-то начал делать старые дела на новый лад, назвал это Agile (ну ведь не waterfall же? а если не он, то получается это уже Agile!), и при этом у него так как все проблемы скатываются к тому, что:
- Если проект работает не по waterfall, то стиль его работы автоматически подпадает у вас под определение Agile. А это не так! Смотрите видео
(Как понять, что Agile работает | https://habrahabr.ru/company/oleg-bunin/blog/309878/ )
- Никто не понимает, что такое Agile - но все по нему работают =)
- Все считают, что привычки и mindset людей при добавлении стендапов моментально меняется - а вот и нет.
- вместо продукта в целом, команды\проекты думают только о своём компоненте (в общем-то, как и в Waterfall). Тестеры же всё равно проверят в конце!
- тестирование реализовано кусочно: unit тесты уже хорошо, но всё ещё не достаточно. Проблема всех и вся.
- P. S. Справедливости ради стоит отметить, что такие проблемы существуют не только в Agile компания. +__+
Так ведь Agile не отменяет планирование. Он просто говорит о том, что доставлять работающий продукт это хорошо и нужно.
Иногда для проверок идей вставляют костыли и подпорки, но после этого постоянно и постепенно рефакторят код (если читать про хороший путь), чтобы он не оставался сделанным из костылей. Но тут обычно начинаются проблемы с командой их agile-mindset. Как таковое, команда сама решает что будет использовать: костыли\ костыли + рефакторинг\ красивый код; так как только она отвечает за техническую реализацию фичей.
Просто не повезло с командой и\или начальством.
p.s.: у меня знакомая работает в facebook (почти как у вас, только на 1 рукопожатие меньше). У них свой agile, но совсем не scrum. Есть итерации, есть планирование.
А вы ознакомлены с какой-либо статистикой зафейленных проектов на разных методологиях?
А самое ведь интересное, что если проект с agile - зафейлился (оказался не нужен на рынке или заказчикам и прочее) - то в силу своих принципов унесёт много меньше денег, чем проект с waterfall.
Пока вы собираете требования и планируете то, как это будет сделано в waterfall - ваши конкуренты с agile всё это уже сделают. Как не грустно, но это правда.
немного про статистику:
https://www.infoq.com/articles/standish-chaos-2015
"Если в конце этапа обнаружили, что не достигли требуемого качества (баги), то продлевают срок этапа на устранение дефектов и дальше проект не идет, а ждет окончания этапа."
Но ведь если вы сдвигаете этап "тестирования" в водопадной моделе, то тем самым вы сдвигаете начало этапа "эксплуатация" и следовательно сдвигаете сроки релиза.
"Поэтому и баги и сорванные сроки не могут быть одновременно."
Как тестер я вам скажу прямо без утайки: может.
Невозможно отыскать абсолютно все ошибки в программном продукте:
- Ошибки остаются всегда.
- Построение исчерпывающего входного теста невозможно.
(http://www.4stud.info/software-construction-and-testing/lecture7.html)
А теперь объясню почему, да потому что в водопаде этап не может идти бесконечно, так как деньги на проект кончаются рано или поздно. Когда это случается менеджер согласится пойти в прод с тем состоянием продукта, который есть, либо этот продукт уже не уйдёт в прод никогда.
А как вы/они определяете Agile в проекте или нет?
Смутила концовка ответа "у нас все не так".
Просто у вас другая точка зрения, тоже имеет место быть. Все зависит от цели, которую мы хотим достич.
Пожалуй добавлю целый абзац из последней книги, которую я прочитал о командной работе:
"Как все это связано со следующим пороком – безразличием к результатам? Если члены команды не несут ответственности за свой вклад в общее дело, то они больше внимания уделяют своим собственным делам, своей карьере. Именно с отсутствия требовательности и взаимного контроля начинается равнодушие к успеху команды и безразличие к достижению результатов."
( Пять пороков команды. Притчи о лидерстве. )