Agile *

Аннотация

В данной статье приводится описание спецификации и применения СУИБ (системы управления информационной безопасности) на базе ДОУ (документационного обеспечения управления) организации, где рассматривается:

1. Разработка и проектирование ДОУ в СУИБ организации, в том числе программно-аппаратной реализации и ее сводной спецификации.
2. Сторона унифицированных и специализированных характеристик управления структурой организации для внедрения в промышленную эксплуатацию приведенного формата решения.
3. Формат применительности представленного решения на базе методик проектной деятельности организации.
4. Формирование ДОУ, базирующееся на СУИБ организации, где система представляет из себя образчик требований для обеспечения целостности, доступности и конфиденциальности информации, обрабатываемой посредством ДОУ.
5. Ликвидность организации согласно ДОУ организации, со стороны СУИБ.
6. Формат управления ДОУ и распределения уровней доступа к категорированию информации в формате take-grant (субъект-обьектных) связей, со стороны потокового документооборота организации, учитывая локальные инструкций внутри организации.
7. Типизация форм для оптимизации ДОУ в СУИБ.

Отметим: вся проделанная работа состоит на базе действующего законодательства по ОИБ (обеспечению информационной безопасности) КИИ РФ, где решение поставленной проблемы носит рекомендательный характер к исполнению для оптимизации мощностей организации, включая формат минимизирования и адаптации действующей документации.

Иногда при обсуждении продукта метрики только мешают

Итак, меня спросили: «Если бы для agile-команды можно было бы отслеживать только две метрики, что бы вы выбрали?»

Продолжу тему "«станков» и «растений»" и сегодня поговорим о "растениях"… С тем, что команды agile обладают всеми признаками живой сущности, согласны многие ученые, а значит, мы можем взглянуть на команду как на живую сущность, со всеми присущими признаками и свойствами. И первое, что бросается в глаза — все живое на нашей планете классифицируется и имеет принадлежность к той или иной группе, при этом про команды (или другие группы людей, объединенные общей целью) мы можем только сказать, что они все разные… Хотелось бы обсудить эту тему и предложить свой метод классификации команд.

Всем известна фраза Рона Хаббарда «…хочешь заработать миллион — создай свою религию», которую он выдал в 1950 году. Тогда он создал ещё одну деструктивную секту, можно это было в 60-х в США — которая до сих пор пытается утвердиться в мире, как религия.

Хотя, сорри, друзья.

Во-первых, это было сказано, а точнее написано в 1938 году.

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

В-третьих, впервые это фраза появилась в его письме в виде строчки “there might be a lot of cash in starting a religion”: я бы перевёл, "как можно можно поднять славно деньжат, если застартапить религию".

Долгое время этой простым и немудрённым рецептом пользовались только сайентологи. Но потом к ним подтянулись башковитые ребята из IT — c IQ у них всех было всё OK, а деньги и уважение лишними не бывают.

Будем считать это исключительно моей личной субъективной гипотезой, но именно так появились Agile, а затем Scrum. Давным-давно в XIV веке Уильям Оккам сформулировал одну чудесную фразу в одной из книг: «Non sunt entia multiplicanda praeter necessitatem». Вот и удивляюсь, как жила разработка до появления Scrum. Наверное, её просто не было. На самом деле "клиентоориентированность" — это финальный этап чудесной эпохи потребления, которая как раз заканчивается — вертись вокруг клиента, как Солнце вокруг плоской Земли, и всё будет путём.

В этом посте будет рассказано о том как сделать интеграцию Youtrack со встроенным (embedded) Hub с Teamcity, Gitlab.

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

Как гибкая локализации помогает улучшить качество продукта и оптимизировать бизнес-процессы? Рассказываем о преимуществах применения agile на проектах по локализации продукта.

Я работаю в Слёрм. И по большей части вижу, как курсы создаются, как проходят интенсивы со стороны — как наблюдатель, немного летописец, чуть больше журналист. Я вижу внутренние процессы, как из ничего рождается нечто — всего за пару недель мыслей, идей и слаженной работы нескольких десятков человек. Это почти как магия.

На этот раз я решил стать участником самого курса «Профессия Scrum-мастер». По ряду причин. Мне всегда нравились непрямые подходы мотивации людей. Не банальные «кнут и пряник», которые всем уже знакомы по корпоративным иерархическим структурам. Не триада «стыд, страх, грех», которую применяют древние авраамические религии. А нечто новое. То, что и должно появиться в 21 веке — пора уже, не правда ли?

Лично моё субъективное мнение — это только лишь зачатки того, что будет. Другое отношение к сотрудникам, другое построение компаний — может, появление микро-компаний вместо огромных гигантов корпораций, может, изменения направления трансформации «сверху-вниз» от топов к линейным сотрудникам, может изменения самосознания самих сотрудников, которые будут сами стремиться к такому подходу в компаниях на рынке труда и тем самым формировать сам рынок. Time will tell. Sooner or later time will tell.

Эта статья не реклама. Честно, не люблю рекламные статьи. Это статья — наблюдение и размышление о том, что уже зародилось и продолжает меняться. Лично я считаю, что и Agile и Scrum — это всего лишь первые шаги на пути изменений обычных процессов. И да, пока что они во многих курсах на образовательном рынке слишком близки к «инфобизу», «инфоцыганам» и прочим «тониробинсам». Но тут проблема не в самих гибких методологиях, а в людях. Наносное уйдёт, ценное останется.

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

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

Петрович был старым опытным CTO — он ещё помнил перфокарты, а количество языков программирования, которые он знал, было примерно равным числу языков, которые канули в Лету естественного отбора в IT-среде и благополучно затерялись в долгосрочной памяти Петровича.

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

Петрович аккуратно загнал его в угол и спросил:

— Тебе как зовут, Вася?
— Серёжа.
— Скажи, Серёжа, что такое «99 бутылок пива» и числа Фибоначчи?
— Что?
— «Hello, world» — это что?
— Здравствуй, мир! — просиял Серёжа-Вася.
— Ясно, — сказал Петрович и потащил Серёжу к безопаснику.

Там в кабинете он торжественно вручил коллеге дичь.

— Вот. Шпиона поймал. Производственный шпионаж, как он есть. На пятом этаже бродил, в программировании разбирается, как коза в стиле и этикете.

Безопасник устало махнул рукой:

— Петрович, отпусти его. Наш это. Айтишник. Scrum-мастером зовётся. Уже неделю работает.
— Один спринт, — пискнул Серёжа.

Петрович тоскливо задумался о временах перфокарт.