О чем статья: Это художественное произведение, основанное на реальных событиях, о том, как собрать команду и штурмовать самые перспективные мероприятия на стыке науки и технологий. Одновременно это — руководство для тех, кто хочет впервые принять участие в хакатоне и не сгореть. Прочитав его, вы получите один из вариантов развития событий со стороны менеджера проектов.
Рубрика «гибкие методологии»
Как выжить во время хакатона: история провала, который стоит вашего успеха
2025-10-22 в 15:15, admin, рубрики: extreme programming, гибкие методологии, дедлайн, кейс, командообразование, лидерство, управление проектами, хакатонAgile в функциональном проекте. Организация работы на IT-рельсах
2024-09-13 в 11:08, admin, рубрики: agile, гибкие методологии, метрики процесса, проектыAgile в функциональном проекте. Организация работы на IT‑рельсах
Когда говоришь о проектах в методологии Agile, чаще всего представляешь IT‑команду творческих, открытых к изменениям специалистов, которые занимаются разработкой программной части какого‑то крупного функционала.
Опуская множество НО, в целом, философия Agile (а никак иначе язык сказать не поворачивается) показала довольно неплохие результаты с точки зрения организации команд в других, околоайтишных направлениях.
Заплатки на Scrumban: Tips & Tricks
2024-09-04 в 5:19, admin, рубрики: agile, kanban, scrum, Scrumban, гибкие методологии, скрамВ этой статье я поделюсь своим опытом адаптации стандартов Agile к реалиям своего текущего проекта；перечислю решения, которые продвинули мою команду вперед, призывая мыслить шире и проявлять креативность.
Находясь на позиции бизнес‑аналитика в EPAM Systems, два года назад я присоединился к новому проекту (крупный западный образовательный ресурс).
Команде требовался подходящий рабочий процесс, и мы проанализировали имеющуюся ситуацию:
-
Продуктовый менеджер не является Product Owner и с ним вообще сложно связаться.
Эволюция Lean Canvas и Business Model Canvas. Метод структурирования процессов в компании на 1 листе бумаги
2022-01-14 в 20:13, admin, рубрики: agile, lean management, Анализ и проектирование систем, бизнес, бизнес-модели, бизнес-процессы, гибкие методологии, дизайн, управление, управление персоналом, Управление продуктом, управление проектами и командой, фреймфоркиВ октябре 2021 года меня пригласили провести стратегическую сессию для одной компании, которая занимается комплексным озеленением общественных и корпоративных пространств. Задачей мероприятия была презентация бизнес-целей на ближайшие несколько лет и синхронизация коллектива вокруг них. Всего в компании работает 120+ человек, на встрече присутствовал бэк-офис, 30 человек.
Нужен ли тебе Agile: 5 моделей для проверки
2019-08-28 в 18:47, admin, рубрики: agile, waterfall, гибкая разработка, гибкие методологии, Управление продуктом, управление проектами, управление разработкойДети, рожденные в год подписания Agile Manifesto, в этом году празднуют совершеннолетие. А взрослые люди продолжают спорить, где Agile применим. Обычно бьют по площадям: можно ли использовать Agile вне IT. Иногда добавляют драмы: пробовали ли вы строить атомную электростанцию по Agile? Для художественного эффекта так, конечно, лучше. Но если вы хотите сделать продукт, а не победить в конкурсе ораторов, то лучше смотреть применительно к конкретной ситуации.
В этой статье мы расскажем о нескольких моделях оценки применимости Agile и подробнее остановимся на одной их них — Agile Suitability Model, представленной в Agile Practice Guide от PMI и Agile Alliance.
Читать полностью »
Как в условиях трэшевой архитектуры и отсутствия навыков в Scrum мы создали кросс компонентные команды
2019-06-27 в 15:05, admin, рубрики: agile, agile manufacturing, scrum, scrum трансформация, ubrd, банк, банки, гибкие методологии, ит, скрам трансформация, убрир, цифровая трансформацияПривет!
Меня зовут Александр, и я руковожу ИТ разработкой в УБРиР!
В 2017 году мы в центре развития сервисов информационных технологий УБРиР поняли, что пришло время глобальных изменений, а точнее — agile-трансформации. В условиях интенсивного развития бизнеса и быстрого роста конкуренции на финансовом рынке два года – внушительный срок. Поэтому пришло время подвести итоги проекта.
Самое сложное – менять свое мышление и постепенно культуру в организации, где принято рассуждать: «а кто будет начальником в этой команде?», «начальник лучше знает, что нам нужно делать», «мы здесь работаем уже 10 лет и знаем лучше наших клиентов, знаем, что им нужно».
Agile-трансформация может произойти только, когда в ней меняются сами люди.
Я бы выделил следующие ключевые страхи, мешающие людям меняться:
- Страх потерять власть и “погоны”;
- Страх стать не нужным для компании.
Встав на путь трансформации, мы выбрали первых «опытных кроликов» — сотрудников retail-направления. Первым делом провели редизайн неэффективно работающей структуры ИТ. Придумав целевой концепт структуры, приступили к формированию команд разработки.
Как масштабировать Scrum — пара слов о фреймворке гибкой разработки ПО Nexus
2018-10-04 в 12:45, admin, рубрики: nexus, scrum, Блог компании ИТ-ГРАД, гибкие методологии, ИТ-ГРАД, Управление e-commerceВ январе 2018 года свет увидел обновленный фреймворк Nexus — инструмент на базе Scrum, заточенный под командную работу над крупными проектами. Авторы методологии внесли исправления в ряд определений терминов и поменяли порядок лицензирования. С начала года Nexus Guide распространяется по лицензии Creative Commons. И это значит, что любая компания может свободно использовать Nexus (как и Scrum).
Расскажем об особенностях методологии и её основных компонентах.
Дизайн цифровых продуктов. Цель, роль, метод
2018-09-29 в 2:39, admin, рубрики: scrum, гибкие методологии, дизайн, Управление продуктом, управление проектами, цифровой продуктМне довелось создать с нуля подразделение дизайна в Альфа-Банке и поработать дизайн-директором. На это ушло пять лет. В результате у нас получилась дизайн-система (в коде) и подход к диайну цифровых продуктов. Собственно, про этот подход я и расскажу здесь. Точнее, это — текст лекции, которую я читал в начале 2018 года в Москве, Перми, Новосибирске и Петербурге. В мае я принял решение покинуть банк, теперь дошли руки опубликовать текст лекции.
В Альфа-Лаборатории мы строили процессы продуктовой разработки как раз по скраму, где каждая команда является самостоятельной единицей, способной делать поставки так быстро, как смогут (в идеале — недельными или двухнедельными спринтами).
Важная оговорка: весь текст рассказывает о работе дизайнера в скрам-команде. Это очень важная оговорка, которую надо держать в голове. На лекциях я это упоминал мимоходом, как само собой разумеющееся, поэтому кто-то мог потерять смысл рассказа. Для канбана и традиционных подходов (договор-дизайн-верстка-сборка-акт) такой метод скорее всего может даже навредить. Поэтому, если вам понятие «скрам» ново, изучите подход — может быть кому-то это поможет лучше организовать работу у себя. По ходу текста я насыпал ссылок на статьи и книги.
В конце 2017 года в Лаборатории было около 30 команд (может больше), и почти для каждой нужен был свой дизайнер. Даже на таком относительно большом масштабе важнее работать на уровне стратегии, верхнеуровневых понятий и подходов, потому то «контролировать» работу 30 дизайнеров, которые работают над разными продуктами и в разных командах и с разной скоростью технически качественно не получится. Тактику определяет каждая команда самостоятельно, в этом вся прелесть.
Как использовать Канбан для удобной работы не только менеджеров, но и программистов
2017-08-04 в 7:08, admin, рубрики: agile, kanban, гибкие методологии, метрикиКанбан — методология управления, которая используется примерно в 10 раз реже, чем Scrum, но от этого не становится менее интересной. В ее основе лежит представление процесса всей организации, как набора взаимосвязанных сервисов, которые в конечном итоге являются сервисом для конечного потребителя.
Канбан особенно легко внедряется начиная с топ-менеджмента и прекрасно комбинируется с теорией ограничений, изложенной в книге «Цель» Элияху Голдрата. Канбан выбирают для себя отделы техподдержки, системные администраторы, и даже менеджеры по персоналу и бухгалтеры, тесно работающие с IT.
Одной из основных отличительных черт являются принципы внедрения Канбана: «Начните с того, что имеете, визуализируйте процесс, договоритесь об эволюционном изменении процессов».
Заметьте, что речь идет не о том, чтобы громогласно объявить о внедрении Канбана, а лишь о том, чтобы эволюционно менять процессы в сторону улучшения. Наверное, вы подумали: «Звучит не страшно. Кто же от такого откажется?». И тем не менее, добиться заметных результатов с точки зрения бизнеса без серьезных изменений не выйдет.
Следом за невинной фразой «давайте договоримся об эволюционном изменении процессов» может поступить много разных предложений. И если внедряющий Канбан достаточно опытен, это все пройдет весьма аккуратно. Ниже описаны выгоды, ради которых стоит внедрять канбан, и практики, которые можно использовать для улучшения процессов.
Никто не научит программистов программировать быстрее с помощью этих методов, естественно. Но большую часть времени задачи скорее лежат в очереди или блокируются по тем или иным причинам, а иногда просто оказываются забытыми в гуще недоделанных дел. С наведением порядка в задачах канбан справиться вполне может.
Выгоды внедрения
В наше время, когда интерес к слову Agile, мягко говоря, перегрет, ее может и не предполагаться изначально. Но все-таки, даже если это было затеяно с целью выполнить поручения, из внедрения все еще можно извлечь пользу.
Читать полностью »
7 препятствий для внедрения гибких методологий в больших организациях
2017-04-22 в 17:14, admin, рубрики: agile, scrum, гибкие методологии, перевод, управление персоналом, Управление продуктом, управление проектами, управление разработкойЯ работаю с большими компаниями, которые пытаются применить Agile, начиная со Scrum. Хотя каждая организация находится в своем секторе, использует разные технологии и имеет свою культуру управления, у всех была одна общая болезнь — своего рода «гигантизм». В этой статье содержится список общих проблем гибкости в больших организациях и исследуется возможность избежать симптома «гигантизма».
На первый взгляд проблемы организации будут выглядеть как «слишком много задач» или «не достаточно ресурсов», или «нестабильная ситуация на рынке». При ближайшем рассмотрении, ключевые причины окажутся дурными привычками, сформировавшимися «рефлексами» и заблуждениями.
Одна из очень известных компаний, которая была примером успешного применения Scrum в 1997 году, обратилась за помощью в Danube Technologies, Inc. в 2009 году, потому что «рынок» показал, что они оказались менее гибкими, чем конкуренты. Начинания по внедрению Scrum, которые начались 1997 году, по-видимому, не могли выдержать десятилетие сосуществования с проблемами, присущими крупным предприятиям. К сожалению, большинство попыток внедрить Scrum в крупных организациях не приводит к долговременным преобразованиям. Препятствия для внедрения Scrum обычно также мешают достижению успеха в бизнесе в целом, а устоявшиеся организации обычно неохотно избавляются от них.
Препятствие #1: Наивный менеджмент ресурсов
В Руководстве PMBOK написано:
«зачастую возникает необходимость увеличения бюджета, чтобы добавить дополнительные ресурсы для выполнения того же объема работ в более сжатые сроки»
В отношении программного обеспечения, Фред Брукс (в книге «Мифический человеко-месяц») дает утверждение, которое противоречит предыдущему:
«Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»
Чтобы разрешить этот парадокс, давайте рассмотрим определение «ресурса».
Читать полностью »