Agile *

Современное развитие в области встроенной разработки и электроники с учётом бизнес-процессов ускоряется, часто следуя принципам 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. За это время повидала всякое: от стартапов до корпораций, и в статье делюсь своим опытом. 

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

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

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

Зачем проводить ретроспективы с командой? 

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

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

2. Вовлечение команды: с участие членов команды в процессе принятия решений  дает им новые возможности и увеличивает их чувство владения проектом.

3. Решение проблем: выявление проблем и препятствий своевременно не позволяет им расти и сорвать проект.

Инструменты для ретро

Подготовка и проведение эффективных ретроспектив требует некоторых важных инструментов и методов:

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

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

Итак, проблема, которую мы будем решать — это отсутствие процесса работы с бэклогом и сквозной приоритизацией. Важно отметить, что инструменты, которыми я буду в основном оперировать, — это jira инсталляции server, плагин jira structure, jira kanban. Если реализация возможна на других инструментах, я буду в явном виде на них ссылаться. Но думаю, что в том или ином виде, подход можно переиспользовать и для других тикетных систем.