четверг, 27 января 2011 г.

Все по уму или все по 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?

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

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

20 комментариев:

  1. Formalizing all the foolish, thoughtless, and unforesighted things I would normally do? Sign me up! I’ll call it agile, and the business interests won’t know the difference. (c) http://qahatesyou.com/wordpress/2010/01/developers-think/

    Но вообще мякотка конечно

    ОтветитьУдалить
  2. Спасибо Сергей за ссылку. Улыбнуло название сайта "QA Hates You.You suspected it. Now you know it."

    ОтветитьУдалить
  3. Понравилась статья, все актуальные пункты затронуты.
    Рискну указать ещё одно определение: Agile - это когда ты работаешь в удовольствие, не просиживая за своим компьютером весь день :)

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

      Удалить
  4. Это действительно превратилось в культ карго, но это сложно заметить изнутри.

    Кстати, улыбняка на эту тему - http://www.halfarsedagilemanifesto.org/

    ОтветитьУдалить
  5. Ох с каким удовольствием прочитала, спасибо! Действительно наболевшее, особенно "любимые" пункты 2 и 3.

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

    ОтветитьУдалить
  6. Александр, спасибо за статью. Теперь точно буду знать, что скажу в очередной раз менеджерам.

    ОтветитьУдалить
  7. >andrebrov

    С менеджерами вообще нужно общаться, а не только говорить о наболевшем ;)

    Менеджеров тоже можно понять. Они ведь слушают об успехах гибких вещей на успешеных конференциях от успешных консультантов. Как тут не купит название.

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

    ОтветитьУдалить
  8. Статья ни о чем. Любую хорошую идею можно довести до идиотизма.

    ОтветитьУдалить
  9. >Статья ни о чем. Любую хорошую идею можно довести до идиотизма.
    Но этот идиотизм нужно выявлять и называть идиотизмом во время.

    ...вежливость для дураков, именно поэтому анонимусы хамы правят интернетом?

    ОтветитьУдалить
    Ответы
    1. Статья как раз о том, как идеи доводятся до идиотизма.

      Удалить
  10. Александр, написав тут как по-идиотски где-то устроен рабочий процесс, вы расчитывали на что-то более? Согласен, читать про то что у других может быть хуже чем у тебя - всегда приятно, но стоит ли на это тратить свое время?

    ОтветитьУдалить
  11. Анонимный, простите, что вмешиваюсь, но каждый из прочитанного делает свои выводы. Если для вас это только повод порадоваться, что у кого-то дела обстоят хуже, чем у вас - это в общем-то ваш выбор.

    А для других это, например, может быть предостережение избегать подобных ошибок. А кому-то это может даже открыть глаза но то, что у них ужас и кошмар происходит не потому, что это "по Agile", а потому, что это искажённая идея, с чем надо бороться.

    ОтветитьУдалить
  12. Анонимус, Я уже писал про то, на что я рассчитываю
    Почитай: http://seljava.blogspot.com/2010/11/blog-post_03.html

    ОтветитьУдалить
  13. Лена, давайте представим ситуацию, вы открываете книгу по куллинарии и находите там статью о том как можно с помощью двух яиц, стакана молока и щепотки соли полность изгадить всю кухню. Вам полезны такие знания? Да, как хорошо всетаки что мы теперь знаем что так не стоит поступать.

    ОтветитьУдалить
  14. Ну, если уж играть в аналогии, то давайте возьмём другой пример:

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

    - то да, я за такую информацию буду благодарна.

    Кажется странным?

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

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

    ОтветитьУдалить