![История одного коллектива в 3 компаниях ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Similaire à 8bit Scrum
Similaire à 8bit Scrum (20)
Plus de Nikita Filippov
Plus de Nikita Filippov (20)
8bit Scrum
- 1. 8- bit SCRUM (Embedded Agile) Гибкие методологии при разработке электроники Омельянчук Алексей , C игма-ИС
- 18. Главный радиатор
- 22. Тестирование
- 24. задача на двоих задача для любого
Notes de l'éditeur
- Опыт применения гибких методологий. В основном то же что и для обычной разработки ПО, более того, особенности встроенного ПО позволяют глубже копнуть в основные идеи Agile. Есть конечно разница чисто технологическая, например для автоматизации тестирования приходится делать физически автоматизированные стенды, симулирующие внешний мир.
- крупный интегратор. ЗАО Компания Безопасность немного производства «под проект», программный продукт управления в реальном времени. Минобороны, Минатом, ФСО ~100 чел департаменты разработки Primavera , ЕСКД, ЕСПД, сертификация ФАПСИ, военприемка RUP ( ClearQuest, ClearCase) MSF ( Review, кроссфункциональные группы) – это в департаменте программного обеспечения, 70 человек. Новое подразделение – разработка нового поколения аппаратного – 7 чел – RUP понятно невозможен.
- Охранные и пожарные датчики Внутри такого изделия плата с одним микроконтроллером и несколькими транзисторами обвязки. Себестоимость в пределах 1-2 бакса. Причем гарвардской архитектуры (раздельно область программы и область данных) Понятно, что это вам не под С # программировать – тут искусство, уместиться в 512 команд.
- Пульт управления (Прибор приемно-контрольный) В целом на уровне персонального компьютера образца 1985 года Можно писать на С или даже С++ Операционная система «кооперативная»
- Среди разработчиков электроники применять элементы Agile было легче. Там не было возможности выполнять жесткие процедуры и все уцепились за хоть какие-то способы контролировать разработку. Книжки Книберга тогда не было, частично взяли от Швабера, частично от МкКоннелла. От Швабера (скрам) – фиксированный спринт. Сочли ежедневный стэндап слишком несерьезной деятельностью. Бэклог формировался по мере разбиения одной юзер-эпик «сделать систему вдвое дешевле существующих и превосходящую всех конкурентов по функционалу. Планирование «Сколько влезет» – вместо измерения велосити Шарепойнт использовался в роли «вики» для общения и фиксации требований, архитектуры, решений. CVS как хранилище кода.
- Ведущий показывает список упорядоченный по приоритетности – столько влезет в спринт ? А еще 2 задачи добавить – есть шанс ? Оценки на глаз, но по моему опыту, куда точнее, чем оценивать каждую задачу а потом суммировать. Одновременно мелькают фразы кто что будет делать чтобы уточнить. Типа «я не успею задачи 2,6 и 11», на что вася отвечает, что «задачу 11 может сделать он, а ты лучше сделай 12» Оунер говорит что очень хочет чтобы этот таск вошел в данный спринт. Тогда посмотрим, какой таск (этот и/или другие) можно разбить и сделать только важное а остальное отложить. Такая методика хорошо работает если эстимэйшен плохо получаются. Если проблема психологическая – надо брать карты. Но карты – это заведомо долго. Когда спринт 2 недели терять целый день на планирование жалко.
- Есть много исследований, в основном по поводу project-management, аксакалы agile их часто цитируют. Если известна дата окончания работы, к ней и подгадывают. Бывает опаздывают но почти никогда не бывает раньше времени. Естественное решение – сознательно завысить объем работ, всех предупредить, что запланировано «на всякий случай если вдруг пойдет очень быстро» с превышением на 20-30%. Возникает проблема, что из кучки задач будут выполнены не самые важные а самые удобные или интересные. Выделяется группа задач на ~ 70% velocity ( заведомо будут сделаны) и помечаются как «важные», а остальные (еще на 50-60% velocity) помечаются как «опциональные». Это важно также для отчетности перед руководством, ибо иначе всегда план недовыполнен.
- Неважно – планирование «сколько влезет» или по велосити – важно чтобы 2 группы задач.
- Именно ранние показы рано показали что ведущийся проект ориентирован на другой сегмент рынка – на массовое производство. По обоюдному согласию коллектив этого проекта перешел в другую компанию. Кстати, некоторые другие проекты, на мой взгляд, столь же бесполезные для той компании и бесперспективные в ней - идут до сих пор. За горой бумаг никто не видит цели, непосредственно программисты удовлетворяют свое любопытство и делают интересные работы, некоторые параллельно защищают диссертации или дипломы. Обсуждения крайне важны. Настолько важны, что я долго предпочитал их стэндапу, и до сих пор. Почему противопоставляю – позже.
- 60% контроллеров инжектора для ВАЗа (разработка ВАЗа) Пожарные датчики (2-3 млн в год), охранные датчики, счетчики электричества и воды. Тиражи миллионные. Экономия 1 цента всерьез обсуждается. Разработка собственная слабая, а вот производство ставили корейцы, производство стремится стать поставщиком Рено/Форд и т.д. Ритм от производства, месячно/квартальные планы MS - Project для проектов постановки на производство очень разнородный коллектив автомобильная СМК ( ICO/TS 14949) много мелких проектов по 1-2 человека
- Группы искусственно объединены из нескольких похожих проектов. Не киснут в одиночку и взаимозаменяемость сильно радует руководство. Зависимость от одного разработчика – кошмар, ставить двоих туда где и одного много – нерентабельно. Ежедневные стэндап проводить трудно когда люди не живут в проекте соседа. Каждый раз нужны вводные слова чтобы поняли о чем речь. Традиционно даже в одном проекте занимались узко разными компонентами – специализация по технологиям (отладочные средства и нагрузочные стенды). Например для электросчетчиков нагрузочный симулятор вмонтирован в тумбочку стола – рабочее место фиксировано. Поэтому вместо ежедневного во всем отделении были введены 2 раза в неделю обсуждения состояния в группах. Кроме того, влияние ISO 14949 = FMEA = обсуждения часто действительно носили оттенок FMEA перед постановкой на серию. Спринты длительностью 1 месяц благо вся компания живет ритмом месячных и квартальных планов. Квартальный ритм также удобен ибо время обновления железа не укладывается в месяц. Теоретически можно, но попытки всегда срываются – 2 недели на изготовление, 1 неделя разводка, и всего 1 неделя думать – постоянно изменения вносятся. Невозможно если время на «билд» втрое превышает время на программирование. Поэтому параллельно 3-месячное планирование итераций железа, иногда успевается 2 раза за квартал, обычно если ошиблись в первом, и исправили. Кроме того, демо с присутствием гендиректора компании и гендиректора основного заказчика – только раз в квартал. Это веха, к ней готовятся, за нее получают премии. Инструменты SVN+TRAK (особенно wiki в нем) Доска со списком задач на спринт Доска-радиатор небольшая – листок-список задач на месяц, задачи-вехи на квартал, несколько листков с текущими основными идеями архитектуры. И не во всех группах (во многих негде). ТРАК как существенный радиатор.
- Эта особенность связана именно с производством электроники. Софт развернуть на компьютере можно за пару часов (ну дней). А изготовить железо (плату) - скомплектовать и спаять – в лучшем случае 2 недели. С учетом времени на ее разработку – за месяц не успеть. На каждый случай когда удалось уложиться в 2 недели приходится 3 случая когда не удалось даже в месяц Появляется 3 уровня планирования
- Таски из бэклога иногда откладываются до релиза новой версии платы, даже если они не осень связаны с переделкой железа – просто потому, что они уместны будут только когда будет еще и то и то сделано Ритм производства (6 заводов по стране) Месяц / Квартал. Длина спринта – любая. Если все предприятие живет в ритме месяц/квартал, зачем придумывать иное ? Реально железо иногда делали два раза за квартал, но обязательно хотя бы одно поколение железа новое к отчету за квартал. В следующей компании ритм был по два-три спринта (по месяцу каждый), причем разный для разных изделий, обычно на планнинге вопрос «будем в этом спринте делать новую плату или пока на старой можно работать?» Кроме того, помпезные «демо», на которые удается затащить реальных представителей заказчика, вплоть до гендиректора заказчика (и конечно пару своих директоров) – не чаще раз в квартал. Очень полезные демо – на них только успевай записывать – когда в одном месте несколько умных и заинтересованных в результате людей – не надо было даже направлять разговор. Релиз «наружу» - готовится за пару месяцев - это уже планируется в МС-проджекте, работа технологов, готовится оснастка, прогоняются пробные партии (неважно что прошивка еще сырая), заказ комплектации – на этом этапе задействованы десятки людей.
- Также специфика, но это специфика разработки очень маленьких очень микропроцессорных устройств. Один, ну полтора человека – схемотехник-программист и немного конструктор-механик. Второму там просто нечего делать. Возникает взаимопомощь и – радостный выдох директора – исчезает зависимость от одного разработчика. Кошмар – особенно на этапе уже постановки на производство - закуплено на мегабакс комплектации, перепланирован сборочный участок, а разработчик заболел и неделю-две все стоит.
- Если отдельные устройства просты и ими занимается 1-2 человека, приходится искусственно объединять несколько изделий в одну команду, чтобы люди не закисали в одиночку и чтобы была взаимопомощь и взаимозаменяемость на крайний случай. Люди с интересом готовы обсуждать проблемы соседа, но не в формате 5-минутного стэндап. Просто не успевают понять если не погружены в этот проект. Поэтому рез в неделю по часу с подробным обсуждением схемных и программных решений.
- После ноября 2008 ИТЭЛМА ушла с рынка ОПС. костяк проекта новой ОПС перешел в третью компанию. Среднемасштабное производство (один Топаз) Специализируется именно на разработке и производстве охранно-пожарной техники Наконец проект вышел на серийное производство, пусть пока и не миллион штук в год.
- Наконец мы дошли почти до идеального скрама. Поддержка аджайл на всех уровнях – легко оплачены спец доски и колоды карт. Ежедневный стэндап наконец стал возможен – команда относительно компактная и тесно связанная. Действительно помогает координироваться. Ежедневные встречи хороши если большинство в команде понимают ежедневные заботы каждого. Иначе надо готовиться и описывать подробно, это уже не 15 минут. На стэндап или сразу после, в режиме стэндап, можно обсуждать короткие проблемы, спецмитинги организовывать часто лениво да и заведомо больше потери. Но если команда небольшая всем все понятно и хоть чуть интересно. Кстати, картами почти не пользуемся – пару раз в начале и один раз когда новый человек влился в коллектив – только для психологического раскрепощения. Фото – доска-радиатор Планирование обычно по velocity, но колоду карт применяли пару раз в начале (психологически облегчает в неоднородном коллективе), потом без нее легко договариваемся. Иногда планирование в стиле скрумбан – явно по каждому из людей, особенно если 2 из 6 в отпуске или явно работы нацелены на конкретных людей. Отдельная пачка тасков «сверхплановых» - так и висит в уголке «на после обязательных».
- Пресловутая доска – прям как на обложке у книберга. Аккуратно сделана рекламным отделом. Бумажки с тасками распечатываются из экселя но в процессе планирования появляется множество рукописных и потом в течение спринта тоже новые появляются, чаще на стикерах (но с магнитиками) или на просто бумажках. Таски для ограниченных ресурсов целевые – прямо помечены ресурсы Две группы задач в плане на спринт В разделе «в планах» внизу висят пачкой «опциональные» таски. Кроме того, ежедневное присутствие Project Owner’ а позволяет решать какая задача следующая. Магнитиками прижаты График берндаун иногда рисуем (почти всегда, если оценки для тасков были сделаны а не по методу «сколько влезет») но порой вместо него там или еще где на доске используется просто для обсуждений Справа внизу по классике место для внеурочных и отложенных тасков, но там обычно скапливается всякое прочее – например последняя картинка от дизайнера, распечатки каких-то осциллограмм, таблица целевых параметров. По мере потери интереса они отваливаются. Спринт обычно месяц но иногда добавляем короткий – 2 недели - если почему-то сорвали совсем (типа два чела болели) или если до релиза надо сделать какие-то мелочи.
- Они во-первых любят свимлэйн для каждой задачи, специально распечатывают тикеты узкие горизонтальные Они обязательно рисуют бёрндаун (более однородная команда – С #) Аналогично всякая всячина в углу для «незапланированных» и «следующих»
- Нойман-гарвард архитектура, Оптика-звук В итэлме в проектной группе были в т.ч. Механики конструкторы по пластику.
- Помимо специализации самих разработчиков, рабочие места довольно специализированы. На них отладочные средства под конкретный процессор, на компьютере соответственные кросскомпиляторы.
- Если прибор должен работать с 256 датчиками, значит надо в том числе попробовать с реальными 256 датчиками. Конечно, симуляторы помогают в процессе разработки, но реальное железо почему-то всегда ведет себя не так как симуляторы. В ИТЭЛМЕ было еще хуже – нагрузки для тестирования электросчетчиков – ТЭНы на 10 кВт смонтированы за окном – ресурс абсолютно непереносимый.
- При оценке задач часто подразумевается кот именно ее будет делать. При планировании надо контролировать – если много задач на одного человека, то надо либо переоценить – другой убьет больше времени либо перепланировать. Можн оначинать насыпать тупо по приоритету на сумму = велосити, но если видно что етсь перекос – надо учесть фактическую ожидаемую загрузку по людям.
- На двоих – для этой фичи придется и элеткронику перепаять и программу подрихтовать, причем в двух устройствах.
- Демо обеспечивает прозрачность цели. Если вы хотите как в СССР заниматься за счет работодателя удовлетворением собственного любопытства – ни в коем случае не применяйте Agile. Фиксированная длина спринта – больше плюсов – но надо компенсировать Работа всегда занимает все запланированное время. Можно не успеть но никогда не раньше срока. = надо всегда закладывать больше чем успеем (запас работ). Работы разного приоритета, люди предпочитают те что интереснее. Либо должен ежедневно присутствовать оунер, либо заранее разделить по приоритетам (не стоит последовательно – возможность выбора очередности важна для маневра) на 2 уровня – обязательные и дополнительные. Кстати, скрам – игра. Когда надоест возможно на некоторое время перейдем к более явному канбан, без спринтов но с непрерывным потоком задач.
- Выводы, специфические для широкопрофильной команды с разнородным технологическим циклом – помимо собственно электроники еще и дизайнеры по пластику, технологи, опытное производство. Итерации железа намного медленнее. Ежедневный билд ПО – реальность, время на новый релиз железа – минимум неделя, реально месяц и при этом задачи решаемые в софте отстают от задач решаемых в железе. Окончательно задача будет выполнена в следующем спринте после поддержки в ПО. Задачи, требующие модификации железа, накапливаются и группируются как для микро-релиза. Вообще для железа управление релизами (внешними) куда важнее чем для чистого ПО – перевод производства на новую версию это не просто вопрос замены мастер-диска, это снабжение, программы на станках ЧПУ, оснастка, изменение технологии и обучение рабочих. В разнородной сильно специализированной команде плюс еще при наличии серьезных работ выполняемых вне команды (снабжение, опытное производство) часто необходимо планировать явно под каждого члена команды. Это удобно делать по технологии «сколько влезет».