Перенос принципов командной роботы Agile из ИТ в работу класса.

«Agile» (эджайл) — в перводе с английского расторопный, сообразительный.

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

История появления

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

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

Что должно измениться после внедрения Agile?

Прежде всего должны быть пересмотрены точки ответственности и принципы постановки задач на выполнение. А значит как следствие характер отношений участников команды. Ценности по Agile это:

1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.

Смена приоритетов – это изменение внутренней культуры предприятия. А любая перестройка требует времени, разъяснений, поддержания ценностей примерами. Разъяснения были даны в 12-ти основополагающих принципах Agile. С ними можно познакомиться на странице http://agilemanifesto.org/ .

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

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

Увеличение эффективности между разработчиком и заказчиком:

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

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

Перенос гибких подходов и принципов Agile

За которое время методологию Agile стали пробывать применять не только в программировании, но и в управлении, образовании и экономике. Посмотрите два видео семинара по тематике переноса Agile-технологии в образование.

А также «Scrum – новое слово в организации командной работы класса». Планирование учебного процесса. Подготовительная работа к внедрению Scrum. Организация образовательной среды.

Для групповой работы в начальной и средней школы мы можем рекомендовать набор “Строим лучший мост” от PASCO SCIENTIFIC.  Разбившись на роли архитектор , строители, стройнадзор можно познакомиться с основами инженерного дела и сопротивления материалов.

Для обучения проектной работы в старших классах средней школы и гимназических классах мы рекомендуем попробовать роботизированную руку uArm Swift Pro. Помимо задач перемещения предметов, она также может быть использована для рисования на песке, печати трехмерных объектов и лазерной гравировки. А это значит, что можно придумать задачи по созданию наградных памятных знаков, удаленной игры в шашки, мультфильма на стекле с песком. И соответственно под каждую задачу будут свои роли. Для мультфильма сценарист, программист, осветитель, оператор, звукорежиссёр, верстальщик, критик. Для памятных знаков, дизайнер, программист, тестер, инженер по креплению, и.т.д. Главное не забыть включить в команду представителя заказчика.

Для высших технических заведений можно сделать проект разработки электронного устройства на базе NI ELVIS Engineering Lab Workstation.

По вопросам приобретения обращайтесь по электронной почте ask@ste(.)education. (Не забудьте удалить круглые скобки () из адреса электронной почты перед отправкой.)