Лекция
Это продолжение увлекательной статьи про гибкие методологии разработки по.
...
«Что способствует жизни, достойную того, чтобы ее прожить?»
Он отмечает, что увеличение количества денег не делает нас, людей, счастливее. Хотя средний доход с поправкой на инфляцию в США за последнюю половину двадцатого века увеличился более чем вдвое, уровень счастья, по оценкам самих людей, вообще не увеличился.
Данные о доходах Министерства торговли США, Бюро переписи населения (1975 г.), а также данные об экономических показателях и уровне счастья, полученные из Общих социальных опросов Национального центра исследования общественного мнения Чикагского университета.
Концепция Потока заключается в том, что мы чувствуем себя счастливее и более удовлетворены жизнью, когда можем регулярно погружаться в деятельность, на освоение которой потратили годы.
Поток может возникнуть только тогда, когда мы выполняем очень сложные задачи в областях, в которых мы обладаем высокой квалификацией.
С разработчиками программного обеспечения это происходит, когда они применяют многолетний опыт для решения сложной задачи и настолько поглощены созданием чего-либо, что у них не остается достаточно внимания, чтобы контролировать свои пять чувств или думать о проблемах в своей жизни. или осознают, что они голодны или устали. Это экстатический, буквально внетелесный опыт. Именно здесь выполняется настоящая работа и где разработчики чувствуют себя наиболее вовлеченными и удовлетворенными своей работой.
Попасть в Поток — это как заснуть. Почти невозможно заставить его существовать – это требует времени, и малейшая мелочь может сбросить его и перезапустить весь процесс . Встречи и перерывы — главные враги Flow на рабочем месте, поэтому компании, в которых работают творческие люди, должны регулярно прилагать усилия, чтобы свести нарушения Flow к минимуму .
Такие методы, как диаграммы сжигания и покер планирования, фокусируются на вашей способности точно оценивать продолжительность задачи, а не на вашей способности создавать программное обеспечение, которое приятно использовать, которое отвечает потребностям ваших пользователей, сводит к минимуму технический долг, которое можно быстро и легко выполнить. модифицирован, содержит небольшое количество ошибок и не требует небольшой армии людей-тестировщиков, вручную запускающих регрессионные тесты каждый раз, когда вы хотите выпустить релиз. Это то, на измерение чего команды разработчиков программного обеспечения должны тратить свое время, но, к сожалению, слишком много команд тратят огромное количество времени и денег, просто пытаясь измерить свою способность угадать, сколько времени займет работа.
Скрам увлекателен измерением производительности. По иронии судьбы, при попытке измерить скорость скорость замедляется! Видите ли, эта вещь, называемая эффектом наблюдателя, вносит путаницу в дело.
В науке термин «эффект наблюдателя» относится к изменениям, которые акт наблюдения произведет на наблюдаемое явление. Зачастую это является результатом работы инструментов, которые по необходимости тем или иным образом изменяют состояние того, что они измеряют. Банальный пример – проверка давления в автомобильной шине; это трудно сделать, не выпустив часть воздуха и не изменив тем самым давление.
То же самое и со Scrum: когда вы пытаетесь измерить скорость, вы существенно меняете ее. Это связано с тем, что производительность обычно измеряется путем добавления встреч и процессов, действий, которые по своей сути отвлекают работников от текущей работы. Обычно это выглядит как создание карточек для возникающих рабочих задач, создание снимков экрана, обсуждение этого в стендапе, включение этого в электронные письма в конце дня, обсуждение этого на спринтерских собраниях и т. д. Вы должны понимать, что эти действия могут легко уделять 30-90 минут своего времени каждый день. Запись выполняемой ими работы означает, что они выполняют значительно меньше работы.
Обычно между видимостью и скоростью существует обратная зависимость. Чем большую известность вы хотите, тем больше препятствий придется преодолеть сотрудникам, и этот дополнительный процесс влияет на их время, моральный дух и динамику.
Я не говорю, что любые измерения плохи – немного измерения и празднования действительно могут поднять моральный дух – вы знаете, прогресс порождает прогресс – но пройдет совсем немного времени, прежде чем вы начнете замечать значительный негативный эффект. Я думаю, что методы Scrum для количественной оценки производительности могут хорошо работать в среде, посеянной недоверием: например, в оффшорном проекте с использованием дешевых, непроверенных подрядчиков. Владельцы продуктов и менеджеры хотят точно знать, чем занимаются их сотрудники, чтобы иметь возможность измерить их эффективность. Отсутствие доверия всегда замедляет ход событий.
Этот компромисс приемлем, когда вам нужно создать процессы для собственной защиты. Но в среде, где вы доверяете своим людям и вашим сотрудникам, что они умны, дисциплинированы и имеют хороший характер, измерение производительности с помощью сложного процесса совещаний и показателей является ненужным и обреченным на провал.
Такие организации, как военные, сосредотачиваются на наборе новобранцев, которые очень молоды, не имеют опыта выполнения своей работы и, возможно, не обладают достаточной дисциплиной. Но они превращают их в ценных членов команды, помещая их в гиперструктурированную среду. Скрам такой. Но я не думаю, что средняя команда разработчиков ПО похожа на среднюю группу новичков, проходящих базовое обучение. Вы должны нанять замечательных людей, а затем уйти с их пути и позволить им быть потрясающими. Сосредоточьте свои усилия на найме замечательных людей, а не на их микроменеджменте.
Мне нравится то, что говорит Манифест Agile : «Проекты строятся вокруг мотивированных людей, которым следует доверять». В любом случае, вот вывод: в следующий раз, когда вы предложите что-то, что поможет вам количественно оценить вещи, просто помните, что в целом, чем большей наглядности вы требуете, тем больше времени потребуется, чтобы что-то сделать. Спросите себя: «Меня больше интересует быстрое движение или знание того, насколько быстро я двигаюсь?»
Скрам-встречи необычайно затягивают. Я много раз слышал нечто подобное:
Дев 1: «Я хочу поговорить со всеми о наших проблемах. Как видно из диаграммы сгорания, мы не учитываем неожиданные проблемы, возникающие каждую неделю. И снова мы не достигнем наших целей в спринте».
Разработчик 2: «Что мы можем сделать, чтобы исправить нашу неудачу?»
Разработчик 1: «Я думаю, нам нужно начать проводить ежедневные проверки примерно в середине дня в дополнение к нашим утренним стендапам, чтобы мы могли спросить каждого, реалистичны ли его индивидуальные цели спринта».
Дев2: «Звучит как отличная идея. Возможно, мы сможем устранить проблемы, если это действительно необходимо».
Дев 1: «Да. Я имею в виду, что прошло Х времени с тех пор, как мы запустили Scrum, а мы *до сих пор* не поняли, как это сделать правильно!»
Люди начинают проводить собрания, потому что думают, что встречи сделают их более эффективными. А иногда встречи действительно помогают поговорить о важных вещах и улучшить ведение бизнеса. Но встречи — это скользкий путь, потому что чем больше их у вас есть, тем меньше времени у вас остается на выполнение дел. И как Scrum отвечает на недостаточное выполнение задач? Больше встреч и процессов! Когда вы попадаете в такую ситуацию, люди недоумевают, почему они продолжают не достигать своих целей Scrum, они выгорают из-за повторяющихся неудач, и моральный дух страдает.
Другая проблема Scrum заключается в том, что он предлагает вам тысячу мелочей, о которых можно забыть , вместо того, чтобы решать сложные проблемы разработки программного обеспечения.
«Закон тривиальности Паркинсона показывает, что комитет, чья работа заключалась в утверждении планов атомной электростанции, тратил большую часть своего времени на обсуждение относительно тривиальных и неважных, но простых для понимания вопросов, например, какие материалы использовать для персонала сарай для велосипедов, игнорируя при этом нетривиальную предлагаемую конструкцию самой атомной электростанции, которая является гораздо более важной, но также гораздо более сложной и комплексной задачей, которую можно критиковать конструктивно».
Разработка программного обеспечения, как и строительство атомной электростанции, трудна. К сожалению, Scrum вводит в процесс создания программного обеспечения множество тривиальных вещей – вещей, о которых легко составить свое мнение – и требует много времени для обсуждения их в больших группах. Это, естественно, приводит к потере велосипедов. Вместо того, чтобы тратить время на разговоры о том, как повысить уровень нашей инженерной игры (которая намного сложнее, поэтому гораздо меньше людей готовы поставить на кон свое мнение), непомерное количество времени тратится на разговоры о том, как использовать Scrum.
Роберт К. Мартин, один из первых авторов Agile-манифеста, дает этот словесный урок истории Scrum. Далее следует напечатанная версия основных моментов. Все ошибки мои.
Это был 1999 год. В мире царил водопад. Было несколько статей Кена Швабера о странных вещах под названием Scrum. Это привлекло немного внимания, но не сильно. Затем Кент Бек предложил еще одну странную вещь под названием «Экстремальное программирование». У Кента было видение — видение, как залечить ущерб, нанесенный между бизнесом и развитием. При наличии правильных дисциплин и правильного минимального процесса между разработчиками и бизнесом может возникнуть доверие. Бизнес начал бы доверять разработчикам, а не думать, что они ленивые, продажные, противные существа, а разработчики начали бы смотреть на бизнес и понимать, что они разумные, рациональные существа, а не с какой-то другой планеты.
Когда [мы втроем вместе со многими другими] создали Манифест Agile в 2001 году, Кент Бек подтвердил свое видение преодоления разрыва между бизнесом и развитием. Кент создал этот веб-сайт, и мы были ошеломлены, когда тысячи и тысячи людей подписались на этот сайт. Поэтому мы решили создать организацию — Agile Alliance. Я был первым председателем этой организации. Следующим председателем стал Кен Швабер. Он решил, что хочет заняться чем-то другим. Он хотел сделать альянс машиной, приносящей доход…
Кен пришел ко мне через некоторое время и сказал, что собирается провести курс под названием «Сертифицированный мастер-класс Scrum». Я подумал, что это глупая идея. Но глупая идея, которая работает, — это не глупая идея. Люди пришли и им понравилось. Чем больше он брал, тем больше людей приходило. Он начал раздавать сертификаты и создал небольшую организацию — Scrum Alliance. Прекрасное событие.
Как вы думаете, кто посещал эти курсы? Это были разработчики? Нет. Видите ли, я был разработчиком и думал, что это глупо. Все разработчики, с которыми вы говорили, считали это глупостью. Так кто же посещал эти курсы? Менеджеры проекта. Они вовсе не считали это глупостью, они занимались этим уже много лет. Менеджеры проектов начали выстраиваться в очередь на эти курсы, и сумма денег, полученная от них, была поистине поразительной.
Это привело к легитимизации Agile. Без этого курса сертифицированного Scrum Master Agile был бы ничем. Это заставило Agile преодолеть пропасть и стать мейнстримом. Но проблема была в том, что курс проходили не разработчики, а менеджеры проектов.
Изначально Scrum Master был тренером, а не менеджером. Они отвечали за защиту процесса, но не более того. Он не защищал график, бюджет, отставание, истории — он защищал только процесс, а роли должны были меняться между членами команды. Идея этой роли заключалась в том, чтобы постепенно исчезнуть, чтобы в конце концов вам не понадобился Скрам-мастер. Я не думаю, что менеджерам проектов, прошедшим курс Scrum Master, понравилась такая интерпретация. Я думаю, они хотели стать Скрам-мастерами!
Так получилось, что компании поняли, что решающим элементом успеха Scrum-команды является выбор правильного Scrum-менеджера. Обратите внимание, насколько похожим был выбор правильного менеджера проекта. Это очень хорошо отображается. А Скрам-мастер, проделавший действительно хорошую работу, мог встать в конце и сказать: «Моя команда добилась успеха!» Кому достанется слава и успех? Команда поддержит прославленного Скрам-мастера! (Позы для триумфального эффекта)
Так не должно было быть. Как вы думаете, это помогло устранить разрыв между развитием и бизнесом? Нееет, нет, это усугубило разделение между бизнесом и развитием…
Scrum заставляет вас работать быстро, как и любой Agile-метод, потому что каждые пару недель вы что-то доставляете. Можете ли вы представить, насколько это было чуждо в 1999 году? Люди начали делать что-то очень быстро. Скрам-команды: если вы скажете им выполнять доставку каждые две недели, они будут выполнять работу каждые две недели. Они не выполнят всего, что обещали, но кое-что дадут, и дело будет сделано. Поначалу они могут двигаться очень-очень быстро. Но что-то происходит.
Чему не учили на сертифицированном курсе Scrum Master? Практики разработки программного обеспечения. Все эти вещи, которые были в XP – все эти вещи о парном программировании, простом проектировании, рефакторинге, разработке через тестирование – все это было там не просто так. Потому что, когда вы едете быстро – а вы можете идти быстро – вам нужно что-то, что поможет вам оставаться чистым. Вам нужно что-то, что предохранит код от гниения. Когда вы работаете быстро и сосредотачиваетесь на выполнении историй, и историй, и историй, код может гнить так же быстро, как и вы. Итак, что происходит через год, так это то, что темпы начинают замедляться… Мартин Фаулер ввел термин — Flaccid Scrum — для описания Scrum, используемого без каких-либо технических принципов.
Возникло отношение «мы против них» — разработчики против менеджеров проектов. Дошло до того, что если пойти на Agile-конференцию, то там будет 90 докладов о методах управления проектами и ни одного разговора о методах разработки. Или один. Или два. Был огромный перекос в пользу методов управления проектами. И разработчики, которые породили этот процесс, теперь почувствовали себя обделенными, они почувствовали себя бесправными, они начали думать: «Это досталось кучке парней, которые получают бумажки за то, что потратили много денег, чтобы пойти на трехдневный курс». в то время как остальные из нас, кто изо всех сил старается заставить эти Scrum-проекты работать, получают от этого кайф. Мечта Кента провалилась. Разрыв между бизнесом и развитием вновь открылся. И он вновь открылся прямо среди нас, прямо среди самого Agile-сообщества.
Что происходит со Scrum-командой, когда она начинает замедляться? Скорость начинает падать. Чем занимается бизнес? Что делает Скрам-мастер? «Ребята, держите скорость». «Ребята, вам нужно продолжать писать истории». «Ребята, мы подводим бизнес». Обратите внимание на эту кучу вины, которая начинает расти на разработчиках, и обратите внимание на тех, кто ее не несет. Скрам-мастер, который говорит ребятам: «Надо идти быстрее». На самом деле говорит: «Ребята, вам нужно идти быстрее». Команда начинает давать сбои, в команде растут фракции, и люди начинают уходить с отвращением, и в конечном итоге, если этому позволить продолжаться, команда снова вернется к водопаду, потому что, по крайней мере, в водопаде у вас есть эти длительные периоды отдыха.
Scrum забывает, что скорость невозможна без качества. Вы не можете иметь скорость, пока у вас есть технический долг. И чем больше у вас будет технического долга, тем медленнее вы будете идти. И это ужасный порочный круг, потому что чем медленнее вы идете, тем больше технического долга вы приобретете.
Из-за этого родилось еще одно движение — движение Software Craftsmanship. Это свидетельство раскола общества. Группа из нас почувствовала необходимость вновь утвердить ценности экстремального программирования в этом мире, в котором теперь доминировал менеджер проектов Scrum Master Scrum. Мы надеемся, что это пробуждение видения Кента. Я не уверен, что на этот счет есть какие-либо доказательства.
Сегодня многие люди используют Scrum. Мало кто занимается TDD.
Я бы пошел на шаг дальше того, что говорит Роберт К. Мартин, и заявил, что, возможно, одна из причин того, что многие команды, использующие Scrum, не используют хорошие методы разработки программного обеспечения, заключается в том, что у них просто не хватает времени из-за тяжелых накладных расходов Scrum. Всем компаниям приходится тратить много времени на создание новых функций и исправление ошибок. Если использовать аналогию Стивена Кови, это вещи, которые одновременно срочны и важны. Но важные, но не срочные дела — это то, над чем вам действительно придется приложить усилия, потому что они имеют тенденцию ускользать от внимания. И это те вещи, которые однажды могут действительно навредить вам, потому что вы так и не удосужился их сделать. В мире ПО это: написание тестов, рефакторинг, погашение технического долга, меры безопасности, парное программирование и наставничество.
Говорят : «Scrum — как твоя свекровь: он постоянно указывает на твои недостатки» . Мой ответ таков: когда кто-то говорит вам, что с вашей жизнью что-то не так, первый вопрос, который вам следует задать: «Вы пытаетесь мне что-то продать?» И ответ для Scrum: да. Оказывается, Scrum Alliance заработал большие деньги, используя движение Agile в области программного обеспечения, обучая и сертифицируя людей, которые, в свою очередь, взимают дорогостоящую плату за обучение и консультации. Не верите мне?
Хотите стать сертифицированным Scrum-профессионалом ? Это будет 250 долларов , пожалуйста.
(Не забудьте после этого платить нам 25 долларов в год)
Хотите стать сертифицированным Scrum-мастером ? Это будет 1250 долларов , пожалуйста.
(Этот тоже стоит 25 долларов в год)
Хотите стать сертифицированным владельцем продукта Scrum ? Это будет 1395 долларов , пожалуйста.
(Не забывайте, после этого это будет 25 долларов в год)
Устали платить деньги за экосистему Scrum и готовы принять участие в работе самостоятельно? Просто станьте сертифицированным тренером Scrum ! Это будет 5000 долларов в год, пожалуйста.
(Вам лучше начать привлекать людей, иначе в этом году вы не заработаете денег!)
Итак, Scrum Alliance — это некоммерческая организация, задача которой — помочь сохранить экономику Scrum для тех, кто отдает ей должное. Это зло? Конечно, нет. Капитализм и прибыль — великие вещи. Я уверен, что Scrum помог многим предприятиям и частным лицам добиться успеха в различных отношениях. И были люди, которые зарабатывали деньги на Agile, продавая книги и время от времени проводя конференции до того, как появился Scrum. Но Скрам вывел его на совершенно новый уровень, и тем самым они создали евангелистов, которые получали прибыль от распространения идей Скрама. Многие люди, которые сейчас пропагандируют Scrum, заинтересованы в игре: они не только хотят, чтобы вы добились успеха, но и получают финансовую выгоду. Итак, вы должны знать, что многие из тех блоггеров, онлайн-комментаторов, авторов книг и консультантов, которые продвигают Scrum, не просто учителя, но и продавцы.
Более того, многие из тех, кто защищает Scrum, не являются техническими специалистами — они, возможно, никогда не были разработчиками и не практиковали какую-либо другую современную методологию разработки программного обеспечения, потому что писать код — не их работа. Многие из них являются менеджерами проектов. Таким образом, они могут быть продавцами, которые не понимают альтернатив тому, что они продают, или того, как их продукт влияет на людей, потому что люди, использующие их продукт, отличаются от них. Так что просто имейте это в виду.
Даже если вы не нанимаете консультантов по Scrum и не посещаете тренинги по Scrum, Scrum будет стоить вашей команде больших денег. Как? Потому что Scrum требует, чтобы ваша команда тратила много времени на оценку работы и обсуждение работы, а не на ее фактическое выполнение.Предположим, команда из 8 человек тратит 12 часов на собрания и подобные мероприятия каждые 2 недели спринта. (Очень легко потратить столько времени между стендапами, встречами по планированию спринта с планированием покера, очисткой отставания, обновлением диаграмм выгорания, обзором спринта, ретроспективой спринта и демонстрациями.) Это означает, что они потратили 96 человеко-часов. каждый спринт делает это. Допустим, этим людям платят почасово, а средняя зарплата в команде составляет 35 долларов в час (около 70 000 долларов в год). Это означает, что в каждом спринте команда тратила 3360 долларов на Scrum-деятельность. Если в году 50 рабочих недель, это дает нам 25 двухнедельных спринтов.
3360 долларов × 25 спринтов = 84 000 долларов в год на команду, использующую Scrum.
Если бы эта команда прекратила использовать Scrum, они могли бы выполнять тот же объем работы, каждый день отправлять всех домой на час раньше, нанимать еще одного штатного инженера и тратить более 10 000 долларов на ежегодный командный выезд!
12 часов совещаний за спринт могут быть приемлемыми для того, кто работает над вашим проектом 40 часов в неделю, но для того, кто работает над вашим проектом только 25–30 часов в неделю, такое же количество совещаний означает гораздо больше накладных расходов. В первом случае встречи каждую неделю отнимают у человека 15% времени. Но во втором случае встречи занимают у человека почти 25% недели.
Основной принцип Scrum заключается в том, что команды располагаются рядом и работают в общем рабочем пространстве. Я с этим не согласен. Я считаю, что DHH прав, когда говорит, что будущее за удаленной работой и что работа на дому имеет бесчисленные преимущества для отдельного человека, компании, местного сообщества и семьи – преимущества, которые намного перевешивают недостатки. Будь то возможность нанять первоклассных специалистов, которых нет в вашем городе, сокращение городского трафика, разрешение сотрудникам путешествовать и жить где угодно, разрешение родителям работать из дома и быть рядом со своей семьей или любые другие преимущества удаленного доступа. - Работая, я думаю, что на этот компромисс стоит пойти.
Конечно, в Agile-манифесте говорится: «Личный разговор — лучшая форма общения» , но это не так сильно, как утверждение о том, что вы должны находиться в одном месте. Современные инструменты в значительной степени смягчили недостатки удаленной команды: мы можем вести видеоразговоры лицом к лицу, отслеживать нашу работу в режиме реального времени на цифровой доске задач и совмещать программы с низкой задержкой.
Скрам не говорит о инженерии. Это методология разработки программного обеспечения, но в ней не говорится о методах кодирования. Совсем. Это глубоко тревожит.
Scrum учит менеджеров проектов тому, что они могут быть отличными лидерами команды разработчиков программного обеспечения, ничего не зная о разработке программного обеспечения. Я категорически против этой идеи. Как может генерал эффективно управлять своими войсками, если он никогда не держал в руках винтовку, не ездил с кавалерией и в него не стреляли? Он не может. Конечно, любой, у кого есть власть и люди под ее началом, является лидером. Любой может указывать другим людям, что им делать. Но это не лучшее лидерство. И это не значит, что они собираются эффективно руководить своей командой.
Когда руководители команд не умеют программировать, они не могут подавать пример. Поскольку они не могут участвовать в создании программных активов, их работа заключается в создании обновлений статуса компании. Таким образом, они, естественно, создают процессы для постоянного мониторинга тех людей, которые создают программные активы, отсюда и сильный упор Scrum на оценку и отслеживание прогресса.
Такая методология, как экстремальное программирование, также подчеркивает необходимость проводить много времени вместе, но вместо того, чтобы говорить, что вы должны проводить это время на собраниях для измерения прогресса, она рекомендует тратить это время на выполнение реальной работы, парное программирование, создание бизнес-активов, обучение у каждого. технические знания других, совместное повышение уровня, рефакторинг, написание тестов и т. д.
Из-за того, что в нем упор делается на разговоры о том, что вы делаете, а не просто на выполнение этого, вам очень легко говорить об одном и том же несколько раз. Я работал с командами, где они чувствовали, что им нужна электронная почта в начале дня (где они сообщали о том, что они собираются сделать в течение дня), стендап в середине дня (где они говорили о том, что они сделали вчера и что они планировали сделать сегодня) и электронное письмо в конце дня (где они рассказывали о том, что они сделали сегодня, а что не сделали). Добавьте к этому совещание по планированию итерации и ретроспективу итерации, и легко увидеть, что происходит много дублирования усилий.
Я работал в другой команде, у которой была цифровая доска управления задачами, ежедневные утренние встречи, электронные письма в конце дня и физическая доска для заметок. Мы отслеживали работу в четырех местах, проводили совещания по планированию итераций и совещания по ретроспективе итераций.
Хотя многие Scrum-команды не так уж нелепы, некоторые из них довольно близки, если задуматься. И это не просто трата времени. Когда вы дублируете места, в которых сообщается о том, что происходит, у вас больше не будет единого источника истины. У вас есть несколько источников полуправды. Вы должны собрать воедино информацию из нескольких источников, чтобы увидеть все, что происходит. Становится легко забыть обновлять все места обо всем, что вы делаете.
Вот почему мы используем инструменты, которые показывают, над чем мы работаем: чтобы нам не приходилось постоянно говорить о том, над чем мы работаем. Хотите знать, над чем люди работают сегодня? Хотите знать, заблокирован ли кто-то? Хотите знать, что было включено в наш последний выпуск? Пусть совет говорит. Не собирайте всех вместе и не прерывайте их работу, чтобы поговорить об этом.
Я также считаю, что излишне проводить ежедневную беседу, ежедневную электронную почту, совещание по планированию спринта и обзор спринта. В каждом из этих мест вы говорите об одном и том же, и в дополнение к этому у вас есть доска управления задачами. Почему бы просто не выбрать одно средство коммуникации и не сделать его действительно хорошо? Наверное, мне больше всего нравятся ежедневные электронные письма в конце дня. Такой сервис, как iDoneThis, может справиться с этим автоматически. Это позволяет каждому начинать свой день в любое время, никого не прерывать из Flow на стендап или совещание в середине дня, и люди могут работать так поздно, как им хочется. Бонус электронного письма в конце дня заключается в том, что если каждый сосредоточится на создании хороших снимков экрана и написании хорошей документации в своих электронных письмах, вы сможете повторно использовать этот контент для примечаний к выпуску или публикации в блоге, которая будет отправлена клиентам.
В некотором смысле кажется, что Scrum противоречит основным идеям Agile. В Agile-манифесте говорится: «Люди и взаимодействие важнее процессов и инструментов». Scrum — это высокоструктурированный процесс с большим количеством накладных расходов. Вместо оптимизации для отдельных разработчиков и передовых методов разработки, здесь изложен тяжелый процесс, который фактически мешает мастерству.
Точно так же в Agile-манифесте также говорится: «Реагировать на изменения, а не следовать плану». Что ж, если Scrum – это не только составление и выполнение планов, то я не знаю, что это такое. Напротив, Канбан кажется более гибким. Он имеет непрерывный поток вместо спринтов, ограниченных по времени, вы можете менять истории/работу, когда вам нужно, вместо того, чтобы ждать, пока вы окажетесь между спринтами, и вся идея ежедневных обязательств может быть покончена со всей идеей ежедневных обязательств.
Ах да, ежедневные обязательства. Я не могу сказать вам, сколько раз я был здесь воплощением Невезения Брайана. Я просматривал свой дневник и заметил эту запись.
Сегодня у меня произошло девять вещей, которых я не ожидал. В конце дня я сделал эти девять дел, но еще не закончил то единственное, что обещал сделать этим утром. Это был один из моих самых продуктивных дней за долгое время! Но вы знаете, что? В конце дня мне стало грустно, вместо того, чтобы гордиться объемом проделанной работы.
Вместо того, чтобы прославлять все способы, которыми я помогал людям, удовлетворял все «вещные» запросы, которые я выполнял, и скрытые сложности, которые я преодолел, я чувствовал, что потерпел неудачу. Ежедневные обязательства делают это.
Идея «обязательства» делать что-то каждое утро мне не нравится. Это бросает вызов скрытой сложности и прямо противоречит мастерству. Независимо от того, намеренно это или нет, эта практика культивирует следующие вещи:
Это не просто плохой бизнес, это плохая мораль. Это нечестно. И это то, на что я больше всего обижаюсь. Написание программного обеспечения требует слишком много переменных, чтобы можно было честно сказать: «Я обязуюсь сделать это сегодня». И если ваша команда соглашается на эту небольшую оценочную игру, вы подтверждаете руководству и/или своему клиенту, что такая деловая практика приемлема.
Покос газонов? Конечно, легче последовательно угадывать, сколько времени займет что-то, поэтому легче сказать, что вы сможете что-то сделать за
продолжение следует...
Часть 1 Scrum его достоинства, недостатки и критика
Часть 2 СКРАМ ИЗМЕРЯЕТ НЕПРАВИЛЬНЫЕ ВЕЩИ - Scrum его достоинства, недостатки и
Часть 3 Вау!! 😲 Ты еще не читал? Это зря! - Scrum его достоинства, недостатки и критика
Надеюсь, эта статья про гибкие методологии разработки по, была вам полезна, счастья и удачи в ваших начинаниях! Надеюсь, что теперь ты понял что такое гибкие методологии разработки по, scrum и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем
Комментарии
Оставить комментарий
Разработка программного обеспечения и информационных систем
Термины: Разработка программного обеспечения и информационных систем