Это люди, которые создают продукты. Это люди, которые пишут программы. Это все еще люди, которые должны сотрудничать и повторять, чтобы создать что-то ценное. Agile-манифест подчеркивает этот факт, заявляя «Люди и взаимодействие важнее процессов и инструментов». Это напоминание. Мы должны делать акцент на людях и взаимодействиях, а не на процессах и инструментах.
Мы видели различные идеи, методологии и фреймворки, возникающие вокруг Agile, и мы узнали пару вещей на этом пути. В настоящее время Agile является основным способом создания программного обеспечения. Но было и много критики и негативного отношения к нему, точнее, в основном против Scrum. Scrum — это основной фреймворк Agile, поэтому, очевидно, будет много мнений, как и в отношении любого широко распространенного инструмента, фреймворка, языка программирования и т. д. Тем не менее, кажется, что существует разрыв между теорией и реальностью.
Теоретически Scrum — это облегченная структура с несколькими определениями ролей, форматами встреч и высокоуровневыми идеями о том, как управлять вашим продуктом. В теории.
Реальность кажется другой, даже внутри команды или компании. Владельцы продукта, скрам-мастера, разработчики, менеджеры — кажется, у всех разный опыт или мнение о скраме. Разработчики, кажется, имеют самые большие проблемы со Scrum, читайте, например, это, это и это. Все сообщения имеют веские аргументы, плюс это реальный опыт. С этой точки зрения Scrum не дал результатов, или, если быть более точным, люди, внедряющие Scrum, потерпели неудачу. Agile, реализованный таким образом, что акцент делается на ритуалах, артефактах, графиках выгорания и отчетах, упускает смысл быть agile. Это все о процессе. Но помните, речь идет о людях важнее процесса, так какую роль люди играют в этом уравнении? Очевидно, что проблема не только в Scrum, но и в людях. Люди внедряют Scrum. Другая проблема, которую я вижу, заключается в том, что нам нужны лучшие ответы на эти проблемы. У кого-то был или есть очень негативный опыт использования Agile/Scrum/XP/…. Какой совет мы можем дать? Чаще всего это одна из следующих реакций:
а. «Scrum — единственный способ создания программного обеспечения. Вы недостаточно используете Scrum. Вы должны делать это по правилам",
б. «Agile или Scrum — это ужасно».
в. "У Agile, XP или Scrum есть несколько хороших идей, давайте создадим новую методологию, которая объединит все хорошие идеи, и добавим новые идеи и правила, пока мы это делаем".
С а. или б. являющиеся общими ответами. Это явно преувеличено.
Кажется, существует много неправильных представлений о том, что означают Agile, Agile, Scrum или XP. На какую книгу все ссылаются? Есть ряд отличных книг по этой теме и еще больше книг, полных универсальных подходов. Кто-нибудь в последнее время читал Объяснение экстремального программирования? Там еще есть отличные идеи. Поэтому, когда кто-то выдвигает аргумент делай это по правилам, возможно, было бы лучше сказать прочитать Руководство по схваткеили прочитать книгу XP . Большой опыт работы со Scrum, XP и т. д. получен от внешних консультантов, коучей или, может быть, от кого-то, кто внедрил Agile-фреймворк внутри компании. Таким образом, мы слышим аргументы в пользу того, что XP или Scrum говорят делать то или это, в то время как очевидно, что те же самые люди, делающие заявления, не читали никаких книг, манифестов или иным образом глубже копались в основополагающих принципах.
Является ли ошибкой разработчика то, что он или она считает, что гибкость означает, что вам нужно менять команду каждые 8 недель или что вы должны отчитываться перед скрам-мастером во время стендапа? То же самое касается истории, ретроспективы игр и длинного списка других распространенных проблем Scrum. Когда компания ценит заявление о том, что она «делает agile», а не способствует развитию agile-мышления, вы не можете винить разработчиков в потере мотивации. И все дело в мотивированных личностях, помните?
Создавайте проекты вокруг мотивированных людей.
Предоставьте им необходимые условия и поддержку,
и доверьте им выполнение работы.
Возможно, нам следует чаще ссылаться на Agile-манифест. Это разумно, это все о ценностях и очень недогматично. Это все еще в силе.
Мы должны помнить, что в конце концов все зависит от людей. Опытная команда разработчиков выполнит любую методологию. Заявление Agile решит все ваши проблемы — это маркетинговый ход, но я думаю, что большинство согласится с тем фактом, что Scrum может быть очень полезным вводным курсом для перехода на территорию Agile. С другой стороны, культовый Scrum — это тоже нечто настоящее.
Вот некоторые моменты, которые я записал, над которыми, возможно, стоит подумать. Пожалуйста, не стесняйтесь критиковать или расширять, если вы видите, что чего-то не хватает, или дайте мне знать, могу ли я ошибаться в том или ином аспекте.
На какую книгу люди должны ссылаться, когда их просят сделать это "по инструкции"?
Либо перестаньте заявлять, что это нужно делать «по правилам», либо дайте команде возможность понять основные принципы. Знают ли все участники, что на самом деле означает «по правилам»?
Какую роль играет техническое совершенство?
XP уделяет большое внимание этому аспекту, в то время как Scrum уделяет большое внимание бизнесу. Скрам без аспекта технического совершенства менее эффективен, может быть, даже неэффективен.
Больше внимания разработчикам. Многие книги по Agile посвящены менеджменту.
Перестаньте называть разработчиков «всего лишь частью команды». Я видел это в нескольких статьях и книгах. Разработчики — такая же целевая аудитория, как и менеджеры, скрам-мастера и владельцы продукта. Это плохо. Неудивительно, что никто не заинтересован в понимании основных основ. Говорите и пишите разработчикам, всем бортпроводникам.
Что нужно команде? Как чувствует себя команда?
Опять тот же пункт, что и выше. Люди над процессом. Особенно это касается скрам-мастеров и консультантов. Команда здесь не для того, чтобы облегчить вашу работу. Наоборот, вам нужно убедиться, что вы понимаете людей, которые составляют команду. Все разработчики разные, каждая команда отличается. Вам понадобится правильный скрам-мастер, консультант для правильной команды. Чаще всего на роль скрам-мастера выбирают кого-то, у кого нет навыков, но есть сертификат. Мы можем сделать лучше, чем это.
Слишком много внимания уделяется простым задачам
Артефакты и встречи — это самые легкие части. Организовать ежедневный стендап — самая простая часть. Но именно этому уделяется наибольшее внимание. Мы определили время? У нас есть пост? Сложные части — это совместная работа людей, понимание того, как работает ремесло, как гарантировать, что каждый может преуспеть в техническом плане, привлечение пользователей на ранней стадии и т. д. Все дело в людях. Люди создают продукты для людей. Вы не можете научиться этому на двухдневном семинаре, и вы не можете понять это, не работая или не будучи частью выступающих команд в течение некоторого времени.
Перестаньте использовать аргумент «Это сработало для X — значит, это должно сработать для Y»
Это классика. Идет рука об руку с двумя предыдущими пунктами.
Запутанные аргументы. Противоречивый совет.
"Мы не оцениваем время. Но если в истории 13 точек, нам нужно разбить ее, так как для ее реализации потребуется больше, чем спринт». Добавьте измерение скорости на основе этих точек истории. Что теперь? мы оцениваем время, функции или сложность?
Рабочее ПО — единственный показатель.
Итак, зачем возвращаться к метрикам, похожим на отчеты, см., например, диаграммы выгорания? Работающее программное обеспечение — это единственная метрика, все остальное — это цифры и диаграммы — какую ценность или понимание эти метрики на самом деле добавляют или дают?
Проблемы с прозрачностью.
Прозрачность может привести к микроменеджменту. Это один из самых сильных аргументов разработчиков. Прозрачность не может быть улицей с односторонним движением, она должна работать в обоих направлениях. Разработчики получают представление о бизнесе и наоборот.
На эту тему можно написать гораздо больше. Это всего лишь отправная точка. Если у вас есть какие-либо отзывы или вопросы, свяжитесь с нами в twitter.
