Agile *

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

Сегодня рассмотрим как практике использовать модель Херси — Бланшара в управлении людьми.

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

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

Когда ломается система продаж, первый вопрос от бизнеса часто звучит так: «Когда уже ИТ все наладят» или «Почему опять не работает?». Но редко кто задаётся другим — более фундаментальным — вопросом: из чего состоит стабильность цифрового контура?

В реальности, если ИТ не работает — бизнес останавливается. Но в восприятии большинства сотрудников/менеджеров/агентов, ИТ по-прежнему выступает как вспомогательная функция, а не как ядро операционного процесса.

Это подтверждает и внутренняя диагностика, проведённая нами через анкетирование бизнес-заказчиков. Вот что мы увидели:

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

Статья будет полезна для тех, кто менторит стажеров/джунов-программистов, и для самих смельчаков-новичков в этом нелегком деле.

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

Иногда кажется, что команда вроде бы стабильная, спринты идут по плану — а под конец снова в панике жмёмся к дедлайну, выкидываем фичи и дорабатываем вечерами. Чтобы такого не происходило, я хочу рассказать про простую и очень рабочую модель — 3–3–3. Она помогает прогнозировать скорость команды без гаданий на story points и держать реалистичный фокус: сколько мы реально успеем, а не сколько хочется.

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

Чтобы быстро и точно понять текущее состояние дел, удобнее всего использовать так называемый LiveBoard — дашборд, который показывает тебе реальную ситуацию в моменте. Он не про эффективность на дистанции, а про то, чтобы сразу видеть: что сейчас в работе, где возникли проблемы, и на какие задачи обратить внимание прямо сегодня.

Agile — только для IT? Точно нет. Команда Kaiten поговорила с экспертами из разных сфер и выяснила, как принципы Agile работают за пределами разработки: какой эффект они приносят и какие сложности вызывают.

Рассказываем истории других команд, которые помогут пересмотреть подходы в своем отделе и сделать процессы эффективнее.

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

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

Создателей эксперимента вдохновили преступники нацистской Германии, и они задались вопросом: «Почему обычные люди выполняли чудовищные приказы?». Чтобы на него ответить, они провели серию экспериментов, в которых обычные люди попадали в ситуацию подчинения.

Изменения в управлении часто ассоциируются с громкими заявлениями, трансформациями, реструктуризациями и, конечно, внутренним сопротивлением. У нас всё случилось иначе.

За последние несколько лет мы практически полностью перешли от принципов менеджмента 2.0 к менеджменту 3.0. Но интереснее всего то, что сотрудники этого почти не заметили — просто потому, что всё происходило естественно. Делюсь своими наблюдениями, как и почему это получилось.

Всем привет!

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

Время выполнения потоковых задач в разработке часто колеблется: один день задача занимает 2 часа, в другой — 6. Из-за этого сложно предсказать, уложится ли команда в срок. Control chart помогает отслеживать разброс времени, находить аномалии и корректировать процесс до того, как отклонения станут проблемой. 

В статье разберем, как это работает, и покажем, как можно читать график, чтобы определить SLA при работе с заказчиком.

Знаете, в чем сила канбан-досок? С их помощью можно организовать любой проект — и разработки, и крипто-стартапа, и контент-студии. Чего угодно. Рассказываю, как сэкономить время, силы и деньги и выбрать лучший сервис с канбан-досками.

Для кого эта статья: менеджеры, тимлиды, директора, отвечающие за организацию процессов, трансформацию команд и внедрение устойчивых практик управления IT. Если вы ищете понятный способ освежить знания по ITIL 4 и посмотреть, как принципы работают вживую — этот разбор для вас.

Разработчики делают задания ради галочки, в их глазах больше не горит огонь, а число инновационных идей от девелоперов уменьшилось? Нет, сотрудники не обленились. Им просто не хватает мотивации для эффективной работы. Разбираемся вместе с командой системы управления проектами Kaiten и консультантом по современному менеджменту Neogenda Марией Савельевой, как вернуть мотивацию IT-команде. 

Таск-трекер без бизнес-процессов ― деньги на ветер! Самая частая ошибка ― пытаться заводить задачи, не продумав сам процесс. В этом тексте показываем 6 универсальных процессов, которые можно внедрить буквально за 10 минут: от онбординга до работы с подрядчиками.

Всем привет! С вами Леша Жиряков, и сегодня я затрону тему планирования и Agile.  Недавно кластер/трайб/холдинг, в котором я работаю, проходил трансформацию методов работы, все началось с идеи: а давайте сделаем продукт более открытым. С одной стороны, бизнес требует предсказуемости и возможности строить долгосрочные стратегии, с другой — рыночная турбулентность и подводные камни в IT диктуют необходимость быстрой адаптации к меняющимся условиям. 

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

Классическое долгосрочное планирование на год и более даёт стратегическую перспективу, но часто оторвано от реальности быстро меняющегося рынка и технологий. Двухнедельные спринты позволяют гибко адаптироваться к изменениям, но затрудняют видение большой картины и координацию масштабных инициатив. Где же золотая середина?

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

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

В процессе создания программного обеспечения участвует множество ролей, каждая из которых имеет свою систему ценностей, приоритетов и целей. Эти различия часто приводят к противоречиям в требованиях. Для структурированного анализа таких конфликтов используется модель «Гексапараллакс», которая рассматривает шесть ключевых точек зрения:

Много JavaScript‑фреймворков назад, в 2009 году, Джеффри Дин, будучи инженером в Google, представил знаменитые «числа, которые должен знать каждый программист».