Agile *

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

За 2,5 года работы в этой компании я поработала ещё и в роли переводчика, помощника руководителя, event-менеджера (начиная от организации участия компании в выставках и заканчивая корпоративами коллектива) и даже работником отдела кадров. Что и говорить, уровень зарплат в городе был такой, что приходилось быть и швецом, и жнецом и на дуде игрецом.

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

За два с половиной года я успела поработать в бюро переводов и в международной компании-автопроизводителе, но продолжала «искать себя». Стоило бы обновить резюме, но другая международная, теперь уже IT, компания опередила меня, пригласив на интервью на роль администратора проектов, и я приняла оффер.

Первые два года я вникала в особенности работы в IT сфере, занимаясь при этом в основном финансовым планированием проектов и разными отчетностями. Нагрузка увеличивалась, наш отдел рос и развивался, появлялись новые проекты, и я часто стала задерживаться в офисе. Сначала на часик, а через какое-то время я поняла, что уезжаю из офиса не раньше 22:00, учитывая начало рабочего дня в 9:30. То есть я совершенно точно не справляюсь с нагрузкой и мне перестало нравиться то, чем я занималась. В тот момент я начала обдумывать варианты развития в компании, где активно практикуется Agile и применяется Scrum.

Моё знакомоство с предметметно-ориентированным проектированием началось не совсем книги, а конференций 2019 года. Встречи с коллегами на AgileDays 2019, DDDevotion, DotNext, ArchDays позволили ясно увидеть два лагеря: не многих у кого DDD заработал, и многих кто хотел, но не взлетает. Это натолкнуло на длинные рассуждения, что DDD применим только при определённых производственных отношениях, а команды должны эффективно обучаться и применять на практике DDD.

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

В интернете есть уже тысячи споров о том, чем является DevOps. Мы решили подойти иначе: не навязывать вам точку зрения «понимайте это слово так-то», а оглянуться в прошлое и проследить историю его возникновения. Что привело к появлению DevOps? Какие люди первыми стали употреблять это слово и что они под ним подразумевали? Что изменилось за это время, а что осталось неизменным? И что там дальше?

А разобравшись со всем этим, в итоге можно обнаружить, что теперь и на вопрос «что такое DevOps» отвечаешь себе более четко.

Корпоративная (пред)история

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

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

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

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

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

Привет! На экране перед тобой снова текст за авторством ребят из Hays — а значит, мы опять делимся своей экспертизой в мире IT-вакансий. Сегодня мы рассказываем о профессии R&D Engineer в IT. Разбираемся, чем они занимаются и куда двигаются по карьерной лестнице дальше.

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

Меня зовут Константин Морозов (morozovvtbl), и я руководитель управления развития информационных систем — то есть отвечаю за всю разработку в ВТБ Лизинге, а также лидирую Agile-трансформацию в компании. Под катом я расскажу о том, как мы внедрили гибкую разработку в крупную компанию консервативного толка.

Операция под кодовым названием «Т», или как мы дали каждой команде по кластеру и вышли в прод за 6 месяцев.

Спор «фуллстек против узкой специализации» вечный. Но одно дело — спорить в комментах, а совсем другое — создать собственную компанию и проверить экстремальный подход на практике. Антон Кекс пошел по этому пути: стал сооснователем компании Codeborne, где разработкой занимаются исключительно «фуллстек-крафтсмены» и практикуется экстремальное программирование. И по его словам, там командами из 2-4 человек получается сделать то, на что другим требуется человек 50.

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

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

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

Эпоха до Agile

Привет. Меня зовут Саша Бородкин, я занимаюсь разработкой бэкенда в «Открытии». В прошлом году я стал частью первого Agile-трайба, который создали в нашем банке.

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

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

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

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

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

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

Привет, Хабр! Меня зовут Вадим Кузенков, я руковожу проектным офисом и работаю с командами в компании KODE. За плечами — 18 лет опыта в управлении проектами.

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

Чем он может быть полезен? Вы сможете проверить свою осознанность, начать строить мост над пропастью между теорией и практикой, возможно — избавиться от стереотипов. Материал прежде всего ориентирован на джунов в PM, но будет полезен и другим IT-специалистам. Развеем миф, что попугая можно повысить до PM, если научить его говорить «Ну что там?»

Привет, Хабр! Меня зовут Андрей Ревяшко, я СТО сети Эльдорадо. Мы регулярно встречаемся с командой и обсуждаем различные окологиковские темы. Совсем недавно мы говорили про психотипы членов команды разработки и их влияние на общий результат. Поделюсь этим материалом и с вами. Уверен, что часть из вас точно возьмет его на вооружение.

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

Всем привет!

Статей на Хабр я раньше не писал и поэтому расскажу немного о себе.

ТТХ автора:

               Имя                     - Андрей;

               Возраст              - 25 лет;

               Опыт работы    - мог бы быть и побольше.

Моя «стремительная» карьера разработчика началась в далёком 2019 году и за это время я успел поработать в двух компаниях. О первой компании скажу, что это был отличный опыт в отличной компании и я многому там научился. А сегодня я работаю разработчиком в блоке развития и поддержки Автоматизированной Банковской Системы (АБС) в РСХБ-Интех, чему я очень рад.

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

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

Контекст проекта и немного введения

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

Наша команда состояла из Data Science и Computer Vision специалистов, было несколько QA, один Frontend Developer и один Backend Developer. Я выступал в роли Project Manager.

Когда я только приступил к работе над проектом, там не было никакой документации, плана, отчетности и т.д. Все делалось на словах, что-то немного трекалось в Trello, это был тот еще хаос. 

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

Этап 1. Начало внедрения Agile.

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

В интернете я наткнулся на целую кучу различных статей о том, как выстраивать процессы в DS, но у всех были разные мнения: кто-то советовал Kanban, кто-то Scrum, кто-то описывал свои методики, но ничего общего я не нашел, не было ничего, что можно применить к любому проекту такого рода. Однако, самым ценным было знакомство с концепцией CRISP-DM.

Меня зовут Ольга Умнова, я — Product Owner (владелец продукта) железнодорожного оператора Первой грузовой компании (ПГК). Мы создаем такие IT-продукты, которых на нашем рынке еще нет. Разработчики ПГК — первопроходцы в своем деле. Сегодня я расскажу вам, как формировалась и работала команда, которая создала один из флагманских проектов компании — приложение «Мобильный репортер» для контроля коммерческого состояния крытых вагонов. Этот продукт мы называем Instagram для грузовых вагонов.

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