Изменения

Пожалуй, прошедшая конференция SECR стала для меня первой конференцией, на которой я из-за общения в кулуарах пропустил много докладов, на которые планировал пойти. И еще больше докладов, на которые я не пошел, потому что они конкурировали с другими докладами, или с общением, а по названию или аннотации я их не отметил к посещению. Придется их смотреть отдельно. Или {{red|'''не смотреть'''}}, Это происходит потому что Стас Фомин, который ведет съемку, на закрытии конференции сказал, что хочет подтверждения актуальности его съемок докладов в виде комментариев на '''http://0x1.tv/Category:SECR''' и будет выкладывать видео по мере появления комментариев на этом сайте, или на facebook/вконтакте - в конце каждой публикации там ссылка на странички. Так что просьба ко всемзамечательные участники, кто меня читает с которыми интересно разговаривать и смотрит видео конференций - вспомните о своих просмотрах '''и напишите комментарии''', лучше, думаю, в соцсетях - так другие тоже увидятможно узнать много содержательного.

Придется смотреть доклады отдельно. Или {{red|'''не смотреть'''}}, потому что Стас Фомин, который ведет съемку, на закрытии конференции сказал, что хочет подтверждения актуальности его съемок докладов в виде комментариев на '''http://0x1.tv/Category:SECR''' и будет выкладывать видео по мере появления комментариев на этом сайте, или на facebook/вконтакте - в конце каждой публикации там ссылка на странички. Так что просьба ко всем, кто меня читает и смотрит видео конференций - вспомните о своих просмотрах '''и напишите комментарии''', лучше, думаю, в соцсетях - так другие тоже увидят. [https://www.facebook.com/tim.levitskiy/posts/1760966134031298 Из отзыва '''Тимофей Левицкого'''] на конференцию, показывающего разницу особенности аудиторииSECR: Всё-таки полезно ездить по конференциям. Особенно выступать. Столько нового узнаёшь! Приехал поведать коллегам, как правильно "дружить" стартапы и корпорации. Хорошо, вовремя сообразил, что на SECR ходит много хорошо подготовленных слушателей, которым интересно не потому, что ух ты всё такое новое, а потому, что они знают 80% ответа (и поэтому у них хорошие вопросы).

А теперь - мои впечатления о докладах, которые я писал на FB в ходе конференции. И По докладам Анатолия Левенчука и некоторым другим заметок много, поэтому в конце - список докладов, о которых я точно сожалею, что их пропустилотдельных разделах.

[https://www.facebook.com/mtsepkov/posts/1951424254914519 Пост на FB] Игорь Агамирзян - размышления о развитии разработки. Фантастическое ускорение процесса разработки и не менее фантастическое ухудшение качества. По очень многим приложениях прикладная система использует ресурсы процессоров и памяти максимум на 1% от достижимого при аккуратном программировании. Объем приложения FB за последние 2 года вырос в 2 раза. А функционал? И сейчас у нас кризис практического программирования. Экстенсивный рост, при чем без роста функционала. : Интересный комент от Дениса Бескова: А чем эти rants отличаются от Software Crisis 50-летней давности? https://ru.wikipedia.org/wiki/Кризис_программного_обеспечения : Мой ответ: Это - хороший вопрос. Потому что все это время разработка софта развивалась, давай новые приемлемые решения в ответ на проблемы - языки высокого уровня, системы сontinious integration/delivery, agile-процессы разработки, автотесты, многое другое. Пожалуй, сейчас проблема состоит в том, что требуется массовая разработка софта, управляющего интернетом вещей, для которых требуется сложность и надежность, ранее достигаемая только для квалифицированных инженерных решений (типа бортового софта автомобилей), и сознательно не достигаемая в массовых (например, в web-сайтах), и это - в условиях относительного дефицита мощности устройств, а также распределенного между устройствами исполнения= Анатолий Левенчук.Стейхолдерское мастерство =

[https://www.facebook.com/mtsepkov/posts/1951456538244624 Пост на FB] '''Анатолий Левенчук (Anatoly Levenchuk). Стейкхолдерское мастерство ''' - подробный рассказ в театральной метафоре. Стейкхолдер: действующее лицо из театральной метафоры. Принц Гамлет и есть - исполнитель. В театре - понятно, обращаемся к роли или актеру. А в жизни - путаем.

* Кругозор - пьеса целиком, менеджмент, инженерия, предпринмательствопредпринимательство

* актер - вынимать правильные роли из головы, перебирать. Не преображатсья преображаться в принца Гамлета полностью.

[https://www= Александр Турханов.facebook.com/mtsepkov/posts/1951570701566541 Пост на FB] Орхан Гасымов (Orkhan Ayaz Gasimov). Современная микросервисная архитектура. Несколько шагов преобразования от классического монолитного приложения. (1) делим монолит на маленькие сервисы, которые можно масштабируемо поднимать. Нужен реестр сервисов Распределенное лидерство и маршрутизатор с балансировкой нагрузки, а вместо больших серверов получаем много легких. (2) Сами сервисы делим на Command и Query, шаблон CQRS. (3) Команды реализуем через event sourcing - пишем журнал/очередь команд-событий, и их обработчики. Никаких синхронных вызовов между сервисами. (4) Обработчики событий - через паттерн reactor - идет один основной обработчик, который все тяжелые запросы раскидывает на внешние потоки. И каждый отдельный элемент этой конструкции - легкий. Модуль - просто набор функций. В целом - реализуем реактивный манифест.SysArchi =

[https://www.facebook.com/mtsepkov/posts/1951638554893089 1952896208100657 Пост на FB] '''Александр Леонов, Анатолий Кушниренко, Никита БесшапошниковТурханов. Введение Распределенное лидерство и SysArchi'''. Очень интересный опыт. Александр Турханов читает курс системного лидерства в кооперативное программирование: персональная ответственность - коллективный результатшколе Анатолия Левенчука. Совершенно неожиданно - доклад был Рассказывал он про обучение 6распределенное лидерство в строгой модели -летних детей программированию мы делим лидерские обязанности между стейкхолдерскими ролями, которые при этом могут совмещаться в детских садах в Сургуте. Успешноодном человеке, или быть распределены между разными людьми. При этом дети работают кооперативнослучай совмещения и возникающих взаимодействий тоже разбирался на конкретном примере: каждый пишет программу для своего роботаАлександр-business-actor ставит Алксандру-спикеру задачу выступления на конференции, исходя из собственных интересов. И обозначено не просто переключение между позициями, а роботы работают в общем поле и должны действовать согласованосмена онтологии, свойственной каждой позиции. И 6-летки реально решают сложные задачиеще отдельная позиция, Player, который отвечает за смену позиции, и которых тоже у них цель - довести к 3 классу до полной программы 11-летней школы. Решаются сложные задачи - синхронизации, управления кланами роботовчеловека может быть несколько. При этом команды детей соорганизуютсяпозиции стейкхолдеров нормативно закреплены в культуре, друг другу помогаютмы имеем 200-300 стейкхолдерских позиций на отрасль. А Archimate и его редактор SysArchi позволяет все это формально описывать, но при этом программу своему роботу каждый должен написать сами эта часть тоже была в докладе. Круто!

При этом занятия ведут обычные воспитатели, обычно 40Доклад был на английском -летние женщиныэто часть эксперимента SECR, после переподготовкипозволяющая докладчикам и слушателям прокачать свой скилл английского языка. но! Они знают группу, если ты группу И поэтому я не знаешь постил впечатления в темпе доклада - максимум 6 человекэтого я пока не умею. Потому что если 6-летний ребенок застрял, А то есть 1.5 минуты, чтобы ему помочь, иначе он выпал..бы было много больше.

[httpsВ комментарии Александр Турханов раскрыл тезисы://www# Deloitte Unversity Press в 2017 опубликовал отчет Human Capital Trends, в котором 9 тысяч менеджеров из 130 стран мира сказали, что лидерство для них важно, и 85% считают, что модель лидерства должна измениться.facebookПри этом мы думаем о командах в терминах 100-летней давности, а софта для управления лидерством нет.com/mtsepkov/postsМы инженеры и должны такой софт сделать, я расскажу как.# Традиционная модель лидерства и недостатки мышления о команде в терминах "орг.структура" и "орг.звено". В "матричных" организациях один человек входит в множество орг.звеньев и его должность не говорит нам ничего о фактических интересах. Но СЕО всегда так жили, так что надо просто разобраться, как же это работает.# История распределенного лидерства. Военка, японские корпорации и "ба", Евроконтроль и ответственность каждого за безопасность, адаптация распределенного лидерства коммерческими компаниями.# Определение распределенного лидерства в терминах системного подхода.# Главный источник дополнительных возможностей команды - управление ее вниманием.# Классическое управление вниманием в маленьких командах. Практика управления ресурсами команды (crew resource management/1951715454885399 Пост team resource management) в операционной комнате. Метафора хирургической операции и зоны внимания и ответственности членов команды. Трудности переноса практик CRM в проекты по разработке софта.# От управления индивидуальным фокусом и потоком к управлению командным фокусом и потоком.# Как SysArchi поддерживает системное мышление в командах. Системное мышление как управление вниманием.# Механистичен или нет системный подход? Стейкхолдеры.# Названия должностей не работают, поэтому надо уметь различать стейкхолдеров и понимать их взаимодействие. Так вы сможете построить влияние в проекте даже если у вас нет полномочий. В одной индустрии могут быть тысячи названий должностей и орг.звеньев, но всего 200-300 стейкхолдерских ролей. Знаете их и можете разговаривать по сути с кем угодно.# Аристотелевская схема "субъект-действие-объект" в системном подходе. Стейкхолдер-практика-объекты практики. Ключевой момент лидерства - "прогрузить" нужные концепции в голову исполнителей. И вот как SysArchi помогает в этом.# Отличие SysArchi от канбан.# Как научить свою команду правильно строить theory of mind (модель психических состояний) других членов команды, чтобы предсказывать и влиять на FB] '''Мой доклад [[Мыслить проектно: история поведение.# Человека в организации можно рассматривать как орг.звено, как стейкхолдера и современность как актера (SECRвнутреннего режиссера, который переключает роли).# Да, это все похоже на Дорофеева, но тут поддержано архитектурной моделью в репозитории, поэтому круче.# С точки зрения системного подхода эта трехчастная модель человека в организации есть разделение интересов и мультидисциплинарность. Команда как система. На каждом системном уровне свои организационно-2018технические решения по тому, как устроено распределенное лидерство.# Проблема с классическим определением команды и концептуальный переход от командного стиля управления к распределенному.# Функционально-конструктивное определение команды, два типа системных моделей команды. Общая системная модель команды помогает координировано ее строить, причем каждый может взять тот кусочек, который ему интересен. Управление фокусом внимания команды по онтологическому описанию проекта.# Архитектурная модель проекта и операционное табло (канбан)]]'''как основа сложной координации и коллаборации.# От команд обратно к людям. Техники управления индивидуальным вниманием от Брюса Тулгана.# Обоснование необходимости распределенного лидерства из-за нехватки времени руководителя на разговоры со всеми.# Описание технологии, ссылки на соглашение о моделировании и бесплатный редактор Archi. В [https://www.facebookarchimatetool.com'''Слайды https:/photo.php?fbid=10215049070717988&set=a.1914289494739&type=3 посте Димы Безуглого] продолжается большое обсуждение, читайте../yadi.sk/i/DgjcxXh3yPjQIA'''

Дмитрий Безуглый О проектном мышлении, о том что у них не получалось разрабатывать по RUP ,не получалось по agile .= Анатолий Левенчук.Как и что какое мышление нужно чтобы получилось )) Дмитрий Волошин водопад!: Дмитрий Безуглый Дмитрий Волошин Ага ): Дмитрий Волошин и еспд: Рина Ужевко водопадный аджайл 😊: Максим Цепков Водопада в докладе не было вообще. Так же как ЕСПД. Слайды - опубликованы. Taya Saburova Гибридные методологии? Наталья Свешникова Инструменты меняются, но проблема, похоже, все-таки в головах, и носим мы ее с собой из проекта в проект: Максим Цепков Нет. Это в вечном неизменном мире мы носим вечные проблемы. А мир - развивается, ставит новые задачи, по мере которого как старые мы учимся решать. И решение этих задач вызывает развитие культуры. Максим Цепков Дима, я не понял интерпретацию доклада. У кого "у них не получалось"? Доклад был про отраслевой опыт и изменение культур ведения программных проектов, я об этом рассказываю с 2015 года, и, кстати, визуальный ряд доклада появился тогда. При этом тема - развивается, это не повторение старых докладов. А если говорить конкретно об опыте моих проектов и проектов нашей компании, то мы их успешно делаем и наши клиенты это оценивают. При этом RUP я с самого начала оценивал как бессмысленные процедуры, и не пытался применить в силу явной работоспособности, а вот Scrum в свое время дал определенный импульс развития, а потом - сильно изменился внутри. И сейчас компания продолжает меняться. А в отрасли - как было 20-30% успешных докладов - так и есть. RUP и выросший из этого PMBOK не смог это повысить, повысив при этим стоимость, а Agile - дает примерно те же цифры, но дешевле и добавляет самонаведение на цель. А фокус доклада был не на этом, а на том, что в последнее время (с 2012) принципиально изменилась рамка проекта - хотя далеко не все люди это осознали.: Дмитрий Безуглый Максим Цепков Посмотри видео , ты так хотел продать Agile что многократно прозвучали обобщающие оценки. RUP не работает , Академический не работает и т.д. Потом ты постарался объединить но из песни слов не выкинешь: Максим Цепков Дима, я не продавал Agile. Вообще, Agile - стандарт дефакто в глобальной IT-отрасли давно, с 2007 года примерно. Академический подход не смог ответить на конкретные вызовы, проекты фейлились. Попытка классического менеджмента тоже провалилась, Мифический человеко-месяц об этом. Следующая итерация, RUP тоже не смог ответить на конкретные вызовы, и потому пришел Agile, который на них успешно ответил. И потом, естественно, появились новые вызовы, ответ на которые в agile-практиках не содержался, и как ответ на них - возникали новые практики и новая культура. Уже.: Это все история. И она произошла и ее надо понимать. Чтобы представлять, что прежде попытки применить старые подходы из учебников, написанных до попыток их применения, стоит посмотреть на результаты. Включая попытки применить Agile, который уже тоже старый подход со своей историей фейлов и успехов, и на ее историю тоже надо смотреть.: А еще - надо представлять законы диалектического развития (в варианте диалектического материализма, смотрите эти статьи). Agile явился отрицанием RUP и академической культуры, принес новое. То, что происходит сейчас и несет отрицание Agile, и ври этом, естественно, использует переосмысленные практики более ранних конструкций для синтеза нового. При этом часть представителей прошлой культуры, увидев это их близкое сердцу старое просто удовлетворенно говорят "наконец-то этот кошмар agile-культуры кончился и происходит возврат". Нет, возврата не происходит, это все - история и не понимание диалектики развития. Дмитрий Безуглый Давай по правде проекты проваливались, проваливаются и будут проваливаться. Более того успешные проекты делаются и делались и большая часть успешных продуктов появилась до Agile и продолжает появляются без Agile )) Agile is not silver bullet . Особенно agile for teams. До тех пор пока нет приемлемой статистики по успешности проектов все заявления о стандарте же факто не являются доказательством лучшей эффективности или целесообразности. Диалектику я не забываю )): Максим Цепков Конечно. Серебряной пули не существует. Продукты делали до agile и делают без agile на личных способностях. Agile дает технологию, и это является преимуществом. Альтернативные технологии - статистически дают такую же результативность успешность проектов, но дороже и обладают большим порогом входа. А дальше - берем конкретный проект и строим технологию.: Дмитрий Безуглый Максим Цепков Если внимательно слушать "гуру" , то можно понять что agile не только не технология, но даже и не методология ...Про порог входа верно , но в целом вход в agile начинается со 2 у уровня CMMI "не тушкой, так чучелком" и по сути представляет улучшение его же. Но на полный 3-й уровень ни в одной своей ипостаси в не поднимается, хотя есть элементы и 4-ого и 5-ого. Но снижение порога имеет свою цену ..развивать =

[https://www.facebook.com/mtsepkov/posts/1951760418214236 Пост на FB] '''Анатолий Левенчук. Как и какое мышление нужно развивать'''. Журнал выступления - оно того стоит.

[https://www.facebook.com/mtsepkov/posts/1952615644795380 Пост на FB] Алексей Пименов (Alexey Pimenov). LeanKanban подход к оценке = Мой доклад и прогнозированию проектов. Начался с сильного утверждения: на основе анализа мирового опыта выполнения проектов: нет корреляции между оценками проектов и реальными сроками выполнения.доклад Дмитрия безуглого =

Поэтому идея: вместо оценки и диаграмм Ганта использовать SLA. Основа Эта связка - спектральные диаграммы LEAN, которые позволяют ретроспективно выявить потоки характерных проектовпотому что доклады были подряд, и работать с нимиобсуждения их в постах на FB тоже оказались взаимосвязаны.

Дальше делаем типологию и чеклист классификации[https://www. И дальше накладываем facebook.com/mtsepkov/posts/1951715454885399 Пост на спектральную диаграмму - FB] '''Мой доклад [[Мыслить проектно: история и проверяем, что получилась характерная диаграмма нужного распределениясовременность (SECR-2018)]]'''. В [https://www.facebook.com/photo.php?fbid=10215049070717988&set=a. Нормальное1914289494739&type=3 посте Димы Безуглого] продолжается большое обсуждение, пуассоново, и обобщенное распределение Вейбла - ширина пика и отстояние пика от матожиданиячитайте.. Из этих данных можно извлекать полезное для предсказуемости.

НапримерДмитрий Безуглый О проектном мышлении, если много коротких запросов - точно можно вычленить для оптимизациио том что у них не получалось разрабатывать по RUP ,не получалось по agile ..и что нужно чтобы получилось ))

НоДмитрий Волошин водопад! Проблема есть толстых хвостов: fat tail. Вы обеспечиваете сервис заказчику, прилетает толстый хвост Дмитрий Безуглый Дмитрий Волошин Ага ): Дмитрий Волошин и убивает компаниюеспд: Рина Ужевко водопадный аджайл 😊: Максим Цепков Водопада в докладе не было вообще. Так же как ЕСПД. Слайды - опубликованы.

Почему прилетает толстый хвостTaya Saburova Гибридные методологии? Есть вариант, что в процессе реализции прилетают все новые запросы. А также многочисленные возвраты на доработку или рефакторинг.

Делаем диаграмму потоков работ. Проблемные точкиНаталья Свешникова Инструменты меняются, но проблема, похоже, все-таки в головах, и носим мы ее с собой из проекта в проект* Синхронизация разных потоков* Возвраты на переработку* Блокировки по ресурсам: людямМаксим Цепков Нет. Это в вечном неизменном мире мы носим вечные проблемы. А мир - развивается, внешним зависимостямставит новые задачи, взаимодействие с заказчикомпо мере которого как старые мы учимся решать. И решение этих задач вызывает развитие культуры.

Влияние блокировок Максим Цепков Дима, я не понял интерпретацию доклада. У кого "у них не получалось"? Доклад был про отраслевой опыт и других проблемных точек перевешивает влияние трудозатратизменение культур ведения программных проектов, я об этом рассказываю с 2015 года, и, кстати, визуальный ряд доклада появился тогда. При этом тема - развивается, это не повторение старых докладов. А если говорить конкретно об опыте моих проектов и проектов нашей компании, то мы их успешно делаем и наши клиенты это оценивают. При этом RUP я с самого начала оценивал как бессмысленные процедуры, и не пытался применить в силу явной работоспособности, а вот Scrum в свое время дал определенный импульс развития, а потом - сильно изменился внутри. И сейчас компания продолжает меняться. А в отрасли - как было 20-30% успешных докладов - так и есть. RUP и выросший из этого PMBOK не смог это повысить, повысив при этим стоимость, а Agile - дает примерно те же цифры, но дешевле и добавляет самонаведение на цель. А фокус доклада был не на этом, а на том, что в последнее время (с 2012) принципиально изменилась рамка проекта - хотя далеко не все люди это осознали.: Дмитрий Безуглый Максим Цепков Посмотри видео , ты так хотел продать Agile что многократно прозвучали обобщающие оценки. RUP не работает , Академический не работает и т.д. Потом ты постарался объединить но из песни слов не выкинешь: Максим Цепков Дима, я не продавал Agile. Вообще, Agile - стандарт дефакто в глобальной IT-отрасли давно, с 2007 года примерно. Академический подход не смог ответить на конкретные вызовы, проекты фейлились. Попытка классического менеджмента тоже провалилась, Мифический человеко-месяц об этом. Следующая итерация, RUP тоже не смог ответить на конкретные вызовы, и потому пришел Agile, который на них успешно ответил. И потом, естественно, появились новые вызовы, ответ на которые в agile-практиках не содержался, и как ответ на них - возникали новые практики и новая культура. Уже.: Это все история. И она произошла и ее надо понимать. Чтобы представлять, что прежде попытки применить старые подходы из учебников, написанных до попыток их применения, стоит посмотреть на результаты. Включая попытки применить Agile, который уже тоже старый подход со своей историей фейлов и успехов, и на ее историю тоже надо смотреть.: А еще - надо представлять законы диалектического развития (в варианте диалектического материализма, смотрите эти статьи). Agile явился отрицанием RUP и академической культуры, принес новое. То, что происходит сейчас и несет отрицание Agile, и ври этом, естественно, использует переосмысленные практики более ранних конструкций для синтеза нового. При этом часть представителей прошлой культуры, увидев это их близкое сердцу старое просто удовлетворенно говорят "наконец-то этот кошмар agile-культуры кончился и происходит возврат". Нет, возврата не происходит, это все - история и не понимание диалектики развития.

Leak time против время касания проектаДмитрий Безуглый Давай по правде проекты проваливались, проваливаются и будут проваливаться. Не путать время касания с трудозатратами Более того успешные проекты делаются и делались и большая часть успешных продуктов появилась до Agile и продолжает появляются без Agile )) Agile is not silver bullet . Особенно agile for teams. До тех пор пока нет приемлемой статистики по успешности проектов все заявления о стандарте же факто не являются доказательством лучшей эффективности или целесообразности. Диалектику я не забываю )): Максим Цепков Конечно. Серебряной пули не существует. Продукты делали до agile и делают без agile на личных способностях. Agile дает технологию, и это является преимуществом. Альтернативные технологии - потому статистически дают такую же результативность успешность проектов, но дороже и обладают большим порогом входа. А дальше - берем конкретный проект и строим технологию.: Дмитрий Безуглый Максим Цепков Если внимательно слушать "гуру" , то можно понять что может быть очень малые трудозатратыagile не только не технология, но даже и не методология ...Про порог входа верно , но в целом вход в agile начинается со 2 у уровня CMMI "не тушкой, так чучелком" и по сути представляет улучшение его же. Но на полный 3-й уровень ни в одной своей ипостаси в не поднимается, хотя есть элементы и 4-ого и 5-ого. Но снижение порога имеет свою цену ..

Эффективность потока: время касания к времени производства. Обычно лишь 5-15% И надо признаться, что наши проекты больше стоят, чем идут - при том, что мы следим, чтобы "все работали".  Компания, работающая на накопление знаний - сервисно-ориентированная. Разработка софта - такая же. В сервисе может быть несколько способов обслуживания. Эскалатор. Если все стоят на каждой ступеньке, одинаковое обслуживание - поднимется больше, но все одинаково. Если справа стоят, проходят слева - то в целом поднимется меньше, но некоторые - быстрее. Дальше очень часто есть варианты проектов одного типа. Надо провести анализ* Что-горело* Работа в обычном ритме* Проект не слишком важен изначально. Дальше делаем классы проектов: горящие, обычные и фоновые. А дальше - еще ставим лимиты, сколько мы делаем каких проектов. Горящих проектов не может быть слишком много. Если проект уходит в толстый хвост - ему можно поднять класс обслуживания. И можно отслеживать и принимать решения. Данных много не надо. Был кейс с рекрутерами - данных за два месяца хватило. И нашли любопытный толстый хвост. Когда программист-кандидат разослал резюме в несколько мест, получил оферы и приходит к начальству и требует повышения, ему дают - и закрытие вакансии у всех вылетело в толстый хвост. Про 5-15% - исследование Microsoft по проектам своих и партнеров примерно в 2009. Его опыт подтверждает. Подход cocoma - на выделенную команду. А реально есть разброс по ресурсам и впихивания заказчиками работ. И это нарушает детерминистический подход - его ломает плохой менеджмент. А здесь мы смотрим, что реально у нас получается с нашим плохим менеджментом, и прогнозируем из этого. В ответах на вопросы: для первой статистики в среднем достаточно 30 проектов/ответов на запросы. То есть немного! [https://www.facebook.com/mtsepkov/posts/1952665734790371 Пост на FB] '''Дмитрий Безуглый. Прикладная цифровая революция. От разделения труда к совместному мышлению'''. У доклада получилось два слоя, и один - очень крут. Это про интерпретацию Кеневин (Cynefin) фреймворка как пути технологии, от области хаоса где работают фантазеры и визионеры, через запутанную (complex) область исследователей и сложную (complicated) область инженеров, делающих решение в простую область готовых изделий для конечных пользователей. При этом современный digital-мир требует протаскивания новых продуктов и технологий по всей этой области вместо прежнего традиционного разделения труда между различными институтами. И происходит это за счет того, что операционная стоимость организации производства за счет digital-технологий (3d-принтинг, облачные инфраструктуры и многое другое) почти обнуляется. А это, в свою очередь, обрушивает традиционный цикл улучшений Деминга и многое другое из классического менеджмента, которые вообще не смотрят на исследования, теоретическую работы и визионерство, потому что они были вынесены из производства в другие институты.

= Про Agile. Алексей Пименов и Сергей Кушнир = А эти доклады я объединяю, потому что доклад Сергея Кушнира по сути дает частный пример для того, о чем рассказывал Алексей Пименов. [https://www.facebook.com/mtsepkov/posts/1952615644795380 Пост на FB] '''Алексей Пименов. LeanKanban подход к оценке и прогнозированию проектов'''. Начался с сильного утверждения: на основе анализа мирового опыта выполнения проектов: нет корреляции между оценками проектов и реальными сроками выполнения. Поэтому идея: вместо оценки и диаграмм Ганта использовать SLA. Основа - спектральные диаграммы LEAN, которые позволяют ретроспективно выявить потоки характерных проектов, и работать с ними. Дальше делаем типологию и чеклист классификации. И дальше накладываем на спектральную диаграмму - и проверяем, что получилась характерная диаграмма нужного распределения. Нормальное, пуассоново, и обобщенное распределение Вейбла - ширина пика и отстояние пика от матожидания. Из этих данных можно извлекать полезное для предсказуемости. Например, если много коротких запросов - точно можно вычленить для оптимизации. Но! Проблема есть толстых хвостов: fat tail. Вы обеспечиваете сервис заказчику, прилетает толстый хвост и убивает компанию. Почему прилетает толстый хвост? Есть вариант, что в процессе реализации прилетают все новые запросы. А также многочисленные возвраты на доработку или рефакторинг. Делаем диаграмму потоков работ. Проблемные точки* Синхронизация разных потоков* Возвраты на переработку* Блокировки по ресурсам: людям, внешним зависимостям, взаимодействие с заказчиком Влияние блокировок и других проблемных точек перевешивает влияние трудозатрат. Leak time против время касания проекта. Не путать время касания с трудозатратами - потому что может быть очень малые трудозатраты. Эффективность потока: время касания к времени производства. Обычно лишь 5-15% И надо признаться, что наши проекты больше стоят, чем идут - при том, что мы следим, чтобы "все работали". Компания, работающая на накопление знаний - сервисно-ориентированная. Разработка софта - такая же. В сервисе может быть несколько способов обслуживания. Эскалатор. Если все стоят на каждой ступеньке, одинаковое обслуживание - поднимется больше, но все одинаково. Если справа стоят, проходят слева - то в целом поднимется меньше, но некоторые - быстрее. Дальше очень часто есть варианты проектов одного типа. Надо провести анализ* Что-горело* Работа в обычном ритме* Проект не слишком важен изначально. Дальше делаем классы проектов: горящие, обычные и фоновые. А дальше - еще ставим лимиты, сколько мы делаем каких проектов. Горящих проектов не может быть слишком много. Если проект уходит в толстый хвост - ему можно поднять класс обслуживания. И можно отслеживать и принимать решения. Данных много не надо. Был кейс с рекрутерами - данных за два месяца хватило. И нашли любопытный толстый хвост. Когда программист-кандидат разослал резюме в несколько мест, получил оферы и приходит к начальству и требует повышения, ему дают - и закрытие вакансии у всех вылетело в толстый хвост. Про 5-15% - исследование Microsoft по проектам своих и партнеров примерно в 2009. Его опыт подтверждает. Подход cocoma - на выделенную команду. А реально есть разброс по ресурсам и впихивания заказчиками работ. И это нарушает детерминистический подход - его ломает плохой менеджмент. А здесь мы смотрим, что реально у нас получается с нашим плохим менеджментом, и прогнозируем из этого. В ответах на вопросы: для первой статистики в среднем достаточно 30 проектов/ответов на запросы. То есть немного! [https://www.facebook.com/mtsepkov/posts/1952730434783901 Пост на FB] '''Сергей Кушнир. Reliable Scrum: итеративная разработка и жесткие сроки. Опыт применения'''. Практический доклад про решение в команде. Ситуация - команда работает с крупными задачами, которые помещаются 1-2 в спринт, при этом идет поток багов и срочных задач. И воронка проблем затягивалось, было несколько попыток решения. А дальше было решение - выделение отдельного буфера для дополнительных задач, контроль за ним, параллельно с основными задачами, за которыми тоже идет контроль. И всякие нарушения, например, впихивание задач хитрого product owner - мгновенно стало видно. В целом решение успешно, производительность выросла, и воронка пошла раскручиваться. При этом, что интересно, люди не верили и не верят, даже внутри компании, что такие относительно простые решения могли так изменить ситуацию, и ищут подвох.

[https://www.facebook.com/mtsepkov/posts/1952896208100657 1951424254914519 Пост на FB] Александр Турханов (Alexander Turkhanov)'''Игорь Агамирзян''' - размышления о развитии разработки. Распределенное лидерство Фантастическое ускорение процесса разработки и SysArchiне менее фантастическое ухудшение качества. Очень интересный опыт. Александр Турханов читает курс системного лидерства в школе Анатолия Левенчука. Рассказывал он про распределенное лидерство в строгой модели - мы делим лидерские обязанности между стейкхолдерскими ролями, которые при этом могут совмещаться в одном человеке, или быть распределены между разными людьми. При этом случай совмещения По очень многим приложениях прикладная система использует ресурсы процессоров и возникающих взаимодействий тоже разбирался памяти максимум на конкретном примере: Александр-business-actor ставит Алксандру-спикеру задачу выступления на конференции, исходя из собственных интересов1% от достижимого при аккуратном программировании. И обозначено не просто переключение между позициями, а смена онтологии, свойственной каждой позицииОбъем приложения FB за последние 2 года вырос в 2 раза. А функционал? И еще отдельная позиция, Player, который отвечает за смену позиции, и которых тоже сейчас у человека может быть нескольконас кризис практического программирования. При этом позиции стейкхолдеров нормативно закреплены в культуреЭкстенсивный рост, мы имеем 200-300 стейкхолдерских позиций на отрасль. А Archimate и его редактор SysArchi позволяет все это формально описывать, и эта часть тоже была в докладепри чем без роста функционала.

Доклад был на английском : Интересный комент от Дениса Бескова: А чем эти rants отличаются от Software Crisis 50- летней давности? https://ru.wikipedia.org/wiki/Кризис_программного_обеспечения : Мой ответ: Это - хороший вопрос. Потому что все это часть эксперимента SECRвремя разработка софта развивалась, позволяющая докладчикам и слушателям прокачать свой скилл английского языкадавай новые приемлемые решения в ответ на проблемы - языки высокого уровня, системы сontinious integration/delivery, agile-процессы разработки, автотесты, многое другое. И поэтому я Пожалуй, сейчас проблема состоит в том, что требуется массовая разработка софта, управляющего интернетом вещей, для которых требуется сложность и надежность, ранее достигаемая только для квалифицированных инженерных решений (типа бортового софта автомобилей), и сознательно не постил впечатления достигаемая в темпе доклада массовых (например, в web- этого я пока не умею. А то бы было много большесайтах), и это - в условиях относительного дефицита мощности устройств, а также распределенного между устройствами исполнения.

В комментарии Александр Турханов раскрыл тезисы[https:# Deloitte Unversity Press в 2017 опубликовал отчет Human Capital Trends, в котором 9 тысяч менеджеров из 130 стран мира сказали, что лидерство для них важно//www.facebook.com/mtsepkov/posts/1951570701566541 Пост на FB] '''Орхан Гасымов. Современная микросервисная архитектура'''. Несколько шагов преобразования от классического монолитного приложения. (1) делим монолит на маленькие сервисы, которые можно масштабируемо поднимать. Нужен реестр сервисов и 85% считают, что модель лидерства должна измениться. При этом мы думаем о командах в терминах 100-летней давностимаршрутизатор с балансировкой нагрузки, а софта для управления лидерством нетвместо больших серверов получаем много легких.Мы инженеры (2) Сами сервисы делим на Command и должны такой софт сделатьQuery, я расскажу какшаблон CQRS.# Традиционная модель лидерства (3) Команды реализуем через event sourcing - пишем журнал/очередь команд-событий, и недостатки мышления о команде в терминах "оргих обработчики.структура" и "оргНикаких синхронных вызовов между сервисами.звено". В "матричных" организациях (4) Обработчики событий - через паттерн reactor - идет один человек входит в множество оргосновной обработчик, который все тяжелые запросы раскидывает на внешние потоки.звеньев и его должность не говорит нам ничего о фактических интересахИ каждый отдельный элемент этой конструкции - легкий. Но СЕО всегда так жили, так что надо Модуль - просто разобраться, как же это работаетнабор функций. В целом - реализуем реактивный манифест.# История распределенного лидерства[https://www. Военкаfacebook.com/mtsepkov/posts/1951638554893089 Пост на FB] '''Александр Леонов, японские корпорации и "ба"Анатолий Кушниренко, Евроконтроль и ответственность каждого за безопасность, адаптация распределенного лидерства коммерческими компаниямиНикита Бесшапошников.# Определение распределенного лидерства Введение в терминах системного подходакооперативное программирование''': персональная ответственность - коллективный результат.# Главный источник дополнительных возможностей команды Совершенно неожиданно - управление ее вниманием.# Классическое управление вниманием доклад был про обучение 6-летних детей программированию в маленьких командах. Практика управления ресурсами команды (crew resource management/team resource management) детских садах в операционной комнатеСургуте. Метафора хирургической операции и зоны внимания и ответственности членов командыУспешно. Трудности переноса практик CRM в проекты по разработке софта.# От управления индивидуальным фокусом и потоком к управлению командным фокусом и потоком.# Как SysArchi поддерживает системное мышление в командах. Системное мышление как управление вниманием.# Механистичен или нет системный подход? Стейкхолдеры.# Названия должностей не При этом дети работаюткооперативно: каждый пишет программу для своего робота, поэтому надо уметь различать стейкхолдеров и понимать их взаимодействие. Так вы сможете построить влияние а роботы работают в проекте даже если у вас нет полномочий. В одной индустрии могут быть тысячи названий должностей общем поле и оргдолжны действовать согласовано.звеньевИ 6-летки реально решают сложные задачи, но всего 200у них цель -300 стейкхолдерских ролей. Знаете их и можете разговаривать по сути с кем угодно.# Аристотелевская схема "субъектдовести к 3 классу до полной программы 11-действие-объект" в системном подходелетней школы. СтейкхолдерРешаются сложные задачи -практика-объекты практикисинхронизации, управления кланами роботов. Ключевой момент лидерства - "прогрузить" нужные концепции в голову исполнителей. И вот как SysArchi помогает в При этом.# Отличие SysArchi от канбан.# Как научить свою команду правильно строить theory of mind (модель психических состояний) других членов командыдетей соорганизуются, друг другу помогают, чтобы предсказывать и влиять на поведениено при этом программу своему роботу каждый должен написать сам.Круто!# Человека в организации можно рассматривать как орг.звеноПри этом занятия ведут обычные воспитатели, как стейкхолдера и как актера (внутреннего режиссераобычно 40-летние женщины, который переключает роли)после переподготовки.# Да, это все похоже на Дорофеева, но тут поддержано архитектурной моделью в репозитории! Они знают группу, поэтому круче.# С точки зрения системного подхода эта трехчастная модель человека в организации есть разделение интересов и мультидисциплинарность. Команда как система. На каждом системном уровне свои организационноесли ты группу не знаешь -технические решения по тому, как устроено распределенное лидерствомаксимум 6 человек.# Проблема с классическим определением команды и концептуальный переход от командного стиля управления к распределенному.# ФункциональноПотому что если 6-конструктивное определение командылетний ребенок застрял, два типа системных моделей командыто есть 1. Общая системная модель команды помогает координировано ее строить5 минуты, причем каждый может взять тот кусочекчтобы ему помочь, который ему интересениначе он выпал. Управление фокусом внимания команды по онтологическому описанию проекта.# Архитектурная модель проекта и операционное табло (канбан) как основа сложной координации и коллаборации.# От команд обратно к людям. Техники управления индивидуальным вниманием от Брюса Тулгана.# Обоснование необходимости распределенного лидерства из-за нехватки времени руководителя на разговоры со всеми.# Описание технологии, ссылки на соглашение о моделировании и бесплатный редактор Archi. [https://www.archimatetoolfacebook.com/mtsepkov/posts/1952736568116621 Пост на FB] '''Слайды https://yadiАлександр Колесников.sk/i/DgjcxXh3yPjQIAПоддержка работы управления проектами'''. TFS - наше все. Потому что (и это - за рамками доклада). И вокруг - лоскутное одеяло разных систем, потому что TFS не хватает - например, тренд за год не посмотреть. И они снаружи прикрутили Grafana для мониторинга состояния проекта - и оно получилось. Об этом и был доклад. При этом примеры графиков в докладе - высокотехнологичные, примерно такие, которые используются для мониторинга нагрузки на продуктовые сервера и другую инфраструктуру. НО IT-шники - вполне разбираются. Мониторят ход проектов так же, как мониторят продуктовые сервера, предсказывают клиентские обращения и многое другое.