Персональные инструменты
 

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

Материал из CustisWiki

Перейти к: навигация, поиск

8-битный Scrum

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

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

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

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

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

Для всех 3-х предприятий характерна выраженная специализация разработчиков, необходимость синхронизации разработки аппаратной и программной части и «размазанный» по нескольким командам Product Owner.

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


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

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

Not Invented Here-2009-05-04.jpg
Not Invented Here-2009-05-05.jpg

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

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

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


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

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

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

  • спринты, ограниченные во времени
  • демо (по признанию докладчика практика оказалась самой полезной)
  • планирование. Причем, планируют 120—140 % от запаса времени, с разделением на обязательное и бонусы

Длительность спринта составляет 1 месяц, что было связано со сложившимся на предприятии укладом. Также был «мегаспринт» — 3 месяцы. Эта цифра обусловлена

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

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



Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».