Профессиональный SEO

По состоянию на Видео UniPymes Я написал этот небольшой урок, чтобы узнать, из чего состоит эта гибкая методология.

В традиционной методологии планирования проекта, или каскада, сначала предъявляются требования, затем проектируется, затем выполняется кодирование и, наконец, оно интегрируется, с этого момента мы говорим, что срок и продукт соблюдены. Это закончено. Впоследствии управление техобслуживанием налажено.

Проблема с этими методологиями заключается в том, что существует большая неопределенность, поскольку они, как правило, представляют собой проекты на один, два или три года, поэтому обычно случается так, что вам нужно сдвинуть крайний срок, и, вероятно, стоимость (выделенные люди или ресурсы) обычно варьируется для что 100% указанных требований соблюдены.

Альтернатива поднимается в гибкой методологии, здесь требования не являются фиксированными (как это происходит в каскадной методологии), но ресурсы (люди) и дата доставки являются несменяемыми.

Это происходит потому, что в гибкой методологии нет необходимости ждать годы, чтобы доставить продукт, а частичные поставки осуществляются. Важно, чтобы каждая поставка была функциональной продукцией, чтобы клиент мог доказать это и дать нам обратную связь. После этого отзыва мы можем обратиться к изменениям для следующей доставки.

Scrum - это методология поэтапной разработки Agile (каждая итерация проекта увеличивает количество требований) и является итеративной (существует много рабочих циклов и поставок, каждый раз, когда мы осуществляем доставку, клиент указывает, согласен он или нет)

Команды от 3 до 10 человек обычно используются.

Роли - это заинтересованные лица (спонсоры продукта), которые вкладывают деньги, владелец продукта (который представляет спонсоров и определяет, что требуется от продукта). Эти две роли не являются частью продукта.

Команда состоит из команды инженеров с человеком, отвечающим за контроль качества. Все это во главе с Скрам Мастером, который отвечает за методологию, а также отвечает за устранение препятствий, которые могут возникнуть у команды.

Динамика работы начинается с незавершенного производства продукта (требования владельца продукта проекта на один или два года). Впоследствии мы просим владельца продукта расставить приоритеты по всем этим требованиям от самых важных до наименее важных. Со всей этой документацией мы превращаем ее в задачи, и команда на первых итерациях будет уделять больше внимания наиболее важным задачам.

Исходя из этого приоритета задач, мы берем ряд задач (спринт Backlog) и определяем короткие сроки поставки продукта (не более 30 дней). Очевидно, что на первых итерациях продукт удовлетворяет только нескольким спецификациям Владельца продукта, но важно, чтобы через 30 дней владелец продукта мог протестировать продукт и своевременно дать отзыв.

Сокращая первую доставку до нескольких дней, неопределенность очень низкая, и мы гарантируем, что эти задачи будут выполнены в эти дни.

Также важно отметить, что каждый день происходит короткое собрание команды (Scrum Master, Engineers и QA), таким образом, общение приветствуется. Мы поговорим об этом позже.

Каждая итерация в гибком процессе аналогична итерации каскадного, но сжатого обработчика, поскольку количество задач, которые необходимо решить, значительно меньше. Каждая итерация имеет планирование, спецификацию и разработку, которые выполняются почти параллельно с тестами, то есть не нужно ждать окончания разработки, чтобы пройти тестирование.

Когда первая итерация завершена, она представляется Владельцу продукта, который высказывает свое мнение и возможные изменения. С этими возможными изменениями, которые ранее были преобразованы в задачи и следующие задачи в порядке приоритета, начинается вторая итерация. Эта новая итерация будет перепланирована, определена и проверена в последовательных итерациях, пока этот конечный продукт не будет соответствовать всем требованиям, которые запрашивал владелец продукта, иными словами, продукт был полностью завершен.

Большим преимуществом методологии scrum против каскада является то, что люди всегда имеют среднюю / высокую нагрузку, в отличие от методологии каскада в последние месяцы, работа всегда накапливается, а нагрузка преувеличивается, что приводит к задержкам или плохо выполненная работа. Другое преимущество заключается в том, что вы видите результаты в краткосрочной перспективе, и это утешительно.

Каждая итерация должна составлять от 2 до 4 недель, поскольку время между планированием и спецификацией меньше, чем то, что мы теряем много времени, и в течение более 4 недель мы теряем эффективность гибкого метода.

На структурном уровне каждая итерация будет состоять из встречи с владельцем продукта, планирования, разработки, а затем с доставкой проводится демонстрация и ретроспективное собрание, на котором команда садится и анализирует, что у них хорошо получилось, что они сделали неправильно и что можно улучшить для следующего спринта.

Планирование гораздо важнее, чем вы думаете, так как это тот момент, когда команда приобретает обязательство выполнять задачи в срок. Кроме того, все члены команды (те, у кого больше опыта и меньше) оценивают стоимость рабочего времени, которое займет каждая задача, даже если она не является назначенной им задачей.

Важно отметить, что Scrum показывает задачи, и каждый инженер априори выбирает, какие задачи он хочет выполнить, и выполняет их. Теоретически, это не Scrum Master, который назначает эти задачи, хотя на практике Scrum Master много раз должен решать, когда есть несколько человек, которые хотят одну и ту же задачу. Философия заключается в том, что если инженер выбирает задачу, которая больше всего его мотивирует и контролирует уровень его вовлеченности, он возрастает гораздо больше, чем если бы ему навязали работу.

При планировании работ сначала предъявляются новые требования, затем планируется и разрабатывается приоритетный бэклог продукта.

После того, как планирование и назначение задач закончено, нам нужна «Доска задач Scrum» с тремя колонками («В ожидании», «В процессе» и «Завершено»).

Очень важно указать, что задача не завершена, пока контроль качества не пройден. Поэтому очень важно, чтобы вся команда понимала, что такое выполненное задание.

Диаграмма Burndown является той, которая отмечает нас, когда мы идем, исчерпывая часы (поскольку задачи завершены) до завершения спринта. В действительности то, что случится с нами, если мы хорошо спланируем, будет состоять в том, что большинство задач будет выполнено на последнем этапе спринта.

Если с нами случится переоценка, то для следующего, возможно, будет интереснее подойти к более коротким спринтам и провести хорошую ретроспективную встречу.

Также может случиться так, что мы вмешаемся в переоценку и уберем задачи. Этого следует избегать, и если это будет сделано, мы будем рассматривать его только в том случае, если поставленный продукт имеет смысл сам по себе, то есть не имеет смысла поставлять стол без двух ножек. Я могу сказать, что он не окрашен, но конечный продукт должен иметь смысл сам по себе.

Наконец, у нас есть недооцененный Burndown с вмешательством, это также не рекомендуется, так как команда была расслаблена, и нам пришлось сделать полупериод.

Внутри команды особенно важно, чтобы система контроля качества была достаточно умной, чтобы работать с инструментом с точки зрения пользователя и от любого ненормального использования, которое может сделать конечный пользователь. Также важно, чтобы в программных проектах было автоматизированное управление повторяющимися тестами для ускорения работы QA.

Настоятельно рекомендуется, чтобы контроль качества был в команде, так как он способен выдвигать ошибки, поскольку инженеры завершают задачи в рамках схватки и, следовательно, за меньшее время проводят тест.

Ежедневное собрание длится 15 минут и всегда происходит в одном и том же месте и в одно и то же время, в котором должны участвовать все члены команды, за исключением владельца продукта, который не является действительно необходимым. На этой ежедневной встрече виден ход итерации, и каждому члену команды задаются 3 вопроса. Что ты делал вчера? Что ты сделал сегодня? И какие препятствия вы должны выполнять свою работу? Этот третий вопрос важен, потому что часто случается, что другой инженер решает препятствие другого члена команды.

Когда спринт заканчивается, должна быть проведена ретроспективная встреча

На этом совещании оцениваются цели, а приверженность к улучшению приобретается, если цели не были достигнуты и проблемы, которые могли быть решены во время схватки, были решены.

Обычно менеджеры не участвуют в ретроспективном собрании.

В заключение укажите, что эта методология способна адаптироваться к каждой компании, что зависит от контекста и опыта команды, так что она действительно эффективна.

Похожие

Комментарии