Не секрет, что обсуждения о пользе Agile подходов идут параллельно с ещё большим количеством обсуждений о вреде, проносимом «внедрением Agile». Интерес к «темной стороне» был, есть и должен быть. По той простой причине, что для составления объективного мнения нужно выслушать две стороны (а ещё лучше четыре).
Поэтому статья Дэниэля Маркхема «Agile Ruined My Life» вызвала бурные обсуждения. Недавно я нашёл русский перевод, который настоятельно рекомендую прочитать. Многие Некоторые люди смело могут сказать «Agile разрушил мою жизнь» и будут в какой-то мере правы.
Если говорить о «внедрении Agile» как о цели, то однозначно есть целый ряд проблем. Дэниель в своей статье перечисляет лишь некоторые из них:
Придуманные истории успеха
Тренеры, которые не могут выполнить работу
Негибкость в стане сторонников
Синдром волшебной пули
Отказ от доминирующей роли команды
Это то же самое, только другое
Это только те, которые я лично встречал в своей жизни. Благодаря работе переводчика, вы сами можете прочитать все подробности и согласиться или не согласиться с Дэниелем.
Обсуждение Agile часто звучит в стиле анекдота «Как, вы не любите кошек?! Да вы просто не умеете их готовить!» уже давно приводит в бешенство любую аудиторию. Лично меня раздражает, что многие называют Agile МЕТОДОЛОГИЕЙ! 🙂
Опять цитирую Дэниэля:
Итак, что такое Scrum? Это стандартизованный вариант управления проектом для итеративной и инкрементальной разработки, вот что. В нем есть доска, тест, класс. Единое целое. Когда мы говорим о Scrum, у нас есть точные термины и концепции для обсуждения (нравятся они или нет, это другая история).
Наш финальный вопрос: что такое Agile. Обычно у пары человек есть идеи. Один скажет: «Это TDD». Другой: «Я думаю, что это манифест».
После долгой паузы я говорю классу (звучит как шутка, но шутки в сторону):
У Agile нет определений.
Истинно. Дуля с маком. Никаких.
Если вы любите метафоры, то предлагаю использовать пример из языков программирования.
Agile – это интерфейс. У него есть описание каких-то констант (ценностей) и возможно даже намёк на методы (принципы). Но никакой информации об их реализации. Вы пользуетесь этими ценностями и принципами, когда принимаете решение, как будет работать ваша команда. Какие-то из них вы вообще пропускаете, поставив заглушку, а какие-то становятся самыми используемыми.
Scrum – это абстрактный класс. В нем уже есть конкретные роли и методы – это и есть методология. И в тоже время, Scrum по-прежнему абстрактен – это лишь каркас (framework).
MyScrum – это то, что вы строите в своей команде, основываясь на базе Scrum. А по дороге ещё наследуете или используете другие «хорошие практики». И если вы выкинули все родительские методы, то просто не называйте это Scrum :-). Во всяком случае, не говорите, что вы работаете по Scrum, если вы только проводите ежедневные встречи. Ну пожалуйста, будьте честны с собой.
Я не думаю, что у Agile нет определения. Напротив, вполне четкое определение – набор принципов и ценностей, определяющих направление в разработке программного обеспечения. Ты как раз привел мою любимую метафору с интерфейсом, абстрактным классом и реализацией. Она как нельзя лучше описывает взаимоотношение между множеством Agile методологий, Agile принципами и ценностями, а также конкретными процессами разработки, постренными в компаниях. Scrum в этом плане хорош тем, что предоставляет базовую реализацию многих принципов, но оставляет много свободы и пространства для модификаций и нововведений. Это делает его удобной отправной точкой.
Коля, если копать глубже, то все метафоры лживы и в том числе та, которую я привел 🙂
Много разработчиков, могли поймать меня на том, что интерфейс обычно как раз подразумевает некий “контракт” и даже если не содежрит описания методов, то используется как “маркер” при проверке действительно ли мы используем его.
С Agile все сложнее – нет никаких явных признаков его использования или не использования. Я сам неоднократно говорил, что мы руководствуемся ценностями и принципами при принятии решений. В тоже время – как ты проверишь, что команда проводит ежедневные встречи сидя, и именно из соображений “individual and interaction over processes and tools”, а не каких-то других? 🙂
Scrum, как раз более “ограничен” правилами, поэтому и легче начать с проверки на следование этим правилам, чем абстрактным принципам. В тоже время, встречаются “формальные” реализации скрама, где нет как раз приверженности принципам таким как совместная работа, самоорганизующейся команды, постоянная адаптация и другим.
Маша написала замечательный пост в тему 😉
Статья напомнила мои недавние поиски Scrum Antipatterns.
Идея проста: чтобы лучше понять некую сущность, полезно сравнить ее с тем, чем она не является.
По этому поводу мне понравилась эта презентация:
http://www.slideshare.net/rowanb/kicking-scrumbut
Для меня одним из косвенных показателей хорошего Scrum/Agile является “уровень ржача” в команде (на ряду с остальными параметрами).