Методологии Управления Проектами, Или Что Такое Waterfall, Agile И Scrum
Содержание
Нельзя упускать из виду нерешенные проблемы с доставкой программного обеспечения и услуг, а также с надежностью и безопасностью. Если кто-то пытается использовать знания, полученные в результате применения DevOps, с целью консультирования других, это нормально. Но не стоит забывать, что большинство DevOps ー это технические специалисты-практики, которые постоянно в поиске новых удобных инструментов для своей работы. Наш product owner или представитель заказчика, который тесно с нами сотрудничал, всегда начинал планирование спринта с описания того, что в первую очередь нужно сделать. После этого команда производила оценку трудозатрат для всех user story, начиная с самой важной. В процессе у команды возникало много вопросов по поводу того, как это должно функционировать.
Поэтому перед разработкой системы для Академии мы организовали совместный тренинг с ребятами из Scrum Ukraine. Перед нами стояла задача создать единую информационную систему для Академии. Это значит, что уже после первой итерации заказчик получает пусть и небольшой, но вполне полезный и работающий продукт, проверяет его в деле и сразу дает обратную связь. Удобное проектирование, управление, мониторинг и оркестрация системам.
- Хотя Scrum не требует наличия спецификации на разработку, то, что у нас было готово описание предметной области, оказалось большим плюсом.
- Упрощать функциональность, а затем ее развивать — это нормально.
- Хотя на самом деле, первоначальные идеи DevOps исходят как раз не от разработки, а от людей, вовлеченных в Operations.
- Ретроспективы полезны, особенно когда что-то идет не так.
- Поэтому вместо того, чтобы говорить с компанией о диете, начните говорить о результатах, которые хотите увидеть, о проблемах, которые есть.
У них есть идеи и подходы, которые вы можете использовать. Люди начнут обсуждать это между собой и тут появитесь вы с четким списком приоритезированных задач и предложите попробовать изменить что-то. Изменения не происходят, потому что вы переубедили увальней. Они происходят, потому что вы взрастили первых последователей.
А, значит, квалифицированные технические специалисты уделят больше времени задачам высокого приоритета. В 2009 Патрик Дебуа и Эндрю «Clay» Шафер придумали термин DevOps, после чего Патрика провел первые DevOpsDays в Генте. Это дало мощный толчок развитию направления, и теперь, имея свое название, концепция стала быстро распространяться (OpsCamp Austin, Velocity и DevOpsDays в штатах).
Но в то же время, полностью перекраивать действия не должно быть первоначальной задачей DevOps. Принципы DevOps ー часть общей корпоративной культуры Agile, но в основе он несет то, как именно оперейшенс вовлекаются в гибкую разработку. Нельзя просто взять команду Operations и назвать командой DevOps ー это делу не поможет. Только изменения на уровне организации, а не выделение отдельной должности, помогут ощутить преимущества DevOps.
То маленькое количество людей, которые в итоге стали двигателем изменений. Скорее всего, они были созданы, чтобы обойти какие-то проблемы и справиться со сложностями. Есть шанс, что вы это разрушите, а это окажется несущей стеной. И вы будете стоять на пепелище со своим прекрасным scrum-ом. Отнеситесь к этому сопротивлению с любопытством – если люди так сильно упираются – что вы не учли?
Использовать Возможности
Команде порой сложно научиться правильно расставлять приоритеты и оценивать задачи, а общий успех проекта отчасти зависит от профессионализма одного человека – скрам-мастера. Методология направляет всех участников реализации проекта к активному взаимодействию и взаимозаменяемости. Если кто-то из https://deveducation.com/ членов команды не может выполнять свою работу, ее сразу же подхватывает другой, не давая проекту стоять на месте. Именно поэтому, согласно этой методологи, и решение принимают коллективно. Никто не может заставить принять другое решение, если команда уверена, что остановилась на правильном.
В рамках Scrum нет единственно правильного пути в разработке продукта. Это не учебник с заданиями и правильными ответами в конце. Страшный сон команды исполнителей — это когда до начала разработки надо «нырнуть» в неизвестную предметную область и оценить еще сырую идею. При этом нужно гарантировать результат в назначенный срок за фиксированные деньги.
Какие Бенефиты Дает Компаниям Цифровая Трансформация
Принципы DevOps ー нет четкого списка принципов, хотя были неоднократные попытки из описать. Например, Джон Уиллис и его «CAMS», или Джеймс Тернбулл с его собственным определением. «Инфраструктура как код» часто упоминается как один из базовых принципов этой философии.
Scrum требует от команды завершения вполне осязаемого отрезка работы, что позволяет получить инструмент, который можно предоставить пользователю в конце каждой итерации. Это помогает видеть решение в работе и на начальных этапах понимать, что нужно изменить, чтобы продвинуться дальше. Для нас ретроспектива является вторым по значимости мероприятием в Scrum после планирования спринта. Во-вторых, людям свойственно преувеличивать свои возможности, а шкала не позволяет сильно ошибаться с оценкой времени и ресурсов. Например, команда сошлась на мнении, что на одну из задач достаточно 6 story points. Но если нет уверенности, что хватит и 5, то лучше выбрать 8.
Agile
В среднем по нашему сегменту рынка на менеджмент затрачивается около 15% от стоимости разработки. Для нас ретроспектива — это важное мероприятие сразу же после sprint demo. Ретроспективы полезны, особенно когда что-то идет не так.
Методы Agile ー процессы, с помощью которых реализуются принципы Agile. Это может быть XP, Scrum или ваш собственный процесс, разработанный внутри команды. Это уровень, на котором мы видим воплощение философии через практики. Нет обязательных методов Agile, но можно ориентироваться на возможные способы реализации принципов. Раньше те, кто входил в «Dev», считались создателями продукта или услуги.
На сегодня разработано огромное количество методологий управления проектами. Некоторые используются только в одной компании, есть и глобальные, применяемые бизнесом различной направленности во всех уголках мира. Мы всегда приветствовали, чтобы после каждой продемонстрированной истории заказчики сами попробовали что-то сделать в системе.
По мнению Патрика DevOps стал ответной реакцией на негибкость и разрозненность в имеющихся практиках. В статье Джона Уиллиса об истории движения DevOps хорошо описаны нити, которые переплелись в создании подхода. В идеале в схеме Agile-manifesto информация исходит от более верхних уровней к тем, что расположены ниже. Команды, которые применяют методы и практики DevOps или Agile не понимая, зачем это нужно, могут не видеть общей картины. Предлагаем рассмотреть уровни непосредственно DevOps культуры.
При поддержке руководства можно продвигаться на этап составления плана действий внедрения DevOps. Для оценки готовности команды к переходу в DevOps можно попробовать использовать фреймворк CALMS , ранее ー CAMS DevOps. Наблюдайте за тем, как работают все пять уровней DevOps на практике, не только разработка программных продуктов. Как только коллеги из других департаментов увидят, что это действительно приносит плоды, распространение подхода будет происходить быстрее. Также советуем понаблюдать, через какие каналы и какими способами в компании успешно реализуются инициативы, например, Agile. Термин DevOps охватывает слишком много методов и практик, чтобы иметь однозначное толкование.
Тогда конечный пользователь проверяет каждый пункт критерия приемки. Он говорит, что устраивает, а что нет, какие аспекты можно улучшить. И так — по каждой user story, которая была запланирована на этот спринт.
Компании
Направление DevOps начало развиваться как ответ на рост системных технологий и потребность в инновациях. В его основе лежат принципы администрирования Agile System Administration и практики движения скрам гайд Enterprise Systems Management . Можно сделать поправку на то, что фокус DevOps ー на комплексном продукте или услуге, доставляемым заказчику, а не только на работающем программном обеспечении.
У длинных спринтов свои плюсы — меньше накладных расходов, таких как планирование спринта, демо и так далее. Но мы выбрали короткие, чтобы быть гибкими и меньше рисковать. Проджект-менеджер AniArt Андрей Лещинский рассказывает, как компания внедряла Scrum на одном из своих проектов и какие выводы сделала.
Заметьте, последовательность значений на карточках — нелинейная. Во-первых, это нужно, чтобы избежать появления ложного чувства точности для больших оценок. Если история оценивается примерно в 17 story points, то нет смысла обсуждать, должна ли она быть 15, или 18, или 21.
Верьте в собственные ценности и убеждения до последнего. Даже если в вашей компании никто не верит в agile или scrum не взлетает – это не значит, что не может взлететь, и что это не работает. Будьте верны своему опыту, потому что если вы не будете верить – никто не поверит.
К тому же в 2008 году O’Reilly провели первую конференцию Velocity, посвященную производительности работы в Интернете. Конференция стала площадкой для обмена знаниями об инновационных практиках работы и администрировании. Такие инструменты как Puppet и Chef неплохо себя зарекомендовали в создавшихся условиях.
Как Мы Внедряли Scrum И Какие Выводы Сделали
Сложно однозначно сформулировать, что обозначает этот термин. DevOps ー гибкая философия, поэтому предлагаем рассмотреть все области, которые охватывает DevOps определение, и найти для себя наиболее оптимальное. Есть набор подходов к реализации проекта, которые вместе работают эффективнее, чем по отдельности. Преимуществами этой методологии является высокий уровень взаимодействия между членами команды проекта, быстрый результат, а также гибкость.
Уважать Старые Пути Делать Работу
К тому же ни один этап не может быть выполнен раньше предыдущего. Необходимо договариваться с заказчиком о включении в sprint backlog технических историй и методологических часов. 12% — много, но это того стоит, так как в классическом «водопаде» цена использования методологии — это отдельная роль проджект-менеджера.
Без ретроспектив может оказаться, что команда наступает на одни и те же грабли снова и снова. На наших демо часто присутствовали специально приглашенные учителя и завучи, которые не были на планировании. Разработчики по очереди демонстрируют новые функции вживую на реальных данных.
После этого заказчик решил, что существующей функциональности достаточно — поэтому мы поставили разработку этого инструмента на паузу и сместили ФОКУС на конструктор расписания. Это позволяет бизнесу понять, какую функциональность он может ожидать в конце спринта. Позволяет быть команде предсказуемой и оставаться «на одной волне» с заказчиком. Sprint backlog — это выборка историй из общего product backlog.
Концепция DevOps подразумевает не только использование инструментов. Причина, почему необходимо развернутое определение DevOps, ー вероятность того, что многие пройдут мимо теории, сосредоточившись только на уровне инструментов автоматизации. Такой подход, без следования принципам культуры DevOps, будет ошибочным, антипаттерном концепции.
Category: Uncategorized