Poclac что это – Что такое poclac в гибких методологиях?

Как объяснить бабушке, что такое Agile за 15 минут с картинками / Edison corporate blog / Habr

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера
Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

Роли

Это Пэт, владелец продукта. Она не знает технических деталей, зато обладает видением общей картинки, знает, зачем мы делаем продукт, какие проблемы он будет решать и для кого.
Это заинтересованные лица. Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.
Это пользовательские истории. В них выражены пожелания заинтересованных лиц. Например, «у системы бронирования авиабилетов у пользователя должен быть поиск по рейсам».
У заинтересованных лиц много идей, и Пэт помогает сделать из идей пользовательские истории.
Это команда разработчиков. Те, кто будет строить рабочую систему.

Пропускная способность

Так как команда использует гибкую методологию разработки, они не копят все эти истории до большого релиза, наоборот, они выпускают их сразу и как можно чаще. Обычно они выпускают 4-6 пользовательских историй в неделю. Это их пропускная способность. Ее очень просто измерить — количество пользовательских историй за 7 дней.

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

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

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

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

Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.

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

Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”

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

Kanban рекомендует ограничиться несколькими задачами — WIP limit. Допустим команда решает, что 5 — это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.

Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.

Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.

Есть только один способ держать список задач под контролем — это слово “нет”

Это наиболее важное слово для владельца продуктом. Он должен тренировать его каждый день перед зеркалом.

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

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

Принятие решений

Некоторые истории крайне необходимы, а некоторые просто бонусные фичи. На разработку одних историй уйдет пару часов, на разработку других — месяцы.

Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.

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

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

Одной приоритезации недостаточно. Чтобы выпускать истории быстро и часто, нужно разбивать на кусочки, которые можно сделать за пару дней. Мы хотим чтобы в начале воронки были маленькие и четкие истории а в конце — большие и неопределенные. Вовремя делать такую разбивку мы можем воспользоваться нашими последними открытиями относительно продукта и нужд пользователя. Это все называется очистка Backlogа.

Пэт проводит встречу по очистке Backlogа каждую среду с 11 до 12. Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц. Содержание встреч бывает разным. Фокусировка на оценке, на разбивке историй, на критериях приемки.

Владелец ИТ-продукта должен постоянно со всеми общаться

Матерые владельцы продукта выделяют 2 компонента успеха: страсть к работе и общение. Какие задачи владелец продукта решает месте с командой.

Баланс между сложностью разработки и ценностью пользовательской истории

На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.

Риски

Бизнес риск: «Правильную ли вещь мы делаем?»

Социальный риск: «Сможем ли мы сделать то что нужно?»

Технический риск: «Будет ли проект работать на данной платформе?»

Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»

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

Компромисс между ценностями знания и ценностями для клиента

С точки зрения заказчика кривая выглядит вот так:

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

Компромисс между краткосрочным и долгосрочным мышлением

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

Делать правильные вещи, делать вещи правильно или делать быстро?

В идеале — все три одновременно, но в реальности приходится выбирать.
Предположим мы здесь. Пытаемся создать идеальный продукт с помощью идеальной архитектуры. Если мы потратим много времени, мы можем не попасть в «маркетинговое окно» и у нас появятся проблемы с деньгами.

или

Мы делаем быстро прототип продукта. Для краткосрочной перспективы это неплохо. В долгосрочной — мы получаем технический риск. И скорость разработки снизится до нуля.

или

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

Между ролями в Scrum существует здоровое противостояние

Владелец продукта фокусируется на построении правильных вещей. Команда фокусируется на том, чтобы строить вещи правильно. Scrum-мастер или agile-тренер фокусируется на сокращении цикла обратной связи.

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

Компромисс между разработкой нового продукта и улучшением старого

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

График уничтожения историй

Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.
Два тренда — оптимистичный и пессимистичный (можно на глаз). Расстояние между трендами показывает насколько нестабильна скорость работы команды. Со временем эти тренды стабилизируются и конус неопределенности будет уменьшаться.

Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?

Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.
Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.
Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»

Обычно лучше уменьшать содержимое проекта, чем увеличивать время. Если мы уменьшаем содержание, у нас будет возможность отодвинуть сроки. Мы можем выпустить кое-что здесь, а остальное — позже.

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

Несколько команд

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

Большая картинка
Исходник — Agile Product Ownership in a nutshell

видео на английском

видео на русском

Читать еще

2 ноября — самый айтишный день в году

---

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

А вот так в Edison разрабатывают продукты по гибкой методологии:

habr.com

Agile/Scrum для начинающих. Что такое гибкая методология?

Что такое Agile и Scrum?

Что такое Agile?

В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по “гибкой” разработке программного обеспечения.

Agile Manifest

Суть agile-подхода изложена в “манифесте”, но для заказчика ее можно коротко сформулировать так:

• разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;
• в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;
• команда разработки сотрудничает с Заказчиком в ходе всего проекта;
• изменения в проекте приветствуются и быстро включаются в работу.

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

Основополагающие принципы Agile.

Краткое видео о том, что такое Scrum (english).

Что такое Scrum?

Scrum – это одна из нескольких методологий гибкой разработки ПО:

• • Scrum
  • Lean
  • Feature Driving Development
  • Extreme Programming

Scrum процесс на одном листе

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

Артефакты в Scrum

В скрам используется всего четыре артефакта:

• Product Backlog
• Sprint Backlog
• Sprint Goal
• Sprint Burndown Chart.

Я рекомендую вам посетить наш тренинг “Scrum для проектных команд“. Тренинг помогает изучить Scrum-процесс от начала и до последних нюансов.

Product backlog:

• Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
• Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
• Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
• Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

На снимке ниже представлен Backlog проекта. Команда проекта выбрала 2 требования в Sprint#3.

Project Backlog (JIRA)

Sprint backlog:

• Это список всех требований, которые нужно сделать в ближайший спринт.
• В течение спринта, новые требования не могут появится в Sprint backlog.
• Все требования должны быть разделены на задачи и оценены.

Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

Kanban Доска в Спринте

Sprint Goal

• это краткое описание того, ради чего выполняется данный спринт.
• цель на спринт помогает команде принимать обоснованные решения.

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

Sprint Burndown Chart

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

Внешний вид диаграммы на рисунке ниже. На практике такая диаграмма очень наглядна: каждый день можно быстро узнать, насколько команда продвинулась вперед.

Burndown диаграмма в Jira

Если есть время, посмотрите мою запись о книгах, которые можно скачать для изучения Agile/Scrum.

Роли в Scrum

В скрам используется всего три роли:

• Product Owner
• Scrum Master
• Team.

Роль Product Owner

• формулирует требования
• приоритезирует требования
• корректирует приоритеты на каждом спринте
• несет персональную ответственность за ценность требований для рынка/пользователей
• отвечает за взаимодействие с рынком
• только один человек

Product Owner – это представитель подразделения, которое владеет разрабатываемым продуктом. Например в банке это может быть Департамент карточных продуктов. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

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

В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них “главного”, который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

Роль Scrum Master

• следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
• организует работу команды и обеспечивает её всем необходимым
• защищает команду, несёт ответственность за её эффективность
• только один человек.

Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет “администратор”. Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

• Скрам мастер не назначает людей на задачи – это делает сама команда;
• Мастер не заставляет людей делать работу – это ответственность команды;
• Мастер не указывает Product Owner какие требования он должен написать – это работа владельца продукта.

Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

Функции Scrum Master’a существенно шире, но чтобы пояснить их все нужна отдельная статья. Пишите в комментариях, если таковая нужна.

Team (команда проекта)

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

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

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

Команда НЕ принимает решений:

• какие требования являются приоритетными – это делает Product Owner.

На снимке ниже команда проекта проводит обязательный “ритуал” – Daily Meeting (см. ниже).

Команда проводит “ритуал” Daily Meeting

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

Ритуалы (процессы в Scrum)

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

Ритуалы в скрам это:

• Sprint Planning Meeting
• Daily Meeting
• Sprint Review
• Retrospective

Sprint Planning Meeting (встреча по планированию спринта)

• выполняется всей командой перед началом спринта
• команда выбирает требования из Product Backlog и формирует Sprint Backlog
• если требуется учесть взаимосвязи между операциями, то это делается здесь
• команда декомпозирует требования на задачи (tasks)
• каждая задача проходит оценку в трудозатратах или универсальных единицах
• во время встречи Product Owner отвечает на вопросы команды.

Встреча, которая проводится перед началом каждого спринта. Структура встречи:

• представление и пояснение Product Owner’ом списка требований
• вопросы со стороны команды
• /рекомендуется перерыв/
• декомпозиция требований на задачи (tasks)
• оценка задач по методу Planning Poker.

Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа. Крепитесь.

Daily Meeting (ежедневная встреча команды).

Из названия понятно, что встреча проводится ежедневно. Основные принципы:

• проходит ежедневно и только в одно и то же время;
• встреча проходит только стоя;
• поэтому длительность встречи не более 15 минут;
• чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

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

Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

Kanban Board во время спринта

Sprint Review – сдача спринта Product Owner

По завершению каждого спринта команда обязана провести демонстрацию полученного результат. Ценность этого ритуала я поясню отдельно.

Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

Структура встречи:

• команда зачитывает требования из Sprint Backlog
• по каждому критерию приемки происходит демонстрация полученных результатов
• каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
• каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

На встрече могут присутствовать любые сотрудники организации или просто заинтересованные лица. Важно, чтобы право голоса имели только участники Scrum процесса (Produt Owner, Team, Scrum Master).

Никаких презентаций в PowerPoint на встрече, если вы правильно меня поняли!

Retrospective

Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

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

• какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
• какие проблемы мешают команде выполнять взятые на себя обязательства?
• как улучшить взаимодействие с Product Owner’ом?
• какие ошибки совершает команда и почему.

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

Почему появился Agile?

Теперь немного слов о том, как и зачем появился этот подход? История возникновения этого подхода стала ответом на запросы отрасли:

1. Заказчик не может сформировать четкие требования к ПО;
2. Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе;
3. Заказчики и разработчики ПО не удовлетворены процессом взаимодействия.

#1 Заказчик не может сформировать четкие требования к ПО

В начальной фазе проекта заказчик не может сформулировать исчерпывающие требования к продукту. Этому есть несколько причин:

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

Один из принципов Agile гласит «Используйте прототипы и делайте поставки продукта как можно чаще». Это позволит снять неопределенность в требованиях и проверить, как с ней будут работать реальные пользователи.

В традиционных «водопадных» моделях руководитель проекта минимизирует изменения в проекте, используя для этого отдельные процессы – управление изменениями. Но если требования будут меняться раз в месяц, то управление изменениями становится трудоемким и замедляет ход проекта.

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

#2 Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе

К середине 90-х разрабатываемое ПО было в основном десктопным и его требовалось устанавливать на каждый отдельный компьютер (например, MS Word). С появлением веб-приложений внедрение новой функциональности стало происходить быстрее: требовалось развернуть приложение только на сервере и все пользователи получали к нему доступ. Эта инновация серьезно усилила конкуренцию между компаниями: тот, кто применил новую технологию раньше других – выигрывает рынок и клиентов.

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

#3 Заказчики и разработчики не удовлетворены процессом взаимодействия

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

Основная идея agile – сотрудничество с заказчиком важнее, чем контрактные обязательства. И поэтому agile-методы стремятся к уменьшению объема документации. Это позволяет Заказчику платить только за результат, имеющий ценность для бизнеса.

При этом agile не отказывается от формулирования требований. Заказчик (в agile – владелец продукта, product owner) предъявляет требования в упрощенном виде и на сценариях работы пользователей.

Резюме

Agile-философия проста. Agile-принципы разумны. Но переход к реальному применению agile – это серьезный вызов для каждой команды. Требуется не только освоить новый подход к управлению проектами, но также подобрать людей, способных работать в agile режиме.

0 91 100 34 Закрыть

Большое спасибо, что нашли время написать отзыв!

• Содержание статьи

• Актуальность информации

• Содержание статьи

• Актуальность информации

Спасибо! Все изложено в доступной форме!

• Содержание статьи

• Актуальность информации

Очень содержательно и последовательно!

• Содержание статьи

• Актуальность информации

Thanks a lot for your article! It was very helpful to me.

• Содержание статьи

• Актуальность информации

• Содержание статьи

• Актуальность информации

• Содержание статьи

• Актуальность информации

• Содержание статьи

• Актуальность информации

Очень информативно и структурировано!

• Содержание статьи

• Актуальность информации

• Содержание статьи

• Актуальность информации

Очень интересная и новая для меня тема. Понравилась статья!

• Содержание статьи

• Актуальность информации

Спасибо за краткость и точность

www.pmoffice.by

Стань Agile-коучем в Сбербанке! — Олег Бурко. Курсы, тренинги, консалтинг.

Кто такой Agile-коуч?

Осенью 2016 года Сбербанк сообщил о запуске программы трансформации Sbergile(Sberbank + Agile), которая основана на методологии Agile software development («Гибкая методология разработки») и позиционируется как самое значимое событие в истории банка.

«Agile – может быть, самая радикальная трансформация в нашей истории, за все 175 лет нашего с вами развития», – сообщил глава «Сбербанка» Герман Греф.

 

 

 

 

 

 

Ключевая роль в программе отводится Agile-коучам и ниже приведено описание данной вакансии в режиме «вопрос-ответ».

 

Agile-коучи: вопросы и ответы

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

Срок приема заявок продлен на 1 неделю (до 20 июня). В настоящий момент идет отбор в команду agile-коучей для первой волны agile-трансформации. Решения о том, каким образом будет происходить отбор agile-коучей для второй волны, пока не принято.

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

Интервью с кандидатами уже начались. Каждый участник конкурса, успешно прошедший первый этап отбора (на основании резюме) получит индивидуальное приглашение на интервью. Каждый кандидат должен будет пройти интервью с двумя членами рабочей группы по agile-трансформации Банка. Группы для обучения будут формироваться после 15 июля. Обучение участников первой волны Agile-трансформации начнется c 1 августа 2016 года.

Вопрос: Каковы перспективы развития и карьеры Agile-коуча?

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

Вопрос: Внедрение Agile мне напоминает внедрение ПСС. Или есть принципиальные отличия?

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

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

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

Вопрос: Сколько всего коучей планируется набрать?

На первом этапе планируется набрать 30 человек.

Вопрос: Сотрудники каких должностей рассматриваются на данную позицию?

Специальных требований по грейду и должности не установлено. В конкурсе могут принять участие сотрудники Центрального аппарата / ПЦП Блока «Технологии» / «Сбербанк-Технологии» в Москве, которые обладают следующими качествами:

1. Способны сплотить команду для достижения результата.
2. Создают вдохновляющую атмосферу и помогают развиваться.
3. Умеют слушать и находить общий язык с разными людьми.
4. Понимают природу конфликтов и умеют их разрешать.
5. Способны лидировать изменения, имеют опыт участия в успешных проектах.
6. Имеют какой-то опыт в Agile (желательно).
7. Участвовали в проектах с IT-составляющей (желательно).

Вопрос: Сколько команд будет курировать Agile-коуч?

Один Agile-коуч будет курировать 3-5 команд.

Вопрос: Что именно будет делать Agile-коуч? Это обучение команд или непосредственное участие в проектной деятельности в качестве наставника-консультанта? Обязанности коуча будут ограничены только внедрением Agile, или в ходе настройки новых процессов предполагается решение существенно более широкого круга проблем?

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

Основные обязанности и полномочия Agile-коуча:

1. 1. обучение участников команд
   2. запуск команды, выстраивание процессов поставки результатов
   3. работа над постоянным развитием и улучшением методов Sbergile (совместно с другими Agile-тренерами) и их внедрение в повседневную работу Команд
   4. развитие процедур обмена знаниями и опытом внутри Банка
   5. помощь команде в повышении эффективности и зрелости
   6. отслеживание групповой динамики развития команд
   7. проведение бесед с членами команд в формате «один на один» по вопросам индивидуальной эффективности
   8. идентификация проблем (и успехов) команд, помощь в их решении
   9. участие в совместной регулярной оценке участников команд, поиск возможностей для улучшения и трансляция этих возможностей командам (POCLAC)

Вопрос: Программа рассчитана только для сотрудников подразделений банка, расположенных в Москве?

На первом этапе принято решение о привлечении кандидатур тех сотрудников, которые работают в Центральном аппарате и СБТ И ПЦП московской локации. Это связано, в первую очередь с тем, что кандидатам предоставляется трехмесячный срок, в течение которого они могут вернуться на свое рабочее место. Соответственно, руководители кандидатов должны будут сохранять эти позиции незанятыми в течение этого срока. В отношении территориальных банков таких договоренностей пока не существует. Кроме того, в бюджет проекта на этом этапе не заложены затраты на релокацию.

Вопрос: Какой формат работы планируется? Это full-time или возможен вариант совмещения с текущей деятельностью? Можно ли пройти обучение по данной программе, но остаться в текущем подразделении?

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

Вопрос: Где будут находиться территориально коучи во время обучения? После обучения? Возможны ли командировки?

Во время обучения и последующей работы постоянное местонахождение Agile-коуча – ЦА (Москва). Командировки не предусмотрены.

Вопрос: Как непосредственно будет происходить отбор? Только по отправленному эссе и резюме или будут какие-то дополнительные этапы, личные собеседования, что-то еще?

Отбор будет проходить в три этапа:

1. Рассмотрение резюме, эссе, изучение информации о кандидате из базы HR
2. Собеседование с рекрутером
3. Собеседование с двумя членами рабочей группы по Agile-трансформации, в том числе с опытным Agile-коучем

Вопрос: Когда будут подведены итоги конкурса?

Итоги конкурса будут подведены в конце июля. Но решения по конкретным кандидатам могут быть приняты раньше

Вопрос: Могу ли я подать заявку, если мной еще не пройден испытательный срок?

Можете, если соответствуете предъявляемым к кандидатам требованиям

Вопрос: Требуется ли знание английского языка? И на каком уровне?

Знание английского приветствуется на уровне Intermediate, так как потребуется изучение различных непереводных текстов, презентаций, видео материалов.

Вопрос: Сколько времени будет проходить обучение? Можно ли во время обучения совмещать его с текущей работой?

Обучение Agile-коучей в первой волне проекта начнется 1 августа и будет проходить модулями в течение примерно двух недель. Программа обучения в настоящее время уточняется. После этого они будут проходить практику вместе с опытными agile-коучами с внешнего рынка. Во время обучения потребуется 100% отвлечение от рабочего процесса. Более детальная информация по вопросам обучения появится в ближайшее время.

Вопрос: Подскажите, пожалуйста, можно ли на данную программу пойти параллельно с шестым потоком Сбербанк 500?

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

Вопрос: Будут ли после прохождения (до прохождения) коучинга образовано постоянное структурное подразделение по Agile? Коуч будет работать в этой структуре или вернется на прежнее место работы?

После 3-х месячного периода тестирования agile-коучи будут переведены в отдельное структурное подразделение.

Вопрос: Что означает трехмесячный срок, в течение которогоможно вернуться на свою прежнюю позицию и заниматься тем же, чем занимался до Agile? С какого времени исчисляется этот срок?

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

Вопрос: Что значит: «будут уделять новым обязанностям 100% своего рабочего времени» в совокупности с «прежнее место работы будет закреплено за Agile-коучами»? Три месяца коучи будут числиться в своём исходном отделе/управлении, но выполнять обязанности, связанные с коучингом, получая задачи от другого руководителя?

Совершенно верно. Первые три месяца кандидат будет числиться в прежнем подразделении, но на 100% выполнять новые функции, исходя из задач, которые будут формироваться совместно с новой командой. И на оценку работы коучей будет влиять оценка команд, с которыми он работает.

Вопрос: Будет ли связано поле деятельности Agile-коучей с исходным отделом после истечения трех месяцев? Будет ли после этого иметь к ним отношение руководитель их исходного отдела?

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

Вопрос: Предусмотрен ли перевод сотрудников в другие отделы/должности по итогам обучения и работы?

Цель обучения – обеспечить потребности банка в Agile-коучах. После трехмесячного периода тестирования agile-коучи будут переведены в отдельное структурное подразделение. Если же по каким-то причинам кандидат вернется на прежнее место работы в течение трехмесячного срока, то его перевод на другое место работы или продвижение по должности будут находиться в компетенции прежнего руководителя.

Вопрос: Как будет компенсироваться труд Agile-коучей? Что вообще имеется в виду под компенсацией?

Под компенсацией понимаются условия материального вознаграждения, которые применяются в банке и СБТ и ПЦП сейчас.До конца года условия материального вознаграждения будут сохранены. Затем будет использоваться система материального вознаграждения для Agile-команд, которая будет разработана в течение первой волны проекта.

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

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

Вопрос: Какие грейды будут у Agile-коучей?

Вопрос грейдирования Agile-коучей будет решаться в течение первого этапа пилота. Система грейдирования в agile-командах, возможно, будет отличаться от действующей сейчас в Банке. Задача сохранения дохода — это задача подтверждения своих компетенций и навыков, а не сохранения грейда. Пока, на первом этапе, сохранятся те грейды, которые есть сейчас, то есть до конца 2016 года компенсация Agile-коучей будет соответствовать условиям на их прежней позиции.

Вопрос: Касательно условий вознаграждения – в бизнес-подразделениях основная часть вознаграждения приходится на бонусную часть. Как это будет учтено за 2016 г.?

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

Источник: sberbank-talents.ru

olegburko.ru

Что такое Agile-подход и зачем он нужен бизнесу? — статья в блоге ScrumTrek

Agile («аджайл») — слово, которое последнее время звучит из каждого утюга. Но что такое Agile и, главное, зачем этот Agile нужен?

Если открыть толковый словарь, например, Оксфордский, то можно прочитать там, как минимум, два определения:

1. Able to move quickly and easily.
2. Able to think and understand quickly.

То есть, чтобы быть agile, надо уметь быстро и легко двигаться и быстро соображать. Кажется, довольно полезные качества, особенно в бизнесе. Быстро соображать и быстро реагировать — это именно то, что доктор прописал, для нашего времени, иначе просто не выжить: конкуренты сожрут. В мире всё меньше отраслей, где этих конкурентов, нет. Да ещё скорость копирования практически лишает возможности вывести продукт на рынок и почивать на лаврах. Без способности быстро адаптироваться к изменениям, которую даёт так называемая «методология Agile», выживать всё сложнее.

Я не случайно беру выражение «методология Agile» в кавычки, потому что его можно часто услышать, но оно не совсем верное. Если не вдаваться в технические детали, то Agile — это не методология, а собирательное название различных методик и подходов к управлению, которые:

1. Фокусируют команду на нуждах и целях клиентов.
2. Упрощают оргструктуру и процессы.
3. Предлагают работу короткими циклами.
4. Активно используют обратную связь.
5. Предполагают повышение полномочий сотрудников.
6. Имеют в своей основе гуманистический подход.
7. Не являются конечным состоянием, а, скорее, образом мышления и жизни.

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

Фокусировка на нуждах и целях клиентов

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

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

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

Примеры подобных инструментов — Lean Canvas, Impact Mapping, User Story Mapping и другие Agile-методы описания гипотез и процессов.

Упрощение оргструктуры и процессов

Один из краеугольных камней Agile — это предельная простота. И оргструктура организации, и процессы, по которым работают люди, и правила должны быть настолько простыми, насколько это возможно. Это позволит людям сфокусироваться на своей работе, на ценности, которую они создают, а не на соблюдении регламентов и правил. Прекрасные примеры такого подхода можно найти во множестве команд, работающих по Scrum — самому популярному способу организации рабочего процесса в Agile. Фактически, все договорённости и правила команды в 10-11 человек, текущие задачи на пару недель, цели, а также стратегические планы легко могут поместиться на 2-3 листа бумаги А0. На одном листе может быть так называемый «бэклог спринта», перечень всего, что команда собирается сделать в ближайшую итерацию. Если повесить такой в помещении, где идёт работа, можно избавить себя от необходимости всё это запоминать. То же самое касается и процессов. Скажем, в Скраме место и время проведения всех встреч жестко фиксируются. Любой участник точно знает, что, например, в понедельник в 10-00 планируется ближайшая итерация, а в пятницу в 17-30 — встреча по улучшению процесса работы.

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

Примеры упрощения (и уплощения, но это тема отдельного разговора) в Agile — Scrum, Nexus, LeSS (Large-Scale Scrum, или Скрам на больших масштабах), а также сам Agile-манифест.

Работа короткими циклами

В мире Agile не принято запираться в мастерской на три года, чтобы точить там что-то интересное. Очень уж велик риск, потратить море сил и времени на то, что никому не нужно или устарело.

Чтобы подобного избежать, применяется так называемый итеративно-инкрементальный подход, когда:

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

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

Ещё одно преимущество такого подхода, помимо раннего выхода на рынок и внесения изменений на ранних стадиях работы, — это возможность более точно измерять прогресс. Мы не просто «сделали 15% всей работы», что довольно абстрактно. Мы «сделали 15% функционала», который уже работает.

Все процессные подходы в Agile имеют короткие циклы, будь то упомянутые ранее Scrum, Nexus, LeSS, SAFe или XP, плюс необходимость работы такими циклами упомянута и в самом манифесте Agile.

Активное, системное использование обратной связи

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

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

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

Примеры, опять-таки, есть везде: ретроспективные встречи в Scrum, Kanban, Nexus и LeSS, циклы I&A в SAFe, подход к созданию продуктов Design Thinking, циклы обратной связи в DevOps и т.д.

Повышение полномочий сотрудников

Зачем давать больше полномочий, когда можно дать бумажку с инструкцией? Есть, как минимум, три причины это делать.

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

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

В-третьих, это всё та же скорость. Если человек может сам, на своём месте, никого не спрашивая, решить какую-то проблему, это сокращает время принятия решений. Не надо больше отправлять вопрос «вверх» и ждать ответа от менеджмента. Это преимущество не так заметно, если у вас работает 3 человека, но если вас 30, или 300, или 3000… В больших организациях, построенных сугубо на иерархическом принятии решений, паралич воли может быть довольно частым явлением.

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

Гуманистический подход

Зачем относиться к людям по-человечески? То есть, моральная сторона дела ясна, а какую пользу это принесёт владельцу предприятия?

Ответ довольно простой. Если создание того, что вы продаёте, не требует умственного труда, а только механический действий — можете не заморачиваться. Просто платите соразмерно сделанной работе, и всё. Но как только в дело вступает мозг работников — придётся считаться с принципами мотивации умственного труда. А они говорят, что для людей важны возможность самореализации, повышения своего мастерства, принесения чего-то ценного в мир, самостоятельности в решениях и ещё ряда факторов. И человек мотивированный (не путать с человеком простимулированным!) будет вкладываться в работу сильнее, и результат будет качественнее и быстрее. Да и в целом, приятная обстановка на работе добавляет желания туда приходить и работать — с этим тоже вряд ли кто поспорит.

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

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

Agile — это не конечное состояние, а образ мышления и жизни

Этот пункт о том, что применение Agile в целом — путь, а не цель. Нельзя «внедрить» Agile и расслабиться. Если вы выбираете этот путь, у вас всегда будет что-то ещё, что можно сделать лучше, какой-то ещё вызов, которому надо ответить, какая-то ещё проблема, которую надо решить, ещё одна высота, которую надо покорить… Это движение бесконечно, потому что нет идеального процесса или продукта, развитие и конкуренция не останавливаются никогда, как никогда не прекращается борьба за выживание в природе.

И если всё удалось: люди в компании понимают и разделяют ценности и принципы Agile и работают согласно им, — тогда менеджменту не придётся «тащить» на себе любые изменения или «пинать» работников, чтобы они начали что-то делать по-другому. Предприятие станет единым организмом, управление которым будет отнимать меньше сил и приносить больше удовольствия.
А там, где больше удовольствия от работы, и результат выше. Это касается не только специалистов, но и менеджмента, причём в ещё большей степени.

На этом наше обзорное знакомство с принципами Agile заканчивается. Какие цели ставятся перед Agile в России и каких реальных результатов достигают компании, переходящие на гибкие методологии, можно узнать, познакомившись с отчётом исследования ScrumTrek об использовании Agile в России от 2017 года.

scrumtrek.ru

Что такое agile, scrum, kanban и в чем разница?

Если раньше офисы модно было обустраивать «по фэн-шую», то теперь — исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?

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

Рубрика «Инновации в корпорациях» выходит при поддержке Spinon.

---

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

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

К отдельным agile-подходам относятся scrum и kanban.

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

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

Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

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

Примеры употребления

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.

(Из статьи на VC.ru)

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

(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)

Главная идея Kanban – визуализация рабочего процесса. Она заключается в создании физической панели, на которой можно наглядно отмечать прогресс.

(Из перевода колонки Forbes на Rusbase)

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

(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)

Слово экспертам

, :

Владимир Овелян

Владелец и генеральный директор Dostаевский

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban.

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

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

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

Виталий Сотников

Креативный директор Бюро визуальных коммуникаций «Черника»

Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности.

Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота.

Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow.

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

Илья Шихалеев

Ведущий разработчик и скрам-мастер iSpring

Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом.

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

Евгений Россинский

Директор по технологии в онлайн-кинотеатре ivi

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.

Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.

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

Ирина Черепанова

Директор по продукту uKit Group

Scrum мы внедрили с двух попыток, потому что всем, от команды до пользователей, хочется иметь более прогнозируемый результат. В этом плюс методологии – четкие ритмы упорядочивают коллектив, повышают общий уровень знаний о проекте. Как следствие, результат становится более прогнозируемым, в том числе для наших «стейкхолдеров» – пользователей.

Командная работа также повышает ответственность: все получают бонус, только если команда выполнила поставленные на определенном этапе задачи.

Инга Корягина

Доцент кафедры теории менеджмента и бизнес-технологий РЭУ им. Г.В. Плеханова

Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.

Что почитать по теме?

1. Agile-манифест разработки программного обеспечения (Manifesto for Agile Software Development)
2. Дж. Сазерленд «Scrum. Революционный метод управления проектами»
3. Д. Андерсон «Канбан. Альтернативный путь в Agile»
4. Э. Стелманн, Дж. Грин «Постигая Agile. Ценности, принципы, методологии»
5. K. Schwaber, J. Sutherland “The Scrum Guide”
6. M. Cohn “Agile estimating and planning”

Текст: Александр Петров.

Видео по теме:

Cover photo by Daria Nepriakhina on Unsplash

rb.ru

что это и зачем нужно

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

Что такое Аджайл

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

Буддисты верят, что могут достичь просветления. Они медитируют, стараются быть умеренными и не причиняют вреда другим.

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

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

Как появился Аджайл

Раньше продукты делали сразу целиком. Для этого они шли по цепочке: «идея → техзадание → дизайн → программирование → тестирование → релиз». Если на этапе дизайна появлялась новая идея, приходилось игнорировать ее или переделывать все предыдущие этапы. Это было неудобно — проект или получался хуже, чем мог бы, или растягивался во времени и не укладывался в бюджет.

Прогрессивные разработчики стали пробовать новые подходы к работе. Так появились экстремальное программирование, Скрам и ещё с десяток новых техник. Команды могли тестировать и изменять продукт в процессе работы, за это такие подходы назвали «гибкими». Эксперименты оказались удачными: клиенты получали отличные продукты, разработчики выдерживали сроки и бюджеты, а размеры компании не влияли на продуктивность команды.

Чтобы найти формулу успешных продуктов, в 2001 году семнадцать практиков современных подходов собрались в маленькой горной деревушке Сноубёрд. Они обсудили свои стратегии разработки и сделали открытие: подходы у всех разные, но общие идеи совпадают. Эти идеи легли в основу «гибкой» философии, которую назвали Аджайлом. Их записали в итоговых документах: «Манифесте» и «Принципах Аджайла».

В чем суть философии Аджайла

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

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

Традиционная пекарня Новыми рецептами занимаются шеф и технолог. Мнение кондитеров и продавцов учитываться не будет: первым дадут готовые инструкции для работы, вторым — готовую продукцию. Шеф и технолог будут отчитываться перед директором пекарни. А он — хвалить или ругать за неудачный проект.

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

Аджайл — это быть командой профессионалов, которым не нужен начальник

Процесс работы тоже отличается: строгое распределение функций в традиционной пекарне и совместные эксперименты аджайл-команды:

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

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

Аджайл — это работа вместе с клиентом, эксперименты и готовность изменить план

Результаты пекарен будут кардинально различаться: непредсказуемые у одних и гарантированно хорошие у других:

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

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

Аджайл — это быстрый выпуск работающего продукта, который нравится клиентам и заказчикам

Чтобы выстроить работу в духе аджайла пекарня из нашего примера использовала в работе постулаты «Манифеста»:

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

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

Что дает Аджайл

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

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

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

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

Комфортный режим работы и объем нагрузки. Один из принципов Аджайла: команда должна быть в состоянии работать бесконечно долго. Аджайл запрещает авралы и пропагандирует комфортный ритм, в котором интересно работать и справляться с новыми профессиональными вызовами.

Аджайл помогает быть счастливее: видеть в работе дело жизни и получать от нее удовольствие.

При чем здесь Скрам и Канбан

Мы выяснили, что Аджайл — это набор философских ценностей. Они звучат заманчиво, но использовать их в жизни сложно. Не каждая команда может завтра начать работать без начальника. Непонятно, как делать проект без подробного ТЗ. Не всякий клиент согласится ездить в офис разработчиков каждый день или созваниваться по нескольку раз в день. И с чего начать быть аджайл не понятно.

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

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

Можно быть аджайл без фреймворков. Так работают почти все стартапы и некоторые подразделения в крупных компаниях. Если вас в отделе всего двое, вряд ли вы сосредоточены на соблюдении регламентов или четко распределяете функции между собой. Скорее вы напару непрерывно разгребаете огромную кучу входящих заданий. Каждый берет кусок работы, который больше нравится, делает его, оглядывается на напарника. Если надо — помогает или принимает помощь.

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

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

Лучший вариант — соединить философию с практикой и получить предсказуемо хороший результат.

Шпаргалка

Запомнить Аджайл — это образ мышления со своей системой ценностей. Фреймворк — это набор правил, шаблоны действий для переноса философии Аджайла в жизнь. Вместе они дают результат.

Говорить правильно быть аджайл работать в духе Аджайла работать по Аджайлу аджайл образ мышления

agilebasics.ru

hr-portal.ru

Классификация ЛКМ по сухому остатку и VOC: LS, MS, HS, UHS/VHS

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

Именно экологические проблемы на протяжении многих лет заставляют законодателей большинства развитых стран, в первую очередь Западной Европы, предъявлять к производителям ЛКМ и кузовным мастерским новые, все более жесткие требования к экологической чистоте материалов. Прежде всего, эти требования направлены на сокращение выбросов в атмосферу вышеупомянутых растворителей или, как их называют по научному, — летучих органических соединений (volatile organic compounds, VOC).

C природой шутки плохи

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

Чем опасны органические растворители? Помимо того, что они повышают пожаро- и взрывоопасность во время хранения и использования ЛКМ и негативно влияют на здоровье работников, они несут в себе еще более глобальную угрозу.

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

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

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

Однако в нашем Отечестве отношение к экологии пока не такое трепетное. Причем российское «невмешательство» в мировую политику вылилось в то, что даже стандарты в этой сфере у нас диаметрально противоположны западным. В Европе, в первую очередь, считают то что испаряется, обозначая этот параметр аббревиатурой VOC, который измеряется в граммах на литр. У нас же крайне важное значение имеет содержание материала, наоборот, оставшегося на поверхности после испарения всех растворителей — так называемое содержание сухого остатка.

Получается как всегда — они считают то, что улетело, а мы то, что осталось. Наверное, здесь дает о себе знать наш неистребимый оптимизм — прямо как в том популярном выражении о «наполовину пустом или наполовину полном стакане».

LS, MS, HS, UHS/VHS/HD

Эти волшебные аббревиатуры как раз и говорят нам о содержании сухого остатка в готовой к применению смеси того или иного лакокрасочного материала — эмали, грунта, лака:

• LS (Low Solid) — низкое содержание сухого остатка;
• MS (Medium Solid) — среднее содержание сухого остатка;
• HS (High Solid) — высокое содержание сухого остатка;
• UHS/VHS/HD (Ultra High Solid/Very High Solid/High Density) — «сверхвысокое» содержание сухого остатка.

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

К материалам различного содержания сухого остатка в лакокрасочной терминологии часто используются такие термины как «низконаполненный» (это относится к LS-материалам), «средненаполненный» (MS), «высоконаполненный» (HS).

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

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

Теперь спроецируем эту картинку на ЛКМ, где сахар — это пленкообразователи (смолы), а вода — растворители. Растворимость смолы зависит как от ее молекулярной массы и химического состава, так и от применяемых растворителей. Под растворителями здесь имеется в виду не то, что мы наливаем (эти жидкости правильнее называть разбавителями), а те жидкости, которые вводят в ЛКМ на заводе при изготовлении.

Так вот, в случае с ЛКМ пространства для маневров гораздо больше. Благодаря совершенствованию полимеров и разработке новых, все более эффективных растворителей, химикам удалось существенно повысить концентрацию «сахарного сиропа»: от низконаполненного (LS), до средне- (MS), а затем высоконаполненного (HS) и сверхвысоконаполненного (UHS/VHS).

LS и MS

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

Если же мы обратимся к цифрам, то увидим, что летучесть LS-материалов составляет порядка 820-840 г/л (тот самый VOC). Если смотреть по сухому остатку, он у этих материалов крайне низок — порядка 30-40%. Из-за этого наносить LS-материалы нужно было не меньше, чем в три слоя, иначе добиться рабочего слоя краски в 50-60 мкм, особенно на вертикальной поверхности не представлялось возможным.

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

Как по экологическим, так и по экономическим соображениям, материалы класса LS устраивали мало. Учитывая, сколько при нанесении LS-материала уходило в опыл (помните, коэффициент переноса пистолета раньше был очень низким), а сколько просто испарялось, получается, что из литра краски у нас не остается практически ничего!

Все это привело к тому, что химики, подстегиваемые все более жесткими экологическими нормативами, стали искать способ сделать лакокрасочные материалы менее летучими. Так на свет появились материалы MS.

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

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

А вот содержание VOC в MS-материалах значительно упало — в среднем до 600 г/л. Если смотреть по «нашей» методике, то величина сухого остатка на поверхности у этих материалов в зависимости от амбиций производителя стала составлять от 40 до 55%.

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

HS и UHS/VHS

Однако и 600 г/л не стали пределом. В конце 2000 года законодательные органы Европейского Союза опубликовали постановление о планируемом в 2007 году ужесточении требований к производству, продаже и применению лакокрасочных материалов по критерию содержания в их составе летучих органических растворителей. Ограничения должны были коснуться всего перечня ЛКМ: от обезжиривателей и шпатлевок до прозрачных лаков и аэрозолей.

Предел, ограничивающий содержание органических растворителей в литре приготовленной базовой краски, 2K эмали или лака теперь предполагалось снизить до 420 г/л.

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

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

Но если в случае с LS и MS материалами для получения пространственно сшитых пленок в реакциях сшивания достаточно участия сравнительно небольшого числа функциональных групп, то в материалах с высоким сухим остатком должно прореагировать намного большее их количество.

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

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

Высоконаполненные материалы стали более вязкими, что привнесло некоторые изменения в процесс работы с ними. HS-материалы уже за полтора слоя дают возможность достигать толщины покрытия в 50-60 микрон. Содержание сухого остатка в этих материалах удалось повысить до 55-65%.

Но безгранично уменьшать количество растворителя в краске невозможно — вязкость станет слишком большой. Если бы мы захотели получить получить 100% сухого остатка в банке, в конечном итоге получили бы порошковую краску.

Максимальный предел лежит где-то в районе 82-85%, и этого удалось достичь у современных «сверхнаполненных» UHS/VHS-материалов, многие из которых допускается наносить и вовсе в один слой! (или в полтора, но первый — очень легкий).

Выше наполнить материал уже просто невозможно по определению.

Слово свое «зеленые» сдержали и с октября 2007 года в Европе любое малярное предприятие обязано удовлетворять новым экологическим требованиям.

Если кому интересно, для полного перечня компонентов ремонтной системы максимально допустимые величины VOC в соответствии с современным законодательством выглядят следующим образом:

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

Поэтому, чтобы добиться снижения VOC в базовых эмалях, пришлось переделывать их «под воду». Таким образом при низком сухом остатке, за счет замены органических растворителей водой удалось добиться экологичности базовых эмалей. Вода, разумеется, не из-под крана, а специально обработанная. 🙂

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

Разработчики ЛКМ даже стали выделять сольвентные продукты, отвечающие этим требованиям, в отдельные группы материалов и давать им особую маркировку. Чаще всего эти материалы можно распознать по наличию в их названии аббревиатуры VOC или словосочетания Low VOC (LV). Если речь о лаках, то такие лаки часто называют просто VOC-лаками.

Подобная маркировка позволяет специалистам ремонтных предприятий при выборе материала не заниматься подсчетом VOC. Если это продукты заслуживающих доверия производителей, то все расчеты уже произведены, и, что самое главное, утверждена их легитимность в органах, контролирующих экологическую обстановку. Ведь часто поставщики пишут на банках: HS, VHS, а проверишь — у большинства в лучшем случае MS, а то и LS. Получается, обманывают и себя, и потребителя, и природу.

Однако дело здесь не только в экологии.

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

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

Кроме того, при равной толщине пленки материалом с большим сухим остатком можно укрыть большую поверхность. Так, одним литром лака HS можно покрыть площадь примерно на треть большую, чем лаком серии MS.

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

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

artmalyar.ru