Agile *

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

Заставить профессионала работать? Да тут весь Agile построен на том, да и практика подсказывает, что все манифесты и принципы разработки дают как раз базис для того, чтобы ты развивался "без потолка" и имел свой профессионализм и никто тебя не заставлял работать.

Это как внутренний движок, который, верстая своими шестеренками опыта, дает новый глоток пользы своего существования в командной работе.

А вот тут мы сейчас затронули интересный момент. Кто видел хоть раз, как работает команда профессионалов? Вот они и задают фреймворки, ну, или точнее, фреймворки писались с них.

НЛП говорит нам, что ничего не создается просто так, а успешные кейсы создаются как раз из эмпирического наблюдения за успешными кейсами и их оцифровки.

Для создания Scrum, SAFe и прочих фреймворков брались успешные команды внутри компаний и описывался процесс, вычленялись церемонии в духе - "что было важного, без каких встреч не обойтись и наделялась их ценность.

Ну вроде бы, окрестили встречи, возвели значимость, дабы коварный зверь бизнеса понимал что,для,чего и зачем и не снес тебе встречу, поставив свою с девизом "я сейчас сам всем скажу как надо работать"-опс, даже корпоративную культуру внутри компании можно задвинуть, ведь даже ценности Agile есть, а от них можно, в интеграции с HR даже цифровизацию профилей задвинуть и тогда мы можем наложить примерно 2 картинки для того, чтобы понять, как и чем должен обладать кандидат (конкретно, что развивать и как связать с обучением в корп.академии и у провайдеров).

Scrum стал священной коровой индустрии. Его преподают на курсах, под него заточены целые карьеры, а сертификация Scrum Master стала отдельным бизнесом на миллиарды долларов. Но давайте честно: когда вы в последний раз выходили со стендапа с мыслью «вот это было полезно», а не «ещё пятнадцать минут жизни, которые я не верну»?

Я предлагаю признать очевидное: мир разработки изменился настолько, что процессы, придуманные в начале двухтысячных, стали тормозом. И если профессия программиста еще поживет какое-то время, то Scrum должен умереть сейчас.

Да что он такое несёт?

Сейчас же большинство менеджеров останутся без работы.

Разбираемся: а точно ли нужно всё это скрам-добро?

Количество участников в команде влияет на статистику, но не определяет эффективность процесса. Ключевой фактор успеха — не численность, а чёткое распределение зон ответственности и поддержка траектории профессионального роста каждого коллеги.

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

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

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

Что именно разберём:

1. Как провести аудит ресурсов: энергия, контексты, доступные инструменты.
2. Как дробить большие задачи до уровня конкретных действий.
3. Как собрать день в виде короткой итерации и не ломаться при сбоях.
4. Как делать ретроспективу, чтобы система становилась лучше каждую неделю.

Привет, мир! Софья, 5 лет в ERP на Turbo Script, старший разработчик Консист Бизнес Групп. За это время я не раз убеждалась: обучение стажёров — это искусство баланса между академическими знаниями и реальными задачами, где каждая строчка кода может стать либо фундаментом архитектуры, либо техническим долгом.

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

Если Вы джун, который только входит в мир продуктовой разработки, или наставник, ищущий подход к обучению, добро пожаловать под кат!

Если у нас преобладает умственная работа, то главным нашим ограничением является мыслетопливо - некий когнитивный ресурс, необходимый для принятия решений, мышления, произвольного удержания внимания, поддержания силы воли…

“Не хватило времени” - социально-приемлемая отмазка, которая позволяет не думать над истинными причинами. Но здесь, как и в известном анекдоте, есть нюанс…

Рано или поздно любой руководитель задается вопросом: «Почему мы не достигаем целей на проекте?». Как правило, ответы размытые и сопровождаются презентацией из десяти файлов. После этого в компании появляется идея «оцифровать проектную деятельность». И начинается путь выбора системы, полный надежд, ожиданий и типовых ошибок.

В этой статье разберемся, как подойти к выбору ИСУП без иллюзий и маркетингового тумана: на что действительно стоит смотреть, какие вопросы задать себе до покупки и как получить реальный эффект от внедрения.

Спойлер: внутри — ссылка на полезный гайд со сравнительными таблицами и небольшой обзор популярных ИСУП. 

Раньше я использовал плагин Reminder для отображения всех задач в боковой панели. Результат был предсказуем: каждый день передо мной возникал огромный список заданий без какой-либо системы приоритизации. Необходимо быстро понять приоритеты, оценить требуемый уровень включенности и временные затраты. Это создавало когнитивную нагрузку еще до начала рабочего дня.

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

Многие внедряют SCRUM как набор инструментов: доски, итерации, встречи. Но за кадром часто остается самое главное – орг. структура, созданная под «водопадную» модель. Без понимания того, что структура первична, гибкие процессы просто накладываются на жесткую иерархию отделов. В итоге форма соблюдается, но истинный смысл ритуалов полностью теряется.

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

За неделю я разделил свою жизнь на сферы, выстроил систему и процессы, чтобы еще один год не прошел впустую. Думаю, что получилось очень неплохо, опытом результатом делюсь в этом материале.

Задача может «двигаться по доске», менять исполнителей и статусы — и при этом неделями оставаться незавершённой. В такие моменты команда обычно чувствует суету, а не прогресс: контекст утекает, зависимостей становится больше, а работа в In Progress разрастается как сорняк.

В статье разберем метрику возраста задачи (Work Item Age) — как её считать, чем она отличается от cycle time, какие визуализации помогают быстро увидеть «залежавшиеся» элементы, и почему управление WIP и блокерами часто даёт больший эффект, чем очередной рывок по старту новых задач.

Личный опыт лидера команды по переходу от формального "зачитывания требований" к совместному созданию понимания. Простые шаги, которые помогли нам победить "иллюзию понятных задач" и в разы сократить количество срочных доработок в середине спринта.

Прошел год с тех пор, как наша команда Sugar CRM совершила прыжок из уютного водопада в бурные воды Agile. Мы пережили мучительные получасовые, а иногда и часовые дейлики вместо 15-минутных, прошли через «гадание на кофейной гуще» на планировании спринтов и вроде бы обжились.

Но одна проблема упорно не сдавалась, грозя похоронить все наши agile-начинания. Мы вроде делали всё по книжке: проводили Product Backlog Refinement (PBR), оценивали задачи в Story Point (SP), обсуждали задачи, писали чек-листы и выходили с встреч с чувством выполненного долга.

А потом начинался спринт. И всё шло под откос.

 Некоторым системам подходит модель "commit - это и есть наш релиз", но некоторые системы требуют иметь релиз как ветку в git. В худшем случае, эта ветка является долгоживущей, что порождает трудности, но и даёт преимущества.

Когда лучше выбирать модель долгоживущих релизов, как бороться с проблемами и какие преимущества вы можете получить?

Как заставить поставщика признать ошибку и исправить её за два часа, а не за неделю, руководство для Jun-аналитиков.

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

Привет, Хабр! Меня зовут Ольга Губина, я работаю в МТС Web Services в ЦП Agile. Меня часто просят помочь провести сессии по генерации идей или посоветовать рабочие инструменты. Решила и с вами поделиться тремя альтернативами классическому мозговому штурму — старому (ему уже больше 80 лет!) и проверенному способу генерации идей, при котором участники свободно высказывают любые мысли и предложения, не подвергая их критике.

Зачем такому проверенному способу альтернативы? Представьте картину: все собрались в переговорке, кто-то вещает, кто-то активно жестикулирует, кто-то сидит в телефоне. Через 40 минут кроме слов «надо мыслить нестандартно» и трех одинаковых идей в воздухе повисает лишь усталость. Так зачастую терпит крах классический подход с лозунгом «чем больше идей, тем лучше» — много шума и мало результатов. А еще часто люди привыкают к единообразному формату «свободного» мозгового штурма, что снижает его эффективность и включение в процесс.

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

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

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

В этой статье — о том, почему доверие в команде не возникает автоматически и что на самом деле меняется, когда QA Lead перестаёт быть формальной функцией и становится менеджером, на которого можно опереться.