Одна вещь, которая недавно привлекла наше внимание вопрос предоставлено на stackexchange.com. Этот вопрос был направлен на понимание влияния Scrum на работу программистов.
Автор вопроса, пользователь Qiulang, поднимает довольно смелую тему: «Scrum превращает хороших разработчиков в посредственных программистов.
Является ли это возможным?".
Основная идея Scrum-фреймворка — организовать процесс разработки для более быстрого завершения работ на различных этапах жизненного цикла проекта.
Но всегда ли такой подход подталкивает разработчиков к правильным моделям поведения? Многие пользователи, присоединившиеся к обсуждению вышеизложенного вопрос на Stack Overflow видели подобные вещи, когда разработчики срезали углы, уделяли слишком много внимания высоким баллам, присвоенным их билетам, или даже притворялись менеджерами высокоэффективными.
Как избежать этих опасностей? 
Вопрос, о котором идет речь, перенесен из рабочее место.
stackexchange.com на Softwareengineering.stackexchange.com .
Это говорит о том, что программисты рассматривают соображения, связанные со Scrum и его эффективностью, как нечто вполне серьезное, выходящее за рамки управления циклом разработки программного обеспечения.
Они чувствуют влияние этого метода управления проектами на общую рабочую среду.
Является ли Scrum причиной плохих методов разработки или это просто оправдание проблемы?
Было много споров о влиянии Scrum на команды и отдельных разработчиков, а также об ограничениях, которые эта структура накладывает на тех, кто ее использует. В то время как многие обвиняют Scrum в неудачах команды, другие полагают, что это ошибка атрибуции и что корни проблем в командах разработчиков лежат гораздо глубже.Сторонники Scrum винят в своих проблемах плохой менеджмент. Вот что говорит пользователь Ллевеллин , резюмируя: «Руководство по сути игнорирует разработчиков.
Существуют фиксированные сроки, которые необходимо соблюдать для достижения заранее определенных результатов.
Работу выполняет не коллектив, ориентированный на достижение одной цели, а группа людей, в которой каждый заботится только о себе.
Долгосрочное планирование и нестандартное мышление не приветствуются.
В таких условиях программист в конце концов поддается обстоятельствам и находит спасение в простом выполнении поставленных перед ним задач.
Я работал в таких условиях.
Но не вините в этом Скрам».
Пользователь диджей Клейворт выразил мнение многих комментариев, заявив, что программисты, которые думают, что находятся под давлением, будут плохо работать при применении любой методологии управления разработкой.
Противоположное мнение по этому вопросу лучше всего высказал пользователь Мартин Маат , который указал аудитории, что сам факт того, что так много людей чувствуют необходимость высказаться по этому вопросу, красноречиво говорит о разочаровании, которое вызывает у них Scrum.
Каковы общие болевые точки при использовании Scrum?
В комментариях были затронуты некоторые распространенные ошибки Scrum, которые возникают либо из-за неправильного применения структуры, либо из-за присущих Scrum проблем.Вот почти десяток проблем такого рода, привлекших наше внимание.
▍1. Ежедневные встречи для менеджеров
Первая критика Scrum заключается в том, что нежелательные тенденции возникают во время ежедневных стендапов.Одним из аргументов в пользу этой идеи является то, что стендап-комедия может переродиться в мероприятие, на котором участники ничего не делают, а только и говорят о том, насколько они продуктивны.
Особенно если на таких мероприятиях присутствуют менеджеры.
Поэтому пользователь Мэтью Гайзер (он уже писал нам, но мы случайно наткнулись на его комментарий) называют стендап-мероприятия, которые направлены на информирование менеджеров о текущей ситуации ( управление обновлениями ).
Он считает, что разговоры разработчиков на таких мероприятиях лишь стимулируют менеджеров наблюдать за тем, над чем работают, но никакой пользы это не приносит. В еще большей степени это актуально для распределенных команд, когда каждый участник команды работает в своем режиме.
▍2. Основную роль играет выполнение заданий
Другая идея, возникшая из комментариев, заключается в том, что любая методология разработки, которая делит большие задачи на более мелкие и отслеживает ход выполнения этих задач, намеренно или нет, приводит к новым подходам к измерению производительности.Если вы просто начнете использовать какие-то метрики, это повлияет на поведение людей, эффективность которых оценивается в соответствии с этими метриками.
Многие комментаторы говорят, что это означает, что разработчики могут срезать углы, чтобы завершить то, что необходимо сделать в текущем спринте.
Проблема, о которой сообщил пользователь Гайзер и других пользователей, заключается в том, что единый тикет, над которым ведется работа и который в ходе спринта переводится в категорию «готово», является «черным ящиком».
Что бы ни находилось внутри этого «черного ящика», это не повлияет на результат оценки скорости работы.
Пользователь Gaiser пишет, что некачественная реализация, прошедшая отдел QA, и идеально протестированная и спроектированная реализация ничем не отличаются друг от друга.
В результате получается, что учет количества закрытых билетов является недостоверным показателем производительности труда.
▍3. Чрезвычайно продуктивные разработчики, которые не работают в команде
В другой теме обсуждалось противоречие между великими программистами-одиночками и великими командами.Когда все следуют методологии Scrum, некоторые разработчики могут быть чрезвычайно продуктивными, но тогда о «команде» можно забыть.
Пользователь Gaiser говорит, что без правильных стимулов самоорганизация — недостижимая цель: «Члены команды будут решать проблемы так, как им удобно или так, как им предписывают. Если это не поможет построить команду, многие вещи не будут сделаны, и члены команды просто будут двигаться вперед в беспорядке».
Он продолжает: «Более того, позволяя каждому разработчику выбирать собственные методы решения проблем, это означает, что отладку кода становится сложнее».
▍4. Сложные задачи откладываются на потом
Гайзер, рассуждая в том же духе, продолжает критиковать иллюзию продуктивности.Он говорит, что при использовании Scrum основное внимание уделяется переходу билета в состояние «Готово».
Глубокое размышление над задачей не кажется особенно продуктивным.
Поэтому разработчики могут иметь тенденцию браться за простые задачи и избегать более сложных.
Здесь опять же, по словам пользователя Gaiser: «Scrum побуждает разработчиков браться за простые задачи, на решение которых уходит мало времени, что позволяет разработчикам показывать стабильно высокую скорость».
В результате получается, что ежедневный отбор задач и ежедневные отчеты о работе подталкивают к отбору задач, на решение которых требуется один день.
▍5. Характеристики продукта важнее качества кода
Тот же Гайзер считает, что использование Scrum-фреймворка приводит к снижению качества продуктов: «Насколько хорош разработчик, обычно определяется его способностью разрабатывать надежный код. Скрам, если владелец продукта не разбирается в программировании и не просматривает код, серьёзно обесценивает эту характеристику проектов».Он подчеркивает здесь, что «готовность» тикета зачастую определяется не после проверки качества кода, а только после реализации соответствующей функции.
▍6. Недостаток времени для обсуждения рабочих вопросов с коллегами
Если скорость разработки является единственным показателем эффективности команды, это означает, что у членов команды больше нет времени обсуждать проблемы друг с другом, узнавать мнение других людей или проверять свои идеи с кем-то еще.говорить о них.
Но именно это делает команду командой.
Здесь опять же слова пользователя Gaiser: «Великие разработчики часто консультируются с другими разработчиками и ищут альтернативы их мнениям.
Но такая деятельность отнимает время, необходимое для закрытия заявок, а это снижает скорость разработки».
▍7. Недавно обнаруженные ошибки должны ждать своей очереди.
Еще одно плохое поведение, вызванное использованием Scrum, заключается в том, что «ошибки обнаруживаются после спринта и рассматриваются как новые проблемы».
Это может подтолкнуть разработчиков к выпуску некачественного кода, поскольку в текущий спринт невозможно включить дополнительные задачи.
▍8. Архитектура, управляемая билетами
Тикетная система основана не только на том, какие задачи выбирают для себя разработчики.Пользователь Гайзер также говорит, что использование Scrum непреднамеренно приводит к созданию запутанной архитектуры проекта, поскольку разработчики работают над заявками в порядке их появления и независимо друг от друга.
В результате «архитектура быстро становится отражением билетов».
▍9. Методология управления разработкой, которая влияет абсолютно на все
Читая обсуждение, можно обратить внимание на комментарии, авторы которых отмечают, что корень всех проблем кроется в недостаточно строгом соблюдении правил Scrum. Однако, пожалуй, самое сильное утверждение Гайзера против Scrum заключается в том, что эта структура подавляет все остальное.Это может разрушить сильную команду.
«[Scrum] искажает и ломает любой другой механизм управления разработкой, фреймворк становится всеобъемлющим явлением, в котором ничего, кроме выполнения ритуалов, не делается единообразно, а выполнение этих ритуалов создает иллюзию успеха».
Мы обсудили достаточно большой список проблем, которые могли быть вызваны использованием Scrum, а возможно, стали только более заметными из-за использования этого фреймворка.
Но в обсуждаемой нами дискуссии столько же идей о том, как застройщики могут жить в мире и согласии, следуя Правила скрама .
Как получить максимальную отдачу от Scrum?
Многие из ответов на комментарии Гайзера, получивших много положительных комментариев, заключались в том, что то, о чем он говорил, не было Scrum. Вот что написал по этому поводу пользователь Стивен Бирн: «Я думаю, что это хороший ответ и содержит некоторые ценные идеи, но я должен согласиться со многими другими комментаторами, что то, что здесь описано, определенно не является Scrum, хотя и рассматривается под видом Scrum. Скрам».Но многие либо открыто ненавидели Scrum, либо соглашались с пользователем Gaiser, что если при использовании Scrum что-то идет не так, то это означает, что фреймворк просто применяется неправильно.
Как правильно использовать Scrum?
▍1. Ежедневные встречи — это не то же самое, что брать новые билеты каждый день.
Многие говорили о том, как ежедневные встречи заставляют разработчиков закрывать заявки каждый день.
Но, как заметил диджей Клейворт , также невозможно обойтись без приоритизации задач.
А если приоритеты не расставлены естественным образом, то Scrum Master должен взять на себя эту задачу: «Задачи внутри спринтов должны быть расставлены по приоритетам, более крупным задачам нужно придавать более высокий приоритет, поэтому кто-то должен взять на себя сложные задачи в первый день спринта».
спринт. В любом случае, если ко второму дню никто не взялся за большую и сложную задачу, Scrum Master должен сказать примерно следующее: «Я вижу, что никто не взялся за задачу сжатия базы данных.
И это большая задача.
Если мы собираемся завершить спринт, нам нужно начать работать над этой задачей сейчас».
▍2. Стоит перестать оценивать результаты отдельных разработчиков и перестать рассчитывать метрики, относящиеся к отдельным тикетам.
Все задачи, решаемые в спринте, необходимо разбивать на мелкие части.
Это неоспоримо.
Но структура Scrum не говорит, что разработчики должны быть одержимы метриками, которые указывают на определенные результаты.
Scrum не предлагает натравливать разработчиков друг на друга.
Пользователь Гайзера предложения полностью перестать учитывать баллы отдельных программистов.
Он также указывает, что многим менеджерам, возможно, придется заново изучить правила Scrum: «Скажите менеджерам, что в тот момент, когда они хвалят разработчиков или дают им повышение в зависимости от количества закрытых заявок, это момент, когда они радикально меняют поведение команды».
" Пользователь диджей Клейворт соглашается, что намеренное игнорирование показателей, связанных с отдельными тикетами, должно быть частью работы хорошего Scrum-мастера: «Фокус должен быть сосредоточен на том, чтобы команда достигла своих целей как команда.
Скрам-мастер должен придерживаться этой линии поведения и избегать любых обсуждений или расчетов показателей, основанных на том, сколько пользовательских историй продвинул каждый отдельный член команды».
▍3. К большим целям нужно идти маленькими шагами, но при таком подходе об этих целях забывать не стоит.
Вот еще одна идея разбить большие задачи на более мелкие части: «То, что вы работаете над маленькой частью головоломки, не означает, что вам нужно забыть обо всей головоломке».Пользователь Ллевеллин подчеркивает, что использование Scrum не может служить оправданием полного игнорирования принципов разработки качественного программного обеспечения: «Вы должны хорошо представлять, куда движется проект. Эти знания можно использовать для планирования архитектуры проекта, планируя даже в рамках текущего спринта».
Scrum не освобождает программистов от необходимости делать свою работу, вкладывая в нее все свои знания и весь свой опыт. Поэтому послание Ллевеллина относится и к программистам, которые входят в число читателей комментариев: «Вы были на встрече, можете посмотреть бэклог, вы знаете, каково общее видение проекта в организации.
Вы стремитесь избежать необходимости тратить много времени на что-то из далекого будущего.
Но нет ничего плохого в том, чтобы заложить фундамент расширяемой модульной системы, которая одновременно подойдет для решения текущих задач и позволит легко создавать дополнительные возможности, уже запланированные в будущем».
▍4. Нам нужно решить, что означает «Готово».
Одной из тем, возникших в ходе обсуждения, которое мы обсуждали, было определение готовности (DoD) и то, как определение этих критериев помогает отдельным программистам придерживаться определенных стандартов качества и знать, чего от них ожидают. Самый актуальный вопрос здесь заключался в том, кто и когда разрабатывает эти критерии.
В отношении " Когда », обычно речь шла либо о том, чтобы как можно быстрее разработать критерии, либо о том, что их следует разрабатывать во время планирования спринта.
Ответ на вопрос о том, кто производит DoD, был написан SpoonerNZ как ответ на другой вопрос на сайте Программной инженерии.
«Критерии готовности создает команда, но этот процесс может потребовать присутствия Scrum Master. Это нужно для того, чтобы установить ограничения по качеству в случае, если у команды нет четких стандартов разработки.
Например, команда может не захотеть заниматься код-ревью или юнит-тестами, что приведет к тому, что все это будет добавлено в DoD по инициативе Скрам-мастера, чтобы обеспечить высокое качество разработки.
В идеальной ситуации команда, поняв сильные стороны того, что ей предлагают, с радостью примет это, но реальный мир не всегда идеален».
Кто должен работать, соблюдая требования Министерства обороны? Естественная (и сложная) цель состоит в том, чтобы обеспечить соблюдение положений Министерства обороны одной командой и поддержку их всеми членами этой команды.
Но есть веские причины распространить влияние Министерства обороны на несколько команд. Или даже всей организации.
Вот что пишет об этом пользователь Алан Лаример : «Отсутствие общепринятого определения продукта в Министерстве обороны негативно влияет на качество и прозрачность результатов работы.
Организационный уровень Министерства обороны должен быть минимальным, техническим, а иногда и организационным, который может обеспечить универсальное применение критериев готовности.
Организация может предложить стандарты кодирования.
Организации может потребоваться автоматическое создание сборок, предоставив ресурсы для создания и поддержки сборок для каждого продукта.
Любая часть Министерства обороны, независимо от того, создана ли она организацией или отдельным разработчиком, должна привносить что-то ценное в критерии готовности».
▍5. Менеджеры должны играть роль молчаливых наблюдателей.
Хотя то, что изложено в заголовке этого раздела, уже закреплено в официальном руководстве Scrum, анализ обсуждения показывает, что это правило, к сожалению, часто нарушается на ежедневных встречах, где присутствуют менеджеры.
Из-за этого программисты чувствуют необходимость объяснить, почему работа над билетами занимает у них больше времени, чем планировалось.
Если на встрече присутствуют только программисты, особой необходимости в таких объяснениях нет. Вот что об этом говорит Scrum Guide: «Ежедневный Scrum — это внутреннее собрание команды разработчиков.
Если присутствует кто-то еще, Скрам-мастер следит за тем, чтобы он не мешал встрече».
▍6. Люди должны быть важнее процессов
Если вы ищете рекомендации о том, как применять правила Scrum, прочитайте это от Фрэнка Хопкинса, которое напоминает нам классический принцип: «Люди важнее процессов».Здесь он добавил следующее: «Хорошая команда должна определить свои процессы; жестко определенные процессы не способствуют формированию хорошей команды».
Другой пользователь меритон , отметил, что использование Scrum зависит от отдельных программистов: «Scrum не предусматривает того, что разработчики работают независимо друг от друга.
Scrum предполагает, что команда разработчиков является самоорганизующейся, то есть команда принимает решения о том, как взаимодействуют ее члены».
Пользователь nvoigt примечания , что команды в Scrum самоорганизуются за счет того, что приходят в проект с уже определенной миссией: «Фреймворк Scrum основан на том, что вы — команда.
В команде не имеет значения, был ли вчера закрыт тикет конкретным программистом.
Тот, кто работает в команде, понимает цель (то есть ДО) и стремится достичь ее вместе с остальными членами команды».
▍7. Создавайте команды для работы по принципам Scrum, но не ждите, что использование Scrum приведет к созданию команды.
Пользователь нвоигт использовал спортивную метафору: «Представьте, что 11 человек получили печатное руководство по футболу.
Им сказали, что нужно заниматься каждый день, около 10 утра, в конференц-зале №5, тратя на это 15 минут. Как вы думаете, из этого получится хорошая футбольная команда? Что, если бы эти 11 человек были хорошими профессиональными футболистами? Разве команда в любом случае не сработала бы? Да, это не сработает. Футбольные команды устроены не так.
Как и любой командный вид спорта, Scrum требует от тех, кто использует эту структуру, быть командой.
Если это просто группа людей, которые просто хотят заработать очки, показывая, сколько очков пользовательской истории они выполнили или сколько целей они достигли, то эта группа всегда будет проигрывать команде, члены которой играют вместе, а не рядом друг с другом.
друг или друг против друга».
Полученные результаты
Пользователь нвоигт Я готов признать, что Scrum «не подходит абсолютно всем людям и командам».И, как показал интерес сообщества к обсуждаемому здесь вопросу, применение набора правил, к разработке которых может способствовать Scrum, может привести к построению рабочей среды, далекой от той, которую хотелось бы создать.
Нам хотелось бы обобщить этот материал словами пользователя Сет Р.
.
Он говорит, что не следует ожидать чудес от ритуалов гибких методологий.
Те, кто хочет использовать их, как по волшебству, для исправления недостатков команды разработчиков, хотят слишком многого.
Вот как он видит ситуацию: «Это все завязано на ускорении обратной связи.
В результате у команды появляется возможность провести самооценку и принять решение о том, как работать для достижения лучших результатов.
Скрам не поможет вам создать лучший продукт, но если вы серьезно отнесетесь к самооценке, он может помочь вам создать лучшую команду.
А это, в свою очередь, приводит к разработке лучшего продукта».
Многие сравнивают эту структуру с демократией.
Так может быть, Scrum — худшая форма управления процессом разработки, если не считать всех остальных? Или, может быть, это так, как говорят в официальное руководство , структуру, которую легко понять, но трудно освоить.
Как бы вы ответили на вопрос, вынесенный в заголовок статьи? 
Теги: #программирование #Управление разработкой #Управление проектами #разработка #Управление продуктом #scrum
-
Обход Капчи С Помощью Headless Chrome
19 Oct, 24 -
Как У Вас Появился Timeweb.ru!
19 Oct, 24 -
Djbdns
19 Oct, 24 -
Делаем Дом Видимым На Спутнике Google Map
19 Oct, 24 -
Обнаружение Лжи
19 Oct, 24
