Викилоги

Пост на Facebook, запоминаю в блоге

Facebook напоминает о прошлом и выдал мне этот пост годичной давности, в котором я делился докладом на AnalystDays-2016 про схемы СМД-методологии.

Примерно пять лет назад я начал знакомиться с СМД-методологией - с нашей компанией начал работать Борис Маркович Островский, один из учеников Георгия Петровича Щедровицкого. Постепенно осваивал ее схемы, чему способствовало участие в играх у Петра Георгиевича в Бекасово. И вот год назад, на #AnalystDays рассказывал об этих схемах аналитикам. Потому что там наработано очень много ценного про устройство мира, и это имеет смысл использовать в практической деятельности, а не просто интересоваться как частью истории человеческой мысли. В частности, в этом году на #SQAdays у меня будет доклад по самоопределению с продолжением на баркемпе, в основу которого легли три схемы: две были в прошлогоднем докладе, а третья - схема самоопределения из лекций Петра Георгиевича по третьей промышленной революции, которые я слушал, конспектировал и публиковал конспекты в прошлом году. Когда хочешь в чем-то практически разобраться - сделай об этом доклад :) Так что приходите слушать!

Этот пост возник, как ответ на один из вчерашних докладов на IT Spring 2017, в котором нам рассказывали о построении конвейера в IT-разработке, чтобы делать программы как автомобили по всем правилам инженерной науки. Так вот, это доклад не инженера, а изобретателя. Изобретатели — очень увлеченный народ, уверенный в своей гениальности, в том, что у них точно получится, даже если у многих раньше — не получалось. Например, вечный двигатель. А инженеры — они все-таки сначала смотрят на работы предшественников и разбираются с предметом.

То, что софт нельзя производить по регламентам и правилам было осознано на опыте проектов еще в 1980-х, и об этом есть классическая книга Тома ДеМарко «Человеческий фактор». А несколько позднее, в 1992 в статье What is software design (перевод) Ривз объяснил, почему так, в чем именно отличается разработка ПО от создания самолетов, которые у Боинга не только собираются, но и проектируются по регламентам, и почему вследствие этих отличий производство софта по регламентам не работает. Схема этого объяснения - справа.

Но инженеры — они ведь умные. Это у других не работает, а они придумают так, что заработает. И группа гуру во главе с Иваром Якобсоном (автором use case и соавтором UML) придумала RUP. Но и у них не получилось? этому есть много примеров и статистика. Конечно, всегда есть объяснение, что это не получилось по причине неправильного применения регламентов. Но квалифицированные инженеры — они осознают свои ошибки, и для меня лично достаточным основанием является факт, что практически все ведущие авторы RUP, включая самого Ивара, достаточно быстро приняли Agile, который был следующим тактом развития, и участвуют в его развитии.

Впрочем, это не останавливает других инженеров: ну и что, что у других не получилось, у них-то получится. Конечно, может и получится, только для этого в конструкции должны быть некоторые принципиальные инновации по сравнению с предыдущими провалами. А этого — не наблюдается, в докладе было рассказано о конструкции регламентов на 4-5 уровней, а далее авторы с удивлением обнаружили, что большинство проектов у них на нулевом, перевели их на первый, получили профит. Что давно известно и в Agile — гигиеническое нормирование процесса необходимо. Только там для этого применяется легкий механизм чек-листов начального уровня, без разработки совершенной многоуровневой конструкции, которая останется в идеальном мире.

И, что интересно, сейчас регламенты перестают работать не только в IT, но и в других отраслях. Почему так — написал другой классик, Питер Друкер в книге «Менеджмент. Вызовы XXI». Анализируя изменения в характере деятельности, связанные с повышением роли знаний, он выделил возникающие при этом вызовы, на которые традиционный менеджмент не может ответить — а они непременно придут. И они уже пришли. Зафиксированные на глобальном уровне тренды Business Agility и Цифровизации обесценивают культуру правил, делая это, однако, по-разному.

Обо всем этом я буду рассказывать сегодня в своем докладе «Agile — ответ на вызовы третьей промышленной революции», приходите. Кто был на AgileDays - тоже приходите, с тех пор доклад был доработан и дополнен.

Кстати, сама конференция мне понравилась. Разработчики разбираются с софт скилл, основательно, в том числе - добираясь до старых теорий, и я узнал про психоделическую революцию Тимоти Лири и его подходы к описанию личности в рассказе Ярополка Раша, и про связь конституции человека с его психозами в модели Эрнста Кречмера, о которой рассказывал Юрий Сорокин. Я, кстати, по ней - маниакально-депрессивный шизоид. Но позитивный. На этом, пожалуй, закончу.

Пост на FB

Для проектирования учета и фиксации его правил при разработке приложений мы в компании придумали удачное фирменное средство — Диаграммы учета и успешно применяем сами. И профессиональные бухгалтеры, с которыми мы взаимодействуем, тоже проникаются идеей графического изображения и начинают использовать при проектировании учетной политики. Я даже писал об этом в профессиональном журнале «Бухгалтер и компьютер» Когда всем понятно, а другие материалы можно посмотреть в Категория:Диаграммы учета. Никто из профессионалов не рассказывал нам, что у бухгалтеров аналогичная нотация уже есть, и в книгах я ничего не видел.

Поэтому, когда примерно год назад Максим Осовский прислал мне фотку из книги Леонтия Бызова «Графические методы в планировании, статистике и учете» (1940), на которой изображен план счетов горнодобывающего предприятия, я очень заинтересовался.

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

А еще Бызов пишет, что графическая нотация для планов счетов — не его изобретение. Он ссылался на книгу Эйгена Шмаленбаха «Счетные планы». Эта книга была переведена в 1928 году и я ее тоже взял. Прочел, что схемы планов счетов были разработаны специально для обучения, увидел серию схем, одну из которых можно увидеть ниже. Фрагмент книги со схемами я отсканировал и публикую Файл:Эйген Шмаленбах. Счетные планы - фрагмент.pdf. Вообще у Шмаленбаха есть целая серия книг, но переведена на русский только одна.

Возвращаясь к книге Леонтия Бызова, хочу сказать, что у него в книге не только учетные диаграммы и представления для статистических данных, но и интересные организационные схемы, например, представленные на этом развороте документооборота. Подробнее можно посмотреть в отсканированном мной фрагменте книги Файл:Леонтий Бызов. Графические методы в планировании статистике и учете - фрагмент.pdf

Леонтий Бызов много занимался графическими языками, его биографию можно прочитать в очерке внука, тоже Леонтия, «Мой дед Леонтий Бызов», а в прошлом году я был на встрече, посвященной его работе по созданию графического языка.

А еще, что интересно, и на Шмаленбаха и на Бызова — достаточно много ссылок в рефератах и научных работах. И достаточно очевидно, что люди не читали оригинал, а пересказывают с чужих слов — потому что оригинал слабо доступен. А то и просто копируют в список литературы. С Бызовым вообще интересно — одна из его книг процитирована в статье «Графические методы» Большой Советской Энциклопедии, но фамилия названа с опечаткой, «Вызов» — так эта ссылка и кочует из работы в работу :) И Вы можете исправить это, проголосовав за оцифровку работ на сайте Ленинки: Леонтий Бызов, Эйген Шмаленбах

В эту пятницу прошло первое собрание группы ГосAgile, которая официально называется «Подгруппа по применению гибких подходов в государственных проектах рабочей группы по развитию проектной деятельности при президиуме Совета при Президенте Российской Федерации по стратегическому развитию и приоритетным проектам». Группа была официально запущена пару дней назад, как раз в день космонавтики :) Состав группы — очень разный, там собрались не только те, кто успешно применяет Agile, в том числе в государственных проектах, но и те, кто отвечает за формирование нормативной и методологической базы ведения проектов и, возможно, предпочли бы сохранение более консервативных подходов, однако не могут игнорировать изменения в мире. А также те, перед кем стоит задача масштабных изменений в отдельных сегментах государственного управления, и они смотрят на Agile как на возможное средство для проведения изменений и готовы ему учитьcя и адаптировать к реалиям государственных проектов. Поиому что, хотя кейсы применения Agile в госпроектах есть, и их даже довольно много, нигде не идет речи о применении чистых методов, везде строится достаточно сложная комбинация.

Disclaimer. Это - мои впечатления с заседания и они не являются официальным протоколом или пресс-релизом.

Собрание началось с формулирования направлений работы и ожиданий. Андрей Анатольевич Бадин, Заместитель директора Департамента проектной деятельности Аппарата Правительства РФ, рассказал о внешнем контексте — о других рабочих группах и их направления движения, в частности, методической группы. Основной стандарт будет гейтовый, в нем будет о контрольных точках, но не о методах их достижения. А по методам как раз работают другие подгруппы, в том числе новая подгруппа по Agile.

Фото из поста Ивана Дубровина

Далее были направления работы и ожидаемые результаты за год от Олега Качанова, Директор Департамента проектов по информатизации Минкомсвязи России, руководителя подгруппы. Затем была короткая презентация по Agile для выравнивания контекста от Ивана Дубровина, заместителя руководителя подгруппы. Иван начинал развитие ГосAgile еще в 2015 году, работая тогда в Минкомсвязи, и в ноябре 2015 во многом его усилиями прошла AgileKitchen на территории Аппарата Правительства, которая вывела это движение в публичное пространство еще до выступления Германа Грефа.

Потом достаточно быстро перешли к организационной части. И организационная часть была построена на самоорганизации. Об этом хочется остановиться подробнее, это — интересный опыт, особенно в госуправлении.

• Продвижение будет идти по обозначенному набору тем, при этом список является открытым, и его даже дополнили прямо на встрече. По каждой теме есть годовой ориентир — чего хотелось бы достигнуть. В процессе он может изменяться — цель смещается по обстоятельствам.
• Участникам было предложено определить интерес работы в одной из предложенных тем, обозначив уровень своего участия от максимального — готов самостоятельно создавать контент и участвовать во группы встречах между общими — до минимального, предполагающего только оценку материалов.
• По каждому из направлений предложен вариант ожидаемого через месяц результата, который можно было скорректировать в обсуждении.
• Раз в месяц будут общие встречи, на котором по каждой теме будет сообщение о достигнутых результатах и текущем статусе — демо, а также заявлен ожидаемый результат на следующий месяц.
• А дальше — ожидается что внутри групп участники как-то сами соорганизуются вокруг общего пространства: trello для ведения задач, GoogleDocs для документов, telegram для сообщений и GoToMeeting для конференций. Использование открытых платформ на текущем этапе предполагается оправданным: закрытых материалов не ожидается, а знакомые инструменты обеспечивают низкий порог входа.

Обозначены следующие темы работ.

• Анализ зарубежного опыта — потому что он успешно применяется во многих государствах и хороший опыт полезно взять. При этом идут бурные изменения — и надо быть в курсе нового опыта.
• Оценка действующих нормативов, предложения по их изменениям, взаимодействие с регуляторами. И здесь по обсуждению возникло два вектора: от нормативных документов и от проблем в реальных проектов.
• Определить границы применения гибких методологий, с предложением начать от тех точек, где он эффективнее других (что требуется обосновать).
• Методические рекомендации по применению гибких методологий. Как в существующих условиях нормативного регулирования, так и в идеальном будущем — чтобы померить gap по нормативке и его устранить.
• Вести и работать с пилотными проектами. Что интересно, Agile сейчас применяют не только у подрядчиков на госпроектах, но и в государственных организациях и органах управления. А пилотные проекты призваны как решать конкретные проблемы, так и расширять области применения, исследовать границы и методы на практике.
• Мотивация в условиях применения гибких методологий. Понятно, что многие традиционные методы перестают работать, а они воплощены в нормативке и, главное, в сознании руководителей — и надо дать рабочую альтернативу применительно к условиям госуправления. Эта тема сформулировалась непосредственно на заседании. И это как раз пример реальной гибкости в работе.

Календарь конференций имеет два сезона - весной и осенью. Весна для меня началась в феврале выступлением на World Information Architecture Day в Петербурге: От монолитных моделей предметной области — к модульным. Вообще это - очень интересная встреча высокого уровня и у докладчиков и у участников, подробности можно прочитать в (отчете в блоге с обзором докладов. Потом было выступление на AgileDays: Agile — ответ на вызовы третьей промышленной революции. Сама конференция - рабочая, много контекста и много параллельных треков, так что в отчете - только общие впечатления. А апрель начался с участия в качестве со-ведущего на Radiometrics в передаче с Дмитрием Завалишиным, Алексеем Вайсбергом и Олегом Смирновым, на которой обсуждали консалтинг как составляющую часть IT-проектов.

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

• 15.03 ProfsoUX в Санкт-Петербурге: Сотрудничество с корпорациями: рецепты из практики - единственная в России профессиональная конференция UX/Usability/UI. Я был несколько раз, но не выступал. Каждый год круче предыдущего, и этот - не исключение.
• 24.03 AnalystDays в Москве: Как выбрать для проекта практики проектирования и работы с требованиями. Конференция в представлении не нуждается, вместе с Летним Аналитическим Фестивалем (ЛАФ) - место профессионального общения IT-аналитиков и всех остальных, кто занимается проектированием софта.
• 25.03 Международный экономический симпозиум - Соколовские чтения в Санкт-Петербурге: Диаграммы учета как средство для наглядного и целостного отображения правил учета - профессиональная конференция экономистов и бухгалтеров, проводит экономический факультет СПбГУ.
• 29.03 IT Spring в Минске: Agile - ответ на вызовы третьей промышленной революции. Об этой конференции я слышал хорошие отзывы, но сам буду первый раз. Программа этого год мне нравится, думаю, не только выступлю, но и послушаю других и вообще почувствую атмосферу.

И в мае тоже будет продолжение. Я надеюсь поехать на IT Global Meetup в Петербург, и буду на SQAdays в Москве.

Я надеюсь, будет интересно и содержательно!

Сегодня было очень интересное обсуждение на Радиометрикс с Дмитрием Завалишином, Алексеем Вайсбергом и Олегом Смирновым ведение IT-проектов. На этот раз я участвовал в передаче как один из ведущих, а гостями были Дмитрий Завалишин и Алексей Вайсберг. Очень интересно и содержательно. Запись доступна на сайте передачи, смотрите и слушайте. А здесь анонс на FB, по нему можно найти отзывы.

Непосредственным поводом к передаче послужила публикация Димой в своем ЖЖ серии постом, посвященных процессу разработки. И она тоже интересная и содержательная, читайте http://dz.livejournal.com/tag/ПроцессЗавалишина Надеюсь, Дима продолжит публикацию.

А основным обсуждавшимся вопросом о консалтинге Заказчика в ходе внутри IT-проектов: почему он нужен, что является его предметом, явный или неявный, из какой позиции - ведь заказчик лучше понимает свой бизнес. И разговор часто переключался на процесс ведения проекта, в том числе на Agile. Тем более, что Ждима в первом из постов серии написал "Невозможно не сказать пару слов про эджайл. Скажу. Эджайла нет. Уложился? :)" Впрочем, потом уточнил "Реально, конечно, эджайл вполне есть...".

Сон разума рождает чудовищ или закономерности роста бюрократии в организациях?

Эту историю я услышал в кулуарах SQAdays. Тестировщик работал в компании А, которая предоставляет своих сотрудников на аутстафф в разные проекты. И как аутстаффер работал на проекте в одной крупной компании Б, им были довольны. А он рос, повышал свой уровень и рассчитывал на повышение зарплаты. Обсуждая это со своим руководством в А, которое обещало, но не сильно много, и изучая рынок, рассматривая предложения. В том числе - в компании Б, где он работал на проекте и им были довольны. Компания Б тоже сделало предложение, но зарплату предложили меньше, чем предлагала компания А, при этом условия для своих сотрудников там были жестче, чем для аутстафферов. Он удивился, а ему объяснили, что они бы и рады предложить больше. но в компании приняты тарифные сетки, и он не подходит по формальным условиям. В общем, он остался в компании А, договорившись о траектории роста квалификации, предъявляемом через тесты и соответствующей траектории роста зарплаты. И по-прежнему работает в компании Б на аустаффинге в том же проекте, и компания Б платит компании А не только его зарплату, но и достаточно много сверху, потому что компания А - вовсе не благотворительная организация :)

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

Макс Вебер

Мишель Крозье (его сайт)

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

Однако, именно сейчас в мире происходят глобальные изменения. Осмысленность организации деятельности, ее соответствие целям компании сейчас является нормой во многих организациях, и их число растет. Правила и регламенты никуда не исчезают, но они всегда проверяются: является ли их соблюдение осмысленным, ведет ли к цели организации? И если нет - делаются исключения или правила меняются. Мир становится другим, и при желании не столь сложно найти места, где он уже изменился и работать там. Можно - не значит что обязательно нужно, везде встречаются разные интересные проекты, а у людей - разные цели. Но вот думать, что мир по-прежнему тотально-бессмысленен - неправильно. Даже среди больших организаций. Тем более в IT, который изменяется быстрее других отраслей.

На этом - все.

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

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

А еще идет обобщение практики и развитие методов. Я вижу, что такая работа идет, например, по докладу Алексея Пименова, и хотя мне сложно оценить ее в контексте развития методов в рамках мирового Agile-движения, но со-участие России в этом для меня очевидно.

Второй вектор развития на конференции - это внедрение Agile в тех организациях, где IT не является главным двигателем. В первую очередь интересны кейсы внедрения в органах государственного управления. Тренд ГосAgile начал развиваться в 2015, а после выступления Грефа на Гайдаровском форуме - усилился и был представлен на конференции в прошлом году. А в этом конференцию приветствовал заместитель руководителя Аппарата Правительства РФ Андрей Слепнев. Но при этом, что важно, вопрос о переходе на Agile - не ставится, предполагается, что он сам найдет своих сторонников, и важно, чтобы они могли действовать не нарушая нормативов. В общем-то, кейсы показывают, что при поддержке со стороны руководства это возможно уже сейчас.

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

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

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

Третий вектор - инженерные практики. По моим ощущениям, в этом году таких докладов было больше, чем в предыдущем. Микросервисная архитектура от Александра Бындю, DevOps, DDD и многое другое, разного уровеня, для продвинутых и для начинающих с детальными объяснениями.

Практически не было докладов про внедрение Agile в небольших компаниях и командах. Это по-прежнему актуальная тема: хотя для тех, кто в Agile давно, она относительно понятна. Многие компании и команды, в том числе новые, вступают на этот путь. Но здесь правильнее для начала пройти тренинг, получив готовые ответы, а не изобретая велосипеды. Рассказ о практиках, тем не менее, востребован, но, насколько я понимаю, для этого есть форматы AgileCamp и AgileKitchen. Впрочем, могу ошибаться.

Было некоторое количество докладов "из широкой рамки" управления проектами, и организациями, не связанными непосредственно с Agile. Некоторые из них явно диссонировали с духом Agile, в котором сотрудники совместно делают общее дело, а была позиция менеджера, профессионально обеспечивающего эффективную работы сотрудников. И даже в кулуарах я слышал "и кто пустил его на Agile-конференцию". Так вот, Agile - это не секта, нетерпимая к иному образу мыслей. В период формирования весь этот спектр вопросов активно обсуждался и на них есть ответы. Просто с тех пор часть из них ушло в неявное знание у опытных и отсутствует у тех, кто воспринял Agile-конструкции как готовые. Так что если кому-то подобные доклады сильно режут ухо и есть желание их исключить, то, скорее, надо взглянуть на историю и разобраться в позиции, представляемой докладчиком, включая позитивные и негативные последствия. А еще в таких докладах обычно достаточно много практик, которые уместны для решения конкретных проблем и могут быть включены в арсенал, если сделать поправки на изменение позиции. Это вообще в традиции Agile - черпать практики из самых разных источников, адаптируя и трактуя. Наиболее яркие примеры - Kanban и Lean.

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

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

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

С опозданием пишу отзыв о 20 конференции SQAdays, которая была в конце ноября в Минске. И вовсе не потому, что конференция мне не понравилась. Наоборот, было много хороших докладов и интенсивное, конструктивное общение. И мне хотелось написать обстоятельный отзыв, по горячим следам это не получилось, все время были другие дела, но наконец очередь дошла.

Зато уже через два месяца - следующая конференция SQAdays, на этот раз в Москве. И, может быть, кто-то прочитав этот отчет вдохновится, и решит съездить, а может быть даже сделает доклад! Организаторы этому всегда рады!

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

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

→ продолжить чтение…

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

Итак, есть два принципа.

1. В организацию (сообщество, движение) объединяются люди, разделяющие общее целеполагание организации и готовые им руководствоваться в своих действиях.
2. Признается и уважается право любого участника на собственную интерпретацию целеполагание и действий, исходя из своего понимания целей.

Исходя из них формулируется примерно следующая процедура.

1. Каждый кому пришла в голову хорошая идея, реализация которой работающая на цели организации, может собирать необходимых ему единомышленников для реализации, включая обеспечение ресурсами и финансами, если они необходимы.
2. О планах по реализации информируются все потенциально заинтересованные члены организации (или вообще все).
3. Мнения - выслушиваются и принимаются во внимание. В том числе - предложения о возможном увеличении предполагаемой пользы. Но решение принимают инициаторы.
4. А вот возражения, касающиеся потенциального вреда от реализации плана действий из-за конфликта должны быть решены с поиском решения исходя из целеполагания движения в целом.
5. А дальше - реализация.

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

1. Форма инициативного предложения.
   1. Безличная форма "А не сделать ли нам ..." (продукт, мероприятие, ...) годится только чтобы "прощупать ситуацию" на предмет резких возражений. А дальше надо переходить к одной из двух позиционных форм.
   2. Я думаю, что будет полезно сделать то-то (для таких-то целей и в такой-то конструкции), но не готов сам это делать
   3. Я готов сделать то-то (для таких-то целей и в такой-то конструкции).
   • Может показаться, что 1.2 и 1.1 - это одно и то же. На самом деле, нет. Заявляя форму 1.2 говорящий показывает, что выдвигает идею, но готов предоставить инициативу другим. И это важно показать явно. И понятно, что для того, чтобы предложение реализовалось, кто-то должен высказать его в форме 1.3.
2. В ответ на предложение в форме 1.3. от других участников ожидается одна из трех позиций:
   1. Поддерживаю, готов участвовать
   2. Поддерживаю/не возражаю, но не готов участвовать
   3. Считаю неправильным, потому что ...
3. Понятно, что чтобы занять позицию могут требоваться уточняющие вопросы, на них инициатор должен ответить. Могут быть вопросы, на которые ответ труден (не продуман), и тут может быть встречный вопрос "а что для тебя от этого зависит?"
4. Позиция 2.1 рассматривается как предложение о сотрудничестве, и может сопровождаться идеями/условиями. Предложение не обязано приниматься, переговоры - разумно потом, когда сняты возражения про вред (2.3).
5. В позиции 2.3 важно отличить возражения от мнения.
   1. Мнение: "Такой продукт не найдет спроса...", "На такое мероприятие никто не придет..."
   2. Возражение: "Этот продукт будет конкурировать с уже существующим успешно распространяемым, которым я (возражающий) развиваю, и при этом не привлечет новых потребителей"
6. Как с этим работаем?
   1. С возражением - работаем, ищем решение win-win и возражающий должен сотрудничать, как я описывал в [[ранее. Что надо сделать, чтобы новый продукт не деструктивно конкурировал со старым, а привлекал новых потребителей? Изменить сам продукт? Доработать его маркетинговую стратегию? Что-то еще?
   2. Возражать можно только "за себя", из своей деятельности - нельзя искать решение "от имени другого".
   3. Мнение - лишь учитывается инициатором на его усмотрение. Участник, высказывающий мнение может как угодно оценить цели и план действий, которые предлагает автор инициативы. Но никто, кроме самих инициаторов, не является судьей, определяющим, правильно это мнение, или нет, хорошо ли сформулированы цели, или не слишком.
   4. Исключение - мнение, что реализация нанесет вред деятельности другого участника сообщество, который не проинформирован об этих планах.
7. Отдельно следует отметить работу с мнениями или возражениями, которые говорят о потенциальных рисках потерь, которые возникают при неудаче. Хорошо, когда это мнение обосновывается какими-либо прошлыми уроками организации или внешнего мира, о которых инициатор может просто не знать. Но часто оно является лишь некоторым экспертным заключением говорящего. И в этом случае его следует принять в рассмотрение и подумать: если говорящий прав и риск реализуется - как мы сможем раньше заметить поворот событий в нежелательную сторону и предотвратить или уменьшить ущерб? И учесть это в своем плане. При этом если говорящий говорит об ущербе позиционно, из своей деятельности в организации - то с этим работают совместно, как с возражением, а иначе - как с мнением.

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

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

Agile стремительно распространяется за пределы IT-отрасли, и это несет свои особенности. О них - в моей беседе с Мариной Симоновой на сайте AgileSpace. В публикации на FB идет обсуждение.

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

Картинка и схема - из статьи.

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

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

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

Это если кратко. А теперь тоже самое в развернутом виде, на основе книги Фредерика Лалу "Открывая организации будущего", в которой тот подробно разбирает практики решения конфликтов в разных организациях (мой конспект) как сфокусированное изложение.

→ продолжить чтение…

World Information Architecture Day-2017 в Петербурге - великолепный набор докладов, хорошо раскрывающих концептуальные вещи на мировом уровне. Программа встречи.

На открытии конференции было видео-обращение Richard Saul Wurman, который придумал понятие Информационной Архитектуры, а также конференции TED. По образованию и основной деятельности он архитектор. И он когда-то предложил сказал своим друзьям, которые занимались информацией и использовали слово design, что это - неправильное слово, потому что дизайн - это про то, как сделать, чтобы хорошо выглядело. А организуют информацию для другого, обеспечивая, чтобы у нее была хорошая структура. И это - архитектура, а не дизайн. WIAD в целом проводит и координирует Международный некоммерческий институт информационной архитектуры в третью субботу февраля во всем мире, в этом году был в 58 местах в 24 странах. В России - единственная площадка в Санкт-Петербурге, организует UX-сообщество вместе с SEMRush, за что им большое спасибо. Мероприятие проходит в третий раз, масштаб увеличивается - помимо основного трека докладов был второй трек и воркшопы.

После открытия я выступал с докладом От монолитных моделей предметной области - к модульным. Краткое содержание и презентация - по ссылке, отзывы на доклад - там же, организаторы обещают выложить видео.

После моего доклада был замечательный доклад Дмитрия Кудрявцева (СПбГУ) Онтологии и информационная архитектура: соотношение терминов и потенциал совместного использования с обзором способов организации онтологий и примерами конкретных онтологий, и соотнесения онтологий с информационной архитектурой.

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

Из этой пары докладов я вынес много нового в теоретической рамке и системе понятий, включая отличие тезауруса от словаря.

После обеда был доклад Эдуарда Христусь про объектно-ориентированный дизайн (OOD), которые не следует путать с объектно-ориентированным программированием (ООП) - объекты в них разные. А также отличать от Domain Driven Design, Value Driven Design и других. В докладе OOD был представлен на основе создания сайтов, преждде всего - сложных и интерактивных, в которых объектов много. OOD предусматривает создание первым этапом модели объектов, которая обсуждается с заказчиком и часто структурирует коммуникацию, а далее позволяет параллельно запустить процессы детального проектирования (дизайна), разработки SEO (поисковой оптимизации) и наполнение копирайтерами сайта контентом. При обычном подходе SEO и копирайтеры могут подключиться только позднее, после проработки дизайна.

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

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

Лента конференции на Facebook - по тагу #wiad17, есть очень подробный отзыв Дмитрия Кудрявцева, фото моего выступления - из отзыва.

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

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

Между тем, процедурные практики безарбитражного решения не просто выработаны и применяются в конкретных организациях, они вошли в управленческий фреймворк Холакратии, который описан, и быстро распространяется в мире. Там они входят как часть регламента управленческой встречи (goverance meeting) и как раз нацелены на быстрое принятие решений в условиях потенциального конфликта интересов. И далее я дам краткое изложение процедуры, которую можно применять независимо от Холакратии как целостной конструкции, она достаточно автономна.

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

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

1. Люди информируют других о планах, способом, закрепленным в регламентах. Информация распространяется заранее, а решения принимаются на специальных управленческих встречах (но это не принципиально).
2. На самой встрече есть несколько стадий обсуждения решения: Представление автором - Уточняющие вопросы - Мнения по кругу без дискуссии - Обновление предложения автором - Возражения - Принятие решения
3. Мнения свободны, но они лишь принимаются во внимание.
4. Возражение - это фиксация конфликта интересов и они строго определены:
   1. Будет вред, которого раньше не было
   2. Вред подтверждается опытом либо критичен для работы
   3. Вред будет для назначения или обязанности из роли возражающего
5. Оба человека ведут переговоры (из своих ролей), чтобы найти решение win-win.
   1. В ходе переговоров возражающий должен раскрыть механизм вреда, чтобы были выявлены элементы, реализация которых нанесет вред и было место поиска компромиссов. Он не должен доказывать, что вред - будет, оценка - за ним, но вот механизм - должен показать.
6. Если возражающий отказывается от переговоров или не сотрудничает в генерации версий, его возражения не принимаются - отказ от сотрудничества делает их несущественными.
7. Стороны по согласованию могут позвать третьих лиц, которые расскажут прецеденты, помогут в генерации идей или дадут другие советы, но права на решение у них нет.
8. Если решение win-win не найдено, или найдены только компромиссные альтернативы, право выбора конкретной альтернативы - за инициатором. Который учитывает возражения, но принимает решение сам.

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

Те, кто хочет узнать подробнее, я отправляю к презентации Алексея Ильичева на AgileDays-2016, управленческая встреча описана на слайде 18, в видео с выступления это 23:40-28:50, больше 5 минут. Но, в общем, интересно посмотреть видео целиком. Также можно обратиться к сайту http://www.holacracy.org, на котором представлена Холакратия. Там материалы немного закопаны, но они есть, управленческая встреча описана в отдельной статье и в разделе 3.3 статьи 3 Конституции, а на этой странице есть раздел Implementation Resources со ссылками на другие материалы.

Кроме того, за практиками можно обратиться к книге Фредерика Лалу "Открывая организации будущего", в которой тот подробно разбирает практики решения конфликтов в разных организациях (мой конспект).

В третью субботу февраля проводится World Information Architecture Day - на площадках по всему миру. И в этом году, в третий раз сообщество UX SPb проводит его в Петербурге. Пока это - единственная площадка в России, но активные желающие могут присоединиться и организовать у себя тоже. Я ездил и выступал на нем в прошлом году, поеду и в этом.

Программа встречи опубликована, она интересна и мне лично нравится. Кроме меня, выступать будут Евгений Николаев (директор по маркетингу Яндекс.Деньги), Лара Симонова (Информационный архитектор в Collectrium, the Christie’s company; IA и ко-фаундер channelkit.com), Эдуард Христусь (основатель и руководитель производства в Func), Влад Аюкаев (Head of UX в Toughbyte из Хельсинки), Юрий Солоницын, Никита Ефимов и Юрий Веденин. Мероприятие - бесплатное, но регистрация - обязательна, и по опыту встреч Piter United места кончаются быстро. Так что думайте и регистрируйтесь!

Я буду рассказывать про построение моделей предметной области. 20 лет назад делали большие монолитные ERP, но сейчас нет сомнений, что гибкий и быстро развиваемый софт должен быть модульным, а объекты – инкапсулировать сложность. Тот же путь проходят системы понятий и модели, описывающие предметную область, и Domain-Driven Design перенес наследование, полиморфизм, инкапсуляцию, плагины и другие подходы к разработке софта на работу с онтологиями и моделями предметной области.

В это воскресенье 15.01 в 15:00 выступаю на Радио Медиаметрикс: Agile – это не процессы и готовые рецепты, это, прежде всего, новое мышление, новый mindset сотрудников, вовлеченных в работу.

Выступил. Видео на странице передачи. Очень удачно получилось.

Мой анонс на FB.

О чем именно я хочу рассказать.

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

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

Когда обсуждают Agile, то очень часто в спектр его методов включают только организационные методы и практики, такие как Scrum и Kanban, обеспечивающие предсказуемое, гибкое и управляемое прохождение потока задач с коррекцией результата на основе обратной связи от заказчика и рефлексивной адаптацией самого процесса. Однако, ограничиваясь ими, Agile бы никогда не достиг успеха в сложной инженерной области, которой является разработка программного продукта. Этот успех обеспечивают многочисленные инженерные методы и практики, которые сопряжены с организационными и дополняют их. И когда мы переносим Agile за пределы IT-отрасли, необходимо позаботится об адекватной замене этих практик, потому что они достаточно плотно наполнены спецификой IT. Да и если говорить об использовании Agile для IT-разработки, то пренебрежение базовым набором практик приведет провалу проектов в том или ином виде. При этом ряд из них стали известны задолго до появления гибких методов, и они обеспечивают устойчивость и успешность IT-разработки. Тем не менее, до сих пор находятся компании и команды, которые считают их второстепенными и не нужными, и встречается это как среди противников Agile, так и среди его сторонников.

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

1. Countinuous Integration и его современное развитие - Countinuous Delivery. Предназначен для поддержки системы инкрементальной разработки продукта вплоть до непрерывной поставки. Входит в базовый, гигиенический набор практик. Обычно включает исполнение автоматических тестов, но не обязательно.
2. Автоматическое тестирование. Обеспечивает стабильность продукта в условиях непрерывного развития и непрерывного рефакторинга - которые являются платой за гибкость разработки. Это - не обязательная практика, у нее есть альтернативы в виде технологичного ручного тестирования, либо применения практик работы с продуктом, ориентированных на качество кода (FDD, DDD), но является основой практик BDD и TDD, о которых дальше.
3. TDD - Test Driven Development. Разработку начинаем с тестов, это выделилось из XP. Эта практика обеспечивает входное тестирование на достаточность требований: может ли разработчик на их основе написать проверку функционирования системы как черного ящика? Если да - то значит требования достаточно ясные и определенные, и можно начинать продумывать конструкцию системы внутри. Опыт показывает, что слишком часто конструкцию начинают придумывать, не разобравшись с запросом пользователя, и в результате делают совсем не то. что нужно. Кстати, это встречается и в других областях, например. в маркетинге - люди начинают творить не задумавшись о желаемом результате. а лишь наметив область. А еще TDD способствует достаточно ясному и удобному для использования API.
4. BDD - Behavoiur Driven Development. В принципе является дальнейшим развитием форматов userstory, с одной стороны, и TDD с другой и нацелен на прозрачность коммуникации между разработчиком и заказчиком или конечным пользователем. Разработчик получает ожидания пользователя о поведении системы в достаточно формализованном виде, и это является таким контрактом на поведение системы как черного ящика. В пределе это описание на псевдо-естественном языке (формализованном подмножестве естественного), которое может быть играть роль автоматического теста системы.
5. FDD - Feature Driven Development. Придумал Джефф де Люка. Это организационная поддержка декомпозиции системы, базирующаяся и овеществляющая закон Конвея. Мы делим системы на кусочки и за каждым закрепляем ответственного и говорим, что API на границах является контрактом, изменение которого - предмет фиксируемой договоренности двух ответственных. Кусочков достаточно много, каждый ответственный за несколько, и при перегрузках можно передавать друг другу. Дополнительная фишка: ответственный - это обычно ведущий (senior, старший) разработчик, у которого есть 1-3 подчиненных, которых он растит (и которым можно передавать ответственность). Получается организация мини-команд, которая достаточно эффективна (почти каждый ведущий легко берет 1-3 подчиненных, в отличие от руководства командой), и мы получаем размер команды в 30-50 человек, или даже более, в зависимости от связности-модульности системы. Практика обеспечивает удержание архитектуры в условиях меняющихся требований и непрерывного развития. Она обеспечивается за счет мелкодисперсной структуры. При этом на архитектуру интеграции напрямую ограничений не накладывается.
6. DDD - Domain Driven Design, Эрик Эванс. Это - наиболее продвинутый метод работы с требованиями для сложных предметных областей.
   • DDD обеспечивает коммуникацию всех участников проекта с обсуждением системы не в виде черного ящика, как делает BDD, а раскрытием ее внутреннего устройства через построение модели системы, то есть позволяет заказчику обсуждать систему как прозрачный ящик. Для этого в рамках проекта создается специальный Единый Язык (ubiquitous language), описывающий предметную область, используемый для работы с требованиями и описания модели предметной области - которая является предметом согласования (контракта) разработчика с заказчиком. В отличие от обычной многостадийной формулировки требований с переводами (модель предметной области на одном языке, проект системы на другом, и так далее). При этом объекты модели должны трассироваться в код реализации, то есть перевод модели в код идет формально - что и позволяет говорить о представлении системы как прозрачном ящике.
   • А еще DDD сделал очень важный практический шаг в части работы с понятиями. Было замечено, что даже в относительно небольшой предметной области (например, банк или торговая компания) создать полную и непротиворечивую модель - сложно, так как разные люди (например, продажники, логистики и финансисты) используют термины по-разному. В рамках DDD вместо формального требования "единый словарь" эта проблема была осознана и предложено асимметричное решение. Единый язык создается не для всей области, а для некоторого ограниченного контекста (bounded context). Мы держим карту контекстов (context map). Но при этом, поскольку область одна, то в контекстах получается много пересекающихся понятий. И Эванс предложил использовать для них весь аппарат, накопленный ООП для объектов - наследование, полиморфизм, или наоборот изоляция и трансляция. Это реально круто, потому что снимает проблемные холивары о "правильных" системах понятий, которые возникали между специалистами, редко взаимодействующими между собой в деятельности.
   • И, наконец, DDD содержит большое количество шаблонов, применяемых для построения модели. При этом подходы и шаблоны ООП переносятся на уровень организации бизнеса.

Я наверняка перечислил не все. Но перечиленные достаточно плотно покрывают область разработки. Если расположить их относительно процесса разработки на V-диаграмме, получится следующая картинка.

А в заключении хочу отметить следующее.

1. Для сложных систем этого все равно недостаточно, там нужна координация работы с архитектурой и согласованное изменение составных частей. Для этого разработан SAF - Scaled Agile Framework, в котором достаточно много соответствующих активностей. Хотя он больше находится в организационной плоскости, нежели в инженерной.
2. Организационные и инженерные практики должны быть поддержаны инструментально. Здесь в базовый набор входит система контроля версий, например, Git, Task tracker, Wiki-системы ведения документов, средства непрерывной интеграции, автотестов и конвейера поставки продукта. Наглядные Scrum-доски, как правило, не заменяют, а дополняют их, хотя часто начинать можно с этих средств. А вот если вместо task tracker и Wiki-систем у вас почта и свалка документов на файловом сервере, то процесс работать не будет, независимо от гибких методологий.
3. Практики дополняют друг друга, собираясь как паззл в метод разработки. Применяемый метод должен быть адекватен проекту, а в пределе - каждый проект разрабатывается собственным адаптированным методом. И недавно разработан формализм для технологичной работы с индивидуализированными методами IT - разработки - OMG Essence. Но это уже тема отдельного поста.

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

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

И я хочу пожелать всем в Новом году плодотворной деятельности, счастья, здоровья и приятных сюрпризов. И еще раз поделиться со всеми самым неожиданным для меня результатом года прошедшего - песней, ставшей новогодней сказкой! https://youtu.be/28uQ6afWsxU

В посте - мое понимание услышанного и мысли по поводу. Цитаты неточные, смыслы - интерпретированные.

Последняя, 24-я лекция Петра Щедровицкого по СРТ была месяц назад, 25.11. Но я в этот день был на SQAdays в Минске - выступал с докладом и активно общался, а потом участвовал и выступал еще на нескольких мероприятиях. И только сейчас послушал лекцию и пишу эти заметки. В конце отчета будет мое самоопределение в новом мире 3 промышленной революции, а начну я с содержания лекции.

→ продолжить чтение…