Agile *

Гибкость (agility) — это, без сомнения, полезная вещь, и Манифест Agile не выглядит необоснованным. В сравнении с устаревшей практикой, известной как «Waterfall», Agile безусловно имеет свои преимущества. Тем не менее, многие аспекты Agile на практике оказываются весьма вредными, и я не считаю, что дихотомия «Agile/Waterfall» вообще является полезной концепцией.

Существует одна из разновидностей Agile, называемая Scrum, которую я наблюдал на практике, и она реально может привести к гибели компании. Под словом «гибель» я не имею в виду «ухудшение культуры». Я говорю о том, что акции этой компании упали почти на 90 процентов за меньше чем два года.

Привет, Хабр!

Решил свою первую статью на портале сделать легкой, без залезания в дебри и диспуты. Пусть будет своего рода научпоп от менеджмента в ИТ.

Немного предыстории: где‑то около года назад мы с коллегами были на загородном выезде для манагеров. В программе было обучение и брейнстормы, в перерывах и вечером — активный движ и застолья. И вот как‑то раз, после дневных учебно‑мозгоштурмовых сессий народ разбредался по активностям, а я сел в лобби, достал ноут. Сижу. Подходит коллега:

— Что делаешь? Ботаешь?
— Нет, учусь.
— Что учишь?
— ООП
— А зачем?

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

На встречах они не обсуждали функциональность продукта, а говорили о «пользовательских историях» – маленьких повествованиях, описывающих фичи. Каждой такой истории присваивались «story points» — условные единицы, оценивающие объём усилий, необходимых для выполнения задачи. Каждое утро они проводили «стендапы» – короткие собрания, на которых все стоят. В центре их офиса стояла доска, на которую они клеили стикеры и передвигали их по колонкам в зависимости от статуса задачи. Они работали «спринтами» – двухнедельными циклами, посвящёнными определённым задачам.

На общих совещаниях менеджер команды показывал прогресс с помощью специального ПО с дашбордом, отображающим статус всех проектов. Он также мог показать график «velocity» — скорости выполнения задач, с историей изменений и прогнозами.

Так я и узнала, что такое Agile — метод управления разработкой, который получил колоссальную популярность в технической среде и, всё чаще, за её пределами (один TED-спикер даже рассказывал, как внедрил Agile дома, в семье).

Честно говоря, я была впечатлена. В своей работе я часто чувствовала себя потерянной: не до конца понимала, продвигаюсь ли я вперёд или делаю что-то действительно важное. А разработчики, казалось, точно знали, что делают. Если возникала проблема — ничего страшного, они просто с ней разбирались. Они понимали, что требования будут меняться, и двухнедельные спринты позволяли гибко перестраиваться: заменить одну фичу на другую или перейти на другой фреймворк.

Сегодня мы расскажем о внедрении кросс-командной приоритизации во всей компании Спортмастер Лаб, и о том, как мы:

- сократили время планирования разработки в 9 раз (с 18 до 2 недель).

- увеличили количество значимых для бизнеса функций в 5 раз без роста команды разработчиков.

Собственно, краткая суть истории в том, что господин Деминг, светило науки в области управления организациями, на своём семинаре наглядно показывал пример того, как работает мотивация.

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

Логично предположить, что подопытный это сделать не мог. Тогда Деминг подключал «мотивацию»:

Waterfall, Agile, Scrum, Kanban — от выбора методологии зависит то, как команда будет справляться с разными типами задач, уложится ли она в сроки и будет ли вносить бесконечные правки. Если вы хотите четко понять, чем отличаются эти подходы, какие у них сильные и слабые стороны, и в какой ситуации каждый из них действительно эффективен — эта статья для вас.  

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

— Голдстейн. 

— Да, мистер Старк. 

— Дай мощный бит, под который я буду бить лучшего друга, писать эту статью. 

©Железный человек

Привет, Хабр! Меня зовут Дмитрий Сушков, последние 5 лет работаю железным человеком бизнес-аналитиком. Сегодня поговорим про одну из самых важных задач бизнес-аналитика (BA) — сбор и приоритизацию требований. Эта область довольно мутная, ибо редко бывает единый правильный подход. На каждом проекте есть свои «острые углы»: как договориться с заказчиком, прояснить его реальные потребности, оформить требования так, чтобы их поняли все участники, и при этом успеть всё в срок. Это как разжигать костёр в ливень, в открытом поле, пробовали?) И не стоит. 

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

Эта статья будет полезна:

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

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

Привет, Хабр! Это Иван Чаплыгин, руководитель отдела переводов компании КРОК. Сегодня речь пойдет про Agile. Вы, конечно, все на нем собаку съели, а может, и не одну.  И сколько agile-коучей обитает на Хабре, одному богу известно. Но в области ИТ-переводов, вечно находящейся на стыке технических и гуманитарных знаний, гибкость оказалась тоже очень кстати. К Agile мы пришли не в результате цифровой трансформации, коучинговых сессий или серии онлайн-тренингов. Все гораздо банальнее. Методом проб и ошибок мы изобрели свой переводческий «agile-велосипед», чтобы ехать с ветерком. Подробности о том, как мы дошли до жизни такой - под катом. 

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

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

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

Российский рынок систем управления проектами в 2025 году выглядит насыщенным как никогда: есть облачные решения для ИТ команд с досками и задачками, есть и платформенные гиганты с BI аналитикой и матрицей ресурсов. Но как выбрать? Чем они отличаются? Какие из них реально работают в крупных компаниях?

Я составил краткий и честный обзор на 10 систем управления проектами. Без рекламы, с плюсами, минусами и рекомендациями для разных случаев.

В Agile есть прекрасная штука, которая называется Daily Standup или «Ежедневный стендап». Короткая ежедневная встреча команды, во время которой каждый сотрудник делится своими достижениями, планами и затруднениями. Эти встречи позволяют держать руку на пульсе и решать возникшие трудности быстро, а так же не терять фокус на текущей работе. Меня зовут Виталий, я хочу рассказать в этой статье о том, с какими проблемами мы столкнулись при внедрении в команде стендапов (хотя казалось бы что‑там сложного) и как их решили. Получилось, на мой взгляд, достаточно просто, красиво и функционально.

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

Но для начала рассмотрим, что из себя представляет методология Agile, и чем она отличается от классической Waterfall.  

Меня зовут Александр, я CTO компании AppFox. Мы более 10-ти лет занимаемся заказной разработкой и также имеем собственные продукты. 

Всем привет, на связи Scrum‑мастер команды eXpress Дмитрий Шугалей. Совсем недавно мы добавили функцию тегов в мобильной версии нашего корпоративного мессенджера (на десктоп‑клиенте они работали уже давно), и еще раз убедились, что это вполне рабочий инструмент организации работы над задачами в проекте. Попробовал сам, поговорил с коллегами — и родилась идея посмотреть, как один из популярных методов повышения личной эффективности «встраивается» в рабочий мессенджер при помощи тегов. Получилась эта заметка как отражение личного опыта и нового взгляда на старый известный подход.

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

Привет, Хабр! Меня зовут Игорь Батулин, я руководитель группы разработки виртуального хостинга в Рунити. Эта статья — не просто рассказ о том, как я люблю рогейн, а пример того, как можно за несколько итераций и в условиях ограниченных ресурсов создать полезный инструмент, действительно помогающий команде принимать решения. Мой рассказ также подскажет, как можно применять Agile-подходы в реальных задачах.

Внедрение Agile «на хайпе» и искаженное понимание принципов манифеста ведет к сырым ненужным пользователю продуктам. Вместе с автором канала Junior PM, Артемом Летюшевым, разбираемся в разнице между настоящим значением принципов и мифами, которые компании принимают за правила и внедряют в свои процессы.

Небольшое интро:

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

— Удивительно, но в комментариях была тотальная поддержка «претензий». Одна из цитат, набравшая больше всего лайков: «Если человек отрабатывает от звонка до звонка, например с 9 до 18, то он не заинтересован в этой работе».

— Я крайне редко вступаю в дискуссии под чужими видео, но тут не выдержала)) И была рада, когда увидела непривычное для меня количество сердечек — значит, ещё не всё потеряно.