Agile *

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

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

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

Друзья, привет!

Меня зовут Егор Пахомов, последние 3 года я работаю в Альфе: развиваю цифровые продукты в web- и mobile-каналах, управляю несколькими командами разработки. Ещё несколько команд собрал, организовал и бережно передал коллегам. Одновременно у меня в управлении было до 40 сотрудников: аналитиков, разработчиков, тестировщиков, дизайнеров.

Сегодня расскажу, что нужно, чтобы построить сильную продуктовую команду. После прочтения статьи вы будете чуть лучше понимать:

— На что обращать внимание на собеседовании и какие вопросы задавать кандидатам.

— С какими сложностями можно столкнуться при формировании команды.

— Как инженеры будут создавать продукт, а не просто выполнять таски.

— Как сформировать по‑настоящему сплочённый коллектив.

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

Теперь мы оцениваем баги через тг-бота, не тратим 2 ч. времени на встречи, фиксим самые критичные, но не теряем и минорные.

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

Меня зовут Арсентий Гусев, я руководитель группы embedded-разработки в отделе робототехники Яндекс Маркета. И мне бы хотелось рассказать об опыте, который приобрела наша команда в рамках работы над проектом складского робота. В этой статье определим критерии, предпосылки и предложим инструменты для ускорения разработки и снижения её стоимости.

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

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

Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть 1, Часть 2, Часть 3, Часть 4, Часть 5. Сегодня мы обсудим создание площадки обучения DevOps в стенах компании для обмена опытом между коллегами разных подразделений, повышения компетенции и культуры обучения.

Итак, проблема, которую мы будем решать — это смещение фокуса с развития на поддержку.

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

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

Привет! На связи Денис, RTE в компании «Автомакон».

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

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

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

Экстремальное программирование (XP) — это одна из методологий Agile. Несмотря на название, некоторые практики уже стали стандартом в индустрии — например, рефакторинг и непрерывная интеграция. XP сосредоточена на упрощении процесса разработки, минимизации документации и максимизации обратной связи от заказчиков.

Я нашел свою систему «Личного планирования», о чем я поделился в этой статье и передаю этот опыт студентам курсов по менеджменту в Практикуме.

В этой статье расскажу:

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

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

Фокус-группы, исследования целевой аудитории, оценка конкурентов — всё это не дает гарантии того, что ваш продукт действительно нужен пользователям. Это прогнозы, которые могут не сбыться. Чтобы узнать наверняка, нужно создать и выпустить на рынок минимально жизнеспособный продукт. Привет, я Артём Трубин, CPO компании ActiveCloud. В этой статье расскажу, в чем разница между PoC, MVP и MLP и как, при запуске нового продукта, снизить риски с их помощью.

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

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

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

Но вот вы видите блок уроков, посвящённых идиомам. Идиомам. И-ди-о-мам. Кому они нужны, эти идиомы? Разве айтишники используют их в командном общении?

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

Давайте-ка вспомним что такое "идиома". А что такое идиома вообще? Идиома -- то набор слов, который имеет смысл в определенном языке, но не может быть дословно переведён без потери смысла на другой язык. Ну, например, в русском есть идиома "быть на седьмом небе". В английском языке тоже есть такая идиома, но звучать она будет по-другому -- to be on cloud nine.

Так уж случилось, что в интернациональных командах очень часто члены команды имеют классный английский (как нейтивы, так и не-нейтивы), а, значит, их речь наполнена всем: фразовыми глаголами, идиомами, сленгом и т.п.

Приветствую всех читателей Хабра!

Меня зовут Денис, RTE в компании «Автомакон». На данный момент работаю в направлении «Фулстек» на проекте «ВкусВилл».

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

Привет, друзья! Сегодня у меня важный день — я решила приступить к писательскому труду. Не обещаю стать активной, как многие тут, но, кажется, у меня есть, что сказать, особенно тем, кто только начинает свой путь в области управления проектами, будь то Project Manager, Scrum Master или просто руководитель, которому не все равно на свою команду, и кто хочет узнать что‑то новенькое о нематериальной мотивации.

Первая тема, моей статьи возможно нестандартная и казалось бы весьма недооценённая, назову ее так: Тет‑а-теты: Как общение с командой делает проекты крутыми?! В мире управления проектами одно из тайных оружий не всегда выходит за рамки обычного «Привет, как дела?». Это — теты, разговоры, которые поднимают общение в команде на новый уровень. Вам не кажется, что иногда общение в проекте — как танец на клавишах: непредсказуемо и иногда несуразно? Так вот, тет‑а-теты — это ваша тайная кнопка для оживления ваших проектных мелодий.

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

На связи Мария Болдырева — руководитель проектов в IT-компании Outlines Tech. Управляю командами 7 лет, среди которых 4 года — в IT. За это время повидала всякое: от стартапов до корпораций, и в статье делюсь своим опытом. 

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

Многие скажут, мол показатель качества менеджера — это результат его самой команды и подразделения. Хороший показатель вроде бы! Но как оценить вклад и работу самого менеджера? Ведь не редкие случаи, когда повезло, сложились обстоятельства, или команда сильная и самоорганизованная, а лучшая заслуга менеджера — это что не мешал им работать. Или же обратная ситуация, когда всё плохо, все возможные форс‑мажоры случились, команда вышла из этого положения с отрицательными показателями. Но только при при грамотной и хорошей работе менеджера ущерб получился минимальным: он как капитан в шторм провёл корабль через рифы, не потопив судно на первой же скале. Тем не менее результат всё равно отрицательный.