Agile *

Мы продолжаем цикл публикаций о недостатках Аgile методологии. Сегодня перевод статьи о том, почему инженеры презирают Agile (много новых удивительных наблюдений!)

У всего хорошего есть и плохое. Почему разработка программного обеспечения по методике Agile не решит все ваши проблемы.

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

Привет, меня зовут Оля, я Head of Processes&Practices, занимаюсь продуктовой трансформацией в inDriver. Сейчас у нас активная продуктовая и инженерная культура, система OKR, масштабное продуктовое планирование и смелые планы на будущее. Но так было не всегда. И в этой статье я расскажу о тех вызовах, с которыми мы столкнулись в процессе трансформации и о том, чего уже удалось достичь.

Всем привет. Меня зовут Даша Викторова, я Project Lead направления Outbound, которое отвечает за автоматизацию доставки в Lamoda. Сегодня поговорим про проектный менеджмент… Но не совсем :) 

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

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

Привет!

В следующую среду мы проведем митап для скрам-мастеров и тех, кому интересна эта сфера. Митап будет гибридный — классическая онлайн-трансляция (надо зарегистрироваться заранее) и не менее классический, но подзабытый офлайн-формат, в нашем офисе на Технопарке.

Начало в 19.00 МСК.

Всем привет! В прошлый раз я, как Product Owner клиентского мобильного приложения Первой грузовой компании (ПГК), рассказала о формировании нашей продуктовой команды. Спасибо всем, кто оставил комментарии под текстом. Благодаря вашим сообщениям появился этот материал. Сегодня поделюсь с вами опытом, как мы сформировали матрицу компетенций, и как коллеги развивали свои скилы во время прототипирования и проектирования сервиса.

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

Как собирали команду

Мы пригласили в команду представителей разных сфер бизнеса. В нее вошли коммерческие специалисты (продажи) – люди, непосредственно работающие с клиентами, принимающие их заявки и понимающие, что им нужно. Они — «первая линия» по сбору обратной связи о некачественных вагонах. Еще позвали представителей вагонного блока – тех, кто отвечает за ремонт вагонов, специалистов движенческого блока, оформляющих документы на отправку вагона в депо, и ИТ-экспертов, которые воплощают в жизнь пожелания бизнеса и клиентов. Отмечу, что мы выбирали и профильных специалистов, и руководителей.

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

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

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

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

Сегодня перезагрузка процессов с помощью методологии гибкого управления проектами в М.Видео-Эльдорадо находится в руках двух опытных agile-коучей – Сергея Артюхова – выходца из Сбера, где он участвовал в глобальной трансформации финансового конгломерата и Антона Чижова – также экс-члена команды Сбера, ранее работавшего scrum-мастером в X5 и МТС. В М.Видео-Эльдорадо Сергей руководит Центром компетенций Agile, Антон – направлением Agile.

Мы попросили коллег углубиться в тему роли Agile-коуча и ответить на вопрос, как его найти или даже вырастить (здесь и далее повествование ведется от двух лиц, представьте, что вы читаете произведение Ильфа и Петрова только на IT-лад).

Привет, Хабр! Меня зовут Олег Сало, я ведущий архитектор MTS Digital в центре IT-продуктов клиентского опыта B2C. Уже достаточно давно я занимаюсь разработкой и проектированием корпоративных информационных систем, в основном в области  CRM и Customer Experience.

В больших компаниях архитектура любого уровня (Enterprise/Solution/Application) - всегда предмет горячих споров и обсуждений, как минимум потому, что каждое архитектурное решение затрагивает большое количество команд. И с мнением каждой команды нужно считаться, иначе вероятность превратить архитектуру в работающее решение стремится к нулю.

Сегодня я бы хотел рассказать про такую интересную технику, как Active Design Review, как мы ее попробовали применить у нас в компании и что из этого вышло.

Это история о том, как андроид-разработчик попал из домашнего комфорта в крупную компанию, где сотрудников больше, чем столов

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

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

Любое серьёзное преобразование в компании, от «внедрения» какого-либо нового ИТ-процесса до пресловутой цифровой трансформации, является организационным изменением: требуется изменить уже имеющиеся системы управления, чтобы они стали работать по-новому, или обрели новые свойства и способности. Приходится работать с формальной стороной (регламенты), культурной стороной (как у нас принято делать дела), технической составляющей, политической и так далее. Это — очень интересная работа, проводить организационные изменения в средних и крупных компаниях.

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

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

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

Практический опыт применения Референсной архитектуры в крупном swap-проекте для мобильного оператора связи.

Привет, мы - Agile коучи МегаФона и эта статья посвящена разбору тех трудностей, с которыми мы столкнулись, развивая самоорганизующиеся сообщества в нашей и не только компании. Надеемся, что наш опыт и выводы, которые мы сделали, будут полезны как тем, кто только вступает в ряды Scrum мастеров и коучей, так и более опытным коллегам.

Привет! Меня зовут Илья, я разработчик и по совместительству скрам-мастер в B2B-команде Авито Автотека. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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