Pull to refresh

Comments 9

Эй, много пишущий и почти ничего не комментирующий мангуст,

1) Agile — это НЕ методология управления проектами. Это фреймворк, который можно положить поверх какой-то методологии.

Вообще agile — это прилагательное, которое не может существовать само по себе. Например, прилагательное «храбрый» или «озорной» нуждается в объекте. Поэтому сперва методология, затем «агиле» поверх.

2) Scrum, если следовать вашему толкования, это «разновидность agile». Не будет ли корректнее назвать это системой управления в контексте фреймворка agile?

Не будет ли разумно объяснить, почему это называется scrum?

Не будет ли разумно объяснить, почему «заранее определенный период времени» называется спринтом?

Есть на эту тему удивительно тонкая, но всё проясняющая книга «Clean Agile — Back to Basics» (Robert C. Martin). Её перевели в издательстве «Питер» на рус, но лучше, конечно, глянуть в оригинал. Будучи тестировщиками, мы должны понимать, что именно и в чём мы отстаиваем, не так ли?

Даже СКРАМ — не методология и не управления, а тоже фреймворк командной работы. Управления как такового в СКРАМе нет

Основная суть agile заключается в том, чтобы помочь людям организоваться создавать что-то, а не бесконечно это что-то обсуждать.

Читается как "сначала делаем, потом думаем".


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

В результате выпускаем продукт о-о-очень далекий от идеала.
А потом удивляемся, почему всего 12% стартапов доживают до 5-летнего возраста?..


при таком подходе мы можем доставить не то, что нужно… НО ЭТО НОРМАЛЬНО! Зато мы довольно быстро выходим на рынок и можем обратиться к клиентам за обратной связью, а затем также быстро внести изменения в продукт.

О, да! Зачем платить зарплату штатным тестировщикам, если можно бесплатно тренироваться на кошечках клиентах…
Но это ещё полбеды. Главная беда в том, что компании слишком редко прислушиваются к обратной связи, которую они якобы так ждут от клиентов. По личному многолетнему опыту, исправляется лишь 10, максимум 20 процентов обнаруженных багов.


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

А то что без code freeze результаты тестирования могут отличаться — это никого не волнует.


Быть прагматичными и проводить «достаточное» тестирование, не позволяя своему эго настаивать на исчерпывающем тестировании.

Да-да, пресловутое good enough. Так и получаются продукты, которые, вроде бы, работают, но из-за "сырости" пользоваться ими не хочется.


Автоматизировать как можно больше тестов

Повальное увлечение автоматизацией всего и вся — абсолютное зло.
Стремление бизнеса сэкономить ФОТ на ручных тестировщиках понятно. Но это неизбежно сказывается на качестве продукта, что, в свою очередь, неминуемо приводит к недополученной прибыли.


Тестирование локально, не дожидаясь деплоя в больших средах.

Основа основ — тестирование в условиях, максимально приближенных к production. Иначе багов класса "у меня работает, а у тебя нет" не избежать.


Иметь доверие к тому, что уже протестировано другими людьми, и не проводить повторное тестирование.

То есть код, покрытый юнит-тестами, на более высоких уровнях пирамиды тестирования можно не проверять? )


Остаемся вовлеченным на всех этапах работы над продуктом

Пожалуй, это то немногое, с чем я согласен в статье. Но и здесь есть нюанс.


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

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


Подводя итог, за долгие годы работы в компаниях разных направлений и масштабов я пришел к простому выводу.
Agile — это ни что иное как завуалированный способ мягкого контроля над сотрудниками, способ постоянно держать команду в тонусе, не давая ей расслабляться.
Daily standup — краткий устный отчет о проделанной работе перед скрамоводом.
Agile нужен бизнесу для быстрого выхода на рынок. Но рынку, то есть нам с вами — пользователям, "быстрые" продукты не нужны. По причинам, указанным выше.

удивляемся, почему всего 12% стартапов доживают до 5-летнего возраста?..

Удивляются те, кто иначе понимает слово «стартап».

Если стартап - компания, созданная для проверки гипотезы - то это здорово, что гипотезы проверяются быстрее; на те же деньги можно проверить больше гипотез или если гипотез мало - быстрее прекратить этим заниматься. Так что закрытие большинства стартапов - закономерный финал, можно сказать - основная цель. Цинично, да.

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

В результате проверки отсеиваются те, кто хуже. Лучшие просто остаются, как в эволюции.
Но это тоже моё частное понимание

Daily standup — краткий устный отчет о проделанной работе перед скрамоводом.

Зачем?

Если фичекоманда маленькая и вы знаете, что такое прозрачность - вы все в контексте общей работы. Друг другу рассказывать про вчера будет бессмысленно, вы все и так знаете. Отчёт начальству о прогрессе или потраченных человеко-часах? Странный эджайл, хотя ведь вы его понимаете как мягкий менеджмент

Sign up to leave a comment.