Лекция
Привет, сегодня поговорим про гибкие методологии разработки по, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое гибкие методологии разработки по, scrum , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.
Scrum (от англ. scrum «толкучка») — методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. Scrum четко делает акцент на качественном контроле процесса разработки. Кроме управления проектами по разработке ПО Scrum может также использоваться в работе команд поддержки программного обеспечения (software support teams), или как подход управления разработкой и сопровождением программ: Scrum of Scrums.
Подход впервые описали Хиротака Такэути и Икудзиро Нонака в статье The New Product Development Game(Гарвардский Деловой Обзор , январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «подход регби». В 1991 году ДеГрейс и Шталь в книге «Нечестивые проблемы, праведные решения» ссылались на этот подход, как на Scrum (толкотня; схватка вокруг мяча (в регби)), спортивный термин, приведенный в статье Такэути и Нонакой. Кен Швабер в начале 1990-х использовал подход, который привел Scrum в его компанию. Впервые метод Scrum был представлен на общее обозрение задокументированным, четко сформированным и описанным совместно Швабером и Джефом Сазерлендом на OOPSLA’96 (англ.) в Остине. Швабер и Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь их опыт и лучшие практические образцы для индустрии в одно целое, в ту методологию, что известна сегодня как Scrum. Швабер объединил усилия с Майком Бидлом в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM» .
Скрам (Scrum) — это набор принципов, на которых строится процесс разработки, позволяющий в жестко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определен наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всем его протяжении. При этом строго фиксированная небольшая длительность спринта придает процессу разработки предсказуемость и гибкость.
Спринт[10] — итерация в скраме, в ходе которой создается функциональный рост программного обеспечения. Жестко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объема работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в бэклоге проекта. На протяжении спринта никто не имеет права менять список требований к работе, внесенных в бэклог спринта.
Бэклог проекта — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» (user story) или элементами бэклога (backlog items). Бэклог проекта открыт для редактирования для всех участников скрам процесса.
Бэклог спринта — содержит функциональность, выбранную владельцем проекта из Бэклога проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения спринта[11].
Диаграмма, показывающая количество сделанной и оставшейся работы. Обновляется ежедневно с тем, чтобы в простой форме показать подвижки в работе над спринтом. График должен быть общедоступен.
Существуют разные виды диаграммы:
Требуемую функциональность, которую добавляют в бэклог, часто называют историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>». Такая структура удобна тем, что понятна как разработчикам так и заказчикам.
Остановка спринта может быть произведена раньше срока его планового окончания в исключительных ситуациях. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить владелец проекта, если исчезает необходимость в реализации цели спринта. После остановки спринта проводится совещание с командой, где обсуждаются причины остановки. После этого начинается новый спринт.
Абстрактная метрика оценки сложности истории, которая не учитывает затраты в человекочасах. Обычно используют одну из следующих шкал: ряд Фибоначчи(1,2,3,5,8,13,21,34,55); линейную шкалу (1,2,3,4 … n); степень двойки (1,2,4,8 … 2n); размеры одежды (XS, S, M, L, XL).
Добавляются к историям спринта. Выполнение каждой задачи оценивается в часах. Каждая задача не должна превышать 12 часов (зачастую команда настаивает, чтобы максимальная продолжительность задачи равнялась одному рабочему дню).
Критерии, определяющие степень готовности элемента из журнала пожеланий пользователя.
Общее количество очков, набранных командой за предыдущий спринт. Данная метрика помогает команде понять, сколько историй она может сделать за один спринт.
По методике Scrum в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «кур». Эти названия были использованы из-за шутки[12]
Свинья идет по дороге. Курица смотрит на нее и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать „Яичница с беконом“?». «Так не пойдет, — отвечает свинья, — ведь тогда мне придется полностью посвятить себя проекту, а ты будешь вовлечена только частично».
Свиньи создают продукт, тогда как куры заинтересованы, но не настолько — ведь им все равно, будет ли проект удачным или нет, на них это мало отразится. Требования, пожелания, идеи и влияние кур принимаются во внимание, но им не разрешают непосредственно включаться в ход скрам-проекта.
«Свиньи» полностью включены в проект и в скрам-процесс.
Иногда, также, используются дополнительные поля в бэклоге проекта, в основном для того, чтобы помочь владельцу проекта определиться с его приоритетами.
Происходит в начале новой итерации Спринта.
В течение совещания каждый член команды отвечает на 3 вопроса:
Проводится после ежедневного скрам совещания. Позволяет нескольким скрам командам обсуждать работу, фокусируясь на общих областях и взаимной интеграции. Повестка та же, что и на ежедневном скрам совещании плюс следующие вопросы:
Проводится в конце спринта.
Проводится в конце спринта.
Критика методологии Scrum существует, и некоторые люди и организации высказывают свои сомнения по поводу ее эффективности в определенных ситуациях. Однако важно отметить, что Scrum - это все-таки одна из популярных и широко используемых методологий разработки программного обеспечения и управления проектами. Ниже представлены некоторые критические аргументы в отношении Scrum:
Сложность внедрения: Одним из основных критических моментов является сложность внедрения Scrum в больших и сложных организациях. Переход к Scrum может потребовать значительных усилий в обучении, изменении культуры и процессов.
Не всегда подходит: Scrum имеет свои ограничения и может не быть наилучшим выбором для всех проектов и команд. Например, для проектов, требующих высокой степени предсказуемости или жестких сроков, другие методологии, такие как Waterfall, могут быть более подходящими.
Склонность к бюрократии: Некоторые критики утверждают, что Scrum может стать слишком бюрократическим и создавать избыточные процессы, особенно если его применяют неправильно.
Проблемы с командной динамикой: Не во всех командах происходит успешное внедрение Scrum. В некоторых случаях это может привести к конфликтам и недовольству среди членов команды.
Ограничение на изменения: Scrum нацелен на минимизацию изменений во время спринтов, что может затруднить адаптацию к изменяющимся требованиям или приоритетам.
Ежедневные совещания предназначены для менеджеров: На ежедневных стендапах может возникнуть нежелательная тенденция, когда они становятся мероприятием, предназначенным для информирования менеджеров о текущей ситуации, а не для обсуждения рабочих задач.
Главную роль играет выполнение задач: Методология Scrum может способствовать оценке работы исключительно по количеству выполненных задач, что может привести к поверхностному выполнению задач.
Крайне продуктивные разработчики, которые не работают как команда: В некоторых случаях Scrum может поддерживать продуктивность индивидуальных разработчиков, но не способствовать формированию сплоченных команд. противоречие между качественными программистами-одиночками и успешными командами. Когда все придерживаются методологии Scrum, некоторые разработчики могут достичь высокой производительности, но это может привести к отсутствию настоящей командной работы. без правильных стимулов самоорганизация команды становится недостижимой целью. Он говорит: "Члены команды будут решать задачи так, как им удобно, или так, как им предписано. Если это не способствует формированию команды, многие задачи могут остаться не выполненными, и члены команды будут двигаться в разные стороны, без организации".Он также добавляет: "Более того, если позволить каждому разработчику выбирать собственные методы решения задач, это может усложнить процесс отладки кода".
Сложные задачи отодвигаются на потом: В Scrum может возникнуть тенденция откладывать решение сложных задач до более поздних этапов проекта.
Возможности продукта оказываются важнее качества кода: Основное внимание уделяется функциональным возможностям продукта, а не качеству кода.
Отсутствие времени на обсуждение рабочих вопросов с коллегами: Разработчики могут быть заняты выполнением задач и не иметь времени на обсуждение и совместное решение вопросов.
Недавно выявленным ошибкам приходится ждать своей очереди: Ошибки могут быть выявлены после завершения спринта и рассматриваться как новые задачи.
Архитектура, управляемая тикетами: Применение Scrum может способствовать созданию запутанной архитектуры проекта, так как разработчики работают над тикетами независимо друг от друга.
Методология, влияющая на все: Scrum может оказывать сильное влияние на все аспекты управления разработкой и иногда создавать иллюзию успеха за счет выполнения ритуалов.
Однако следует отметить, что многие из этих критических моментов могут быть смягчены или решены правильным внедрением и адаптацией методологии Scrum. Множество организаций успешно используют Scrum и находят в нем ценные принципы для управления проектами и разработкой продуктов.
Эффективность Scrum зависит от контекста и специфических потребностей организации и проекта. Важно подходить к выбору методологии гибко и рассматривать ее в контексте конкретных условий. В некоторых случаях Scrum может быть идеальным выбором, а в других - не столь подходящим. Вцелом применение только этой методологии - сомнительная.
Итак, Скрам. Самая популярная методология гибкой разработки программного обеспечения, которую используют около 70 % гибких команд. О чем все это? Это хорошо или это отстой? Сделал ли Scrum нашу жизнь лучше? Давайте погрузимся.
Scrum имеет благие намерения. Измерение вашей продуктивности. Ответственность за то, чтобы не делать больше или меньше, чем мы договорились сделать заранее. Повышение наглядности для заинтересованных сторон. Общение в команде, чтобы помочь друг другу работать лучше. Проблема в том, что методы Scrum для достижения этих целей не очень хорошо подходят для создания программного обеспечения. Первая проблема, с которой я столкнулся в Scrum, заключается в том, что вся система построена на предположении, что вы можете разумно оценить, сколько времени займут задачи разработки программного обеспечения. К сожалению, это крайне сложно, в первую очередь из-за 3-х вещей:
Эти три вещи разрушают элегантность Scrum, из-за чего становится очень сложно оценить, сколько времени займет работа.
Мало того, Scrum предполагает, что вы можете оценить, сколько времени займут задачи других людей! Планирование покера предполагает, что каждый член команды может иметь разумное представление о том, сколько времени займут задачи всех остальных в других частях системы. А поскольку Scrum выступает за межфункциональные команды, это означает, что специалист по обеспечению качества оценивает, сколько времени займет работа разработчика. Это означает, что разработчик оценивает, сколько времени займет работа дизайнера. Это совершенно нереально.
Теперь некоторые люди сразу же заметят: мы не измеряем задачи Scrum по времени, мы измеряем их по сложности, усилиям, очкам или чему-то еще. К сожалению, это всего лишь симпатичная маленькая обертка, которая ловко пытается успокоить разработчиков, которые говорят, что оценки программирования неточны, и удовлетворить менеджеров проектов, которым все еще нужны оценки. Потому что даже если вы используете эту оболочку, Scrum все равно требует, чтобы вы указали, какой объем работы вы собираетесь выполнить в этом спринте – в этой итерации с фиксированным временем. Scrum хочет, чтобы вы неоднократно отвечали на вопрос: «Какой объем работы мы можем выполнить при наличии определенного количества работников и фиксированного количества времени?»По определению, это уравнение требует от вас – неявно или явно – оценить, сколько времени займет каждая рабочая задача. Итак, как бы вы это ни раскручивали, Scrum предполагает, что вы можете надежно оценить продолжительность задачи.
По причинам, перечисленным выше, я отвергаю предположение, что вы можете достоверно оценить, сколько времени займут ваши собственные задачи, а тем более все остальные.
Некоторые люди говорят, что вам нужно оценить, сколько времени займет все, ради ваших клиентов. Что ж, я думаю, что оценки чаще ошибочны, чем верны, поэтому сроки и даты в нашей работе имеют тенденцию быть неточными. Привычка оценивать вещи означает, что вы часто ошибаетесь в своих оценках, и это создает скользкую дорожку, которая приводит либо к недоверию клиентов из-за того, что работа занимает больше времени, чем первоначально ожидалось, либо к снижению мастерства, поскольку у вас возникает искушение «просто сделать это». потому что вы пытаетесь оправдать свою оценку, хотя знаете, что следующему парню, который прикоснется к этому коду, придется плохо.
Скрам прекрасно вписывается в график менеджера, но не в график создателя . Пол Грэм ввел этот термин в своей классической статье о разнице между менеджерами и создателями в вопросах тайм-менеджмента.
Одна из причин, по которой программисты так не любят встречи, заключается в том, что у них другой график, чем у других людей. Встречи обходятся им дороже.
Есть два типа расписания, которые я называю расписанием менеджера и расписанием создателя. График руководителя – для начальства. Оно воплощено в традиционном ежедневнике, где каждый день разбит на часовые интервалы. При необходимости вы можете заблокировать несколько часов для одной задачи, но по умолчанию вы меняете то, что делаете, каждый час.
Когда вы используете время таким образом, встретиться с кем-то — это просто практическая проблема. Найдите свободное место в своем расписании, забронируйте его, и все готово.
Самые влиятельные люди входят в график менеджера. Это график командования. Но есть и другой способ использования времени, распространенный среди людей, создающих вещи, например программистов и писателей. Обычно они предпочитают использовать время в единицах, по крайней мере, в полдня. Вы не можете хорошо писать или программировать за один час. Этого времени едва хватает, чтобы начать.
Когда вы действуете по графику создателя, встречи становятся катастрофой. Одна-единственная встреча может испортить целый день, если разбить ее на две части, каждая из которых слишком мала, чтобы сделать что-то сложное… Для кого-то, у кого график создателя, провести встречу - это все равно, что создать исключение. Это не просто заставляет вас переключаться с одной задачи на другую; он меняет режим, в котором вы работаете. Я считаю, что одна встреча иногда может повлиять на целый день. Встреча обычно затягивается как минимум на полдня, если ее прерывать утром или днем…
Если вы творец, разве ваше настроение не поднимается при мысли о том, что у вас есть целый день свободного времени для работы без каких-либо встреч? Что ж, это означает, что ваше настроение соответственно подавлено, когда вы этого не делаете. А амбициозные проекты по определению близки к пределу ваших возможностей. Небольшого снижения боевого духа достаточно, чтобы их убить.
Я не думаю, что собрания — это зло, но они обходятся очень дорого, особенно для создателей. Большинству компаний и команд разработчиков программного обеспечения необходимо время от времени встречаться по разным вопросам, но Scrum предписывает еще больше, что усугубляет эту проблему. Между ежедневными стендапами, планированием спринта, обзором спринта, ретро-спринтом, ежедневными проверками, очисткой отставания, демонстрациями продуктов, собраниями компании и техническими тренингами легко проводить достаточное количество совещаний каждую неделю, чтобы держать ваших создателей в состоянии постоянного похмелья . .
Ладно, большое количество встреч не вписывается в график создателя, но почему? Это потому, что встречи нарушают Flow . Михай Чиксентмихайи, ведущий психолог, специализирующийся на теме Потока, задает вопрос:
продолжение следует...
Часть 1 Scrum его достоинства, недостатки и критика
Часть 2 СКРАМ ИЗМЕРЯЕТ НЕПРАВИЛЬНЫЕ ВЕЩИ - Scrum его достоинства, недостатки и
Часть 3 Вау!! 😲 Ты еще не читал? Это зря! - Scrum его достоинства, недостатки и критика
Надеюсь, эта статья про гибкие методологии разработки по, была вам полезна, счастья и удачи в ваших начинаниях! Надеюсь, что теперь ты понял что такое гибкие методологии разработки по, scrum и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Разработка программного обеспечения и информационных систем
Термины: Разработка программного обеспечения и информационных систем