Все по уму или все по Agile...

Уже несколько раз в этом совсем недавно наступившем году слышал фразу:

- А у нас в команде все по Agile....

А совсем недавно, когда мы дискуссировали, как это: работать по-Agile  с одним из разработчиков, мне было сказано:
- Ты когда про Agile услышал?...два года назад. А я семь лет назад, так что...

И разговор сместился с принципов и ценностей на практики Scrum и XP (хотя я о них и не упоминал). Т.е. - я то разговаривал о манифесте и гибкости команды, а собеседник предлагал практики. Я заметил, что так поступают очень многие. Для многих работать по Agile = использовать практики Scrum\XP.

Я заметил еще более ужасную вещь: повально распространено спекулирование модными словами Agile, Scrum, XP и т.п. объясняя тот хаос, что твориться в голове или того хуже - в проекте!


Вначале (года два назад) я думал, что это только мои ошибки. Я чего-то еще не понимаю. Как можно постоянно говорить - у нас все по Agile, выпускать продукт с большим количеством ошибок и ругать пользователей, что они их находят? Ведь главное - это забота о клиенте. Разве нет?

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

Как избавляться от ошибок? Я однозначного ответа дать не могу. Нужно беседовать. Убеждать. Доказывать.  Команде, менеджеру, сослуживцам... Хотя есть крайнее средство - трепанация черепа. Все чаще хочется приступить к последнему. Пока пытаюсь списывать на кризис среднего возраста )).

1. Мы работаем по Agile, и у нас должен быть ежедневный митинг.

"Острый" пример из жизни. Команда из почти двух десятков разработчиков, тестировщиков, субэдистов  и менеджеров расположена в трех разных городах. Более того - в трех разных странах. Но мы же работаем по Agile! - и нам нужен ежедневный scrum митинг!!!

Как они это понимают?

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

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

Насколько я могу судить стоячий scrum митинг очень полезен для следующих вещей:
- небольшой само-ретроспективы сотрудника,
- быстрого обмена информацией: тестировщикам - в очередной раз заявить, что они всей душой за, но верхи не дают билд. Разрабочикам - упомянуть, что они бы тоже не против, но верхи не дают требования. Менеджеру прокашляться и пообещать, что уж завтра точно его верхи дадут спецификацию требований. И тут мы подходим к третьей полезной вещи митинга.
- дать обещание что-то выполнить до завтра. По мне эта третья часть самая важная. Человек подписывается, что он будет работать, и сделает. Завтра на митинге он либо будет краснеть либо улыбаться.

Поэтому если у вас действительно все работает по маслу и нет затыков, то может просто общаться неформально, ориентируясь только на прогресс?

2. Мы работаем по Agile, и нам не нужны тестировщики.

О как! Это  настоящий бич, и не только для меня. Причем в манифесте Agile ни слова об этом.

Некоторые идут еще дальше: нам не нужно тестирование вообще - мы пишем автоматические тесты.

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

Какможно быть гибки и не суметь доказать, что разработка закрыта и ее можно продемонстрировать? Вроде бы практика скрама, но в проектах по Agile бывает предвзятое отношение к практикам. Некоторые внедряются, а некоторые нет.

Конечно, проверять могут и не тестировщики, а аналитики, или пользователи или сами разработчики. Но должна же быть тестовая среда, максимально приближенная к той, которой пользуются пользователи. Должно быть разделение между тестированием на среде разработчиков и тестовой среде. Должно быть разделение между такими процессами как разработка и приемка. Должен быть внедрен процесс, который подтверждает, что use case/user story/feature requirement/etc закончена и новая версия приложения готова к релизу. А кто этим будет заниматься, как этих людей назовут - это не важно. Контроль качества не привязан к названию роли.

3. Мы работаем по Agile и нам не нужна документация.

Это тоже очень интересный момент.

В манифесте белым по черным силуэтам написано: Working software over comprehensive documentation.  Священослужители  "гибкого слова" часто трактуют это как вообще отсутствие документации. Но вчитайтесь в последние строчки: That is, while there is value in the items onthe right, we value the items on the left more!

Для меня под слово документация подпадает даже описание фичи/бага в Jira. Самодокументирующийся код это тоже документация. 

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

Если клиент хочет красивый документ пусть он его получит. Этот документ сам по себе продукт.

Если у вас есть вики и ваш клиент счастлив - пусть будет только вики. И это поддержка разработки.

Но если вы так гибки, чтобы отказаться от документации, расскажите - как вы описываете User Story или требования, может быть жестами глухонемых?

4. Мы работаем по Agile и значит все-все-все должны работать по Agile

То, что от тестировщика требуют быть Agile это вполне нормально (ненормально то , во что это порой превращается).

Самое ужасное, если это говориться клиенту и клиента начинают "грузить" техническими терминами, в то время когда ему нужно пожалуй только ответить только на два вопроса:

Сколько времени это займет?

Сколько мне придется заплатить?

Часто (но не всегда) задается еще один вопрос: Как я могу отслеживать прогресс?

А клиенту рассказывают про спринты, ночные билды, скрам митинги, сертифицированных скрам мастеров, парное програмирование... Как это воспринимает технический неподкованный клиент?

Бла-бла-бла. Бла-бла-бла. Бла. Бла-бла-бла-бла ночью!

Нельзя быть Agile, когда все вокруг не используют "ваш" Agile, точно также, как неоткуда взяться водопаду (waterfall) в океане.

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

5. Мы работаем по Agile - и у нас должны быть спринты.

То с чем я столкнулся: это понимать спринты, как короткие промежутки времени, в течении которых разрабатывается что-то, даже если разработка (какое уж тут тестирование) не заканчивается и ничего демонстрироваться не будет.

И это что-то разрабатывается и во второй спринт (потому что не успели в первый). В третий спринт, как вы понимаете тоже не уложились, а уложились в пятый... Зачем спринты? Ну так они же есть в Scrum!

6. Мы работаем по Agile - у нас все по Agile.

Это просто контрольный выстрел в голову.

Agile, повторюсь, это принципы и ценности. Метрик, по которым можно судить насколько вы Agile не существует (конечно сертифицированные scrum-мастера могут со мной поспорить и даже, наверное, спор выиграют). Есть очень очевидный ложный принцип измерения длины вашего Agile: когда ты услышал про Agile?

Бурчание напоследок.

Я не отвергаю существования Agile мышления в принципе, но тот, кто бездумно произносит  модные слова, внедряя практики уподобляясь культу Карго (не думая головой, насколько это полезно для его команды именно сейчас), подобен капитану "Титаника": мы большие - мы не свернем. Многих не останавливает и тот факт, что проекты "по Agile" также терпят крушение, как и проекты "по Waterfall".  Многие ищут только новое название для своей новой серебрянной пули для того чтобы объяснить то, что сейчас происходит в проекте. Это очень грустно.

Наличие итераций в разработке, отсутствие документации, отсутствие тестировщиков и UAT в принципе, невозможность продемонстрировать окончание User Story (потому, что все готово будет только в -3-N спринте), после каждого релиза наличие критических дефектов - и даже эти результаты называют Agile результатами. Это очень очень грустно.

Мое самое большое замечание - нельзя работать по Agile и продолжать выпускать продукты с плохим или неизвестным качеством. 

У вас все работает по Agile?

Бойтесь этих слов.

Работайте по уму.

Или Agile разрушит вашу жизнь.