Анти-agile пост.

slonik_v_domene — 26.08.2010

Люди реальны

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

У нас на Плюке все обстоит несколько иначе. Программисты не умеют верстать HTML, а дизайнеры почему-то не готовы писать код на C++. Кроме всего прочего, люди ходят в отпуска, болеют, опаздывают, ругаются друг с другом, и вообще занимаются антисоциальными делами. Увы. В раю жить дано не каждому.

То была вводная.Теперь о постулатах.

Коллективное принятие решений и коллективная ответственность

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

Встречаются как-то подводная лодка вероятного противника и русская, переговоры
русских: 
- Кто кинул валенок на пульт?
Представители вероятного противника посмотрели на беспоpядок и говоpят:
- У нас в Амеpике такого нет!
- Да нет больше вашей Амеpики... Кто кинул валенок на пульт?!

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

Другая сторона медали - коллективное наказание в случае провала. Увы, но мотивация на достижение результата не может ограничиваться только положительными подкреплениями. Отсутствие рядом с пряником кнута означает абсолютную безнаказанность. Просто вообразите себе, что ВНЕЗАПНО отменили уголовный кодекс. Кто постарше может просто вспомнить лихие 1990-е с воруй/убивай. Вообразили/вспомнили? То-то.


Теперь представьте себе, что у вас в коллективе есть дизайнер, верстальщик и server-side программист. Допустим, верстальщик не успел к сроку, топменеджеры рвут и мечут и требуют крови. Дизайнер и server-side программист себя виноватыми не считают, они все сделали в срок. Коллективная ответственность предполагает и коллективное наказание, не так ли? Поэтому вы идете клевать мозк всему коллективу. Раз. Другой. Третий. Люди собирают манатки и валят куда подальше от такого руководителя. И правильно делают.

И самое главное. Коллективная ответственность противоречит концепции оценки ключевых показателей эффективности. Либо вы персонализируете достижения и провалы, и у вас есть KPI, либо - коллективная ответственность.

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

Тестирование продукта

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

Как проверить качество? До сих пор ничего лучше ISO 9126 не придумали. Проблема только в том, что большинство критериев оценки - экспертные, а не расчетные. Иными словами, оценка качества в существенной мере базируется на мнении оценивающего.

Сечете фишку? Нет?

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

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

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

Взаимозаменяемый коллектив

Допускаю, путем сильной мотивации можно обучить программиста C++ работе со стилями CSS, а дизайнера - править конфиги. Думается, при этом лояльность будет ни к черту, и качество работы тоже никакое. Говорят, все не так, и где-то есть люди, умеющие все сразу. Не знаю. Я таких полиглотов еще не встречал.

Шили плотники штаны -
Вот тебе и брюки!
Пели песенку слоны -
Вот тебе и звуки!
Лили воду в решето-
Вот тебе и здрасьте!

Лучше все же делать то,
Что ты делать мастер!
      Ю. Ким, Песня о компетентности

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

Вывод: Универсальных солдат нет. Разделяйте обязанности. Грамотное разделение обязанностей повышает и качество и скорость исполнения работ.

Фиксированные по времени спринты

Допустим, для выпуска следующей минорной версии продукта необходимо исправить N известных багов и дописать X нового функционала. Это - план.

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

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

Любой большой проект с длительной историей в значительной мере развивается через фидбэк. Поддержка, исходя из моего опыта, требует от 30 до 60 процентов рабочего времени команды. Следовательно, либо постоянно идут "внеочередные" выкатки, либо в выделенное на buigfix время народ играет в Counter Strike, либо баги не фиксятся неделями.

Второй важный момент: я не встречал проекта где все выполняемые задачи квантизуются примерно на одинаковые разумно-небольшие промежутки времени. Ну то есть нарисовать и полностью отладить новый скин для Почты за неделю вполне себе реально, а вот выкатить новый элемент AJAX под реальную нагрузку - уже нет. А есть и более сложные задачи, реализация которых может занять и полгода, и год. Разбивать задачи между итерациями идеологически неверно, здесь я полностью согласен с теорией. Невеста не бывает наполовину беременной. Точно также и продукт не бывает наполовину сделанным. Либо у вас что-то в продакшене, либо - нет.

Вот и получается что фиксированные итерации - вещь слабо реализуемая. Не надо лицемерить и подстраиваться под сроки. Есть что выкатывать - выкатывайте. Главная задача - делать в срок и качественно. То, что на этой неделе было 2 выкатки, а следующие полмесяца выкаток не планируется - не беда. Если отставания от паланов нет - все нормально.

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

И последнее

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

Иными словами: проповедуется духовное единение вокруг единственного Просветленного, несогласные изгоняются, успех однозначно записывается на счет методологии, а неуспех - старательно игнорируется. ;)

Остался неотвеченным последний вопрос: что же делать если руководство непременно хочет от вас agile? Все просто: называйте agile тот процесс, который позволяет вам работать эффективно. И гоните ссаными тряпками всех этих мастеров с их фиксированными сроками, коллективной ответственностью, отсутствием Q&A и прочей новомодной красивой дребеденью.
У вас УЖЕ agile-разработка. Да еще и с определенными улучшениями! Правда-правда. Вы модное слово сказали? Вас услышали? Ну вот и ладно, всем спасибо, возвращаемся к девелопменту.

Оставить комментарий

Популярные посты:

• Архив