8-битный Scrum (Алексей Омельянчук на AgileDays-2009) — различия между версиями

Версия 16:56, 17 апреля 2011

8-битный Scrum

Докладчик

Алексей Омельянчук (Сигма-ИС)

• http://agiledays.ru/reports/themes/view/7/

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

Представьте, что разработка включает в себя не только написание ПО, но и создание аппаратной платформы, на которой оно будет исполнятся. Более того, процессоры преимущественно используются 8-разрядные, а языки разработки — ассемблер и «чистый» С. Как использовать в этом случае Scrum?

Автор доклада обобщит свой опыт внедрения Agile в трех различных компаниях:

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

Обычно, при словах SCRUM всплывает некоторый стереотип — программисты пишут заказной софт (информационная система, скорее всего с вебинтерфейсом) на основе мощных библиотек и фреймворков, легко удовлетворяя метания бизнес-пользователей за счет заложенной гибкости архитектуры, наслаждаются кроссфункциональностью (в смысле смеются, когда дизайном занимается хардкодер, но в целом все ОК), с энтузиазмом играют во все developers games (ибо в РФ, программист — пока профессия молодых).

А что если нет не то, что лишних пары гигабайт для вечноголодной Жавы, а вообще, есть только 512байт ПЗУ и 32 байт ОЗУ? А если рабочий стол программиста занят не тремя 24" мониторами, а тестерами (в смысле приборами, а не девушками), осциллографами и паяльником? Если специалисты настолько матерые и узкие, что о кроссфункциональности не может быть и речи, а из-за их возраста «standup meetings» приходится отказать?

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

Например, частые демонстрации. Интересно, судя по вопросам, в зале были специалисты из микроэлектронной индустрии, и на их жалобы вида «Как делать регулярное демо (нового прибора), если поставщик только через квартал сможет дать нужную деталь (индикатор)» — докладчик парировал — «Стыдитесь! Для демонстраций и тестирования используйте mock-объекты подключите обычный компьютер с симулятором».

Из отзывов наших сотрудников:

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

Команда его прошла путь от производственного предприятия работающего на МО с жестким Rational Unified Process, через крупного частного производителя контроллеров (крупнейший поставщик АвтоВаза, 2 млн штук в год) до software-предприятия, занимающегося, в основном, программированием, а не железом. На каждом этапе добавлялись новый практики.

Что используются

Еще одна особенность — сборные команды. Каждый проект ведется максимум двумя людьми (большему количеству просто нечего делать на устройстве, куда влезает 500 строк ассемблера), команды объединяют несколько проектов. Ни о какой кросс-функциональности речь не идет (одна настройка рабочего места занимает день-два), но таким образом все-таки немного смягчаются риски того, что в случае болезни одного человека, его будет не кем заменить. Scrum-митинги из-за этой специфики проходят на по 15 минут раз в день, а большее время раз в неделю, чтобы было время въехать в чужую предметную область.