Глубокое обучение и анализ данных. Практическое руководство
Прочитал эту книгу Дмитрия Малова за пару недель, что пришлись на отпуск и разъезды. Книга издана в 2023 году и сопровождается кодом и графиками, что доступны на Github. В книге 270 страниц, разделенных на 8 отдельных глав, причем автор пытается сначала изложить необходимые основы, а дальше уже переходить к практике и примерам:
1. Основы машинного обучения - здесь автор начинает с базиса, в который входит
- Линейная алгебра - скаляр, вектор, матрица, тензор, норма
- Теория информации и теорвер - случайная величина, распределение вероятности, условная вероятность, матожидание, дисперсия, ковариация, правило Байеса
- Основные понятия машинного обучения и решаемые задачи - классификация, регрессия, обнаружение аномалий, машинный перевод, структурный вывод, синтез и выбборка), а также отношение к опыту при обучении и варианты обучения с учителем, без учителя, с частичным привлечением учителя, а также обучение с подкреплением
- Основы разработки: синтаксис python, основы ооп (абстракция, инкаспусляция, полиморфизм, наследование и композиция), процессы разработки: waterfall и agile:)
2. Основные алгоритмы машинного обучения - здесь автор начинает с предобработки данных, а дальше рассматривает алгоритмы снижения их размерности: линейные и нелинейные методы, линейную и логистическую регрессию, деревья решений, метод опорных векторов, наивный байесовский классификатор, k-means, k nearest neighbors, случайный лес и алгоритм градиентного бустинга. Все это умещается в 30 страниц, поэтому если вы отдельно не изучали все эти вещи, то иногда сложно успевать за мыслью автора (я слава богу до этого это все уже ботал лет 10 назад, когда у меня был приступ самообразования и я зависал на Coursera и Edx)
3. Основы глубокого обучения - здесь автор начинает с обратного распространения ошибки (backpropagation), дальше рассказывает про персептрон, цепь Маркова, машину Больцмана, сеть Хопфилда, сверточные нейронные сети (CNN), трансформеры, рекуррентные нейронные сети (RNN), автокодировщики, генеративно состязательные сети (GAN). А в конце приводит пример системы, которую автор походу делал для whitepaper или диплома:)
4. Основы data science - интересно, что тут рассказ начинается с методологии работы с данными, а точнее с CRISP-DM (Cross-Industry Standard Process for Data Mining, дальше рассказывается про роли в команде ML-разработки, где примечательны data analyst, data engineer, data scientist. Дальше автор рассказывает про тренды: deep fakes и борьба с ними, интерес бизнеса к обучению end2end моделей, Auto ML для low-code и no-code использования, MLOps (я недавно писал про whitepaper на эту тему от Google и участвовал в подкасте на эту же тему). А заканчивает эту главу автор тем, что рассматривает популярные библиотеки для ML разработки, среди которых хотелось бы упомянуть TensorFlow, PyTorch, Keras
5. Задачи глубокого обучения - в этой главе автор приводит примеры задач и показывает как их можно решать при помощи deep learning. Тут как раз пригодится код из репозитория, чтобы поиграть с задачами самому. Тут есть примеры аугментации данных, компьютерного зрения и использования OpenCV, классическая задача на распознование символов, обработка естественного языка, обработка аудио, а также обработка видео. В общем, в этой и следующих трех главах собрана самая мякотка:)
6-8. Последние три главы посвящены знакомству с TensorFlow, Keras и PyTorch. Здесь показано как решать задачи из 5 главы с использованием конкретной библиотеки.
Если финализировать саммари по книге, то она показалась мне кратким интро в область deep learning. В ней есть вся нужная базовая инфа, но чтобы ее понять придется почитать дополнительные материалы. Здесь же есть примеры задач и код, который может стать стартовой точкой для ваших экспериментов. В общем, книга мне скорее понравилась, но надо учесть, что за исключением конкретных библиотек TensorFlow, Keras и PyTorch все остальное я уже достаточно давно и неплохо изучил:)
#AI #Math #Statistics #Software #DataScience #ML
Прочитал эту книгу Дмитрия Малова за пару недель, что пришлись на отпуск и разъезды. Книга издана в 2023 году и сопровождается кодом и графиками, что доступны на Github. В книге 270 страниц, разделенных на 8 отдельных глав, причем автор пытается сначала изложить необходимые основы, а дальше уже переходить к практике и примерам:
1. Основы машинного обучения - здесь автор начинает с базиса, в который входит
- Линейная алгебра - скаляр, вектор, матрица, тензор, норма
- Теория информации и теорвер - случайная величина, распределение вероятности, условная вероятность, матожидание, дисперсия, ковариация, правило Байеса
- Основные понятия машинного обучения и решаемые задачи - классификация, регрессия, обнаружение аномалий, машинный перевод, структурный вывод, синтез и выбборка), а также отношение к опыту при обучении и варианты обучения с учителем, без учителя, с частичным привлечением учителя, а также обучение с подкреплением
- Основы разработки: синтаксис python, основы ооп (абстракция, инкаспусляция, полиморфизм, наследование и композиция), процессы разработки: waterfall и agile:)
2. Основные алгоритмы машинного обучения - здесь автор начинает с предобработки данных, а дальше рассматривает алгоритмы снижения их размерности: линейные и нелинейные методы, линейную и логистическую регрессию, деревья решений, метод опорных векторов, наивный байесовский классификатор, k-means, k nearest neighbors, случайный лес и алгоритм градиентного бустинга. Все это умещается в 30 страниц, поэтому если вы отдельно не изучали все эти вещи, то иногда сложно успевать за мыслью автора (я слава богу до этого это все уже ботал лет 10 назад, когда у меня был приступ самообразования и я зависал на Coursera и Edx)
3. Основы глубокого обучения - здесь автор начинает с обратного распространения ошибки (backpropagation), дальше рассказывает про персептрон, цепь Маркова, машину Больцмана, сеть Хопфилда, сверточные нейронные сети (CNN), трансформеры, рекуррентные нейронные сети (RNN), автокодировщики, генеративно состязательные сети (GAN). А в конце приводит пример системы, которую автор походу делал для whitepaper или диплома:)
4. Основы data science - интересно, что тут рассказ начинается с методологии работы с данными, а точнее с CRISP-DM (Cross-Industry Standard Process for Data Mining, дальше рассказывается про роли в команде ML-разработки, где примечательны data analyst, data engineer, data scientist. Дальше автор рассказывает про тренды: deep fakes и борьба с ними, интерес бизнеса к обучению end2end моделей, Auto ML для low-code и no-code использования, MLOps (я недавно писал про whitepaper на эту тему от Google и участвовал в подкасте на эту же тему). А заканчивает эту главу автор тем, что рассматривает популярные библиотеки для ML разработки, среди которых хотелось бы упомянуть TensorFlow, PyTorch, Keras
5. Задачи глубокого обучения - в этой главе автор приводит примеры задач и показывает как их можно решать при помощи deep learning. Тут как раз пригодится код из репозитория, чтобы поиграть с задачами самому. Тут есть примеры аугментации данных, компьютерного зрения и использования OpenCV, классическая задача на распознование символов, обработка естественного языка, обработка аудио, а также обработка видео. В общем, в этой и следующих трех главах собрана самая мякотка:)
6-8. Последние три главы посвящены знакомству с TensorFlow, Keras и PyTorch. Здесь показано как решать задачи из 5 главы с использованием конкретной библиотеки.
Если финализировать саммари по книге, то она показалась мне кратким интро в область deep learning. В ней есть вся нужная базовая инфа, но чтобы ее понять придется почитать дополнительные материалы. Здесь же есть примеры задач и код, который может стать стартовой точкой для ваших экспериментов. В общем, книга мне скорее понравилась, но надо учесть, что за исключением конкретных библиотек TensorFlow, Keras и PyTorch все остальное я уже достаточно давно и неплохо изучил:)
#AI #Math #Statistics #Software #DataScience #ML
👍9🔥3❤2
How Technical Problems Cause Organizational Friction • Adam Tornhill • GOTO 2023 (Рубрика #Architecture)
Интересный доклад от Adam Tornhill на тему социотехнических запахов (презентация доступна здесь). Суть в том, что наши современные системы очень сложны и они включают как software, так и людей, которые его пишут (пока не это не стали делать LLMs самостоятельно). Обеспечить баланс достаточно сложно, так как из кода напрямую не ясен социотехнический контекст - кто и зачем его написал, а также какие в нем были изменения. Adam Tornhill предлагает использовать подход behavioral code analysis, где мы сочетаем в себе анализ кода с данными о том, как команды взаимодействуют внутри кода, например, кто вносит изменения и насколько параллельно это происходит, как выглядят параметры cohesion и coupling, а также насколько сложно поддерживать код с высоким техническим долгом. Интересно, что за год до этого Adam рассказывал крутой доклад на тему приоритизации техдолга и я об этом рассказывал. Если же возвращаться к behavioral code analysis, то автоор предлагает, использую их, уменьшить организационное трение и сосредочить внимание на ряде общих задач
- Выявите узкие места архитектурной координации и поймите технические root causes
- Визуализируйте неявные зависимости между командами, а дальше действуйте так, чтобы отделить (decouple) команды
- Выявите риски знаний, измерив bus factor. Узнайте, как смягчить его
- Сообщите о рисках масштабирования, присущих закону Брукса, показав данные о том, как он влияет на вашу доставку
- Выйдите за рамки технического воздействия, зная, как плохой код приводит к низкому моральному духу и увеличению истощения
Ну и социотехнические факторы, которые называет автор звучат примерно так
1. The overcrowded system - когда слишком много людей работают над одной системой и дают слишком маленький выхлоп:)
2. Coordination bottlenecks in the code - проблема с большим количеством изменений в одних и тех же файлах вашей системы людьми из разных команд. Здесь очень велика сложность поддержания ментальной модели кода, поэтому это приводит к большему количеству багов и более сложным внесениям изменений. Кажется, что в этой части еще пригодились бы подходы из whitepaper "Architecture Anti-patterns: Automatically Detectable Violations of Design Principles", про которую я рассказывал раньше
3. A propagating cost of change - про change coupling и как изменения в одном месте тянут за собой большое количество изменений в других местах, если change coupling высокий. Как раз недавно я рассказывал про книгу Кента Бека "Чистый дизайн" ("Tidy First?"), где неплохо разбирались вопросы change couplin
4. Dependent work crossing team boundaries - здесь автор говорит примерно про обратный маневр Конвея, где нам нужно так выбрать структуру команд, чтобы она матчилась с желаемой архитектурой. Плюс нам надо так организовать архитектуру системы, чтобы она хорошо укладывалась на problem domain и позволяла организовать естественные границы для команд
5. Unhealthy code with a low Truck Factor - тут автор вспоминает про bus factor и выбывающих людей, а дальше показывает, что если это наложить на нездоровый код, то мы получаем большую проблему. Условно, если мы теряем эксперта по запутанному коду, то наши знания о деталях реализации систем сильно уменьшаются и осуществлять изменения становится дольше и дороже.
P.S.
У автора есть сайт https://codescene.com/ и книга "Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis", в которой этот подход подробно разобран. Лицензция стоит $300 в год на разработчика.
P.P.S.
Whitepapers, на которые ссылался автор
- The business impact of Code Quality
- On-boarding costs in unhealthy code
- Happiness and the Productivity of Software Engineers
- The Influence of Organizational Structure On Software Quality
#SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign #Architecture #TechDebt #Management
Интересный доклад от Adam Tornhill на тему социотехнических запахов (презентация доступна здесь). Суть в том, что наши современные системы очень сложны и они включают как software, так и людей, которые его пишут (пока не это не стали делать LLMs самостоятельно). Обеспечить баланс достаточно сложно, так как из кода напрямую не ясен социотехнический контекст - кто и зачем его написал, а также какие в нем были изменения. Adam Tornhill предлагает использовать подход behavioral code analysis, где мы сочетаем в себе анализ кода с данными о том, как команды взаимодействуют внутри кода, например, кто вносит изменения и насколько параллельно это происходит, как выглядят параметры cohesion и coupling, а также насколько сложно поддерживать код с высоким техническим долгом. Интересно, что за год до этого Adam рассказывал крутой доклад на тему приоритизации техдолга и я об этом рассказывал. Если же возвращаться к behavioral code analysis, то автоор предлагает, использую их, уменьшить организационное трение и сосредочить внимание на ряде общих задач
- Выявите узкие места архитектурной координации и поймите технические root causes
- Визуализируйте неявные зависимости между командами, а дальше действуйте так, чтобы отделить (decouple) команды
- Выявите риски знаний, измерив bus factor. Узнайте, как смягчить его
- Сообщите о рисках масштабирования, присущих закону Брукса, показав данные о том, как он влияет на вашу доставку
- Выйдите за рамки технического воздействия, зная, как плохой код приводит к низкому моральному духу и увеличению истощения
Ну и социотехнические факторы, которые называет автор звучат примерно так
1. The overcrowded system - когда слишком много людей работают над одной системой и дают слишком маленький выхлоп:)
2. Coordination bottlenecks in the code - проблема с большим количеством изменений в одних и тех же файлах вашей системы людьми из разных команд. Здесь очень велика сложность поддержания ментальной модели кода, поэтому это приводит к большему количеству багов и более сложным внесениям изменений. Кажется, что в этой части еще пригодились бы подходы из whitepaper "Architecture Anti-patterns: Automatically Detectable Violations of Design Principles", про которую я рассказывал раньше
3. A propagating cost of change - про change coupling и как изменения в одном месте тянут за собой большое количество изменений в других местах, если change coupling высокий. Как раз недавно я рассказывал про книгу Кента Бека "Чистый дизайн" ("Tidy First?"), где неплохо разбирались вопросы change couplin
4. Dependent work crossing team boundaries - здесь автор говорит примерно про обратный маневр Конвея, где нам нужно так выбрать структуру команд, чтобы она матчилась с желаемой архитектурой. Плюс нам надо так организовать архитектуру системы, чтобы она хорошо укладывалась на problem domain и позволяла организовать естественные границы для команд
5. Unhealthy code with a low Truck Factor - тут автор вспоминает про bus factor и выбывающих людей, а дальше показывает, что если это наложить на нездоровый код, то мы получаем большую проблему. Условно, если мы теряем эксперта по запутанному коду, то наши знания о деталях реализации систем сильно уменьшаются и осуществлять изменения становится дольше и дороже.
P.S.
У автора есть сайт https://codescene.com/ и книга "Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis", в которой этот подход подробно разобран. Лицензция стоит $300 в год на разработчика.
P.P.S.
Whitepapers, на которые ссылался автор
- The business impact of Code Quality
- On-boarding costs in unhealthy code
- Happiness and the Productivity of Software Engineers
- The Influence of Organizational Structure On Software Quality
#SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign #Architecture #TechDebt #Management
YouTube
How Technical Problems Cause Organizational Friction • Adam Tornhill • GOTO 2023
This presentation was recorded at GOTO Copenhagen 2023. #GOTOcon #GOTOcph
https://gotocph.com
Adam Tornhill - Founder & CTO at CodeScene; Programmer, Psychologist, Lisp Hacker, Speaker & Author of "Your Code as a Crime Scene" @adamtornhill2546
ORIGINAL…
https://gotocph.com
Adam Tornhill - Founder & CTO at CodeScene; Programmer, Psychologist, Lisp Hacker, Speaker & Author of "Your Code as a Crime Scene" @adamtornhill2546
ORIGINAL…
👍4🔥3👏3❤1
Людей в команде стало больше в 2 раза, а результаты в 2 раза не увеличились (Рубрика #Management)
Вчера в офисе беседовал со своим коллегой на эту тему. Он раньше руководил несколькими командами, а теперь как staff engineer работает над вопросами архитектуры и проектирования. Коллега отметил насчет одной из команд, с которыми раньше он много взаимодействовал, что она значительно увеличилась, а результат увеличился не соразмерно. И дальше мы ушли в обсуждение причин такого эффекта, которые я объясняю следующими факторами
1. Убывающая предельная полезность - по мере добавления инженеров в команду их предельная полезность уменьшается. Суть в том, что добавление первого инженера позволяет начать развивать продукт, решая самые приоритетные задачи. Добавление второго инженера позволяет уделить время важным задачам, а добавление условно седьмого инженера позволяет заняться nice to have фичами. Примерно тоже самое наблюдается и в жизни, условно, когда вы страдаете от жажды в пустыне - первый стакан воды вам просто необходим и вы готовы за него заплатить много денег, второй полезен и вы все еще готовы платить, а условно десятый стакан для вас уже не несет пользы и платить за него вы не готовы:)
2. Групповая динамика отношений и онбординг новых людей - при добавлении новых людей в команду их требуется обучить и вписать в общую динамику группы (модель Такмана). На онбординге мы тратим время самих онбордящихся, а также сильных людей из команд. Кроме того, перформящая по Такману команда может проваливаться в стадию storming, где бурлят обсуждения и команда работает менее эффективно, чем до этого
3. Стоимость коммуникаций - даже если человек уже заонбордился, а динамика команды вернулась в норму, то у нас все равно остаются затраты на коммуникации. Если у нас в команде все общаются со всеми, то у нас получается полный граф, где количество связей равно n*(n-1)/2. Каждую связь требуется поддерживать, поэтому накладные расходы на коммуникации растут квадратично с ростом команды. Отсюда у нас получаются ограничения вида two-pizza team
4. Проблемы с параллелизацией работы - тут нам нужно вспомнить закон Амдала
А значит что парараллелизация работы внутри команды не позволяет линейно масштабироваться с увеличением количества человек, так как у нас есть часть работы, которую мы должны делать последовательно (планнинг, ретро, часть архитектурной работы, работа над местами с bottleneck в коде, про что рассказывалось в докладе "How Technical Problems Cause Organizational Friction", о котором я упоминал вчера). Кстати, именно поэтому все стремятся сделать автономные команды и топологию команд (можно почитать про team topologies или послушать первую серию подкаста Code of Leadership).
Если подводить итоги, то эти факторы приводят к тому, что масштабируя команды мы получаем сублинейное масштабирование эффекта. Причем если процессы на уровне компании выстроены совсем печально, то сублинейное время скорее похоже на ассимптотику log(N), где N - это количество людей🙂 В общем, в лоб решить задачу, закидав ее людьми не получится.
P.S.
Отдельным постом потом напишу про решение действительно сложных задач и почему там требуется не просто наращивать команду, а скорее искать центр кристализации (супер-крутого эксперта) и дальше вокруг него выстраивать команду из инженеров с высоким потенциалом.
#Management #Leadership #Processes #Team #Software #SoftwareArchitecture
Вчера в офисе беседовал со своим коллегой на эту тему. Он раньше руководил несколькими командами, а теперь как staff engineer работает над вопросами архитектуры и проектирования. Коллега отметил насчет одной из команд, с которыми раньше он много взаимодействовал, что она значительно увеличилась, а результат увеличился не соразмерно. И дальше мы ушли в обсуждение причин такого эффекта, которые я объясняю следующими факторами
1. Убывающая предельная полезность - по мере добавления инженеров в команду их предельная полезность уменьшается. Суть в том, что добавление первого инженера позволяет начать развивать продукт, решая самые приоритетные задачи. Добавление второго инженера позволяет уделить время важным задачам, а добавление условно седьмого инженера позволяет заняться nice to have фичами. Примерно тоже самое наблюдается и в жизни, условно, когда вы страдаете от жажды в пустыне - первый стакан воды вам просто необходим и вы готовы за него заплатить много денег, второй полезен и вы все еще готовы платить, а условно десятый стакан для вас уже не несет пользы и платить за него вы не готовы:)
2. Групповая динамика отношений и онбординг новых людей - при добавлении новых людей в команду их требуется обучить и вписать в общую динамику группы (модель Такмана). На онбординге мы тратим время самих онбордящихся, а также сильных людей из команд. Кроме того, перформящая по Такману команда может проваливаться в стадию storming, где бурлят обсуждения и команда работает менее эффективно, чем до этого
3. Стоимость коммуникаций - даже если человек уже заонбордился, а динамика команды вернулась в норму, то у нас все равно остаются затраты на коммуникации. Если у нас в команде все общаются со всеми, то у нас получается полный граф, где количество связей равно n*(n-1)/2. Каждую связь требуется поддерживать, поэтому накладные расходы на коммуникации растут квадратично с ростом команды. Отсюда у нас получаются ограничения вида two-pizza team
4. Проблемы с параллелизацией работы - тут нам нужно вспомнить закон Амдала
В случае, когда задача разделяется на несколько частей, суммарное время её выполнения на параллельной системе не может быть меньше времени выполнения самого медленного фрагмента.
А значит что парараллелизация работы внутри команды не позволяет линейно масштабироваться с увеличением количества человек, так как у нас есть часть работы, которую мы должны делать последовательно (планнинг, ретро, часть архитектурной работы, работа над местами с bottleneck в коде, про что рассказывалось в докладе "How Technical Problems Cause Organizational Friction", о котором я упоминал вчера). Кстати, именно поэтому все стремятся сделать автономные команды и топологию команд (можно почитать про team topologies или послушать первую серию подкаста Code of Leadership).
Если подводить итоги, то эти факторы приводят к тому, что масштабируя команды мы получаем сублинейное масштабирование эффекта. Причем если процессы на уровне компании выстроены совсем печально, то сублинейное время скорее похоже на ассимптотику log(N), где N - это количество людей🙂 В общем, в лоб решить задачу, закидав ее людьми не получится.
P.S.
Отдельным постом потом напишу про решение действительно сложных задач и почему там требуется не просто наращивать команду, а скорее искать центр кристализации (супер-крутого эксперта) и дальше вокруг него выстраивать команду из инженеров с высоким потенциалом.
#Management #Leadership #Processes #Team #Software #SoftwareArchitecture
👍20❤10🔥10
Adaptive Architectures • Marty Pitt • GOTO 2023 (Рубрика #Architecture)
Интересный доклад от Marty Pitt на ту же самую тему, которую он поднимал за год до этого в докладе "Using Semantic Metadata to Create an Automated Microservice Data Mesh", про который я рассказывал раньше. Правда, теперь эта идея подается через адаптивную архитектуру, которая достигается за счет того, что мы не пишем связующий код (glue code), который нам требуется для интеграции наших отдельных API для выполнения полезной работы. Как и в прошлый раз это достигается за счет:
- Языка Taxi для семантической разметки наших существующих API, когда мы поверх ним добавляем этим языком метаданные для описания семантики
- Декларативного языка запросов TaxiQL для описания того, что мы хотим выбрать с точки зрения семантики
- Платформы Orbital для хостинга этих метаописаний и исполнения этих декларативных запросов, когда под капотом платформа выполняет все запросы и выплевывает готовую информацию
В итогe, Taxi похоже на GraphQL в плане целей предоставления единой точки входа для объединения нескольких API. Но в Taxi не требуются resolvers, Taxi независима от протокола и может объединять разные API (OpenAPI, RAML, JsonSchema и Protobuf, ...), TaxiQL позволяет потребителям определять свои контракты данных. Но и проблемы похожи на те, что есть у GraphQL.
В итоге, адаптивную архитектуру по мнению автора можно построить на базе
#Data #Software #SoftwareArchitecture #Architecture #Engineering
Интересный доклад от Marty Pitt на ту же самую тему, которую он поднимал за год до этого в докладе "Using Semantic Metadata to Create an Automated Microservice Data Mesh", про который я рассказывал раньше. Правда, теперь эта идея подается через адаптивную архитектуру, которая достигается за счет того, что мы не пишем связующий код (glue code), который нам требуется для интеграции наших отдельных API для выполнения полезной работы. Как и в прошлый раз это достигается за счет:
- Языка Taxi для семантической разметки наших существующих API, когда мы поверх ним добавляем этим языком метаданные для описания семантики
- Декларативного языка запросов TaxiQL для описания того, что мы хотим выбрать с точки зрения семантики
- Платформы Orbital для хостинга этих метаописаний и исполнения этих декларативных запросов, когда под капотом платформа выполняет все запросы и выплевывает готовую информацию
В итогe, Taxi похоже на GraphQL в плане целей предоставления единой точки входа для объединения нескольких API. Но в Taxi не требуются resolvers, Taxi независима от протокола и может объединять разные API (OpenAPI, RAML, JsonSchema и Protobuf, ...), TaxiQL позволяет потребителям определять свои контракты данных. Но и проблемы похожи на те, что есть у GraphQL.
В итоге, адаптивную архитектуру по мнению автора можно построить на базе
- Taxi - semantic metadata for APIs
- TaxiQL - declarative query language
- Orbital - TaxiQL engine + observability
#Data #Software #SoftwareArchitecture #Architecture #Engineering
YouTube
Adaptive Architectures • Marty Pitt • GOTO 2023
This presentation was recorded at GOTO Copenhagen 2023. #GOTOcon #GOTOcph
https://gotocph.com
Marty Pitt - Founder at Orbital & Notional
ORIGINAL TALK TITLE
Adaptive Architectures: Reimagining API Federation & Microservices Integration
RESOURCES
https…
https://gotocph.com
Marty Pitt - Founder at Orbital & Notional
ORIGINAL TALK TITLE
Adaptive Architectures: Reimagining API Federation & Microservices Integration
RESOURCES
https…
👍5❤4🤓2💩1😐1
Дизайн всего (How Design Makes the World) (Рубрика #Design)
Очень простая и короткая книга на тему дизайна от Скотта Беркуна, который написал много книг, включая "Откровение оратора" (подробнее в посте) и "Искусство управления IT-проектами" которые я читал до этого. Как обычно Скотт пишет очень просто и легко, приводит кучу примеров и много шутит, но глубина проработки тем такова, что читать ее интересно начинающим. Но вы не узнаете много нового, если вы уже в теме и читали упоминаемые Скоттом книги типа
- “Дизайн привычных вещей” ("The Design of Everyday Things") Дона Нормана (подробнее в моем посте) или
- "Предсказуемая иррациональность" ("Predictably Irrational") Дэна Ариели
На протяжении книги автор подводит к тому, что дизайн - это не просто про интерфейсы или визуал, а это про осмысленное создание предметов, которые служат определенным целям определенной аудитории. В итоге, у него получаются 4 главных вопроса, которые задают хорошие дизайнеры
Для того, чтобы оценить повестование можно взглянуть на главы, которые входят в книгу
1. У всего есть дизайн - даже если о дизайне не думали, то он какой-то получился, но чаще всего он получился не очень
2. Производить или проектировать - что сложнее? - Ответ автора в том, что чаще проще сделать вещь, чем ее спроектировать
3. Что такое хорошо? - зависит от цели
4. Люди прежде всего - рассказ про сигвеи и что бывает, если идти от технологии
5. Дизайном занимается каждый - и инженеры при проектировании софта тоже:)
6. Улица за окном - про проектирование городов и районов, а также про прямоугольную сетку улиц (что использовалась с древних времен)
7. Стиль - это послание - про бренд и особенности стиля, которые передают мысль окружающим
8. Дизайн - это функциональность - про ментальные модели, которые дизайнеры используют для облегчения использования предметов, например, про кнопки-плацебо, багажную ленту в аэропорту и так далее
9. За чей счет? - кому-то придется заплатить за улучшенный дизайн: покупателю, продавцу или государству. Тут приводится интересный пример с ремнями безопасности в машинах
10. Как скажут сверху - политики и руководители компаний тоже являются дизайнерами, так как обычно они принимают финальное решение:)
11. Дизайн - это действие - про итеративную работу дизайнеров и дизайн-мышление (design thinking)
12. Билет в кармане - разбор посадочного билета на самолет и почему он такой (спойлер: это обусловлено работой с ограничениями реального мира и наличии legacy систем)
13. Идеи и системы - если системам такова, что там принимаются неудачные решения, то и дизайн там получится неудачный (пример с госучереждениями)
14. Как для себя? - суть главы в том, что вы - нерепрезентативны. А для того, чтобы принимать удачные решения надо иметь разношерстную команду и думать о разных потребителях
15. Образ мышления: это важно! - важно не заставлять клиентов думать о том, как пользоваться вашими спроектированными решениями + если они все-таки ошибаются при использовании, то это не должно приводить к серьезным проблемам
16. Ценности и компромиссы - компромиссы - это то, к чему мы приходим в реальной жизни. Важно понимать к чему мы стремимся и как оценивать альтернативы (и больше не значит лучше)
17. Хороший дизайн незаметен - все должно быть ясно без объяснений и инструкций
18. Дизайн раздора - про темные паттерны дизайна и противоречие между людьми, которое возникает из-за спроектированных решений
19. Новые решения - новые проблемы - примерно про day-2 проблемы (что будет после того, как спроектированное решение будет внедрено)
20. Куда смотреть - чеклист для понимания дизайна от автора
21. Рекомендации - куча отсылок к источникам
В общем, читать интересно и полезно. Но если вы гуру дизайна, то вам будет скучно:)
#Architecture #Management #Thinking #Leadership #SystemDesign #SystemThinking
Очень простая и короткая книга на тему дизайна от Скотта Беркуна, который написал много книг, включая "Откровение оратора" (подробнее в посте) и "Искусство управления IT-проектами" которые я читал до этого. Как обычно Скотт пишет очень просто и легко, приводит кучу примеров и много шутит, но глубина проработки тем такова, что читать ее интересно начинающим. Но вы не узнаете много нового, если вы уже в теме и читали упоминаемые Скоттом книги типа
- “Дизайн привычных вещей” ("The Design of Everyday Things") Дона Нормана (подробнее в моем посте) или
- "Предсказуемая иррациональность" ("Predictably Irrational") Дэна Ариели
На протяжении книги автор подводит к тому, что дизайн - это не просто про интерфейсы или визуал, а это про осмысленное создание предметов, которые служат определенным целям определенной аудитории. В итоге, у него получаются 4 главных вопроса, которые задают хорошие дизайнеры
1. Что вы хотите улучшить?
2. Для кого вы хотите это улучшить?
3. Как вы добьетесь того, чтобы дизайн оказался успешным?
4. Кому может навредить ваша работа - сейчас или в будущем?
Для того, чтобы оценить повестование можно взглянуть на главы, которые входят в книгу
1. У всего есть дизайн - даже если о дизайне не думали, то он какой-то получился, но чаще всего он получился не очень
2. Производить или проектировать - что сложнее? - Ответ автора в том, что чаще проще сделать вещь, чем ее спроектировать
3. Что такое хорошо? - зависит от цели
4. Люди прежде всего - рассказ про сигвеи и что бывает, если идти от технологии
5. Дизайном занимается каждый - и инженеры при проектировании софта тоже:)
6. Улица за окном - про проектирование городов и районов, а также про прямоугольную сетку улиц (что использовалась с древних времен)
7. Стиль - это послание - про бренд и особенности стиля, которые передают мысль окружающим
8. Дизайн - это функциональность - про ментальные модели, которые дизайнеры используют для облегчения использования предметов, например, про кнопки-плацебо, багажную ленту в аэропорту и так далее
9. За чей счет? - кому-то придется заплатить за улучшенный дизайн: покупателю, продавцу или государству. Тут приводится интересный пример с ремнями безопасности в машинах
10. Как скажут сверху - политики и руководители компаний тоже являются дизайнерами, так как обычно они принимают финальное решение:)
11. Дизайн - это действие - про итеративную работу дизайнеров и дизайн-мышление (design thinking)
12. Билет в кармане - разбор посадочного билета на самолет и почему он такой (спойлер: это обусловлено работой с ограничениями реального мира и наличии legacy систем)
13. Идеи и системы - если системам такова, что там принимаются неудачные решения, то и дизайн там получится неудачный (пример с госучереждениями)
14. Как для себя? - суть главы в том, что вы - нерепрезентативны. А для того, чтобы принимать удачные решения надо иметь разношерстную команду и думать о разных потребителях
15. Образ мышления: это важно! - важно не заставлять клиентов думать о том, как пользоваться вашими спроектированными решениями + если они все-таки ошибаются при использовании, то это не должно приводить к серьезным проблемам
16. Ценности и компромиссы - компромиссы - это то, к чему мы приходим в реальной жизни. Важно понимать к чему мы стремимся и как оценивать альтернативы (и больше не значит лучше)
17. Хороший дизайн незаметен - все должно быть ясно без объяснений и инструкций
18. Дизайн раздора - про темные паттерны дизайна и противоречие между людьми, которое возникает из-за спроектированных решений
19. Новые решения - новые проблемы - примерно про day-2 проблемы (что будет после того, как спроектированное решение будет внедрено)
20. Куда смотреть - чеклист для понимания дизайна от автора
21. Рекомендации - куча отсылок к источникам
В общем, читать интересно и полезно. Но если вы гуру дизайна, то вам будет скучно:)
#Architecture #Management #Thinking #Leadership #SystemDesign #SystemThinking
👍8❤3🔥2
Интересно как издатели по разному подходят к обложке книги о дизайне, о которой я рассказывал утром:)
😁15👍5🔥2
Краткая история Китая (The Shortest History Of China) (Рубрикак #History)
Эта книга Джейвин Линды про историю Китая напомнила мне набор разноцветных четок, где каждая из четок - это отдельный исторический период. И этот калейдоскоп начинается с императоров древних времен и заканчивается их аналогами в настоящием:) Одновременно при чтении мне показалось, что каждая глава настолько перегружена событиями и ключевыми персонажами, что она напоминает детский калейдоскоп - если его встряхнуть, то мы получим совсем другую картину, под другим углом и дальше можно будет вглядываться в нее заново. В общем, книга отлично подходит для начального знакомства, которое позволит узнать о многом и дальше нырнуть в то, что заинтересовало, а помогает этому содержание, которое напоминает американские горки:)
P.S.
По мере прочтения этой книги до меня доходили истинные масштабы Китая: количество разных национальностей, людей, городов, героев и злодеев, а также династистий, что сменяли друг друга. И мне вспомнилась фраза из 1984, которой пользовались часть из правителей для того, чтобы управлять будущим
Кстати, рекомендую почитать 1984 хотя бы в виде комикса, про который я рассказывал раньше.
#History #Economics
Эта книга Джейвин Линды про историю Китая напомнила мне набор разноцветных четок, где каждая из четок - это отдельный исторический период. И этот калейдоскоп начинается с императоров древних времен и заканчивается их аналогами в настоящием:) Одновременно при чтении мне показалось, что каждая глава настолько перегружена событиями и ключевыми персонажами, что она напоминает детский калейдоскоп - если его встряхнуть, то мы получим совсем другую картину, под другим углом и дальше можно будет вглядываться в нее заново. В общем, книга отлично подходит для начального знакомства, которое позволит узнать о многом и дальше нырнуть в то, что заинтересовало, а помогает этому содержание, которое напоминает американские горки:)
1. Истоки - Яйцо проклевывается, и рождается цивилизация
2. Чжоу - От идеального правления к периоду Сражающихся царств
3. Цинь - Объединение, тирания и Поднебесная
4. Хань - Интриги, инновации и короткое междуцарствие
5. Великий разлад - Три царства, две женщины-воительницы, семь мудрецов и порошок из пяти минералов
6. Тан - От золотого века до вечной печали
7. Сун - Протосоциалисты, неоконфуцианы и городское житье
8. Монгольская Юань - От "славной резни" к великолепному городу
9. Мин - Великолепие и упадок
10. Великая Цин - Трудный путь к современности
11. Республика - Большие надежды и жестокие предательства
12. Японское вторжение и гражданская война - Республика распадается
13. Годы Мао - Непрерывная революция
14. Эпоха реформ - Процветание и недовольные
15. Новая эра Си Цзиньпина - Появление воинов-волков
P.S.
По мере прочтения этой книги до меня доходили истинные масштабы Китая: количество разных национальностей, людей, городов, героев и злодеев, а также династистий, что сменяли друг друга. И мне вспомнилась фраза из 1984, которой пользовались часть из правителей для того, чтобы управлять будущим
Кто управляет прошлым, тот управляет будущим; кто управляет настоящим, тот управляет прошлым
Кстати, рекомендую почитать 1984 хотя бы в виде комикса, про который я рассказывал раньше.
#History #Economics
👍10❤5🔥2✍1🏆1🍓1
Обложки книги про Китай. Интересно сравнить как они поменялись при переиздании книги на русском
❤7☃2🐳2👻1
Всё о Малыше и Карлсоне (илл. А. Савченко) (Karlsson pa taket flyger igen. Karlsson pa taket smyger igen) (Рубрика #Kids)
Многие взрослые смотрели в детстве мультики про Малыша и Карлсона. Потом взрослые показывают его своим детям, а дальше покупают книжку для того, чтобы читать истории про Карлсона детям перед сном. Мы с женой так и сделали и купили книгу с обалденными иллюстрациями из старых советских мультиков. И все бы хорошо - книга отличная, знакомая история про друга Малыша, что живет на крыше и умеет летать благодаря своему пропеллеру на спине ... но что-то не так. В книге гораздо ярче, чем в мультике проступает истинное обличие Карлсона - гопника без определенного места жительства (если не считать чердак), что разводит детей на еду и игрушки, минимально думаюет об окружающих вокруг и считает себя лучшим в мире по всем активностям. В мультике у Карлсона роль забавного толстячка, с которым Малыш интересно проводит время, а в книге этот забавный толстячок не очень-то и забавен. В итоге, мы за полгода смогли с детишками прочитать 320 страниц из 420, а дальше ни жена, ни сыновья не хотят дальше читать истории про Карлсона.
P.S.
Сама книга вышла качественной - большой формат, плотная бумага, знакомые иллюстрации. Все сделано отлично.
#ForKids #ForParents
Многие взрослые смотрели в детстве мультики про Малыша и Карлсона. Потом взрослые показывают его своим детям, а дальше покупают книжку для того, чтобы читать истории про Карлсона детям перед сном. Мы с женой так и сделали и купили книгу с обалденными иллюстрациями из старых советских мультиков. И все бы хорошо - книга отличная, знакомая история про друга Малыша, что живет на крыше и умеет летать благодаря своему пропеллеру на спине ... но что-то не так. В книге гораздо ярче, чем в мультике проступает истинное обличие Карлсона - гопника без определенного места жительства (если не считать чердак), что разводит детей на еду и игрушки, минимально думаюет об окружающих вокруг и считает себя лучшим в мире по всем активностям. В мультике у Карлсона роль забавного толстячка, с которым Малыш интересно проводит время, а в книге этот забавный толстячок не очень-то и забавен. В итоге, мы за полгода смогли с детишками прочитать 320 страниц из 420, а дальше ни жена, ни сыновья не хотят дальше читать истории про Карлсона.
P.S.
Сама книга вышла качественной - большой формат, плотная бумага, знакомые иллюстрации. Все сделано отлично.
#ForKids #ForParents
❤7🔥6👍4
You Keep Using That Word • Sam Newman • GOTO 2023 (Рубрика #Architecture)
Это доклад Сэма Ньюмана, известного популяризатора термина микросервисы, по которым он написал известные книги "Building Microservices" в 2015 году, "Monolith to Microservices" в 2019 году, которые поспособствовали буму микросервисов. В этом докладе автор решил разобраться не с самими сервисами, а со связами между ними. Эти связи часто классифицируют как синхронные или асинхронные, но что же такое асинхронность и как она соотносится с синхронностью? Автор рассказывает про свой тред в сети X (ex-Twitter) трехлетней давности, где он устраивал дискуссию на эту тему и получил примерно следующие мнения о том, что входит в концепцию асинхронности:
- Immediacy (незамедлительность) - пример звонка по телефону по сравнению с отправкой email
- Temporal coupling (временная связанность) - связь действий во времени
- Non-blocking (не блокируемость) - возможность делать неблокирующие выщовы (аля promises или async конструкций в языках)
- Intermediary (посредник) - наличие промежуточного посредника навроде Rabbit MQ, Active MQ, Apache Kafka
Также автор вспоминает про предыдущий подход к снаряду с асинхронностью от создателей Reactive Manifesto, который был создан пока написание манифестов еще не превратилось в булшит бинго. Конкрентно автор сомневается в полезности определения Asynchronous из этого манифеста
Конкретно у Сэма есть претензия к словам обработки запроса "after it has been transmitted", как будто обработка запроса возможна до этого. Тут сразу вспоминается Герберт Уэллс и его Машина Времени:) Но дальше Сэм сам не предлагает точного определения для асинхронности и говорит о том, что все зависит от контекста. В итоге, в социотехнической системе присутствуют люди, которые вкладывают смысл в слова языка и этот смысл может отличаться для одного и того же слова в разном контексте. На эту тему я рекомендую почитать книгу Александра Пиперски "Конструирование языков. От эсперанто до дотракийского", про которую я рассказывал раньше. В книге речь идет не о лингвистике в общем, а скорее про искусственные языки: краткую историю их исследований и принципы классификации. А при обсуждении искусственных языков мы можем наблюдать весь процесс дизайна языка, начиная с целей, проходя через принципы и приходя к имплементации. Это сильно интереснее обсуждения естественных языков, где многое объясняется тем, что "так исторически сложилось":))
#Architecture #Software #Engineering #SoftwareArchitecture #SystemDesign #DistributedSystems #Design
Это доклад Сэма Ньюмана, известного популяризатора термина микросервисы, по которым он написал известные книги "Building Microservices" в 2015 году, "Monolith to Microservices" в 2019 году, которые поспособствовали буму микросервисов. В этом докладе автор решил разобраться не с самими сервисами, а со связами между ними. Эти связи часто классифицируют как синхронные или асинхронные, но что же такое асинхронность и как она соотносится с синхронностью? Автор рассказывает про свой тред в сети X (ex-Twitter) трехлетней давности, где он устраивал дискуссию на эту тему и получил примерно следующие мнения о том, что входит в концепцию асинхронности:
- Immediacy (незамедлительность) - пример звонка по телефону по сравнению с отправкой email
- Temporal coupling (временная связанность) - связь действий во времени
- Non-blocking (не блокируемость) - возможность делать неблокирующие выщовы (аля promises или async конструкций в языках)
- Intermediary (посредник) - наличие промежуточного посредника навроде Rabbit MQ, Active MQ, Apache Kafka
Также автор вспоминает про предыдущий подход к снаряду с асинхронностью от создателей Reactive Manifesto, который был создан пока написание манифестов еще не превратилось в булшит бинго. Конкрентно автор сомневается в полезности определения Asynchronous из этого манифеста
Asynchronous
The Oxford Dictionary defines asynchronous as “not existing or occurring at the same time”. In the context of this manifesto we mean that the processing of a request occurs at an arbitrary point in time, sometime after it has been transmitted from client to service. The client cannot directly observe, or synchronize with, the execution that occurs within the service. This is the antonym of synchronous processing which implies that the client only resumes its own execution once the service has processed the request.
Конкретно у Сэма есть претензия к словам обработки запроса "after it has been transmitted", как будто обработка запроса возможна до этого. Тут сразу вспоминается Герберт Уэллс и его Машина Времени:) Но дальше Сэм сам не предлагает точного определения для асинхронности и говорит о том, что все зависит от контекста. В итоге, в социотехнической системе присутствуют люди, которые вкладывают смысл в слова языка и этот смысл может отличаться для одного и того же слова в разном контексте. На эту тему я рекомендую почитать книгу Александра Пиперски "Конструирование языков. От эсперанто до дотракийского", про которую я рассказывал раньше. В книге речь идет не о лингвистике в общем, а скорее про искусственные языки: краткую историю их исследований и принципы классификации. А при обсуждении искусственных языков мы можем наблюдать весь процесс дизайна языка, начиная с целей, проходя через принципы и приходя к имплементации. Это сильно интереснее обсуждения естественных языков, где многое объясняется тем, что "так исторически сложилось":))
#Architecture #Software #Engineering #SoftwareArchitecture #SystemDesign #DistributedSystems #Design
YouTube
You Keep Using That Word • Sam Newman • GOTO 2023
This presentation was recorded at GOTO Copenhagen 2023. #GOTOcon #GOTOcph
https://gotocph.com
Sam Newman - Microservices Expert & Author of "Building Microservices" & "Monolith to Microservices" @samnewman4355
RESOURCES
https://twitter.com/samnewman
h…
https://gotocph.com
Sam Newman - Microservices Expert & Author of "Building Microservices" & "Monolith to Microservices" @samnewman4355
RESOURCES
https://twitter.com/samnewman
h…
❤8👍4🔥1
Гибкие технологии: Экстремальное программирование и унифицированный процесс разработки (Agile Modeling: Effective practices for XP) (Рубрика #Management)
Достал с полки раритетную книгу Скотта Амблера (Scott Ambler), которую я читал еще в 2005 году в самом начале своей карьеры как инженера. В то время еще все не молились на Agile Manifesto, каскадная разработка была еще в полном порядке, а по миру шагал унифицированный процесс разработки вида RUP (Rational Unified Process). А в этой книге автор пытался поделиться своим опытом моделирования программного обеспечения. В итоге, в книге было 400 страниц, 30 глав и пять частей, про которые стоит рассказать подробнее
1. Введение в гибкое моделирование - здесь автор рассказывает про agile manifesto и на базе него формулирует свои принципы agile modeling навроде того, что надо ожидать изменения, изменения надо делать небольшими, нам нужно множество моделей, быстрая обратная связь, что содержание важнее формы и так далее. Дальше автор рассказывает про разные методики моделирования: инкрементальные, работа в группе, важность тестирования модели и проверки ее в коде, используйте стандарты моделирования и не увлекайесь паттернами. В общем, мне эта часть была очень полезна почти 20 лет назад
2. Гибкое моделирование на практике - все начинается с важности общения для моделирования софта, дальше развенчиваются мифы вида "заморозки требований" или "высеченного в камне дизайна", дальше упоминается моделирование интерфейса, требований, написание документации, а также использование нотаций - тогда UML была впереди планеты всей, но уже в этой книге была глава с название "По ту сторону UML":)
3. Гибкое моделирование и экстремальное программирование - здесь автор рассматривает XP (extreme programming) и показывает как agile modeling укладывается в этот подход. Из этой книги видно, что XP тогда был на коне и важно было дать отсылку к нему, а не к Scrum, Kanban или еще чему-то
4. Гибкое моделирование и унифицированный процесс - а здесь автор говорит про унифицированный процесс, который потом превратится в RUP (rational unified process). Это другая часть спектра, где мы смотрим на бюрократический процесс, что пришел на смену каскадному. Автор показывает, что и здесь agile моделирование может пригодится
5. Глядя в будущее - в этой части автор говорит про то, как внедрить в свои процессы моделирование софта
Итого, книга для своего времени была очень хороша - качественный разговор про моделирование и дизайн софта, обсуждение того, как это встраивается в тогдашние процессы разработки. Обсуждение практических подходов, инструментов, нотаций и так далее. Я из книги в то время узнал и почерпнул многое. Но сейчас эта книга скорее динозавр из прошлого и читать ее стоит только археологам процессов разработки или ностальгирующим вроде меня:)
P.S.
Интересно, что дальше автор книги, Скотт Амблер, продолжил копать тему Agile подходов и вылепил Disciplined Agile (DA) в 2012 году, который потом был куплен с потрохами PMI (Project Management Institute) в 2019. PMI дальше постаралась с помощью этого тулкита закрыть свое отставание в гибких подходах. Историю про Disciplined Agile я уже рассказывал раньше.
#Processes #Management #Agile #Leadership #Software
Достал с полки раритетную книгу Скотта Амблера (Scott Ambler), которую я читал еще в 2005 году в самом начале своей карьеры как инженера. В то время еще все не молились на Agile Manifesto, каскадная разработка была еще в полном порядке, а по миру шагал унифицированный процесс разработки вида RUP (Rational Unified Process). А в этой книге автор пытался поделиться своим опытом моделирования программного обеспечения. В итоге, в книге было 400 страниц, 30 глав и пять частей, про которые стоит рассказать подробнее
1. Введение в гибкое моделирование - здесь автор рассказывает про agile manifesto и на базе него формулирует свои принципы agile modeling навроде того, что надо ожидать изменения, изменения надо делать небольшими, нам нужно множество моделей, быстрая обратная связь, что содержание важнее формы и так далее. Дальше автор рассказывает про разные методики моделирования: инкрементальные, работа в группе, важность тестирования модели и проверки ее в коде, используйте стандарты моделирования и не увлекайесь паттернами. В общем, мне эта часть была очень полезна почти 20 лет назад
2. Гибкое моделирование на практике - все начинается с важности общения для моделирования софта, дальше развенчиваются мифы вида "заморозки требований" или "высеченного в камне дизайна", дальше упоминается моделирование интерфейса, требований, написание документации, а также использование нотаций - тогда UML была впереди планеты всей, но уже в этой книге была глава с название "По ту сторону UML":)
3. Гибкое моделирование и экстремальное программирование - здесь автор рассматривает XP (extreme programming) и показывает как agile modeling укладывается в этот подход. Из этой книги видно, что XP тогда был на коне и важно было дать отсылку к нему, а не к Scrum, Kanban или еще чему-то
4. Гибкое моделирование и унифицированный процесс - а здесь автор говорит про унифицированный процесс, который потом превратится в RUP (rational unified process). Это другая часть спектра, где мы смотрим на бюрократический процесс, что пришел на смену каскадному. Автор показывает, что и здесь agile моделирование может пригодится
5. Глядя в будущее - в этой части автор говорит про то, как внедрить в свои процессы моделирование софта
Итого, книга для своего времени была очень хороша - качественный разговор про моделирование и дизайн софта, обсуждение того, как это встраивается в тогдашние процессы разработки. Обсуждение практических подходов, инструментов, нотаций и так далее. Я из книги в то время узнал и почерпнул многое. Но сейчас эта книга скорее динозавр из прошлого и читать ее стоит только археологам процессов разработки или ностальгирующим вроде меня:)
P.S.
Интересно, что дальше автор книги, Скотт Амблер, продолжил копать тему Agile подходов и вылепил Disciplined Agile (DA) в 2012 году, который потом был куплен с потрохами PMI (Project Management Institute) в 2019. PMI дальше постаралась с помощью этого тулкита закрыть свое отставание в гибких подходах. Историю про Disciplined Agile я уже рассказывал раньше.
#Processes #Management #Agile #Leadership #Software
👍7❤3🔥3