Введение в RUP (The Rational Unified Process. An Introduction) (Рубрика #Management)

Эта книга Филиппа Крачтена (Philippe Kruchten) посвящена процессу разработки, который в конце девяностых и начале двухтысячных претендовал на то, чтобы стать стандартом де-факто в разработке софта. Это был уже не waterfall, который все трактуют упрощенно и предпочитают блеймить рассказывая про отсутствие итераций и обратной связи (что в общем виде неверно). В этой книге 2001 года выпуска автор дает следующие советы по организации производственных процессов (которые актуальны и сейчас)
1. Разрабатывайте итеративно - автор пинает waterfall, дальше вспоминает про спиральную модель Барри Боема, а потом предлагает итеративный процесс, в результате каждой итерации которого создается релизная версия. Внутри итерации по стандарту есть планирование, управление требованиями, анализ и проектирование, реализация, распространение, тестирование и оценка.
2. Управляйте требованиями - под требованием тут понимается условие или характеристика, которой должна соответствовать система. И автор предлагает активно работать с функциональными и нефункциональными требованиями, а также ограничениями системы. Нам надо уметь документировать требования и отслеживать их влияние на систему и принимаемые решения и компромиссы.
3. Пользуйтесь модульными архитектурами - автор рекомендует использовать модульную архитектуру, которая способствует эластичности, распределению ответственности, использованию стандартизированных компонентов и визуальному моделированию.
4. Используйте визуальное моделирование - здесь автор говорит про важность моделирования и вспоминает UML (unified model language) - унифицированный язык моделирования, на который было много надежд в те времена. Сейчас многие тоже хотят визуально моделировать, но уже используют для этого другие нотации и подходы (C4 Model, ArchiMate, SysML, 4+1, ...). Кстати, именно модель "4+1" и рекомендовалась внутри RUP как процесс, основанный на архитектуре. Суть в том, что у нас были 5 представлений: logical, process, development, physical, scenarios. Причем сценарное представление основанно на сценариях пользователей и объединяет остальные представления.
5. Не забывайте о проверке качества - про важность автоматизированного тестирования и поиск багов на ранних стадиях разработки софта. Сейчас это называется shift-left testing:)
6. Следите за изменениями - здесь автор говорит про повторяемость процесса изменений софта. Сейчас мы добиваемся этого при помощи выстроенного процесса CI/CD (continuous integration / continuous delivery).
Интересно, что рекомендации не устарели за прошедшее время и даже стали гораздо четче + появилась крутая инструментализация:)

Дальше автор рассказывает про четыре функции разработки софта и показывает, что все эти функции реализуются внутри RUP и основаны на 6 советах, приведенных выше
1. Обеспечивать руководство последовательностью действий команды
2. Определять, какие артефакты должны создаваться и когда
3. Указывать, чем должны заниматься отдельные разработчики и целые команды
4. Предлагать критерии наблюдения и измерения продуктов и видов деятельности.

А дальше в книге автор подробно разбирает как устроен RUP и как его использовать для того, чтобы выстроить процесс разработки.

P.S.
Филипп Крачтен, автор книги, - очень крутой специалист как по процессам, так и по software architecture. Он был директором по разработке процесса RUP внутри Rational до 2003 года, когда Rational был куплен IBM. В 2020 году получил Software Architecture Award от Carnegie Mellon University | Software Engineering Institute (вот его выступление про состояние software architecture, которое было приурочено к награждению)

P.P.S.
Помню как лет 17 назад я знакомился с этим процессом поближе, проходя тренинги и обучения в Luxoft. Меня впечатлил подход, когда ты мог собрать себе кастомный процесс из кубиков, что предоставлял RUP. Правда, уже тогда мне казалось это довольно сложной конструкцией:)

#SoftwareArchitecture #Architecture #Software #Management #Leadership

ChatGPT from Scratch: How to Train an Enterprise AI Assistant • Phil Winder • GOTO 2023 (Рубрика #AI)

Интересное выступление от Phil Winder, CEO компании Winder.AI и автора книги "Reinforcement Learning". В этом видео автор рассказывает базово про chatGPT и показывает забавную демку с файнтюнингом модели для написания лирики, а дальше эту созданную лирику зачитывает на фоне музыки, сгенерированной Stable Audio. Если же переходить к основному контенту, то
- Автор начинает с краткой истории LLM, где автор прослеживает эволюционный путь LLM от их рудиментарных форм до передовых архитектур, таких как GPT-4, и как это влияет на область обработки естественного языка (NLP).
- Дальше он рассказывает про базовую архитектуру и компоненты больших языковых моделей (encoder-decoder в трансформерах и дальше только декодер как в GPT)
- Потом речь идет про методы предварительной обработки наборов данных, специфичных для предметной области, которые приводят к созданию узкоспециализированного и эффективного LLM
- После этого доходит очередь до стратегий эффективного и экономичного обучения моделей: от тонкой настройки предварительно обученных моделей до обучения с нуля.
- Напоследок автор дает рекомендации по развертыванию для LLM, включая использование облачных сервисов, таких как AWS и Azure (и тут он показывает заодно демку)
- Ну и в финале приводятся соображения безопасности и этики при развертывании LLM в бизнес-среде, включая конфиденциальность данных и интерпретируемость модели.

#AI #ML #DataScience

Live-трансляция про слайдоцентричное мышление от Кирилла Анастасина и Вани Лукьянова (Рубрика #Speaking)

Сегодня автор комикаки (@komikaki), Кирилл Анастасин, обсудит с Ваней Лукьяновым тему про презентации, в которой поднимет вопросы
— Как мешают слайды готовить доклад?
— Роль слайдов в презентации?
— Как портит жизнь слайдоцентричное мышление в коллективе?
— Что главное в выступлении?

P.S.
Лет 5 назад я проходил обучение у Кирилла и оно помогло мне тогда улучшить публичные выступления. Обкатывал я подходы, готовясь к выступлению на ArchDays 2019, про что я рассказывал 5 лет назад.

#PublicSpeaking #SelfDevelopment

Neural correlates of interspecies perspective taking in the post-mortem Atlantic Salmon: an argument for multiple comparisons correction (Рубрика #Humor)

При изучении книги Дэвида Хэнда "Темные данные" ("Dark data. Why what you don't know matters") наткнулся на разбор этого whitepaper про проведение экспериментов над мозгом мертвого лосося. Этот эксперимент получил Шнобелевскую премию по нейробиологии и он был поставлен следующим образом:
- Мертвому лососю проводили МРТ-сканирование головного мозга
- Одновременно с этим показывали серию фотографий, изображающие людей в различных ситуациях
- А также просили испытуемого определить какие эмоции используют изображенные люди
- Фиксировали определение эмоций при помощи реакции, которая определялась как активность клеток мозга, видимая на вокселях (пикселях МРТ-изображения)
Оказалось, что несколько вокселей оказались активны. Авторы сделали открытие, что

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

Дэвид Хэнд, автор книги про темные данные, а также президент статистического общества и член Британской академии, вспоминает анекдот на эту тему

Экспериментатор А говорит экспериментатору Б, что у него большие проблемы с воспроизведением результатов, полученных Б. "Неудивительно, - отвечает тот, - ведь я тоже не смог получить их первые 100 раз, когда проводил эксперимент".

А для того, что эксперименты у нас в Тинькофф были защищены от такого мы и делаем внутри компании a/b платформу, про которую я уже рассказывал при публикации вакансии staff инженера в эту платформу. Также есть ряд книг, что полезны тем, кому нравится статистика и эксперименты и про которые я уже рассказывал раньше.
- Как лгать при помощи статистики (How to Lie with Statistics) - на пальцах объясняется как врут с помощью статистики, а отсюда становится ясна мотивация создания системы подведения итогов экспериментов
- Understanding Statistics and Experimental Design. How to Not Lie With Statistics (Статистика и планирование эксперимента для непосвященных) - в этой книге рассказывается про дизайн экспериментов и математику, что стоит за ними
- Доверительное a/b тестирование (Trustworthy Online Controlled Experiments) - а эта книга позволяет еще и понять как сделать платформу для проведения экспериментов на уровне всей компании

#Math #PopularScience #SelfDevelopment #Humor #Statistics

Вот так whitepaper про лосося и МРТ видится искусственному интеллекту:)

Как и зачем измерять инженерную продуктивность в крупной компании (Рубрика #Management)

Появилась запись моего выступления на MTS True Tech Day, где я рассказывал про инженерную продуктивность. Эта тема является важно для больших компаний, так как достаточно сложно понять насколько эффективно работает организация. Есть общие показатели на всю компанию, но они
— Показывают общую ситуацию в компании и сложно понять вклад отдельных частей организации
— Отображают уже достигнутые результаты причем с сильным лагом — это примерно соответствует тому, чтобы при управлении машиной смотреть не в лобовое стекло, а в зеркало заднего вида
В крупной технологической компании (а в Тинькофф порядка 10к инженеров) большой вклад в эффективность компании вносит эффективность работы инженеров, поэтому мы уделяем этому большое внимание.

Само выступление имело следующий план
- Затравка про важность этого вопроса (я ее уже тут рассказал ввыше)
- Как я предлагаю сузить границы рассмотрения только продуктовыми компаниями и частью delivery без discovery
- Какие подходы были в академической среде: DORA и Accelerate, SPACE, DevEx - тезисы со ссылками на материалы доступны здесь
- Как это делают в Bigtech, например, в Google используют подход QUANTS - тезисы доступны здесь
- Что есть на рынке в виде коммерческих платформ - тезисы и ссылки здесь
- Как это делаем мы в Тинькофф - тут я расскажу про наш инструмент T-Meter
- Ну и какие выводы из этого всего следуют

Расшифровка есть в статье в моем блоге, а также в виде pdf в этом канале.

P.S.
Так как мой доклад - это не питчинг раунда финансирования для стартапа, то я решил исключить часть про влияние AI на developer productivity, что тянет на отдельный доклад (который недавно как раз рассказывал VP of Product из GitHub)

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership

Выступление про архитектуру и проектирование на фестивале Т-Двор в Питере (Рубрика #Architecture)

Через неделю я еду в Питер, чтобы выступить на нашем фестивале Т-Двор, который будет с 6 по 9 июня. Последний день будет посвящен технологиям и профессиям будущего и именно там я расскажу кратко про то, как мы проектируем свои решения, которые должны работать надежно и масштабироваться под растущую нагрузку из-за увеличения количества клиентов (у нас их уже 42 млн), количества продуктов (их сложно посчитать), а также усложнение нашей экосистемы. Я расскажу про
- Использование RFC/ADR для описания крупных изменений и их ревью
- Фокус на использовании платформ и as a service решений внутри
- Подходы к architecture as a code, которые пока больше похожи на architecthure documentation as code, но на развитие которых у нас большие планы
- Расскажу про RnD подходы к архитектуре, которые пока у меня в голове или в лучшем случае в бэклоге, но по которым мы планируем сделать большой рывок в будущем

В общем, регистрируйтесь бесплатно и выбирайте 9 июня (там можно выбрать билет на один из четырех дней) и приходите на мое выступление:)

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #DistributedSystems #Management #Leadership

ЦЕХ 4 - Урок #8 "MS Word для работы с большими и сложными текстами. Эксперт — Юлия Потемкина" (Рубрика #Writing)

Перегруз на работе привел к тому, что я чуток выпал из курса по написанию книги, но теперь решил нагонять его. Начал с восьмого урока от Юлии про MS Word и его возможности. Чем-то этот комбайн (MS Word) меня пугает (возможно кучей опций по настройке), поэтому я сам обычно использую Google Docs в онлайн варианте. Но урок про Word было интересно. Кстати, предыдущие посты здесь: 1, 2, 3, 4, 5, 6 и 7. Основные мысли, что я вынес из урока такие:

- Word отлично подходит для работы с большими и сложными текстами
- Word напоминает сложную IDE (аля IntelliJ IDEA от JetBrains) для опытного разработчика, но только для опытного писателя/редактора
- Word можно подстроить под себя так, чтобы работать в нем было естественно. Настройки могут отличаться в зависимости от целевого режима - написание текста vs его редактирование
- Бэкапы наше все - Word делает автосейвы, но хорошо бы и самому их делать (для защиты от шифровальщика багов)
- Важно правильно использовать стили - это важно не только для визуала, но и для дальнейшего редактирования текста
- Важно не заморачиваться сильно с форматирование текста, линейными отступами, дефисами и так далее - все это при редактировании поедет
- Чем-то эта работа со стилями и in-place подкручиванием визуала напоминает веб с его CSS (cascading style sheets) и настройками отображения прямо в HTML
- Важно уметь пользоваться поиском и заменой по документу
- Есть специальные элементы в тексте, которые могут пригодиться: сноски, формулы, таблицы и иллюстрации. Если книгу предполагается отдавать в профессиональную печать, то эти элементы могут разъехатся, если сделаны в лоб
- Word позволяет выстроить процесс ревью, комментариев и предложений по редактированию прямо в документе. Это такой асинхронный коллаборативный формат работы. Чем-то напоминает Google Docs, но там это прямо в онлайне и при помощи CRDT (Conflict-free replicated data type):)
- Ну и напоследок стоит сказать, что в режиме написания книги нужно сделать так, чтобы интерфейс и шрифты поменьше отвлекали от самого письма, так что минимальный интерфейс и невычурные шрифты нам в помощь:)

#Writing #SelfDevelopment

Рулетка кейсов: Примеры плохой архитектуры (Рубрика #Architecture)

Появилась запись дискуссии с последней подлодки, куда я пришел поговорить про плохую архитектуру с организаторами, а также Ильей Зоновым и Кириллом Ветчинкиным.
Дискуссия была насыщенной и мы обсудили вопросы
- Что такое архитектура? Когда ее можно считать плохой, а когда хорошей (тут ключом была готовность к изменениям)
- Что такое универсальная архитектура и бывает ли она (нет)?
- А есть ли что-то за hype терминами и подходами (CQRS, GraphQL, микросервисы)?
- Как работать с базой данных и нужен ли ORM или нам поможет паттерн repository?
- Насколько реально мигрировать с одной базы на другую?
- Нужны ли стандарты, а также когда они мешают?
- Как появляется open source в компаниях и что иногда создание собственных инструментов может быть выгоднее, чем использование готовых решений.

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

P.S.
Спасибо организаторам, что подготовили ссылки на те ресурсы, что мы упоминали

1. Антипатерн «Golden Hammer»
2. Книга В. Хононов «Изучаем DDD. Предметно-ориентированное проектирование» и наш разбор ее в книжном кубе
3. Мой пост про «GraphQL: The Documentary»
4. Мой пост про «GraphQL. Язык запросов для современных веб-приложений»
5. Мой пост про «Adaptive Architectures • Marty Pitt • GOTO 2023»
6. Документация MongoDB. Query MongoDB — Web SDK
7. Олдовая статья «Клиент-сервер 2001»
8. Статья «Diplodoc — открытый набор инструментов для создания документации»
9. Мой пост про . Про документальный фильм про Kubernetes
10. Статья «How Discord Migrated Trillions of Messages to ScyllaDB»
11. Статья «Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%» и мой разбор

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #DistributedSystems #Management #Leadership

Корпоративный мессенджер Time

Мы в компании достаточно давно съехали на свой корпоративный мессенджер Time. Это случилось в тот момент, когда Slack отказался работать с русскими компаниями. За эти пару лет само решение прошло испытание огнем, водой и медными трубами и показало то, что этот мессенджер можно использовать для общения в компании с десятками тысяч сотрудников. Также поверх него можно строить бизнес-процессы и автоматизации (аля chat-ops). Какое-то время назад мы начали продавать это решение как коробочный продукт для заказчиков и на него есть устойчивый спрос. Если перед вами стоит вопрос, а какой мессенджер использовать, то вы можете почитать про наш Time и заказать себе демо.

Ну и немного чиселок для гиков о том, какие показатели это решение показывает на одной из инсталляций:)
- 36 тысяч онлайн-подключений в пике
- 2 млн сообщений в день
- 45 тысяч пользователей
- 3,7 млн диалогов инициировано
- 120 тысяч каналов создано
- 99,99% доступность

#Software