В последнее время в силу несколько изменившегося круга должностных обязанностей помимо литературы по информационной безопасности в моей библиотеке прочно обосновались книги по разработке и гибким (agile) методологиям.
Для тех, кто не очень в курсе, Agile - это вообще говоря целая философия, в рамках которой разработаны различные инструменты и подходы, которые позволяют обеспечить ту самую "гибкость" в плане разработки программного обеспечения, направленную на получение оптимального результата за короткие сроки. Но хотя Agile и ассоциируется у многих исключительно с разработкой, эти самые инструменты легко можно применить и для управления проектами, и даже для организации собственной работы.
И надо сказать книжек про это написано огромное количество. Вот, например, на Amazon:
Они конечно все англицком, на русском мало что можно найти, но все же можно:
http://agilerussia.ru/methodologies/borisvolfson_ebook/ - обзор инструментов Agile (для общего понимания)
http://agilerussia.ru/books/scrum_xp-from-the-trenches/ - практика применения Scrum
http://scrum.org.ua/wp-content/uploads/ScrumAndKanbanRuFinal.pdf - практика применения Scrum и Kanban.
Да, они конечно ориентированы именно на разработку программного обеспечения, но тем не менее при должной фантазии можно многое из этого применить и к организации личных дел и к своей профессиональной сфере.
Я, например, использую Scrum в управлении своими задачами, где в качестве спринта выступает календарный месяц. Удобно, наглядно.
В этой заметке я затрону только 2 инструмента agile: Scrum и Kanban.
Scrum - это на самом деле управленческий фреймворк, который помогает организовать работу команды в рамках определенного проекта. На мой взгляд он отлично подходит для организации работы по внутренним проектам по информационной безопасности (любым проектам: внедрение технических средств, аудит ИБ, пен-тест, да что угодно).
Основные инструменты в рамках этого фреймворка:
1) Разбиение всей работы на небольшие фрагменты (длительность 2-4 недели), которые называются спринтами. Спринт жестко фиксирован по времени и это позволяет очень быстро увидеть укладывается ли команда в тот темп, который она запланировала. Если вы, например, 2-3 спринта подряд делаете только половину работы из той, что была запланирована на спринт, то можно смело утверждать, что весь проект вы скорее всего уже не уложите в изначальные сроки. На мой взгляд это очень полезная практика, ведь, как известно, любой проект длительностью больше 6-9 месяцев быстро становится неуправляемым, а разбиение его на небольшие фрагменты с постоянным контролем результатов позволяет не потерять управление ситуацией.
2) Ежедневные scrum-митинги. Это когда команда проекта собирается каждый день, на небольшую летучку (в идеале минут 15) и обсуждает что было сделано за день, какие планы на следующий день и нет ли каких-то сложностей, которые тормозят работу. Применительно к проектам ИБ может быть и не обязательно собираться прям каждый день, но минимум раз в неделю точно нужно что называется "сверять часы".
3) Демонстрация итоговых результатов спринта. Любой спринт должен заканчиваться демонстрацией результатов (пусть даже и промежуточных). Это является дополнительным организующим фактором для команды, т.к. всем понятно, что надо не просто отработать этап и идти дальше, а надо показать чего конкретно удалось добиться. Вообще говоря на демонстрацию приглашаются все желающие, но применительно к ИБ-проектам пожалуй круг нужно сужать до определенных людей, в том числе и от бизнеса, если реализуемый проект каким-то образом затрагивает их работу.
4) Ретроспектива. Это мероприятие проводится по завершению очередного спринта. Суть его в том, чтобы оглянуться на проделанную работу, понять что было сделано хорошо (и закрепить эту практику), ну и понять что было сделано плохо, какие сложности возникли и что нужно сделать, чтобы в будущем их избежать и повысить эффективность работы команды. На ретроспективу собирается вся команда и проводится она как правило в виде коллективного брейн-сторма.
Kanban - это отличный инструмент организации конвеерной скажем так работы. Основной отличительной фишкой канбана является так называемый лимит выполняемой работы (WIP limit). Предположим у вас есть некий процесс, предполагающий прохождение по определенным стадиям. Это может быть обработка инцидентов, обработка запросов на создание учетных записей, обработка заявок на доступ к информационным ресурсам и проч. Т.е задача (или заявка или что-то еще, далее для простоты я буду говорить "задача") проходит последовательно через несколько этапов, за которые могут отвечать в том числе разные исполнители. Основной целью в канбане является то, чтобы прохождение задачи по всем стадиям было как можно более быстрым и чтобы не встречало никаких препятствий, т.е чтобы создавался непрерывный поток, основным показателем эффективности которого является среднее время, которое уходит на то, чтобы пройти процесс от начала до конца.
"А зачем же нужен лимит выполняемой работы ?", спросите вы. Лимит выполняемой работы определяет какое количество задач может одновременно находится на определенной стадии. И если этот лимит достигнут, то никакие новые задачи на эту стадию перейти уже не могут. Это позволяет очень быстро выявить узкие звенья в процессе, на которых случается "затык".
Т.е если какой-то исполнитель на своей стадии не справляется, то его лимит быстро забивается и весь конвеер встает, потому что ему уже не могут передать задачу исполнители, которые стоят до него в цепочке процесса, а те, кто стоят после него остаются без работы (или загружаются меньше чем надо бы). Все это позволяет очень быстро заметить проблемы и принять меры для совершенствования процесса.
Вот так, пробежался по верхам. Для заинтересовавшихся темой рекомендую почитать что-то из предложенной мной выше литературы.
Facebook
Комментариев нет:
Отправить комментарий