Книгу я читал с большим интересном, потому что Илья Павличенко является одним из лучших экспертов в своей области:
Я был уверен, что ему есть что сказать по теме дизайна agile-организаций, и не ошибся.
Не мечта ли любого владельца компании управлять IT-продуктом так, чтобы поставлять продукт в срок, обгоняя конкурентов, и делать это с высоким качеством, радуя пользователей? Хотелось бы найти серебряную пулю для управления и, кажется, она есть. Не такая уж серебряная и не такая уж пуля, но довольно надежный и обкатанный годами подход к управлению, который можно назвать FFF: Fix Time and Budget, Flex Scope.
Почему и когда стоит выбрать FFF? Давайте посмотрим.
Прошло три года с момента моего выступления на AgileDays и Microsoft Dev School, где я рассказывал как бизнес использует микросервисы, чтобы ускорять поставки. С тех пор я запустил с десяток больших проектов в Byndyusoft на микросервисах в качестве IT-архитектора и убедился, что микросервисы в хороших руках могут дать бизнесу гибкость в выборе направления развития и развязывать ограничения, которые раньше создавал монолит. Ниже видео и слайды с выступлений.
Манифест гибкой разработки ПО ставит во главу угла достижение бизнес-ценности, отбрасывая и уменьшая значимость всего, что к бизнес-ценности не приближает. В этом смысле традиционное детальное техническое задание, подписанное заказчиком и исполнителем, часто является причиной потерь.
Этой весной я выступал на Codefest в Новосибирске. Рассказывал, как перейти от проектного мышления к продуктовому. После доклада меня позвали дать интервью, где я рассказал о переходе от проектного мышления к продуктовому, кросс-функциональных командах и о том, где взять крутого Product Owner'а.
В офис Byndyusoft в Челябинске снова пришли ребята с канала Бизнес в стиле диджитал. В прошлый раз мы общались на тему устройства компании, собеседования сотрудников и IT-архитектуры.
Темы из интервью:
В середине марта я выступал на 10-й глобальной конференции по гибкому управлению процессами — AgileDays 2016. Уже по традиции AgileDays проходила в Москве в Центре международной торговли, куда собрались 1200 участников.
В начале осени мы описали как работаем, как создаем IT-продукты с нуля. Статью про пять самых важных составляющих процесса выпуска успешных проектов писали целый месяц вместе с Андреем Шапиро, плюс было несколько рецензентов, среди которых наши заказчики. На Цукерберг Позвонит статья собрала 15 000+ просмотров, после публикации мы получили поток вопросов и увидели огромный интерес к теме.
Стало понятно, что надо рассказывать про наш подход, поэтому осенью мы сделали два выступления — одно на осенней .NETconf, другое на HappyDev 2015. Ниже видео и слайды с выступлений по этой теме.
Для создания ПО мы выбрали эмпирический подход и почти отказались от детерминистского. Опыт показывает, что нельзя просто взять и описать большой продукт в ТЗ, а потом реализовать его по описанию. Жизнь оказывается всегда шире, чем наше представление о ней. С другой стороны, эмпирический подход отражает постоянное углубление нашего понимания предметной области, бизнеса заказчика и изменений на рынке по мере создания и совершенствования продукта.
Stand-up meeting, Daily Scrum Meeting или просто планёрки стали привычной практикой в IT. Я описывал различные нюансы стендапов ещё 5 лет назад в статье Stand-up meeting: лучшие и худшие практики. Казалось бы, техника проведения стендапов уже рассмотрена со всех сторон. Что в планёрке может быть сложного? Но совсем недавно наша компания начала практиковать несколько другой подход, с помощью которого мы ускорили выход задач в релиз.
Всё началось, когда летом 2014 года в Москве мы с Асхатом шли на тренинг и он обратил моё внимание на разницу между стендапами в Scrum и Kanban. До этого я не придавал особого значения таким нюансам. У нас в компании для части проектов используется Kanban, но стиль стендапов остался от Scrum'а.
Сейчас мы поменяли подход к стендапам, об этом я расскажу дальше, покажу разницу между тем, что было и тем, что стало. В конце статьи есть ссылки для более глубокого погружения в тему с описанием разных мнений и нюансов.
Одна из ключевых практик в Kanban — это визуализация работы: «You cannot improve what you cannot see». Следующие три подхода нацелены на визуализацию целей проекта, задач и текущего процесса.
Часто разработчики говорят мне, что soft skills им не нужны. Разработчик — не менеджер и управленческие навыки может не развивать. С одной стороны так и есть — разработчику очень важно углублять свои знания в технологиях и методологиях проектирования ПО. С другой стоны, я уверен, каждому хочется уметь отстаивать свою позицию и получать заслуженную похвалу за хорошую работу. А если так, то почему бы не продвинуться в этом направлении?
В этой статье я собрал техники и подходы, которые помогают мне в повседневной работе наносить непоправимую пользу заказчику и самому оставаться с позитивным настроем. Предлагаю их вам на пробу и надеюсь для вас они будут также полезны как и для меня.
Материала получилось довольно много, поэтому каждый раздел выйдет отдельной статьей:
Под «заказчиком» я имею ввиду любые отношения заказчик-исполнитель, где вы являетесь исполнителем. Заказчиками могут быть пользователи вашего продукта, может быть Project Manager, может быть совет директоров, может быть бухгалтер из соседнего отдела и т.д.
Всё, о чём будет идти речь, точно сработает, если вы действительно хорошо сделали свою работу. Мы не будем рассматривать случаи, когда качество работы низкое и стоит задача убедить заказчика в обратном.
Когда читал книгу Impact Mapping первый раз, у меня было желание бросить её на середине. Всё, что там написано, слишком очевидно. Я нашел в себе силы и дочитал, благо книга коротная и с большими картинками. Как в последствии выяснилось, вся соль была в том, что все эти очевидные и простые практики из книги я не применял в своей работе.
Иногда заказчики писали свои цели в официальных документах к проекту. Иногда мне казалось, что я и так понимаю цели заказчика — они абсолютно очевидны. К чему уточнять очевидное? Разницу я почувствовал, когда начал применять Impact Mapping в работе.
Смотрите видео с мастер-класса по Impact Mapping
У меня есть увлечение - я собираю разные манифесты и призывы из мира IT. На данный момент собрал уже достаточно много, поэтому решил опубликовать их с моими комментариями.
В статье описаны:
Немного предыстории как я попал в Казань с докладом про Lean.
Месяц назад я был в Ульяновске на ulcamp 2013. Это уникальная конференция под открытым небом с палатками. Два дня мы купались в Волге, загорали и ходили от доклада к докладу. Я неожиданно для себя выступил с докладом про Domain Driven Design. Чтобы прочувствовать формат конференции, посмотрите на "площадку" моего выступления:
Разработка ПО - это процесс создания знания. Общая идея продукта, прототипы дизайна и концепция архитекутры могут появиться до начала разработки, но их правильность или неправильность будет проверена только в ходе работы над проектом.
Сегодня прошел семинар для студентов ЮУрГУ, который я недавно анонсировал. Ниже я выкладываю слайды и некоторые комментарии по выступлению.
27 февраля 2013 с 11.30 до 13.30
ЮУрГУ, ауд. 205/3г
Вход бесплатный
На семинаре я рассмотрю две темы, которые я считаю актуальными и полезными для студентов.
Первая - вопросы, которые касаются будущей карьеры. Студенты должны отлично представлять какие первые шаги нужно сделать, чтобы стать успешными в IT.
Вторая - что сейчас происходит в сфере разработки ПО в целом? Какие вещи являются модными? Что используют? От чего отказываются?
Открыта регистрация на 5-ю конференцию .NET разработчиков.
Дата проведения — 21 октября 2012
Место проведения: г. Челябинск, Смолинопарк, Конференц-зал X.O.
Вход бесплатный после регистрации.
Регистрация на сайте http://www.dotnetconf.ru/Registration
Парное программирование является одной из практик XP. Эта практика воплощает экстремальную (преувеличенную) идею Code Review. Если ревью позволяет улучшить качество кода, то давайте делать его постоянно, во время рефакторинга и написания нового кода.