Начинать эту статью с различных вводных матчей о «Великой силе SCRUM» и «недостатках методологии водопада» считаю пустой тратой времени, так как в Интернете уже достаточно много ресурсов, позволяющих научиться всё: от истории предпосылок создания технологий до всех преимуществ и недостатков текущих внедрений.
Как говорится: «Кто ищет, тот всегда найдет.» (с) :-).
Хочу поделиться некоторым опытом и даже скорее всего своим мнением о «существующем зоопарке ПО» в некоторых ИТ-компаниях, а именно о подходах и реализациях.
Итак, начнем… Естественно, чтобы написать новый или улучшить существующий продукт, сначала нужно изучить рынок, проанализировать потребности клиентов, написать кучу каких-то нелепых концепций и технических заданий, в которых для «большего страха и мощи системы» » необходимо использовать выражения типа: «.
на основе существующих артефактов разработанная метамодель поможет реальным пользователям.
», обязательно использовать только термины и сокращения, и конечно, обязательным условием является описание «сферических коней в вакууме».
Затем нам нужно детально проанализировать все эти понятия, приобретя еще миллионы моделей: от простых IDEF-диаграмм до огромных UML-моделей со всевозможными ассоциациями, агрегациями и прочими «атрибутами».
В результате получается все больше и больше «пауков».
Конечным пользователям на самом деле плевать на эти модели, диаграммы и т. д., им нужны работающие кнопки.
После этого начинается сама разработка, программисты начинают «клепать» то, что было запланировано, о чем написано в техническом задании.
Опустим документацию и тестирование.
перейдем сразу к выпуску продукта на рынок.
Маркетологи разработали кучу бумаг о выпуске продукта «СуперМегаСистемПро», который позволит ему не только быть «системой, автоматизирующей то и это», но и (и без лишней скромности)… это… это… это вообще позволяет «автоматизировать весь мир» :-).
Вроде бы все хорошо, система мощная, современная, но клиенты почему-то недовольны.
система вроде бы обо всем, а на самом деле ни о чем.
В результате существующие продукты начинают критиковать все кому не лень, а разработчики спокойно используют SDK (если он есть), чтобы клепать все больше и больше плагинов, лишь бы осчастливить заказчика.
В результате зоопарк растет. Существующие проблемы с программным обеспечением лежат на поверхности; нет необходимости их искать и тем более вытаскивать из глубины.
Но тем не менее начинаются новые дискуссии, новые концепции.
в конце концов, "кто-то в лес, кто-то на дрова".
но самое главное - имеющиеся недостатки завуалированы емкими терминами и, как следствие, новая система стала только еще более сложной и непонятной.
Жалко потраченного времени (2-5 лет), а тем более жалко выбрасывать «тонны кода», ведь программисты не виноваты.
После моей демагогии по поводу «водопадного подхода» :-) имеет смысл перейти к реально работающей технологии SCRUM. Эта технология действительно помогает воплотить продукты в жизнь и помогает в разработке новых и лучших продуктов.
Инициативная группа разработки решила работать по SCRUM, пытаясь исправить существующее положение вещей.
Была сформирована команда, состоящая из программистов, аналитиков и тестировщиков, в которой, как и положено технологии, был ProductOwner со своим ProductBacklog и SCRUM-мастер.
Процесс Мы объединили методы SCRUM с некоторыми практиками XP (экстремального программирования).
SCRUM решает вопросы управления и организации, а XP специализируется на инженерных практиках.
Из XP мы позаимствовали: парное программирование, рефакторинг, CodeReview и стиль описания кода.
Также в ходе ретроспектив мы определили для себя ряд правил, которых придерживаемся.
Для разработки качественного графического интерфейса мы используем практику использования символов.
Мы используем только облегченную документацию: схему базы данных и UML-модель, которые разрастаются только в процессе разработки соответственно — это не такие страшные пауки, как описано выше.
Планирование Планирование спринта в нашей команде длится практически целый день, НО если спланировать спринт плохо, итерация может просто провалиться.
Поэтому планирование — самая важная часть любого SCRUM-проекта.
Для расчета идеальных часов мы используем коэффициент фокусировки 0,4. В принципе, этот показатель является средним по всем итерациям и является оптимальным, поскольку нам обычно удается выполнить запланированные задачи в срок.
Планирование обычно происходит возле «стены дизайна» (доски с маркерами) или за столом с компьютером, где хорошо виден прежний функционал и графический интерфейс.
Некоторые диалоги рисуются прямо на доске и фотографируются, затем эти фотографии будут использоваться при реальном выполнении заданий.
Для оценки трудоемкости мы используем PlanningPoker; практически все задачи тестируемы, что позволяет сразу выявить все ошибки.
SCRUM – встреча Ежедневные встречи проводятся 2 раза в день возле SCRUM-доски.
После встречи на карте горения делается отметка.
Задача считается выполненной, т.е.
переводится в состояние «Готово» только после тестирования.
Программист может взяться за следующую задачу в «ИнПрогресс» только после того, как аналитик утвердит принятую к исполнению предыдущую задачу.
Диаграмма сгорания настраивается Скрам-мастером.
Во избежание превышения лимита времени в 15 минут заседание проводится стоя.
На встрече мы определяем, что мы сделали, что будем делать дальше, какие у нас проблемы.
Технические детали мы стараемся не обсуждать, но это не всегда получается.
Обычно встреча длится не более 10 минут. Если на встрече были выявлены какие-то технические проблемы, то их обсуждение проводится после схватки возле «стены дизайна» (доски с маркерами).
SCRUM - доска В качестве скрам-доски мы используем обычную пробковую доску.
Мы разделили область доски на три части: ToDo (что нужно сделать), InProgress (В процессе), Done (Готово).
Однако мы также ведем в программе электронную версию доски (UserStory, задачи, % участия задействованных членов команды и т. д.).
Это делается «ради истории»; в своей работе мы используем только доску.
Диаграмма выгорания Диаграмма сгорания является четким индикатором прогресса.
Ось X — это ось времени.
Ось Y — сложность незавершенных задач.
Задача считается выполненной, если она проверена тестировщиком; во всех остальных случаях задание не выполнено.
Выполненные задачи переносятся в раздел «Готово» Scrum-доски.
Таким образом, на графике отображается сумма трудоемкости задач, расположенных в разделах «Сделать» и «В процессе».
После ежедневных встреч диаграмма сгорания корректируется с учетом выполненных задач за день.
Также в программу вносится информация о выполнении, где наглядно отображается дата взятия задачи в «ИнПрогресс» и дата выполнения задачи.
Продукт автоматически рассчитывает среднюю скорость команды, коэффициент фокусировки.
Эта информация иногда может помочь переоценить трудоемкость выполнения задач и фактор фокуса команды.
Демонстрация Демонстрация обычно проходит во второй половине дня.
Мы стараемся пригласить как можно больше заинтересованных людей и учесть их пожелания.
Ретроспектива Обычно мы проводим ретроспективу сразу после демо с чем-нибудь вкусненьким, хотя многие SCRUM-гуру предлагают проводить ретроспективы в барах, пабах и т. д. Думаем, что когда-нибудь обдумаем эту идею.
На ретроспективе каждый участник команды рассказывает о моментах, которые ему понравились или не понравились, и предлагает идеи по улучшению процесса в команде.
Также обсуждаются некоторые организационные вопросы и командное взаимодействие.
Для проведения ретроспективы мы используем доску с маркерами, которая условно разделена на 4 блока: минусы, плюсы, идеи и план.
После того, как все участники высказались и все идеи были записаны, мы проводим голосование, размещая магнитные фишки.
Мы в дальнейшем стараемся следовать практически всему, что было записано в блоке «План».
В результате работы над SCRUM наша команда смогла быстро и эффективно решить многие из этих проблем «на поверхности» (правда, систему не реанимировали, а писали с нуля).
Да пребудет с нами «великая сила SCRUM» и подарит пользователям работающие кнопки!!! Теги: #agile #Управление проектами #scrum #Чулан
-
Исправление Ошибки Crc В Ms Outlook 2007
19 Oct, 24 -
Программист-Костыль
19 Oct, 24 -
Новый Мобильный Яндекс
19 Oct, 24 -
О Цветке На Могиле Рабочего Времени
19 Oct, 24 -
23% Россиян Играют В Компьютерные Игры
19 Oct, 24 -
Мы Используем Социальные Сети В Личных Целях
19 Oct, 24
