2018-10-15: SECR - много общения и качественных докладов

Материал из MaksWiki
Перейти к: навигация, поиск
Короткая ссылка: SECR-2018
О других конференциях
Пост на FB
Фото Димы Безуглого
Максим Цепков за работой по аккуратному извлечению смыслов на SECR

Пожалуй, прошедшая конференция SECR стала для меня первой конференцией, на которой я из-за общения в кулуарах пропустил много докладов, на которые планировал пойти. И еще больше докладов, на которые я не пошел, потому что они конкурировали с другими докладами, или с общением, а по названию или аннотации я их не отметил к посещению. Это происходит потому, что на SECR - замечательные участники, с которыми интересно разговаривать и можно узнать много содержательного.

Из отзыва Тимофей Левицкого на конференцию, показывающего особенности аудитории SECR: Всё-таки полезно ездить по конференциям. Особенно выступать. Столько нового узнаёшь! Приехал поведать коллегам, как правильно "дружить" стартапы и корпорации. Хорошо, вовремя сообразил, что на SECR ходит много хорошо подготовленных слушателей, которым интересно не потому, что ух ты всё такое новое, а потому, что они знают 80% ответа (и поэтому у них хорошие вопросы). Вот благодаря вопросам многое удалось прояснить). И почему "песочница" обычно не работает, и почему "акселератор" может внезапно сам замереть... Ольга Самарина, спасибо!

Зато многие доклады мне придется смотреть: Филипп Дельгядо "Каждой фазе проекта – своя методология. Как и зачем", Евгений Зиндер "Архитектурное мышление и планирование software-продуктов для цифровых предприятий", Кирилл Улитин " Исследование эмоциональных откликов при чтении документа", где инструмент исследования - нейрошлем, Игорь Дёмин "Кратчайшая история криптоанархии", Сергей Нужненко "Проектирование системы, как процесс мышления", Светлана Мухина "Коучинг Скрам Мастеров. Истории успеха и другие происшествия", Ксения Антонова "DeepDive with experts: share to improve", и другие.

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

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

Анатолий Левенчук. Стейхолдерское мастерство

Пост на FB Анатолий Левенчук. Стейкхолдерское мастерство - подробный рассказ в театральной метафоре. Стейкхолдер: действующее лицо из театральной метафоры. Принц Гамлет и есть - исполнитель. В театре - понятно, обращаемся к роли или актеру. А в жизни - путаем.

Но дальше - следующие шаги. Лидер в театральной метафоре - это режиссер. Курсы лидерства - есть, там режиссеров учат заталкивать людей в требуемые роли. В то время, как люди не хотят. А вот актеров занимать роли - не учат. Вернее, настоящих-то актеров учат - держать в голове 20 ролей, не сливаться с ними, подирать роли для своего амплуа. А вот в жизни сотрудников - не учат занимать роли. А это нужно.

Чему нужно учить:

  • Прикладные дисциплины (роли) - за них платят
  • Кругозор - пьеса целиком, менеджмент, инженерия, предпринимательство
  • мировозрение и методология - возможность импровизировать и сочинять роли, выбирать роли, находить и признавать ошибки
  • когнитивистские дисциплины - актерское/стейкхолдерское мастерство, умение учиться. антипрокрастинация.

Большинство педагогов работают как мастер - соло. Без разделения труда и разделения работ. Моделирование - мало и неформальное.

А правильно - инженерный подход. Не "я сам себе мастер", а "мы сами себе инженеры" - коллективная работа. Множество ролей, множество обучающих и так далее. Человек не проще атомной станции - и работать надо соответственно.

Модель личности

  • Воля/намерение/надзиратель
  • Актер (стейкхолдерские роли)
  • Экзокортекс внешние диаграммы+тексты - передали другому, компьютер сам подумал
  • Экзотело - инструменты: мышка/гоночный автомобиль как часть тела, были эксперименты.
  • Тело/перформер
  • Бессознательное, биохимия, рефлексы и эмоции.

У нас - киберличность, а не личность - экзокортекс, экзотело.

Внимание - можно не медитировать, а просто за полминуты записать. Те же вечные ценности, но другими методы.

Психотехника удержание внимания на двух фокусах.

  • стейкхолдер - правильная онтология и действия
  • актер - вынимать правильные роли из головы, перебирать. Не преображаться в принца Гамлета полностью.
  • Воля-надзиратель должен это удерживать (как отдельный фокус)

Каждый учебник - учебник игры по роли. Группа - вместе играем пьесу. Скооперируйся с другими группами для большого представления. Включая мертвых - они участвуют через книжки.

А когда режиссер-лидер заталкивает себя в роль - понимай, что происходит и сознательно соглашайся или отказывайся. И если уж согласился - играй честно.

Вообще пересказывать сложно, но - как есть. А так - будет запись, смотрите.

Анатолий Левенчук Вот слайды: https://www.slideshare.net/ailev/ss-119256332 (для страдающих от Роскомпозора -- https://yadi.sk/i/3sKV-D10PiDGMQ)

Из обсуждения. Вадим Овечкин Генеральный директор - роль?

Александр Турханов Генеральный директор - это организационное звено, т.к. г.д. про полномочия и ответственность. Роль - это про поведение. Орг. звено назначается на роль/роли. Генеральный директор может быть разработчиком продукта, маркетологом, финансистом, производственником, клиентом.

Александр Турханов. Распределенное лидерство и SysArchi

Пост на FB Александр Турханов. Распределенное лидерство и SysArchi. Очень интересный опыт. Александр Турханов читает курс системного лидерства в школе Анатолия Левенчука. Рассказывал он про распределенное лидерство в строгой модели - мы делим лидерские обязанности между стейкхолдерскими ролями, которые при этом могут совмещаться в одном человеке, или быть распределены между разными людьми. При этом случай совмещения и возникающих взаимодействий тоже разбирался на конкретном примере: Александр-business-actor ставит Алксандру-спикеру задачу выступления на конференции, исходя из собственных интересов. И обозначено не просто переключение между позициями, а смена онтологии, свойственной каждой позиции. И еще отдельная позиция, Player, который отвечает за смену позиции, и которых тоже у человека может быть несколько. При этом позиции стейкхолдеров нормативно закреплены в культуре, мы имеем 200-300 стейкхолдерских позиций на отрасль. А Archimate и его редактор SysArchi позволяет все это формально описывать, и эта часть тоже была в докладе.

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

В комментарии Александр Турханов раскрыл тезисы:

  1. Deloitte Unversity Press в 2017 опубликовал отчет Human Capital Trends, в котором 9 тысяч менеджеров из 130 стран мира сказали, что лидерство для них важно, и 85% считают, что модель лидерства должна измениться. При этом мы думаем о командах в терминах 100-летней давности, а софта для управления лидерством нет.

Мы инженеры и должны такой софт сделать, я расскажу как.

  1. Традиционная модель лидерства и недостатки мышления о команде в терминах "орг.структура" и "орг.звено". В "матричных" организациях один человек входит в множество орг.звеньев и его должность не говорит нам ничего о фактических интересах. Но СЕО всегда так жили, так что надо просто разобраться, как же это работает.
  2. История распределенного лидерства. Военка, японские корпорации и "ба", Евроконтроль и ответственность каждого за безопасность, адаптация распределенного лидерства коммерческими компаниями.
  3. Определение распределенного лидерства в терминах системного подхода.
  4. Главный источник дополнительных возможностей команды - управление ее вниманием.
  5. Классическое управление вниманием в маленьких командах. Практика управления ресурсами команды (crew resource management/team resource management) в операционной комнате. Метафора хирургической операции и зоны внимания и ответственности членов команды. Трудности переноса практик CRM в проекты по разработке софта.
  6. От управления индивидуальным фокусом и потоком к управлению командным фокусом и потоком.
  7. Как SysArchi поддерживает системное мышление в командах. Системное мышление как управление вниманием.
  8. Механистичен или нет системный подход? Стейкхолдеры.
  9. Названия должностей не работают, поэтому надо уметь различать стейкхолдеров и понимать их взаимодействие. Так вы сможете построить влияние в проекте даже если у вас нет полномочий. В одной индустрии могут быть тысячи названий должностей и орг.звеньев, но всего 200-300 стейкхолдерских ролей. Знаете их и можете разговаривать по сути с кем угодно.
  10. Аристотелевская схема "субъект-действие-объект" в системном подходе. Стейкхолдер-практика-объекты практики. Ключевой момент лидерства - "прогрузить" нужные концепции в голову исполнителей. И вот как SysArchi помогает в этом.
  11. Отличие SysArchi от канбан.
  12. Как научить свою команду правильно строить theory of mind (модель психических состояний) других членов команды, чтобы предсказывать и влиять на поведение.
  13. Человека в организации можно рассматривать как орг.звено, как стейкхолдера и как актера (внутреннего режиссера, который переключает роли).
  14. Да, это все похоже на Дорофеева, но тут поддержано архитектурной моделью в репозитории, поэтому круче.
  15. С точки зрения системного подхода эта трехчастная модель человека в организации есть разделение интересов и мультидисциплинарность. Команда как система. На каждом системном уровне свои организационно-технические решения по тому, как устроено распределенное лидерство.
  16. Проблема с классическим определением команды и концептуальный переход от командного стиля управления к распределенному.
  17. Функционально-конструктивное определение команды, два типа системных моделей команды. Общая системная модель команды помогает координировано ее строить, причем каждый может взять тот кусочек, который ему интересен. Управление фокусом внимания команды по онтологическому описанию проекта.
  18. Архитектурная модель проекта и операционное табло (канбан) как основа сложной координации и коллаборации.
  19. От команд обратно к людям. Техники управления индивидуальным вниманием от Брюса Тулгана.
  20. Обоснование необходимости распределенного лидерства из-за нехватки времени руководителя на разговоры со всеми.
  21. Описание технологии, ссылки на соглашение о моделировании и бесплатный редактор Archi. https://www.archimatetool.com

Слайды https://yadi.sk/i/DgjcxXh3yPjQIA

Анатолий Левенчук. Как и какое мышление нужно развивать

Пост на FB Анатолий Левенчук. Как и какое мышление нужно развивать. Журнал выступления - оно того стоит.

Позиционирование: Ты - говоришь мысли другим деятелям, или деятель сам, воплощаешь свои мысли в реальность?

Сколько процентов занимаетесь будущим, а сколько - текучкой? Винни-Пух знал, что есть другой способ подниматься по лестнице и точно его бы вспомнил, если бы так не бумкало в голове. А вы готовитесь к будущему - у вас текучка сильно булькает?

Denis Beskov «Сколько процентов времени (и денег) вы сами занимаетесь будущим» — март 2018, полгода назад: https://ailev.livejournal.com/1413814.html слайды полуторагодовой давности

Чем не займетесь: помним, что не всех извозчиков взяли в таксисты? А сейчас и таксисты исчезнут, и nvidia уже презентовала автомобильный компьютер, который провел автомобиль 180 километров по силиконовой долине. И суперкомпьютер, чтобы учить этот компьютер ездить по дорогам.

Denis Beskov «не всех извочиков взяли в таксисты» 2011-й год, 7 лет назад: https://ailev.livejournal.com/929655.html

Будущее - как туман: вблизи все в прозрачно, в трех метрах может быть невидимая стена, а все изменения приходят сбоку. Не новый тип лошадей пришел в извозчичье хозяйство. И Яндекс в такси сбоку пришел. Различать прорывные и подрывные технологии. Цифровой фотоаппарат заменил пленочный. А потом пришел смартфон и заменил не только фотоаппарат, а еще многое другое и даже сказки на ночь рассказывает.

Denis Beskov про nvidia и подрывные/прорывные — полгода назад: https://ailev.livejournal.com/1416697.html

ИИ - контринтуитивные суждения

  • НЕ человек
  • НЕ персонаж
  • НЕ субъект - обсуждаем классы решаемых задач
  • НЕ классическая мат.логика. Там инженерная и физическая математика.
  • ИИ отмоделировал интуицию, чуйку - и она лучше человеческой оказалась.
  • Пока моделированная чуйка и логическое размышление - не дружат друг с другом. Но быстро развивается.
  • Регулярно публикуются тесты задач, которые люди ПОКА решают лучше, чем компьютеры. Держатся недолго.
  • AI - творческий. И создает архитектуру, в том числе - собственную.

Миф целеполагания: все важное приходит сбоку, поэтому неизменно идти к конкретной цели - обман. Цель вообще можно поставить только в ограниченной области прозрачности тумана. Надо уметь жить, не выставляя точных целей. Но оптимизируя полезность и многое другое - как в играх.

Denis Beskov против целей — 2,5 года назад: https://ailev.livejournal.com/1254147.html

Критерий новизны: мнения экспертов разошлись, им непонятно, что там есть. Это было мнение для инвестфондов: выдавать гранты там, где мнения разделились. Потому что когда все "за" - там будет громадное количество конкурентов и мало профита.

Переход от стратегии к стратегированию - потому что движения в тумане, а он не линеен.

Моя реплика: Оказывается, я все делаю правильно: я не строю планы по достижению целей, я подвешиваю желаемые образы будущего, и дальше ищу подходящие случаи. Вообще Мизес называл этот подход "предпринимательской бдительностью".

Мы работаем не с начальником, а с таск-трекером. Потому что начальник - не помнит, а такс-трекер - помнит все задачи. А вот если мы начинаем не слушаться таск-трекера - тут-то приходит начальник :)

Закат профессий. Разотождествляйтесь с профессией. А вот компетенции - останутся. Особенно базовые - онтологии, психопрактики, когнитивное мышление.

Требования к базовому мышлению

  • Абстрагирование - держать фокус внимания на важном в окружающем мире. Фундаментальные дисциплины как чеклисты.
  • Адекватность - соотнесение моделей мира с реальным физическим миром. 4D, научное мышление.
  • Осознанность - стейкхолдерское мастерство. Сознательное занятие позиций, в том числе онтологическое, менять онтологии при занятии позиций.
  • Рациональность - state-of-the-art в логике (правила рассуждений, статистическая рациональность) и онтологии (о чем рассуждаем). Я - мир - модель. Я художник, я так вижу - работает плохо.

Пирамида абстракций. Фундаментальные дисциплины.

  • Функциональная грамотность
  • Онтологика
  • Системное мышление (системная инженерия, системный менеджмент, системная педагогика)
  • Научное мышление

А дальше - кругозор. Представление о всех областях деятельности: требования (use case 2.0, jobs-to-be-done и т.п.), управление работами (проектное, потоковое), системное лидерство, баа концепций и так далее.

Видим реальные объекты, поднимаемся по уровням абстракции, мыслим, возвращаемся в реальную жизнь.

domain driven design - тип онтологических процедур и надо это понимать, чтобы его использовать.

Трехдневные курсы не работают без базового образования. А вот двухчасовые доклады - работают, они дают список чеклистов.

Дисциплины по трем сферам деятельности:

  • системная инженерия: концепт, требования, системная архитектура, управление конфигурацией и жизненным циклом, проверка и приемка
  • системный менеджмент: операционный, цепи поставок и логистика, управленческий учет и контроллинг, и т.п.
  • системное предпринимательство: стратегирование, маркетинг-коммуникации, рекламы-продажи ...
  • и все остальное

Вы понимаете такое деление, мыслите в этих дисциплинах?

Научное мышление. Содержание изменилось

  • Логика - байесовская и причинная
  • Понятие объективности, позитивизм, прагматическая революция

Вычислительное мышление: содержание изменилось. deep learning, язык отражает пространство смыслов.

Работа и со схемой, а со схемоидами. А схемоиды - это псевдокод. Нужны и схемы и схемоиды - интуиция и логическое мышление, гипотезы из схемоидов, проверка логикой, и так далее, перемещение по спектру формальности. И надо учить всем частям спектра и, главное, перемещению по спектру определенности - а этому не учат.

Фундаментальное образование - методологические дисциплины

  • Онтологика-1 (про агентов, модели, мир, логики)
  • Онтологика-2 (научное мышление, причины, вывод, выбор, этика утилитаризма). Надо учить инженеров думать об этических проблемах.
  • Системное мышление, плюс системное творчество
  • Вычислительное мышление, включая AI и моделирование, абстрагирование, декомпозиция и многое другое

Применять результаты образования - в жизни. Курсов не достаточно. Курсы - для жизни, а не для образования.

Надежда - на себя, а не на государство. Университеты - закрыть, те, кто умеют учить - соорганизуются и будут учить лучше государства. Он выдает курсы образования гораздо быстрее, чем в государственной системе.

Когнитивисткие дисциплины

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

Люди читают мой учебник и не могут вычитать то, что там написано. Не дают ответы, которые практически есть в учебнике - 97% неправильных ответов с курса на курсере.

Обучение: нельзя поднимать то место, где у вас совсем ноль, не получится. Можно прокачивать то. что у вас уже есть, но недостаточно - прокачивая, поднимаешь следующее. Есть много стратегий чтения книг, мышления. Getting Things Done - одна из них. Изучайте стратегии, выбирайте их.

Denis Beskov Он вроде все это рассказывал В ТЕЧЕНИЕ ПОСЛЕДНИХ 5 лет (на самом деле минимум 7)

Максим Цепков Нет, это - свежий материал, этого про мышление - не было. Я за блогом слежу.
Denis Beskov Максим Цепков ЗА 5 лет
Анатолий Левенчук В докладе на каждой странице по ссылке на какие-то мои материалы. Я сделал это, чтобы было удобней проверять, насколько материал свежий. Иногда там и пара ссылок.
Максим Цепков В общем, Денис постарался привести много ссылок. показывающих, что фрагменты доклада уже были. Конечно фрагменты были, и в самом докладе много ссылок, а благодаря Денису люди смогут и из поста перейти. А сборка доклада - точно новая и приличная часть материала, на мой взгляд, тоже.

Denis Beskov О, в программе был заявлен как мастер-класс. Неужели Анатолий реально продемонстрировал на себе или на людях в зале развитие мышления?

Анатолий Левенчук Похоже, что да, продемонстрировал -- ко мне потом подходили разные люди и говорили, что этот мастер-класс сильно повернул им голову. И я этим людям верю.
Denis Beskov И что, кто-то смог этому научиться, повторяя за вами — а именно, развивать своё мышление?
Анатолий Левенчук То есть я за 1 час 50 минут научу развивать мышление, а потом ещё и верифицирую и валидирую это научение -- это ожидается? Но формально всё, вроде, правильно -- именно так нужно спрашивать, только вопрос от этого не становится осмысленным содержательно.
Denis Beskov Анатолий Левенчук а кто вам мешает встроить в мастер-класс механизмы проверки научения? хотя бы в форме домашнего задания с гугл-формой (регистрируйтесь по этой форме, сегодня вечером вам придёт задание на неделю)?
Анатолий Левенчук В мастер-класс таки встроено домашнее задание -- если присмотреться, то на слайдах есть места, где нужно чекать свой уровень подготовки по отдельным дисциплинам. И принимать на основе их решения -- и тоже их вписывать в слайд.

Но нужно быть реалистом: с проверкой результатов обучения в таких двухчасовых ориентационных курсах всё плохо (что, вставлять проверку того, поняли ли люди идею фундаментального образования и необходимости кругозора?). И её нельзя автоматизировать, так что это ещё и дорого (а когда можно автоматизировать, то это всё равно дорого). И мало кто на неё пойдёт, так что это ещё и утопично. И контекст этих часа пятидесяти -- это контекст конференции, где этих докладов пять треков в параллель, так что любые результаты (кроме экстраординарных) смоются в забвение.

Но потрындеть на тему "как правильно проводить мастер-классы на конференциях" я всегда готов. "Правильно" при этом почему-то оказывается нереалистичным, но это чёрт с ним.
Можно продолжить: почему у меня в учебник не всунуты механизмы проверки научения, или хотя бы проверки, дочитал ли читатель учебник до конца! Хотя бы это проверять!
При этом формат "мастер-класс" -- это никто не знает, что такое, канона нет. Переобзови это keytalk (а это оно и было) и жизнь изменится, все критерии поплывут, оценка мероприятия изменится, хотя в мероприятии ничего не поменялось.
Для меня самого это был просто развёрнутый ответ на некоторые вопросы дискуссии по вопросам IT-образования (не на все вопросы, ибо я не касался собственно software engineering), каковая дискуссия была в этом зале за пару часов до этого моего выступления. Я так и сказал в начале выступления.
Что вынесли люди из доклада? Каждый своё. Ползала доставала телефоны в какие-то моменты доклада и фотографировала слайды. Так что что-то люди унесли с собой, это гарантированно )))
Denis Beskov Анатолий Левенчук ну вот на product camp minsk пару лет назад Иван Замесин (Ivan Zamesin) отлично давал задание на кастдев в зал и потом в течение недели-двух собирал результаты. Иван, расскажи, насколько дорого это получилось?
Анатолий Левенчук Собрать результаты недорого. Дорого с ними потом работать, чтобы это было осмысленным. Но у каждого курса, у каждого задания и у каждого препода своё понятие "дорого".
В Школе системного менеджмента на платных курсах есть и домашние задания, и их проверка. И в зависимости от их выполнения выдаются сертификаты "прослушал" или "освоил" курс. Тут же речь идёт о конференции и keytalk. Рекомендую поговорить на эту тему с Бертраном Мейером или Игорем Агамирзяном, предложить им те же идеи с домашними заданиями и сказать им, что "недорого будет". А я ведь в том же ряду был со своим докладом.
Иван Замесин Denis Beskov https://medium.com/@zamesin/yo-rocks-92b29a559258 детали эксперимента. Потратил часа два и 2 тысячи рублей на книжки
Анатолий Левенчук Мы как-то с Maxim Dorofeev обсуждали разницу между прокрастинацией в делах "записаться на курс английского языка" (по факту -- поменять образ жизни) и "провести 25-минутное интервью" (и считать успешно обученным того, кто его таки провёл, независимо от результата). Увы, у меня материал доклада даже не про одиночные курсы, а про фундаментальное образование в целом. Так что опыт хороший, но не для моих целей. Если бы после двухчасового доклада 60% аудитории поступила бы в какой-то вуз, и потом закончила его, вот это было бы интересно.

Анатолий Левенчук Вот слайды -- https://www.slideshare.net/ailev/ss-119256910 (для страдающих от Роскомпозора -- https://yadi.sk/i/UpV8v-WFOEbX8Q)

Мой доклад и доклад Дмитрия Безуглого

Эта связка - потому что доклады были подряд, и обсуждения их в постах на FB тоже оказались взаимосвязаны.

Пост на FB Мой доклад Мыслить проектно: история и современность (SECR-2018). В посте Димы Безуглого продолжается большое обсуждение, читайте...

Фото Димы Безуглого

Дмитрий Безуглый О проектном мышлении, о том что у них не получалось разрабатывать по 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-ого. Но снижение порога имеет свою цену ..

Пост на FB Дмитрий Безуглый. Прикладная цифровая революция. От разделения труда к совместному мышлению. У доклада получилось два слоя, и один - очень крут. Это про интерпретацию Кеневин (Cynefin) фреймворка как пути технологии, от области хаоса где работают фантазеры и визионеры, через запутанную (complex) область исследователей и сложную (complicated) область инженеров, делающих решение в простую область готовых изделий для конечных пользователей. При этом современный digital-мир требует протаскивания новых продуктов и технологий по всей этой области вместо прежнего традиционного разделения труда между различными институтами. И происходит это за счет того, что операционная стоимость организации производства за счет digital-технологий (3d-принтинг, облачные инфраструктуры и многое другое) почти обнуляется. А это, в свою очередь, обрушивает традиционный цикл улучшений Деминга и многое другое из классического менеджмента, которые вообще не смотрят на исследования, теоретическую работы и визионерство, потому что они были вынесены из производства в другие институты.

Это - реально крутая и прорывная часть. А еще был слой, связанный с сильными эмоциональными нападками на Agile в его поп-варианте, который представлялся как единственный, и в этом варианте сильно отменил инженерную культуру. Я не знаю, насколько это спровоцировал мой предыдущий доклад, где я наоброт, показывал несоответствие классической инженерной культуры в современных условиях, и необходимость ее переосмысления для современности. Собственно, то, что делает Дима в основном содержании доклада - и есть это переосмысление, и, более того, место и роль Agile-практик там тоже указано. Но переосмысление надо сравнивать с идеальными объектами, а не с плохим использованием - иначе оно не доказательно. Про плохую практику и так все понимают, и надо либо показывать, что у теории не может быть хорошей практики - а это не соответствует действительности, либо сравнивать и теорию и практику параллельно. Собственно, такая двухслойная структура сильно мешает восприятию, на прогоне доклада ее не было и он воспринимался гораздо лучше. И отзыв в ходе доклада я не смог написать по этой же причине - поверхностный слой вытесняет содержание.

Обсуждение.

Дмитрий Безуглый Ты прав, меня спровоцировали твои голословные утверждения основанные на плохой практике на предыдущем докладе о не работающей инженерной культуре. И как раз поверхностность доминирующей культуры Agile пропаганды сильно мешает результативности трансформаций.

Игорь Беспальчук Дмитрий Безуглый Ох уж эти вопросы веры при невозможности нормально что-то измерить :) Кстати, может манифест инженерного/знаниевого подхода к организации разработки ПО надо написать? Мы верим, мы ценим, одно важнее другого...
Дмитрий Безуглый Игорь Беспальчук Да было бы неплохо )))
Дмитрий Баранов Dmitry Bezuglyy И хорошо бы не противоречить при этом этическому коду инженера https://www.nspe.org/resources/ethics/code-ethics
Максим Цепков У меня не голословные обвинения. Я раскрыл в чем именно инженерная культура не работает.
1) в инженерной культуре все написание кода правильно относить к части разработки описания (проекта) системы, которая слабо поддается нормированию, с соответствующими подходами к оценке проекта. В то время как инженеры-IT-шники относят кодирование к производству. Обосновал Reeves в 1992, статья признана, на нее ссылаются, тем не менее традицию продолжают вплоть до OMG Essence, который делали инженеры: код программы в альфе "Software System", а в System Engineering он должен быть в "Описание системы" (аналог Требования").
2) Инженерный подход требует определенных компетенций от коллектива разработки, которые практики инженерного образования в ВУЗах дать не могут для нужного количества человек. Инженеры как сообщество устранились от решения этой проблемы и поиска альтернативных для обеспечения образования в нужном объеме и сроках, это происходит не системно.
Как результат: инженерная культура исторически оказалась не способной обеспечить реализацию IT-проектов в необходимом масштабе. И была заменена другой. И эти проблемы в ней до сих пор не решены.
Дмитрий Безуглый Максим Цепков
1) Первый раз слышу о подобной бессмыслице . Даже в "Мифическом человеко месяце ,а это и есть что называется Академическая культура ( Другой тогда не было) нет ничего подобного. Была вынужденнная мера документирования кода в виде листингов связанная с тем , что код приходилось РЕГУЛЯРНО перевводить. наличие хоть десятка статей в Computer Science ни как не может быть свидетельством или доказательством общепринятой инженерной практики. Это все равно как ссылатся на мой доклад 8 летней давности и гооворить вот смотрите Agile практики уже тогда задумались о проблемах маштабирования. Маштабировать Agile начали после того как Леффингуэл выложил на стол SAFe. До этого культура мелко кустарного agile for teams преподносилась как единственно верная .
2) Про компетенции верно. Но абсолютно то же требование предъявляет любой гуру Agile разработки к команде.
Ниша Agile for teams это небольшие проекты для которых 2-й уровень CMMI порождает достаточно много проблем , а 3-й слишком сложен и фактически не нужен.

Повторюсь Инженерные практики - это 4-й 5-й уровень процессов и я его видел объективно работающим. Более того он прекрасно интегрирует в себя итеративный и исследовательсткий подход.

Agile прекрасная альтернатива незрелому 2-му уровню разработки. И там же прекрасно вызревают студенты и новички в професиии. Но Agile в принципе ничего не может предложить существенного для более менее серьезных задач в силу низкого уровня интеграции с инженерными дисциплинами. И плачевные результаты Skype, Сбербанк, сворачивание программы Альфа лаб. Прекрасное этому подтверждение.
Чем выше сложность проекта тем больше проблем создаются отсутвием компетенции инженерного уровня.
Маленькими работающими инкрементами можно построить далеко не все, либо это крайне не эффективно.
Лучший аналог это постройка моста.
Можно ли проектировать ПО ?
Можно, но для этого нужно гораздо больше чем Agile, в том числе с точки зрения организации работы.
Максим Цепков Дмитрий Безуглый Дима, это - не бессмыслица, это достаточно классическая статья. При этом я о ней в первые раз прочитал в хорошем сборнике эссе от разных архитекторов, там была ссылка (но я быстро не нашел). Вот ссылка на перевод http://lib.custis.ru/.../Продукт_инженерной_деятельности_... там есть ссылка на оригинал, а в конце - ссылка на ретроспективное восприятие 13 лет спустя (в 2005). Почитай. Писали инженеры.
Agile начали масштабировать со Scrum of Scrum, ты сам это знаешь и успешно пробовал, но получилось на личном факторе. С масштабированием действительно большие проблемы. Но SAFe - столь же мертворожденная громоздкая конструкция, как и RUP. Ивар Якобсон уроки RUP касательно чрезмерной сложности усвоил, а Леффингуел - нет. Печалька.
Про CMMI. Сазерленд в своем докладе на SECR-2011 показал, что правильный Scrum (тот. который он пропагандирует и ставит), обеспечивает CMMI-5 и даже превосходит его по ряду параметров. Ну и статистику тоже привел. С этим можно не соглашаться, можно аргументировано разбирать, но вообще тема соответствия или не соответствия разным уровням CMMI для меня - не интересна. Потому что CMMI - умозрительный идеал, работоспособность которого не доказана практикой вообще.
Та проблема, о которой ты пишешь - технологичная реализация сложных инженерных изделий - действительно существует и актуальна. Сейчас в IT они выполняются, управляясь по Agile и без Agile, при этом с использованием различных инженерных практик. Системная инженерия Agile-практики управления тоже успешно осваивает - Левенчук об этом пишет. Естественно, сразу в наиболее продвинутом варианте OMG Essence.
Мой тезис. Практики управления проектом по agile дают больший эффект в виде меньшей стоимости проекта, меньших требований к компетентности участников и раннего обнаружения ложных путей, чем практики управления проектом из академической культуры, а практики управления из менеджерской культуры дают еще меньше (Брукс во многом критиковал именно менеджерские практики. которые тогда начали пытаться использовать).
С тезисом, что ни одна из культур не отменяет необходимость применения инженерных практик в нужном объеме, определяемых спецификой проекта, помимо управленческих практик - согласен. При этом считаю, что Agile в IT достаточно хорошо наработал практики такого совмещения.

Сергей Нужненко Как раз у меня в докладе обсуждалась проблема планировщика против исполнителя. AGILE хорош, но его плохо применяют, причем в статистически значимых количествах плохо (хотя в подобных количествах и хорошо). Кто виноват?

Когда мы с вами спорили о ГОСТ 34 и 19 виноват был ГОСТ, точнее отсутствие людей, которые его понимают и могут эффективно использовать.
Так какую задачу нам решать? Бороться с попсовым AGILE? Изобретать что-то, что не сможет исказить толпа ИТ-хомячков? Вводить лицензирование ИТ-инженеров и не допускать к работе неквалифицированных?
Что делать в нашей реальной ситуации в ограниченных ресурсах, когда проекты нужно делать сегодня с этими людьми и с интернетом, загаженным плохими перепевками AGILE в трамвае?
Denis Beskov видимо, работать по 6 принципам Lean Kanban :)
Максим Цепков Ключевой вопрос: "Что делать в нашей реальной ситуации в ограниченных ресурсах, когда проекты нужно делать сегодня с этими людьми". Лицензирование тут не решение, и допуск только квалифицированных - тоже.
В Agile гораздо больше способов и практик контроля за ходом процесса, приближением к результату и увеличения компетентности в процессе деятельности, чем в подходах классического/регулярного/проектного (pmbok) менеджмента. Другое дело, что сейчас нет специализированных курсов Agile для заказчика/руководителя, который учит применению этих способов и работе с agile-командой. Хотя в книгах, стандартах. выступлениях такие приемы описаны. и, более того, в компаниях, активно применяющих agile такеие системы выстроены. А именно в этом и состоит борьба с попсовым Agile: когда заинтересованное в результате проекта лицо будет знать, как ему взаимодействовать с такой командой. обеспечивая нужные результаты.

Про Agile. Алексей Пименов и Сергей Кушнир

А эти доклады я объединяю, потому что доклад Сергея Кушнира по сути дает частный пример для того, о чем рассказывал Алексей Пименов.

Пост на FB Алексей Пименов. LeanKanban подход к оценке и прогнозированию проектов. Начался с сильного утверждения: на основе анализа мирового опыта выполнения проектов: нет корреляции между оценками проектов и реальными сроками выполнения.

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

Дальше делаем типологию и чеклист классификации. И дальше накладываем на спектральную диаграмму - и проверяем, что получилась характерная диаграмма нужного распределения. Нормальное, пуассоново, и обобщенное распределение Вейбла - ширина пика и отстояние пика от матожидания. Из этих данных можно извлекать полезное для предсказуемости.

Например, если много коротких запросов - точно можно вычленить для оптимизации.

Но! Проблема есть толстых хвостов: fat tail. Вы обеспечиваете сервис заказчику, прилетает толстый хвост и убивает компанию.

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

Делаем диаграмму потоков работ. Проблемные точки

  • Синхронизация разных потоков
  • Возвраты на переработку
  • Блокировки по ресурсам: людям, внешним зависимостям, взаимодействие с заказчиком

Влияние блокировок и других проблемных точек перевешивает влияние трудозатрат.

Leak time против время касания проекта. Не путать время касания с трудозатратами - потому что может быть очень малые трудозатраты.

Эффективность потока: время касания к времени производства. Обычно лишь 5-15% И надо признаться, что наши проекты больше стоят, чем идут - при том, что мы следим, чтобы "все работали".

Компания, работающая на накопление знаний - сервисно-ориентированная. Разработка софта - такая же.

В сервисе может быть несколько способов обслуживания. Эскалатор. Если все стоят на каждой ступеньке, одинаковое обслуживание - поднимется больше, но все одинаково. Если справа стоят, проходят слева - то в целом поднимется меньше, но некоторые - быстрее.

Дальше очень часто есть варианты проектов одного типа. Надо провести анализ

  • Что-горело
  • Работа в обычном ритме
  • Проект не слишком важен изначально.

Дальше делаем классы проектов: горящие, обычные и фоновые.

А дальше - еще ставим лимиты, сколько мы делаем каких проектов. Горящих проектов не может быть слишком много. Если проект уходит в толстый хвост - ему можно поднять класс обслуживания. И можно отслеживать и принимать решения.

Данных много не надо. Был кейс с рекрутерами - данных за два месяца хватило. И нашли любопытный толстый хвост. Когда программист-кандидат разослал резюме в несколько мест, получил оферы и приходит к начальству и требует повышения, ему дают - и закрытие вакансии у всех вылетело в толстый хвост.

Про 5-15% - исследование Microsoft по проектам своих и партнеров примерно в 2009. Его опыт подтверждает.

Подход cocoma - на выделенную команду. А реально есть разброс по ресурсам и впихивания заказчиками работ. И это нарушает детерминистический подход - его ломает плохой менеджмент. А здесь мы смотрим, что реально у нас получается с нашим плохим менеджментом, и прогнозируем из этого.

В ответах на вопросы: для первой статистики в среднем достаточно 30 проектов/ответов на запросы. То есть немного!

Пост на FB Сергей Кушнир. Reliable Scrum: итеративная разработка и жесткие сроки. Практический доклад про решение в команде. Ситуация - команда работает с крупными задачами, которые помещаются 1-2 в спринт, при этом идет поток багов и срочных задач. И воронка проблем затягивалось, было несколько попыток решения. А дальше было решение - выделение отдельного буфера для дополнительных задач, контроль за ним, параллельно с основными задачами, за которыми тоже идет контроль. И всякие нарушения, например, впихивание задач хитрого product owner - мгновенно стало видно. В целом решение успешно, производительность выросла, и воронка пошла раскручиваться. При этом, что интересно, люди не верили и не верят, даже внутри компании, что такие относительно простые решения могли так изменить ситуацию, и ищут подвох.

Что интересно - эти практические изменения очень хорошо укладываются в общую теорию, которую Алексей Пименов (Alexey Pimenov) излагал на первом докладе. По сути они ввели два класса обслуживание с отдельными потоками и SLA, и стали за этим следить. Просто они это сделали без теории, но и без изобретения велосипедов - они использовали отдельные практики для эволюционных изменений. В частности, в докладе много ссылок на Максима Дорофеева.

Сергей Добриднюк А почему это нарушение то ? "И всякие нарушения, например, впихивание задач хитрого product owner - мгновенно стало видно." - у них что PO - внешний по отношению к команде, на утренних митингах не бывает ? Откуда протест то ?
Максим Цепков Бывает. И не только на митингах, там-то это не пройдет. А тут видит, что у разработчика пауза - ии подкидывает "маленькую" задачку. А разработчик потом залип... А в конце спринта - разбор про недостаточную скорость команды.

Остальные доклады

Пост на FB Игорь Агамирзян - размышления о развитии разработки. Фантастическое ускорение процесса разработки и не менее фантастическое ухудшение качества. По очень многим приложениях прикладная система использует ресурсы процессоров и памяти максимум на 1% от достижимого при аккуратном программировании. Объем приложения FB за последние 2 года вырос в 2 раза. А функционал? И сейчас у нас кризис практического программирования. Экстенсивный рост, при чем без роста функционала.

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

Пост на FB Орхан Гасымов. Современная микросервисная архитектура. Несколько шагов преобразования от классического монолитного приложения. (1) делим монолит на маленькие сервисы, которые можно масштабируемо поднимать. Нужен реестр сервисов и маршрутизатор с балансировкой нагрузки, а вместо больших серверов получаем много легких. (2) Сами сервисы делим на Command и Query, шаблон CQRS. (3) Команды реализуем через event sourcing - пишем журнал/очередь команд-событий, и их обработчики. Никаких синхронных вызовов между сервисами. (4) Обработчики событий - через паттерн reactor - идет один основной обработчик, который все тяжелые запросы раскидывает на внешние потоки. И каждый отдельный элемент этой конструкции - легкий. Модуль - просто набор функций. В целом - реализуем реактивный манифест.

Пост на FB Александр Леонов, Анатолий Кушниренко, Никита Бесшапошников. Введение в кооперативное программирование: персональная ответственность - коллективный результат. Совершенно неожиданно - доклад был про обучение 6-летних детей программированию в детских садах в Сургуте. Успешно. При этом дети работают кооперативно: каждый пишет программу для своего робота, а роботы работают в общем поле и должны действовать согласовано. И 6-летки реально решают сложные задачи, у них цель - довести к 3 классу до полной программы 11-летней школы. Решаются сложные задачи - синхронизации, управления кланами роботов. При этом команды детей соорганизуются, друг другу помогают, но при этом программу своему роботу каждый должен написать сам. Круто!

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

Пост на FB Александр Колесников. Поддержка работы управления проектами. TFS - наше все. Потому что (и это - за рамками доклада). И вокруг - лоскутное одеяло разных систем, потому что TFS не хватает - например, тренд за год не посмотреть. И они снаружи прикрутили Grafana для мониторинга состояния проекта - и оно получилось. Об этом и был доклад. При этом примеры графиков в докладе - высокотехнологичные, примерно такие, которые используются для мониторинга нагрузки на продуктовые сервера и другую инфраструктуру. НО IT-шники - вполне разбираются. Мониторят ход проектов так же, как мониторят продуктовые сервера, предсказывают клиентские обращения и многое другое.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 22:26, 15 октября 2018 • нет комментариев
Источник — «https://mtsepkov.org/index.php?title=Блог:Максима_Цепкова/2018-10-15:_SECR_-_много_общения_и_качественных_докладов&oldid=5684»