Victor Pryazhnikov

Виды жизненного цикла

Sat, 04 Apr 2020 00:00:00 +0000

Данный пост написан по материалам практикума системного мышления от “Школы системного менеджмента”

Водопадный

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

Между стадиями работ происходит проверка и приёмка результатов предыдущих стадий, по результатам которых принимается одно из возможных решений:

продолжение работ и переход к следуюущией стадии;
возвращение на доработку;
прекращение работ по системе.

Места проверки и приёмки между стадиями называются контрольные точки (milestones). Они известны заранее и используются в планировании работ по проекту.

Спиральный

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

Гибкий

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

В гибких методологиях мы имеем дело с какими-то проблемами (issues), у которых есть описание и известна только ближайшая контрольная точка. При её достижении можно понять, какова следующая контрольная точка и что нужно делать дальше. Обычно для отслеживания состояния таких проблемам используются специальные программы — issue tracking systems.

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

См. также:

Страница Spiral model в Википедии
Страница Issues в Википедии
Страница Issue tracking system в Википедии
Страница Agile software development в Википедии
Учебник “Системное мышление 2019”, глава №9 (“Не жизненный не цикл”) и №10 (“Вид жизненного цикла”).

Жизненный цикл: версии 1.0 и 2.0

Sat, 28 Mar 2020 00:00:00 +0000

Данный пост написан по материалам практикума системного мышления от “Школы системного менеджмента”

Система не создаёт сама себя, а появляется в результате работ, которые выполняют системы обеспечения.

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

Список стадий может быть разным для разных систем. Вот например стадии создания автоматизированной системы по ГОСТ 34.601-90:

Формирование требований
Разработка концепции
Техническое задание
Эскизный проект
Технический проект
Рабочая документация
Ввод в действие
Сопровождение

Такой вариант описания называется жизненным циклом версии 1.0. Его можно считать надсистемой для всех систем обеспечения.

Использовать такой вариант жизненного цикла неудобно по нескольким причинам:

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

Чтобы решить эту проблему в жизненном цикл версии 2.0 делается переход от рассмотрения набора стадий к рассмотрению с точки зрения выполняемых практик.

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

Таким образом, представление жизненного цикла системы раскладывается на две состявляющие части:

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

См. также:

Учебник “Системное мышление 2019”, глава №9 (“Не жизненный не цикл”).
Статья “Жизненный цикл системы” в Википедии

Системные уровни и эмерджентность

Sat, 22 Feb 2020 00:00:00 +0000

Данный пост написан по материалам практикума системного мышления от “Школы системного менеджмента”

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

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

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

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

Например, телевизор, инфракрасный порт и пульт вместе дают новое свойство - управлять телевизором на расстоянии. При этом нельзя добавить к телевизору только пульт или только инфракрасный порт, т.к. по отдельности они не дадут нового свойства (т.к. у телевизора не будет или источника, или приемника сигнала).

При разбиении системы следите за двумя моментами, связанными с эмерджентностью:

Добавлять новый элемент в рассматриваемую систему стоит только если он приносит что-то новое. Если не появляется нового свойства, то зачем же он нужен?
Если набор систем, собранных вместе, не дают нового свойства, то их нельзя считать новой системой.

См. также:

Учебник “Системное мышление 2019”, глава №4 (“Системные уровни”).

Процессы в компьютерных программах с точки зрения системного подхода

Sat, 08 Feb 2020 00:00:00 +0000

Данный пост написан по материалам практикума системного мышления от “Школы системного менеджмента”

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

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

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

Возьмём заказ билета на самолет через сайт авиакомпании в качестве примера. В этом процессе будут задействованы:

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

При желании этот список можно продолжать как “вширь” (добавляя новые шаги покупки билета), так и вглубь (детальнее прорабатывая каждый шаг). Важно помнить, что процесс ограничен не только в пространстве, но и во времени - поэтому учитывайте только те объекты, которые участвуют в рассматриваемом процессе во время его выполнения.

См. также:

Учебник “Системное мышление 2019”, глава №2 (“Воплощение и описание системы”) — отдельно рекомендую прочитать раздел “компьютерные программы” в конце главы.

Как использовать термины в разговорах?

Sat, 01 Feb 2020 00:00:00 +0000

Данный пост написан по материалам практикума системного мышления от “Школы системного менеджмента”

Термин — это слово, которое обозначает какой-то объект (или “концепт”). Проблема с терминами заключается в том, что есть разные “диалекты” и одна и та же вещь быть названа разными терминами.

Спорить о терминах и пытаться переучить собеседника — это плохая идея. Во-первых, это может привести к ожесточённым спорам за правильное название. Во-вторых, даже в случае успеха это повлияет на собеседника и он перестанет говорить так же уверенно, как раньше с использованием хорошо знакомого ему языка.

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

При этом объяснять лучше не на базе других терминов (которые тоже могут быть различаться), а на уровне физического мира. В системном подходе для этого используется понятие 4D-объекта - если объект занимает одно и то же место в (трехмерном) пространстве в одно и то же время (т.е. в четвертом изменении), то это один и тот же объект.

Работая в web-студии много лет назад я неосознанно использовал подобную технику, когда нужно было разобраться с проблемами одного заказчика, который плохо разбирался в интернет-сайтах и использовала термины с непонятными значениями. Она называла ссылки “переходами” и никто не понимал, о чем она говорит и что хочет. Разобраться с её пожеланиями мы смогли только после того, как перестали её поправлять, а посадили её у экрана монитора и просили показывать “пальцем” на то, про что она говорит.

При этом нельзя игнорировать сами слова-термины.

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

См. также:

Учебник “Системное мышление 2019”, глава №1 (“О мышлении”) — очень большая глава-введение в системное мышление.
Экстенсионализм — описание 4D экстенсионализма в Systems Engineering Thinking Wiki.
“Табуирование” — описание приёма в wiki русскоязычного сообщества LessWrong.

Практикум системного мышления

Mon, 27 Jan 2020 00:00:00 +0000

Сегодня начался практикум системного мышления от “Школы системного менеджмента”. Главное отличие этого практикума от онлайн-курса, который я проходил около года назад, заключается в том, что мы будем не просто “изучать системное мышление”, а сразу применять его в своём рабочем проекте. После прохождения онлайн-курса було много сложностей как раз с применением на практике и я решился пройти еще один курс.

В течение следующих 12 недель я буду проходить курс и планирую периодически записывать сюда какие-то основные моменты. Не получится делать это оперативно (практикум предполагает самостоятельную работу по 10 часов в неделю), но надеюсь, что периодически я буду переносить сюда основные моменты из своих записей.

Этот пост будет пополняться

Содержание

Неделя №1

См. также:

Заметка “Как использовать термины в разговорах?”

Неделя №2

См. также:

Заметка “Процессы в компьютерных программах с точки зрения системного подхода”

Неделя №3

Неделя №4

См. также:

Заметка “Системные уровни и эмерджентность”

Неделя №5

Неделя №6

Неделя №7

Неделя №8

Неделя №9

См. также:

Заметка “Жизненный цикл: версии 1.0 и 2.0”

Неделя №10

См. также:

Заметка “Виды жизненного цикла”

Неделя №11

Неделя №12

Обзор конференции Стачка 2019 в Иннополисе

Mon, 04 Nov 2019 00:00:00 +0000

Введение

Конференция “Стачка” уже 7 лет проводится в Ульяновске и сами себя они называют “крупнейшей регональной IT-конференцией. В этом году она впервые прошла не только в Ульяновске, но и в Иннополисе на территории местного университета.

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

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

Обзоры докладов

Как ускорить А/Б тесты в 10-100 раз (Валерий Бабушкин, X5 Retail Group / Яндекс)

Описание

Доклад состоял из двух частей: в первой Валерий рассказал, что такое A/B тестирование и зачем оно нужно, а во втором показал несколько приёмов, с помощью которых можно быстрее получить результаты теста с нужной степенью уверенности.

Всего было три приёма:

Линеаризация - тут мы делаем замену переменной и оцениваем не саму метрику теста (в качестве примера был CTR у какой-то ссылки), а её отличие от значения в контрольной группе. Это значение получается более чувствительным, что сокращает время на получение результата теста с нужной степенью уверенности.
Перевзвешивание (reweighting) - оно позволяет решить проблему наличия разных пользователей (с большой активностью и маленькой, “зевак” и реальных покупателей в магазине и т.д.). Основная идея тут в том, что пользователи учитыаются с разными коэффициентами. Про подбор коэффициентов Валерий не рассказал, сославшись на то, что его просили не раскрывать детали (видимо, это коммерческая тайна).
Использование теоремы Байеса - основная идея тут была в том, что мы переходим от сравнения с контрольной группой к сравнению с моделью поведения в контрольной группе, созданной с помощью машинного обучения. Детали я не записал и не смог восстановить по презентации, но кажется, что по смыслу это похоже на описанное в статье “Учёт данных о прошлом поведении пользователя в метриках A/B-тестирования”.

Как перестать бояться и начать разрабатывать специализированные структуры данных (Алексей Миловидов, Яндекс)

Описание, презентация

Алексей Миловидов - тимлид команды, занимающейся разработкой ClickHouse, и на его докладе был аншлаг. В докладе Алексей рассказал про задачу анализа фрода для Яндекс.Метрики и решении, которое он делал для хранения необходимой для этого информации. Он рассказал про набор оптимизаций, которые позволили не одном сервере хранить данные для 600К RPS. Мне запомнились эти:

Cчётчики с вероятностным инкрементом старших байтов для хранения количества запросов к конкретным URL - это позволяет (с погрешностью) хранить счётчики с миллиардными значениями в одном байте:
Hyperloglog для хранения уникального количества (кажется) IP адресов, запрашивающих URL - тут для меня стало откровением, что при снижении точности результата можно очень серьёзно сэкономить место для хранения счётчиков (с нескольких килобайт буквально до пары десятков байт).
Counting bloom filters - разновидность фильтров Блума, считающие не факт наличия значения в потоке, а количество вхождений (до определённого предела). Они позволяли вообще не хранить информацию об URL, которые запрашиваются слишком редко.

Этот доклад понравился мне больше всех остальных на этой конференции. Это уже повтор выступления Алексея с одного из “Яндекс.Субботников”, поэтому есть вероятность, что “Яндекс” опубликует видео или текстовую расшифровку. Пока же рекомендую посмотреть презентацию.

“Как разрабатывается популярный OpenSource фреймворк” (Александр Макаров, Yii)

Описание

Александр Макаров рассказал про то, что стоит за разработкой популярного open source продукта. В целом было довольно интересно и я вынес оттуда две основные мысли:

Работа над популярным продуктом - это не столько про программирование, сколько про работу с сообществом, которое пользуется этим продуктом.
Работа над популярным продуктом требует множество усилий, поэтому стоит подумать, зачем оно автору и зарабатывает ли он на нём что-то. Если нет, то есть серьёзная вероятность, что в какой-то момент проект окажется заброшенным.

Тестирование больших кросс-командных проектов в дедлайн (Павел Сташевский, Lamoda)

Описание

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

Выделить список заинтересованных лиц (стейкхолдеров проекта) и собрать из них проектную команду. В этой команде не обязательно должны быть все заинтересованные, но стоит добавить туда “тест лида” (обычно из команды функционала, который будет задет больше всего). Задача тест лида - следить за тестированием всего проекта (и знать проект лучше всех).
Разобраться в бизнес-требованиях проекта и разложить их на составляющие (не только с точки зрения IT-систем, но и с точки зрения данных в этих системах и операционных процессов, которые участвуют).
Собрать требования и подготовить тест-план, ориентируясь на реальность сценариев и их ценность с точки зрения бизнеса. Это позволяет сократить количество сценариев и “победить” комбинаторный взрыв.
После сбора стоит показать сценарии всем членам команды проекта.

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

Профессиональная убедительность для инженеров перед менеджерами (Алексей Пименов, RealResult)

Описание

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

Основной тезис заключался в том, что когда инженеры пытаются убедить менеджеров в своей правоте они апеллируют к цифрам и логике. Проблема в том, что этого мало, т.к. в голове человека есть две системы (система I и система II по Даниэлу Канеману) и к логическим аргументам нужно добавить визуализацию, которая наглядно продемонстрирует идею. Дальше были прикладные примеры диаграмм, которые можно получить из данных трекеров задач, и кейсы-примеры, в которых они помогли.

Алексей показал такие виды диаграмм:

накопительная диаграмма потока: сколько задач в каких статусах находилось в системе в этот день;
спектральная диаграмма: гистограмма распределения количества задач по времени, потраченному на их выполнение;
эффективность потока: показывает долю времени простоя задачи при переходе между статусами.

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

Всё пошло по Кафке (Григорий Кошелев, СКБ Контур)

Описание

Доклад состоял из двух основных частей. В первой Григорий рассказал, как устроена Apache Kafka, а во второй части прошёлся по “граблям”, с которыми они сталкивались. Общий посыл был в том, что нужно очень аккуратно подходить к настройке и следить за изменениями в поведении параметров при обновлении версии. Пересказывать проблемы нет особого смысла - лучше посмотрите презентацию.

Главное, что вынес - что документация к Кафке написана не очень хорошо и если нужно больше информации по тому, как всё устроено и работает, то стоит читать KIP-ы (Kafka Improvement Proposals).

Григорий уже выступал в этом году с похожими докладами:

“А вы Кафку пробовали?” на CodeFest (есть видео и презентация)
“Когда всё пошло по Кафке” на JPoint (есть видео и презентация)

Продукто-ориентированный программист (Дмитрий Шестернин, flowwow.com)

Описание

Рассказ от небольшого онлайн-магазина цветов (как я понял, работающего по Uber модели) про то, как им удаётся работать над продуктом при небольших ресурсах. Основная идея - нанимать программистов, которым интересно думать о продукте, а не тех, кому интересны только технологии.

Из всего доклада запомнилось буквально пара мыслей:

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

Забавный факт: идею важности “думания о продукте” Дмитрий подтвердил на деле тем, что за время проведения конференции подключил к flowwow единственный цветочный магазин в Иннополисе.

Rest API сервер от кода до деплоя (Борис Ершов, Nixys)

Описание

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

Общая идея заключается в том, что в контейнер зашивается версия схемы данных, в которой он должен работать, и всё необходимое для накатывания миграций. При развертыватывании новой версии сервиса, он сам накатит нужные миграции в случае, если версия БД меньше чем необходимая для его работы.

При проблемах в первую очередь откатывается на предыдущую версию сервис, а при необходимости уже потом “по кнопке” откатывается миграция схемы БД. Чтобы это работало нужно думать об обратной соместимости версии базы данных (т.е. не нужно добавлять новую колонку и сразу удалять неиспользуемую, а стоит разделить это на несколько отдельных миграций).

Эластик весом весом в петабайт (Владимир Лила, СКБ Контур)

Описание

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

почему они используют Kafka для записи данных в Elastic;
как организованы и как хранятся индексы;
какие задачи по работе с индексами автоматизированны и почему именно они.

У меня нет практического опыта работы с “эластиком” и было интересно послушать про это. Если тема интересна, то рекомендую посмотреть видео (на “Стачке” видеозаписи не было, но Владимир в этом году выступал с этим же докладом на DUMP, записи откуда можно найти).

Полезные ссылки:

сборка ElasticSearch с открытой лицензией от Амазон;
curator - набор утилит для работы с индексами ElasticSearch.

Заключение

В целом конференция мне понравилась (за исключением некоторых организационных моментов) и я могу рекомендовать её к посещению.