Agile *

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

Добрый день! Меня зовут Денис Окулов, заместитель руководителя направления по функциональной экспертизе PROF-IT GROUP. С 2008 года я специализируюсь на внедрении и развитии решений на базе SAP и 1С, и за это время я реализовал свыше 20+ проектов для ведущих промышленных предприятий в России и СНГ.

В нынешних условиях события развиваются быстрее, чем их можно планировать. Так, очередные пакеты санкций заставляют более четко определиться с «вынужденным» переходом на отечественное программное обеспечение в классе учетных и ERP-систем. Поэтому бизнесу важно суметь адаптироваться под новые и новые вводные. Скорость, с которой бизнес успешно может отрабатывать очередные вызовы, становится залогом успеха и выживания.

Сегодня «модным» запросом рынка становится технология «переезда» с SAP (и аналогичных западных решений) на 1С ERP в кратчайшие сроки, и речь идет о считанных месяцах (месяца 3-4). Более того, у некоторых заказчиков есть желание провести все еще быстрее. Но логика обстоятельств не позволяет играть со сроками, так или иначе, и заставляет считаться с объективными трудностями этого процесса.

Даже при выборе крайне оптимизированной по временному критерию технологии есть минимальные сроки, «сжать» которые становится предельно дорого. Другими словами, каждый дополнительный день экономии по времени потребует вложений ресурсов с растущим в прогрессии коэффициентом. Например, 1-й дополнительный день экономии срока («сжатия графика») потребует + 200 человеко-часов, 2-й день —+500 человеко-часов, 3-й, соответственно, + 900 и т. д. и т. п.

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

В этой статье я хочу рассказать о том, как новичку работать с методикой Agile при создании продуктового дизайна.

С каждым днем всё больше российских компаний открывают для себя пользу масштабируемых Agile‑практик. Причем это уже не просто локальный Scrum в отдельных командах, а переход на более высокий уровень взаимодействия команд и продуктов.

Меня зовут Антон Чижов и я руковожу Центром практик Agile в МТС. В этой статье я расскажу о том, что такое продуктовая трансформация и как мы ее проводили в МТС. А в конце статьи вас ждет анонс моего выступления на конференции True Tech Day, которая пройдёт 31 марта 2023 года.

Думаю, ни для кого не секрет, что Scrum сегодня – одна из самых популярных Agile-методологий. В сети можно найти много позитивных отзывов от людей, которые его попробовали. Но очевидно, что положительных результатов удается добиться не всем, поэтому есть и немалое количество критических статей. Вот, например, недавно тут же – на Хабре – был опубликован перевод подобной статьи  «Почему оценка задач сломала Agile».

У меня есть хороший опыт использования этого самого Scrum`а и оценки задач в нем, поэтому возникла мысль написать разбор приведенных тезисов и ответить на критику (что-то  в стиле «Антипаттерны Scrum»). Но в итоге, я решил, что будет честнее (по крайней мере для моей первой публикации), если я начну с позитива, и сначала попытаюсь сам разъяснить главное на мой взгляд заблуждение в статье – что же такое Story Points, и что такое оценка в Scrum.

При этом я не хочу писать новую инструкцию. Если вам нужны формальное описание и детали, то можете обратиться к первоисточникам, например к книге Джеффа Сазерленда «Scrum. Революционный метод управления проектами» (МИФ, 2015) – там все подробно описано с обоснованиями и прочим. Я же, в свою очередь, хочу предложить более короткий путь: «с использованием местных идиоматических выражений».

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

Scrum - популярный в командах разработки фреймворк. Но так ли он важен и нужен в действительности?

В статье в формате "вредных советов" приведены порочные практики, которые можно встретить в Scrum-командах.

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

Привет! Меня зовут Евгения Воропаева. Я занимаюсь тестированием в PIMS-команде СберМаркета, мы разрабатываем внутреннюю систему для отдела контента и производства. Проект существует уже 2,5 года и за это время PIMS рос и развивался, приходили и уходили люди, менялись подходы к работе, внедрялись новые практики. Методом проб и ошибок мы выстроили процессы в команде тестирования, которые считаем оптимальными. Хочу поделиться результатом, к которому мы пришли и надеюсь, наш опыт будет вам полезен.

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

У меня есть убойная идея для нового продукта! Он будет круче всех. У него будет вот такая классная функция, и вот такой крутой интерфейс, с блокчейном и искусственным интеллектом, с блэкджеком и… ну вы знаете…

Сразу будем делать? Или сначала проверим, а кто‑то вообще его купит?

Я уверен, что у статей‑списков есть огромный потенциал для проверки гипотез о спросе.

Привет всем, кто интересуется Канбан‑методом, и кто хочет познакомиться поближе с одним из его инструментов — S.T.A.T.I.K.

Задумка этой статьи появилась тогда, когда в очередной раз ко мне кто‑то подошел с вопросом: «Мы собираемся делать СТАТИК, где про это можно почитать?»

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

Привет, Хабр! На этапе выбора темы статьи было много идей: написать про DevOps или про платформы, а может про продуктовые команды или про практики SRE? Но пришли к выводу, что нет ничего интереснее, чем реальная увлекательная история трансформации. Мы, команды платформы разработки MOEX и экосистемы Финуслуги.ру, в лице Карапета Манасяна, Александра Барыкова, Антона Квашёнкина и Юлии Лутковской, расскажем практически про весь путь изменений и про их подводные камни. Важно отметить, что в статье затрагивается довольно много тем, местами даже будут блоки со скриптами 😊. Поехалиии!

Каждому проектному менеджеру – от junior до senior, известен скоуп методологий управления проектами. Но многие работодатели не понимают, кто такой менеджер проектов, чем он должен заниматься и какие методологии работают для конкретных задач. Как не выбрать то – не знаю что и не попасть туда – не знаю куда? Давайте разбираться вместе.
Меня зовут Лана Демченко, я администратор проектов направления медицинских ИТ-продуктов в компании «БАРС Груп». Также имею опыт работы в продажах и в административном управлении.

Хочу поделиться своим опытом в том, как я бесплатно получил сертифицированное обучение по основам проектного менеджмента от Google на Coursera. Описываемые действия, в моем конкретном случае, помогли мне сэкономить около €300 на всех частях этого курса. Для меня - это ощутимые деньги и я рад, что вообще есть подобная возможность.

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

Эмпирические выводов по прошествии 5 месяцев профильной работы менеджером проектов в разработке веб-приложений.

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

Предваряю свой рассказ дисклеймером: опытным менеджерам или аналитикам — всем, кто напрямую взаимодействует с заказчиками в бизнесе, — этот материал может показаться крайне бесполезным. А вот начинающим управленцам — сильно наоборот.

Всем привет! Мы - отдел бизнес-поддержки (БП) в Social Discovery Group. В этой статье расскажем, как мы повторили шестой подвиг Геракла, очистив доску от 1500 тикетов, которые накопились за 4 года. 1500 задач - это больно. Тикеты кочевали из спринта в спринт, заказчики ежедневно запрашивали статус по задачам, а мы испытывали стресс от переработок и от того, что не можем дать апдейты. Мы поняли, что нужно менять процессы в отделе и применили подход STATIK, который навсегда избавил нас от бесконечной очереди задач. 

Привет всем читателям, желающим грамотно выстраивать самые многозадачные бэклоги. Меня зовут Фёдор Гвоздев, я основатель интернет-магазина корейской косметики HolySkin. Работаю над развитием этого проекта уже 8 лет и не раз сталкивался с трудностями приоритизации. В этой статье я постараюсь поделиться своим опытом и представить самые «рабочие» модели, которые не раз выручали нас в работе.

Осенью я был на митапе, посвящённом scrum'у. И услышал там интересный тезис: в слаженной скрам-команде роль тимлида/техлида минимальна, потому что все участники команды в той или иной степени являются носителями знаний и прекрасно самоорганизовываются благодаря скраму.

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

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