Agile *

Откуда берется технический долг

• Все начинается со слов: «Давайте сделаем MVP (MLP) поскорее.» Когда ставится задача «срезать углы», чтобы запуститься побыстрее. В стартапах такое случается постоянно, даже у нас после 8 лет.
• Еще есть COBOL и FORTRAN.
• Каждая компания тянет за собой технический долг не только в виде кода, но еще и в виде инженерных практик («У нас так принято»).
• Аутсорсинг и аутстаффинг. Многие аутсорсинговые компании накопили некоторое количество «внутренних библиотек». Если у библиотек нет официального саппорта — это потенциальная проблема.

Я всегда хотел заниматься программированием, но мой путь в IT оказался очень длинным. В маленьком северном городе сфера IT была не развита от слова «совсем» и выбор был сделан в пользу военной карьеры. Так пронеслись 15 лет службы на Севере. Я понимал, что жду пенсии, чтобы заняться по-настоящему любимым делом. Поэтому за 5 лет перед увольнением стал готовиться к «новой жизни», самостоятельно учиться языкам программирования.

Тогда я просто верил, что смогу в свои «около 40» лет измениться и найти работу своей мечты. Но настоящие испытания были еще впереди…

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

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

Кент Бек сделал для IT столько, что его имя упоминается на Хабре в сотнях разных постов. Но при этом до сих пор не было хабрапоста о нём самом. Исправим это упущение.

Во вторник Кент выступит на нашей онлайн-конференции по тестированию Heisenbug. Там этот человек, когда-то популяризовавший подход TDD, поговорит о куда более новой концепции TCR («Test && Commit || Revert»). То есть даже к 60 годам он не стал жить былыми заслугами, а продолжает предлагать новое.

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

Антон работает тимлидом в продуктовой компании. Его команда разрабатывает информационно-аналитическую систему для бизнеса и госкомпаний. В проекте много хаоса, команда ничего не успевает, и Антон предлагает внедрить Scrum. Он сталкивается с непониманием процессов в высшем руководстве и чрезмерной нагрузкой на команду. От Скрам остается часть ритуалов, Антон с трудом «вытягивает» проект и уходит из компании. Разберем по пунктам, почему Scrum может провалиться. 

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

В проектах, где работа идет на поток, а все процессы отлажены, Scrum только мешает. Например, компания выпускает лендинги для бизнеса. Опытный менеджер согласовывает все вопросы с заказчиком, передает дизайнеру понятное ТЗ. Заказчик выдает правки и принимает работу. Дизайнер в спокойном темпе делает по 10-15 лендингов в месяц. 

Привет!

Меня зовут Тимофей, и я продуктовый разработчик. О продуктовой разработке подробнее можно почитать тут. 

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

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

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

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

Мы продолжаем цикл публикаций о недостатках А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, как мы ее попробовали применить у нас в компании и что из этого вышло.

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

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

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

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

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

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

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