Forwarded from Digital Bookshelf
proefschrift_jkm_bbm.pdf
2.3 MB
Помню, когда меня интересовала тема корпоративной архитектуры и я копался в TOGAF - одной из основных техник проектирования рассматривалась использование SBB и ABB, совершенно случайно сейчас на просторах нашел книжку по этой теме.
«The Building Block Method
Component-Based
Architectural Design
for Large Software-Intensive
Product Families»
Ничего про нее не скажу, может вы прочитаете, если вам актуально, и поделитесь обратной связью.
Взято отсюда:
https://www.gaudisite.nl/proefschrift_jkm_bbm.pdf
«The Building Block Method
Component-Based
Architectural Design
for Large Software-Intensive
Product Families»
Ничего про нее не скажу, может вы прочитаете, если вам актуально, и поделитесь обратной связью.
Взято отсюда:
https://www.gaudisite.nl/proefschrift_jkm_bbm.pdf
👍5
Balancing_cognitive_load_in_design_work_A_conceptual_and_narrati.pdf
1.1 MB
«Balancing cognitive load in design work: A conceptual and Balancing cognitive load in design work: A conceptual and
narrative review»
narrative review»
👍2🔥1
Имел к этому отношение, делюсь
Forwarded from Enterprise Agile Russia
Солар — архитектор комплексной кибербезопасности. Компания обеспечивает IT-безопасность более 1000 организаций, в том числе безопасность единого правительственного комплекса.
В апреле 2024 года перед Солар стоял ряд задач:
🔹Меняться под «ландшафт» рынка, в котором зачастую царил хаос, вызванный импортозамещением.
🔹Оптимизировать процессы, в том числе и синхронизацию между смежными отделами компании.
🔹Вовлечь все релевантные подразделения в цикл продуктового развития.
🔹Оперативно реагировать на новые проблемы и риски клиентов.
Читайте про кейс внедрения SAFe® (Scaled Agile Framework®) в Солар в статье.
@EntrpriseAgileRussia
#safe #articles #статьи #cases #кейсы
Telegram-чат сообщества: общение практиков и советы от экспертов.
В апреле 2024 года перед Солар стоял ряд задач:
🔹Меняться под «ландшафт» рынка, в котором зачастую царил хаос, вызванный импортозамещением.
🔹Оптимизировать процессы, в том числе и синхронизацию между смежными отделами компании.
🔹Вовлечь все релевантные подразделения в цикл продуктового развития.
🔹Оперативно реагировать на новые проблемы и риски клиентов.
Читайте про кейс внедрения SAFe® (Scaled Agile Framework®) в Солар в статье.
@EntrpriseAgileRussia
#safe #articles #статьи #cases #кейсы
Telegram-чат сообщества: общение практиков и советы от экспертов.
🔥5❤4
Forwarded from emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc. (Ivan)
Наглядно о том, чем руководство (формальное) отличается от лидерства (неформального):
https://habr.com/ru/articles/536292/
В Nokia разработали собственную мобильную операционную систему MeeGo. Но формальные руководители решили, что будут использовать Windows Phone для смартфонов Nokia.
Далее цитатами:
💬 ситуация в Nokia и в разработке MeeGo была настолько дезорганизована за последние пару лет
💬 Команда MeeGo и другие сотрудники Nokia были задеты за живое, и у них была только одна цель — закончить продукт на основе MeeGo и отправить его на полки магазинов в течение 2011 года.
💬 команда MeeGo была распущена после выпуска N9 и нескольких обновлений прошивки
💬 С 2005 года очень небольшая группа людей с ограниченными ресурсами в Nokia разрабатывала операционную систему Maemo на базе Linux и устройства на ее основе. Команда была известна как OSSO (Open Source Software Operations), и, по словам одного из членов команды, который работал там с самого начала, целью было создание продукта, который изменит мир. Команда OSSO была переименована в команду Maemo в 2007 году. А в результате партнерства Nokia и Intel в 2010 году она была переименована в команду MeeGo. С самого начала группу возглавлял Ари Якси, который ушел из Nokia в октябре 2010 года и перешел в HP для разработки операционной системы WebOS.
Здесь мы видим человека с лидерскими качествами, который силами небольшой группы собрался изменить мир. Но столкнулся с проблемами:
💬 Конечный продукт в основном производился через аутсорсинг без большой помпы и поддержки со стороны топ-менеджмента. Никто не вмешивался в процесс, и это привело к проблемам с качеством готовой продукции. Принимая во внимание небольшие ресурсы и работу с подрядчиками, самая низкая цена всегда была первым приоритетом при выборе компонентов, а остальные требования были на вторых позициях.
Тут отчетливо просматривается недооценка проекта формальным руководством.
💬 Сокращение расходов на разработку программного обеспечения не было особо мотивирующим фактором. Учитывая, что экономия была достигнута за счет менее качественных компонентов...
💬 Трудно было сохранить качество работы субподрядчиков, и контракты не контролировались должным образом. Субподрядчики могли жульничать, заменяя лучших специалистов, которые были в начале, на менее квалифицированных людей потом. Приведенные примеры включали плохой код, написанный в Индии, и проблемы со связью с китайцами и японцами из-за их плохого знания английского языка.
На эту тему была серия постов: https://xn--r1a.website/emacsway_log/1096
Которая вылилась в черновик доклада: http://kr.msk.ru/
Далее началась "Проблема Брукса", и очевидно, что формальное руководство с ним не справилось:
💬 В то же время размер команды вырос, а вместе с ней и бюрократия. Это привело к снижению гибкости и к замедлению в разработке программного обеспечения.
Далее мы видим, что разработчики осознавали ответственность за судьбу проекта больше, чем руководство. И начали защищать проект от руководства:
💬 Предложение было сразу же отвергнуто, но разработчик не сдался, поделившись примером функциональности для тестирования другими. В результате во внутренней системе Bugzilla, используемой сотрудниками Nokia для обработки ошибок, появилась цепочка длиной в несколько сотен сообщений, где руководство и разработчики спорили друг с другом по поводу этой функции. Наконец, эта функция была сделана, и в обновлении PR 1.1 она использовалась по умолчанию.
Тут просматриваются проблемы с организацией SDLC в контексте разрешения неопределенности требований:
💬 Постоянно меняющиеся требования к разработке пользовательского интерфейса вызывали внутренние проблемы в команде разработчиков
Дальнейшее развитие ситуации сравнили с историей:
💬 о человеке, работающем на нефтяной вышке, который просыпается ночью от взрыва и понимает, что вся платформа объята пламенем. Человеку удается добраться до края платформы, и ему необходимо принять решение: остаться и умереть или прыгнуть на 30 метров в темные и холодные воды. Это решение надо принять срочно.
Продолжение...
https://habr.com/ru/articles/536292/
В Nokia разработали собственную мобильную операционную систему MeeGo. Но формальные руководители решили, что будут использовать Windows Phone для смартфонов Nokia.
Далее цитатами:
💬 ситуация в Nokia и в разработке MeeGo была настолько дезорганизована за последние пару лет
💬 Команда MeeGo и другие сотрудники Nokia были задеты за живое, и у них была только одна цель — закончить продукт на основе MeeGo и отправить его на полки магазинов в течение 2011 года.
💬 команда MeeGo была распущена после выпуска N9 и нескольких обновлений прошивки
💬 С 2005 года очень небольшая группа людей с ограниченными ресурсами в Nokia разрабатывала операционную систему Maemo на базе Linux и устройства на ее основе. Команда была известна как OSSO (Open Source Software Operations), и, по словам одного из членов команды, который работал там с самого начала, целью было создание продукта, который изменит мир. Команда OSSO была переименована в команду Maemo в 2007 году. А в результате партнерства Nokia и Intel в 2010 году она была переименована в команду MeeGo. С самого начала группу возглавлял Ари Якси, который ушел из Nokia в октябре 2010 года и перешел в HP для разработки операционной системы WebOS.
Здесь мы видим человека с лидерскими качествами, который силами небольшой группы собрался изменить мир. Но столкнулся с проблемами:
💬 Конечный продукт в основном производился через аутсорсинг без большой помпы и поддержки со стороны топ-менеджмента. Никто не вмешивался в процесс, и это привело к проблемам с качеством готовой продукции. Принимая во внимание небольшие ресурсы и работу с подрядчиками, самая низкая цена всегда была первым приоритетом при выборе компонентов, а остальные требования были на вторых позициях.
Тут отчетливо просматривается недооценка проекта формальным руководством.
💬 Сокращение расходов на разработку программного обеспечения не было особо мотивирующим фактором. Учитывая, что экономия была достигнута за счет менее качественных компонентов...
💬 Трудно было сохранить качество работы субподрядчиков, и контракты не контролировались должным образом. Субподрядчики могли жульничать, заменяя лучших специалистов, которые были в начале, на менее квалифицированных людей потом. Приведенные примеры включали плохой код, написанный в Индии, и проблемы со связью с китайцами и японцами из-за их плохого знания английского языка.
На эту тему была серия постов: https://xn--r1a.website/emacsway_log/1096
Которая вылилась в черновик доклада: http://kr.msk.ru/
Далее началась "Проблема Брукса", и очевидно, что формальное руководство с ним не справилось:
💬 В то же время размер команды вырос, а вместе с ней и бюрократия. Это привело к снижению гибкости и к замедлению в разработке программного обеспечения.
Далее мы видим, что разработчики осознавали ответственность за судьбу проекта больше, чем руководство. И начали защищать проект от руководства:
💬 Предложение было сразу же отвергнуто, но разработчик не сдался, поделившись примером функциональности для тестирования другими. В результате во внутренней системе Bugzilla, используемой сотрудниками Nokia для обработки ошибок, появилась цепочка длиной в несколько сотен сообщений, где руководство и разработчики спорили друг с другом по поводу этой функции. Наконец, эта функция была сделана, и в обновлении PR 1.1 она использовалась по умолчанию.
Тут просматриваются проблемы с организацией SDLC в контексте разрешения неопределенности требований:
💬 Постоянно меняющиеся требования к разработке пользовательского интерфейса вызывали внутренние проблемы в команде разработчиков
Дальнейшее развитие ситуации сравнили с историей:
💬 о человеке, работающем на нефтяной вышке, который просыпается ночью от взрыва и понимает, что вся платформа объята пламенем. Человеку удается добраться до края платформы, и ему необходимо принять решение: остаться и умереть или прыгнуть на 30 метров в темные и холодные воды. Это решение надо принять срочно.
Продолжение...
Хабр
История Nokia MeeGo
Вступление от переводчика: Эта статья на английском была опубликована в далеком 2012 году. Тогда еще были свежи воспоминания о смене стратегии Nokia, отказе от разработки собственных ОС. А переход на...
💔1
Nikita Pinchuk professional channel: IT / EA / BA / Architecture
О стоимости задержки (Cost of delay) как определяющем факторе экономического взгляда на разработку продуктов. Автор доклада Дональд Рейнерштен, автор книги «principles of product development flow”, одной из известнейших книг, на которую опирается фреймворк…
Principles of product development flow - Chapter 1.pdf
1.8 MB
В октябре я писал, что работая с книгой Principles of product development flow (Reinerstein), понял что плотность экономической теории, статистики и пр. Настолько высока, что я решил начать для себя конспектировать ее. И вот когда я начал ее конспектировать, я понял, что ее нужно просто брать и целиком переводить. Именно для себя, чтобы иметь возможность в полной мере ее понять и не ломать голову перечитывая на английском этот достаточно сложный (с точки зрения плотности терминологии) текст. Делаю это в первую очередь для себя, я не переводчик, выложу сюда почти законченную 1 главу. Если уважаемым читателям это будет полезно, продолжу в спокойном ритме это дело.
👍7🔥5❤1
Forwarded from emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc. (Ivan)
Архитектура отвечает за устранение напряжения между требованиями и конструкцией. А когда требования изначально неясны в полном объеме, то еще и за гибкость решения.
Иными словами, архитектура - это постоянная борьба, и шахматы в этом вопросе оказываются очень символичными, хорошо развивая необходимые качества архитектора. Представьте, что за белых играет архитектор, а за черных - Product Owner, который постоянно наровит изменить требования и поставить систему под удар новых требований.
Вилка - тактический прием шахмат, который позволяет взять одновременно две фигуры, т.е., говоря символично, позволяет достигнуть одновременно два "требования" Product Owner. Это то, что архитектор постоянно делает с системой.
Иными словами, одно решение (ADR) позволяет удовлетворить одно из двух требований, независимо от того, какое из них окажется верным в результате эмпирической проверяемости. Возможность адаптировать систему под новые требования. Точка расширения системы.
Другой тактический прием, характеризующий "количество взятий" (т.е. сколько фигур бьет одно и то же поле), символично выражает запас конструктивной устойчивости системы при изменении требования.
С Product Owner, играющим в шахматы, намного легче развивать систему. Фактически он уже владеет основами системного мышления.
В статьях
https://habr.com/ru/company/cian/blog/569940/
и
https://less.works/ru/less/principles/systems-thinking
приводятся примеры радикальных последствий в тех случаях, когда лицо принимающее решение (ЛПР) плохо понимает основы системного мышления и попадает в ловушку ложной коммутативности.
Образно говоря, существуют ЛПР, которые думают, что при ремонте квартиры сперва можно сделать стены а потом выравнивать пол. Это равносильно тому, чтоб утверждать, будто не имеет значения какими фигурами и в какой последовательности ходить в шахматах. Шахматы хорошо приобщают к системному мышлению. А значит, приобщая ЛПР к шахматам, вы приобщаете его к системному мышлению и способствуете взаимному пониманию двух противоборствующих сторон разработки.
Иными словами, архитектура - это постоянная борьба, и шахматы в этом вопросе оказываются очень символичными, хорошо развивая необходимые качества архитектора. Представьте, что за белых играет архитектор, а за черных - Product Owner, который постоянно наровит изменить требования и поставить систему под удар новых требований.
Вилка - тактический прием шахмат, который позволяет взять одновременно две фигуры, т.е., говоря символично, позволяет достигнуть одновременно два "требования" Product Owner. Это то, что архитектор постоянно делает с системой.
Иными словами, одно решение (ADR) позволяет удовлетворить одно из двух требований, независимо от того, какое из них окажется верным в результате эмпирической проверяемости. Возможность адаптировать систему под новые требования. Точка расширения системы.
Другой тактический прием, характеризующий "количество взятий" (т.е. сколько фигур бьет одно и то же поле), символично выражает запас конструктивной устойчивости системы при изменении требования.
С Product Owner, играющим в шахматы, намного легче развивать систему. Фактически он уже владеет основами системного мышления.
В статьях
https://habr.com/ru/company/cian/blog/569940/
и
https://less.works/ru/less/principles/systems-thinking
приводятся примеры радикальных последствий в тех случаях, когда лицо принимающее решение (ЛПР) плохо понимает основы системного мышления и попадает в ловушку ложной коммутативности.
Образно говоря, существуют ЛПР, которые думают, что при ремонте квартиры сперва можно сделать стены а потом выравнивать пол. Это равносильно тому, чтоб утверждать, будто не имеет значения какими фигурами и в какой последовательности ходить в шахматах. Шахматы хорошо приобщают к системному мышлению. А значит, приобщая ЛПР к шахматам, вы приобщаете его к системному мышлению и способствуете взаимному пониманию двух противоборствующих сторон разработки.
Хабр
Темные века разработки программного обеспечения
Пару лет назад я работал в SaaS-компании, которая страдала от всех возможных проблем, связанных с разработкой программного обеспечения . Код был настолько сложным, что внесение простых изменений...
❤1🔥1
Forwarded from Антон Григорьев | Слайдология 💡
Понимание немногих принципов освобождает от необходимости знать множество фактов
— Альфред Норт Уайтхед
Это не просто красивая фраза. Это формула мышления, которая отличает специалиста от энциклопедии. Кстати, это хорошо работает как в работе, так и в жизни. Поэтому во всем я стараюсь найти 20%, которые бы освободили меня от необходимости зубрить 80%.
Лень — двигатель прогресса 😁
Факт — это кирпич.
Принцип — это правило, по которому ты понимаешь, как эти кирпичи складываются в дом.
Можно выучить сотню фактов о презентациях — про шрифты, цвета, размер текста на 16:9.
А можно понять один принцип: люди читают слайд не как страницу, а как вспышку смысла.
И тогда всё остальное — следствие.
В когнитивной науке это называют схематизацией: мозг экономит ресурсы, если может опереться на обобщённую модель. Он не пересчитывает каждую задачу с нуля — он узнаёт знакомую структуру и достраивает детали.
Замечали, что все профессионалы умеют объяснять сложные вещи очень просто? Они не обобщают поверхностно — они видят в глубину.
Им не нужно помнить всё. Им достаточно понимать, как устроено. А факты всегда можно вывести по индукции.
— Альфред Норт Уайтхед
Это не просто красивая фраза. Это формула мышления, которая отличает специалиста от энциклопедии. Кстати, это хорошо работает как в работе, так и в жизни. Поэтому во всем я стараюсь найти 20%, которые бы освободили меня от необходимости зубрить 80%.
Лень — двигатель прогресса 😁
Факт — это кирпич.
Принцип — это правило, по которому ты понимаешь, как эти кирпичи складываются в дом.
Можно выучить сотню фактов о презентациях — про шрифты, цвета, размер текста на 16:9.
А можно понять один принцип: люди читают слайд не как страницу, а как вспышку смысла.
И тогда всё остальное — следствие.
В когнитивной науке это называют схематизацией: мозг экономит ресурсы, если может опереться на обобщённую модель. Он не пересчитывает каждую задачу с нуля — он узнаёт знакомую структуру и достраивает детали.
Замечали, что все профессионалы умеют объяснять сложные вещи очень просто? Они не обобщают поверхностно — они видят в глубину.
Им не нужно помнить всё. Им достаточно понимать, как устроено. А факты всегда можно вывести по индукции.
❤6💯2
Forwarded from Nikita Pinchuk
Оставлю это здесь:
https://www.ivarjacobson.com/publications/blog/scaled-agile-tips/nature-portfolios-managing-investments-projects
https://www.ivarjacobson.com/publications/blog/scaled-agile-tips/nature-portfolios-managing-investments-projects
❤2
Media is too big
VIEW IN TELEGRAM
Measuring queue time vs measuring cycle time.
Many people try to reduce cycle times and do so by measuring the cycle times – which is rather difficult and time-consuming. Don Reinertsen explains a much easier and faster way of achieving real results.
Many people try to reduce cycle times and do so by measuring the cycle times – which is rather difficult and time-consuming. Don Reinertsen explains a much easier and faster way of achieving real results.
❤2👍2
Please open Telegram to view this post
VIEW IN TELEGRAM