Основал компанию byndyusoft
Веду блог, автор книги «Антихрупкость в IT» и методики «Карта гипотез».
Как я помогаю компаниям
Расскажу о новом методе стратегического планирования. Много лет я смотрел, как другие делают Impact Map, сам его делал для своих проектов и проектов заказчиков. В итоге, пересобрал этот метод в новый, чтобы можно было точнее определять причинно-следственные связи между бизнес-целями, задачами и гипотезами достижения целей. Назвал этот метод “Карта гипотез”.
Если на переменах вы больше зарабатываете, чем теряете, вам будет хотеться перемен. В мире, где всё быстро меняется, где конкуренция возвышает одни компании и уничтожает другие, нужно выстраивать работу так, чтобы перемены приносили пользу, а не разрушения.
В докладе поразмышляем как выстроить процессы работы, архитектуру IT-систем и взаимодействия людей, чтобы придать IT-продуктам свойства антихрупкости.
Интервью провел Алексей Пименов из компании Neogenda в рамках рубрики «Нетипичные вопросы профессионалам».
Как IT компания эффективно работает без проджект-менеджеров? Чего хотят заказчики? Сколько стоит разработка ПО? Про антихрупкость в IT, продажу разработчиков - об этом и не только в видео.
Ссылки, которые упоминаются в видео:
Мы в компании активно используем low-code платформы много лет. За время работы набрался опыт в преодолении проблем, связанных с этими платформами, и кристаллизовались подходы, которые хорошо себя показали.
Я разобрал, что в low-code подходе помогает бизнесу, а что создаёт сложности. При рассмотрении проблем я предложил «лекарства», которые помогают нивелировать проблемы.
Читайте по ссылке статью с подробным раскрытием этой темы.
Алексей Пикулев пригласил меня в качестве эксперта на мастер-класс по Impact Mapping. Онлайн-встреча прошла в рамках его сообщества Scrum Mastery Club.
Я уже много лет работаю с этим инструментом, подробно описывал его в своей книге Антихрупкость в IT, поэтому мне было чем поделиться с участниками встречи.
Читайте по ссылке как создается Impact Map.
В идеальном мире можно просто взять исходный код монолита, разделить его код между микросервисами и, соединив их между собой, получить ту же систему, но на новой архитектуре. В жизни так не происходит никогда. Жизнь вносит множество сложностей в эту идеальную картинку. Какие конкретно сложности могут увеличить бюджет перехода на микросервисы в два-три раза?
Я опишу факторы, которые затягивают процесс перехода на микросервисы и делают его сильно дороже, чем ожидалось вначале. Вы получите чеклист для оценки этих факторов и будете более реалистично считать бюджет перехода.
InnerSourcing и микросервисы дополняют друг друга и одновременно повышают порог вхождения новичков в эту тему. Я расскажу с точки зрения IT-архитектора и организатора процесса разработки:
Продуктовый подход описан в книгах давно, но только недавно крупные российские компании начали на него переходить.
При новом подходе IT-продукт создается внутренней кросс-функциональной командой, а процесс основывается на метриках, “гибкой” культуре, машинном обучении и постоянных поставках новых фич. Это подход позволяет бизнесу не просто держаться на плаву, а создавать инструменты для конкурентной борьбы за доли рынка.
Обсудим почему компании больше не хотят писать ТЗ для проекта, разбивать ТЗ на части, раздавать отделам и аутсорсерам. Расскажу, как создаются продуктовые команды в аусторсе, какие качества отличают крутых Product Owner'ов от посредственных и какие инструменты и подходы стоит применять уже сейчас.
Статистика популярности языков программирования:
Отчет IT Market Clock for Programming Languages: жизненный цикл языков
Идея микросервисов звучит красиво, пока вы не создадите десятки и сотни микросервисов. Раньше приложение запускалось на одном мощном сервере и работало на одной СУБД, а теперь надо управлять сотней микросервисов, которые связаны между собой паутиной API вызовов и шин сообщений. Разработка, выпуск релизов, тестирование, соблюдение версионности превратятся в кошмар, если не использовать правильные подходы и инструменты.
В докладе будут показаны инструменты и принципы, которые помогают облегчить создание и управление микросервисной архитектурой. Рассмотрим пример переезда конкурса «Мисс Россия» на Azure, где инфраструктура развернута кликами мышкой на чистом PaaS, а за счет изменения архитектуры сайт выдерживает в 40 раз больше посетителей без увеличения бюджета на серверные мощности.
Тема перехода на микросервисную архитектуру стала одной из самых горячих на конференциях по архитектуре ПО. Заказчики и разработчики захотели раздробить монолитные приложения на множество маленьких сервисов, чтобы увеличить скорость доставки релизов до пользователей, разделить ответственность команд, уменьшить взаимозависимость бизнес-функций приложения и использовать горизонтальное масштабирование вместо вертикального.
Идея микросервисов звучит красиво, пока вы не создадите десятки и сотни микросервисов. Раньше приложение запускалось на одном мощном сервере и работало на одной СУБД, а теперь надо управлять сотней микросервисов, которые связаны между собой паутиной API вызовов и шин сообщений. Разработка, выпуск релизов, тестирование, соблюдение версионности превратяться в кошмар, если не использовать правильные подходы и инструменты. В докладе покажу инструменты, которые помогают облегчить создание и управление с микросервисной архитектурой.
Для создания ПО мы выбрали эмпирический подход и почти отказались от детерминистского. Опыт показывает, что нельзя просто взять и описать большой продукт в ТЗ, а потом реализовать его по описанию. Жизнь оказывается всегда шире, чем наше представление о ней. С другой стороны, эмпирический подход отражает постоянное углубление нашего понимания предметной области, бизнеса заказчика и изменений на рынке по мере создания и совершенствования продукта.
Делать задачи, которые приносят прибыль, и не делать задачи, которые прибыль не приносят — естественное желание. Но, когда мы не погружаемся в планирование и кодирование, возникает вопрос — как отделить первые задачи от вторых? Что мешает нам увидеть разницу и что помогает?
Расскажу о подходе, которым мы стартуем каждый проект. С помощью Impact Mapping синхронизируем с заказчиком видение продукта и пути достижения успеха.
Типовые проекты, где в центре системы стоит реляционная БД, перестают удовлетворять современным требованиям рынка ПО. В норму входит использование очередей, поисковых движков, NoSQL решений, облачных технологий. Всё это требует перехода от «классической» архитектуры к дроблению системы на набор низкосвязанных компонентов, взаимодействующих друг с другом через сообщения или интерфейсы.
Корпоративные системы состоят из множества подсистем, которые написаны на разных языках и платформах. Используются общие БД, репликации, обмен сообщениями и другие средства интеграции.
Мы рассмотрим шаблоны и инструменты интеграции, которые сейчас есть на платформе .NET для реализации взаимодействия различных систем.
Принцип Command Query Responsibility Segregation (CQRS) довольно давно был описан, но не так давно оброс примерами реализаций и готовыми фреймворками с открытым исходным кодом.
Какие проблемы и решения возникают при применении CQRS? Я рассмотрю ряд вопросов, всплывающих в реальных проектах, покажу, где появляются возможности по масштабированию и построению гибких решений.
Scrum, XP и Kanban — это всего лишь инструменты и мы можем затачивать их под себя в зависимости от реалий проекта. Я буду вычеркивать и комбинировать практики из разных методологий в зависимости от типа проектов и стадии работы.
У меня всё меньше времени на преподавание, поэтому я вижу ценность в выкладывании записи лекций. Возможно в ближайшие годы я вообще перестану ходить в университет. Ниже две части одной лекции, где мы общаемся на тему Agile. Там есть про манифест, отношения между заказчиками и исполнителями и истории из жизни.
Подробнее в статье в моем блоге.
У меня всё меньше времени на преподавание, поэтому я вижу ценность в выкладывании записи лекций. Возможно в ближайшие годы я вообще перестану ходить в университет. Ниже две части одной лекции, где мы общаемся на тему Lean Software Development. Обсуждаем историю и причины возникновения, ценности и принципы.
Самая эффективная команда та, в которой каждый участник имеет правильную жизненную позицию. Команда в данном случае — это участники процесса создания программного продукта, т.е. программисты, руководители и заказчик. Сразу такую команду не создать, нужен инструмент. Agile — это «инструмент» создания такой команды.
Мы рассмотрим влияние ценностей и практик на успешность команды, а также границы применимости Agile.
В этом видео я разрабатываю приложение с помощью TDD на языке C#. Кроме демонстрации того, как надо писать модульные тесты, я постарался показать, как работает TDD на уровне приложения в целом.
При разработке применил принцип инверсии зависимости, а также использовал IoC-контейнер.
Подробности в статье TDD для начинающих. Ответы на популярные вопросы.
Я рассмотрел, как эволюционировал подход к управлению зависимостями в коде. Какие проблемы возникали на каждом этапе и как эти проблемы решались. Возможно на каком-то этапе вы узнаете свой проект и поймете куда двигаться дальше.
Основные темы:Перед этим видео желательно посмотреть пример разработки приложения с помощью TDD.
Цикл статей о техническом задании:
Докладчик расскажет об опыте работе в найме, нескольких лет консультирования IT-компаний, а также ответит на следующие вопросы, исходя из своего опыта:
Прошлой осенью моя книга Антихрупкость в IT вышла в цифровой и аудио-версии, а в январе этого года книга появилась на Озоне в бумажном варианте. Я издал книгу самостоятельно при том, что в начале пути у меня не было опыта и знаний о том, как издаются книги.
В этой статье я опишу весь процесс издания книги: какие шаги нужно сделать, на что обратить внимание, какие подводные камни есть на этом пути.
Читать в блоге...Как достигать результатов в IT-проектах в условиях неопределённости
В моём понимании IT занимается обслуживанием бизнеса. Код пишется и макеты рисуются для того, чтобы компания быстрее и точнее конкурентов понимала и выполняла потребности своих клиентов. Для достижения этого результата следует понимать, какие инструменты работают, а какие мало применимы в мире постоянных перемен.
