Ретроспектива

Энергия старого мира

04.09.2020 20:08:16 |

Автор: admin

Введение

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

Теперь нужно решить энергетический вопрос. И тут начинаются основные отличия от двигателей внутреннего сгорания (ДВС). В таких двигателях бензин, смешиваясь с воздухом, попадает в цилиндр двигателя и при воспламенении этой воздушно-топливной смеси выделяется энергия. Расширившиеся продукты горения давят на поршень, производя работу. Но вот у паровых машин, энергия рождается не в двигателе. Она рождается в котле. Котёл производит пар, который в свою очередь и будет давить на поршень нашего двигателя. Эту древнюю энергию нам и требуется обуздать!

Устройство

Паровой котёл котёл, предназначенный для генерации насыщенного или перегретого пара. Может использовать энергию топлива, сжигаемого в своей топке, электрическую энергию или утилизировать теплоту, выделяющуюся в других установках. (Википедия)

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

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

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

Для лёгкого понимания работу такого котла можно представить в упрощённой форме:

Создание прямоточного котла

И, конечно, мне захотелось сделать именно прямоточный котёл.
Подобрав длинные нержавеющие трубки разного сечения, я сварил их вместе таким образом, чтобы сечение постепенно увеличивалось. Затем, весь этот 8 метровый кишечник был компактно свёрнут и уложен в раму мотоцикла. Внешние стенки, которые должны удерживать пламя и направлять его в нужную сторону, были сделаны из простой жести. Насос, закачивающий воду (носитель), изготовил из газового доводчика, который обычно придерживает капоты и багажники автомобилей. Конструктивно, доводчик это готовое изделие. Мне необходимо было только приварить вход и выход для воды и приделать клапан, который не пускал бы закаченную воду обратно. Насос подвижно крепился одной своей частью к раме, а второй к кривошипу на валу колеса. С помощью гибкого шланга высокого давления (тормозной шланг от авто) вода под давлением закачивалась в котёл, а забиралась из отдельного бачка, располагавшегося выше насоса. Горелку сделал по типу кровельных, такими рабочие греют рубероид на крышах зданий. Чтобы процент обтекания трубок был больше, горелки поставил сразу две.

Итог

Испытания парового мотоцикла, оснащённого прямоточным котлом, с самого начала пошли не так. Самой первой проблемой стало отсутствие начального давления в котле. Приходилось руками покручивать колесо, чтобы насос отправлял некое количество воды в трубопровод. Но, когда я открывал ручку газа (подавая пар на двигатель) давление пара мгновенно падало, не успевая закрутить колесо. Выход нашёлся не сразу. Был сделан небольшой воздушный ресивер после насоса. Он работал как пружина для воды. Запасал энергию сжатия от насоса и отдавал её обратно, когда насос был в мёртвой точке или в фазе всасывания питательной воды.
Двигатель заработал! Но проработал, около 10 секунд. Золотниковый клапан заклинил. При разборе двигателя, никаких проблем выявлено не было. Собрав его обратно и запустив снова, я столкнулся с той же проблемой. Она оказалась приходящей и уходящей сама собой. После изучения этой проблемы, нашлась ошибка в расчётах теплового расширения. Изначально, золотник представлял собой цельную деталь из фторопласта, а у него, как оказалось, очень большой коэффициент теплового расширения (22) и он при прогреве расширялся настолько, что его насмерть заклинивало в корпусе.
После подробных и тщательных расчётов тепловых расширений был выточен стальной золотник, оснащённый фторопластовыми кольцами, шириной 2 миллиметра.

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

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

я понял, что у меня слишком маленький котёл (длина обогреваемой трубки), в следствие этого при увеличении производительности, вода просто не успевала испаряться и вылетала вместе с паром в двигатель. От такого эффекта пропадает КПД всей установки, так как расширение воды слишком мало или не происходит вовсе. Увеличить длину котловой трубки уже задача не такая простая. Но и на этом моё горе не закончилось.
Во время очередных испытаний, я мучил аппарат, заставляя его работать, но состояние двигателя начало резко ухудшаться и в какой-то момент он заклинил. На этот раз, просто остудить его снегом, не помогло. Снова понадобилась капитальная переборка. Результаты вскрытия показали, что расплавились все фторопластовые кольца и даже алюминиевый поршень от нагрева расширился настолько, что начал задирать цилиндр. И это оказалось фатальной проблемой. Дело в том, что при большом расходе, данный котёл не успевал производить должное количество пара, а при маленьком расходе, он создал пар такой энергии, что просто вышел из строя весь двигатель. И не удивительно. Ведь выходные трубки котла были раскалены докрасна. То есть пар, достигал температур, порядка 600-700 *С. Как мы знаем, фторопласт распадается при 400*С. Для меня, это и стало последней каплей! Мне уже хотелось получить работоспособный мотоцикл, а я погряз в каких-то бесконечных проблемах! Нужно было переделывать в котле почти всё. И в этот-то момент я понял, что, несмотря на неоспоримые преимущества прямоточного котла, это изделие весьма не простое и требует тонкого расчёта, дополнительного регулирующего оборудования, да и насос съедал не малую часть вращательной энергии. Сложилось чёткое понимание, что, если бы я делал классический котёл, то ни одной из этих проблем просто не возникло бы!
Небольшое видео про мучения с прямоточным котлом:

Классический котёл

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

Изготовление

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

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

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

Для контроля давления установил небольшой манометр. Температуру носителя контролировать не обязательно, так как она напрямую связана с давлением и явно не выходит за критическую отметку (400*С). Давление в котле решил сделать как у реальных паровозов 16 bar. Предохранительный клапан настроил на 18 bar. Теперь осталось его опрессовать. Это своего рода проверка на прочность. Котёл наполняется доверху водой и накачивается повышенное давление. Сначала, я это делал оставшимся от предыдущей котловой системы, насосом из доводчика, но сжимать такой насос при давлении более 20 bar, оказалось не простой задачкой (очень хорошо, что мы теперь можем отказаться от такого узла, ведь он забирал уйму мощности на себя). Оказалось, что опрессовывать удобнее всего углекислотным огнетушителем. Им я без труда создал давление в котле в 25 bar (это был максимум моего манометра) и, выждав несколько минут, приступил к настройке предохранительного клапана.

Итог

Котёл получился на славу. Даже давление в 25 bar оказалось ему нипочём. Он даже не начал хрустеть. Предохранительный клапан (использовал от компрессоров) срабатывал чётко, хоть и ронял давление с 18 до 9. Этот для нас очень не выгодно, но он будет срабатывать только в тех случаях, когда сам за давлением не уследишь. Так что, до его срабатывания лучше не доводить. Это будет бессмысленное выбрасывание ресурсов.

Пламя

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

Изготовление

На металлоприёмке нашёл отличные, маленьких размеров, нержавеющие бачки. Судя по их форме и синей окраске, это кислородные баки от какого-то пассажирского самолёта. Я собрал несколько таких бачков в батарею и объединил магистралями подачи газа и заправки. Объём каждого бачка примерно 1.7 л, а значит, можно будет везти с собой запас топлива более 5л. жидкого газа. Согласитесь, не плохой запас энергии.

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

Эксперимент (рис А)Пламя с не прогретой горелки (рис В)Правильный режим, прогретая горелка

Поэтому подавать газ, в нашу горелку, следует плавно, чтобы она успела прогреться.
Испытания котла прошли как по маслу. Заправил примерно 35 л воды, горелку вывел на полную мощность и ждал. Через 14 минут вода закипела, и давление потихоньку начало подниматься. Примерно через такое же время в котле было 16 bar.
Для управления подачей пара, я использовал простой водопроводный шаровой кран, который отлично справлялся и с температурой, и с давлением. В них используется тот же самый фторопласт, так что проблем, думаю, не будет.
Для интереса, я решил открыть кран на полную и посмотреть на нашу энергию. Струя пара долетала до соседних гаражей и создавала шум взлетающей ракеты. При этом я ощутил силу реактивной тяги, пришлось даже придерживать котёл, чтобы он не начал летать по всей улице. Я был очень доволен!

В котле подобного типа запасается огромное количество энергии. Спуская пар в течение 5 секунд через отверстие дюйма, давление в котле упало всего лишь наполовину. Дело в том, что при уменьшении давления, смещается и точка кипения воды. То есть вода начинает кипеть и без подогрева, всего лишь от уменьшения давления. Этот эффект будет работать до тех пор, пока температура воды не упадёт до 100 *С. Это для нас приятная новость. Значит, можно будет долго ездить и с выключенной горелкой.
Но есть и один не совсем для меня понятный эффект. При активном выпускании пара при давлении менее 5 bar, начинает вылетать вода. Я предположил, что она кипит столь интенсивно, что в своём неистовом бурлении долетает до сухопарника и подхваченная потоком пара улетает наружу. Для эксперимента я слил часть воды, оставив уровень 20%. Эффект конечно уменьшился, но всё равно остался. Неужели вода подпрыгивает в котле на 30-40см? Если честно, с этим я пока так и не разобрался. Такая вот небольшая загадка.
Ну да ладно! Функционал готов, пора собрать наш аппарат!

Стиль

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

Большинство различных самоделок имеют стиль Безумного макса или Постапокалиптического мира. Да, так проще всего. Особо то и делать ничего не нужно. Ржавые железки, приваренные гаечные ключи, немного висящих тряпок и стиль готов. Но этой простоты, или так сказать ленивого стиля в нашем мире очень много. Мне захотелось сделать что-то маленькое, милое и красивое. Сделать конфетку, так сказать. И раз уж у нас древняя паровая технология, сам собой напрашивается Стимпанк.

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

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

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

Видео отчёт. Испытания парового мотоцикла

Заключение

Когда задумывал строить этот паровой мотоцикл, я рассуждал так: вот сделаю его, как нибудь это всё проедет и, удовлетворив все свои инженерные интересы, поставлю его дома напротив дивана в качестве эстетического элемента, навсегда. Но нет! Теперь это наоборот не даёт мне покоя. Я хочу его изучать, модернизировать, переделывать и побивать его же рекорды, хочу определить его максимум, понять всё, на что он способен! Конечно, в рамках этой концепции.
Первое с чего начну, это переделаю систему переключения пара на классическую. Мне стало интересно, какова будет разница. И ещё, при последующих испытаниях нужно будет поиграть с настройками. Добиться максимальной скорости, подобрав наиболее правильное опережение впуска пара. Ещё, хочу поэкспериментировать с разными видами топлива.
Видимо грядёт большая модернизация. Так что, если наш паровоз собирался уйти на пенсию и отсидеться где-нибудь в музее, тут я его сильно разочарую! У него впереди ещё длинное, тяжелое, но интереснейшее будущее!

Подробнее..

Из песочницы Ретроспектива разработки интерфейса листа персонажа

22.11.2020 14:12:21 |

Автор: admin

Близится 2021 год, а значит, минуло почти 4 года с момента, когда я присоединился к разработке Pathfinder:Kingmaker в качестве разработчика интерфейсов. За это время игра превратилась из маленького прототипа с минимальным функционалом в огромную, сложную систему. Игра пережила релиз, год активного багофикса и поддержки DLC, а также портирование на консоль. И теперь, когда разработку этого проекта можно считать завершенной, пришло время оглянуться и попробовать собрать ретроспективу того, как проектировались и создавались интерфейсы.

Я решил начать с основного, на мой взгляд, интерфейса игры, с листа персонажа.

Введение

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

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

Взято отсюда: http://runelords.peepersbog.org/index.html

В отличии от своих, более опытных в играх и разработке коллег, весь мой опыт настольно-ролевых игр сводился к играм в юности по обрывкам правил DnD и прохождения Baldurs Gate в момент, когда я даже не понимал, что она сделана по настольной игре. И, конечно, такой опыт является огромным минусом, когда нужно перенести настольную игру в компьютерную. Однако, сейчас я понимаю, что в тот момент недостаток обратился в достоинство, потому что это дало возможность взглянуть на интерфейс с точки зрения человека, ничего не знающего об игре. По сути задачей стало объясни самому себе, как это устроено, что, конечно, намного проще. Ведь никто так не сможет рассказать, как пользоваться чем-то, кроме как человек, только что этому научившийся. В момент, когда была поставлена задача на дизайн листа персонажа в игре, всё казалось очень просто: перенеси его в цифровой вид, убери лишнее и готово! И, конечно же, это оказалось не так. Чем глубже я погружался в устройство правил настольной игры, тем более ясным становилось, что Pathfinder это игра не по правилам, а по исключениям из правил.

Информационное проектирование

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

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

Переосмысление существующего, бумажного, в совокупности с новым, компьютерным, привело к идее разбиения экрана на три столбца. Хотя, правильней сказать, к идее протягивания уже существующей компоновки инвентаря. Левая треть экрана должна была стать сквозным информационным ядром интерфейсов персонажа и вобрать в себя основные характеристики. А ключевой частью этого блока должен был стать портрет. В отличии от других современных RPG, где основным представлением персонажа является 3D-кукла, у нас для роли отождествления игрока, как героя игры, был рисованный портрет. На это был сделан упор по нескольким причинам: 1. Это жанровое, духовное наследие Baldur's Gate. 2. Портретом можно выразить более сложные эмоции и лучше охарактеризовать героя, сделав игровой опыт глубже. Другие составляющие блока должны были отвечать на вопросы кто? и какой?: Хаотично-добрый полуорк, варвар, сильный и красивый, но глупый, бьёт молотом так-то, защита такая-то. Остальные две трети должны были раскрывать подробности о способностях и навыках и истории. Как результат информационного проектирования, все возможные блоки персонажа были сгруппированы и распределены по столбцам и страницам. Таким образом появилось логическое разбиение.

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

Отдельной темой хочется выделить визуализацию классовых прогрессий. Особенность Pathfinder тут в том, что, в отличии от многих игр схожего жанра, развитие персонажа здесь нельзя формализовать в статичную карту развития. Игрок может на любом повышении уровня выбрать себе другой класс и стать, например, магом 5-го уровня и вором 3-го и предсказать это невозможно. Кроме того, у каждого класса есть архетипы, выбор которых подменяет часть способностей и не обязательно на том же уровне. А еще часть способностей появляется в классе только после того, как игрок определиться с божеством своего персонажа или происхождением.
Для непосвященного человека описание почти любого класса выглядит как набор способностей, получаемых в случайном порядке и непонятно как связанных между собой. Так что на этапе сбора информации задача состояла в том, чтобы осознать паттерн организации классов и сформулировать идею, как упростить его представление.

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

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

Всё собранное было решено визуализировать уже на этапе сбора информации, чтобы оценить размеры и количественные характеристики.

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

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

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

Поиск разметки

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

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

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

В макетах использованы портреты из Baldurs Gate.

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

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

Здесь были эксперименты с группировкой способностей. Нужно было отделить способности, именуемые Feat, которые персонаж выбирает вне зависимости от класса от Special Abilities, которые уникальны для каждого класса. Плюс еще существовали Traits, сюжетное происхождение персонажа, которое за столом игрок выбирает для более интересного отыгрыша роли, но в нашем случае просто еще один способ повлиять на значения характеристик. А еще мы хотели показывать многие характеристики, которые, однако, были не всегда полезны применительно к отдельно взятому классу персонажа. Например, для мага не очень важно, насколько велик его Base Attack Bonus, он им не пользуется, когда бросает огненные шары. Но всё же некоторые блоки уже стали искать свою около-финальную компоновку с проверкой контента.

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

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

Финализация дизайна

В макетах использованы иконки из League of Legends.

Обсуждения у нас это всегда долгий процесс, отягощённый многочисленным столкновением мнений и интересов. Я не помню ни одного собрания, которое длилось бы менее 3-х часов. Одни полагают, что важнее предоставлять максимум механической информации, другие что важнее погружение в историю и атмосферу, а механические детали можно спрятать поглубже. Чаще всего такие дискуссии единственный эффективный способ выйти из тупика и, в результате обмена мнениями, прийти на следующую итерацию с новыми идеями. Страницы биографии персонажа и древо развития класса в целом были утверждены всеми участниками. А вот с главной страницы было решено убрать информацию о способностях, таблицу заклинаний и прочие числовые характеристики персонажей. Центром интерфейса решили сделать сюжетную составляющую игры. Для основного героя это стало Колесо мировоззрения, а для компаньонов мы придумали набор сюжетных карточек, ключевых событий этого персонажа, которые будут открываться игроку по мере прохождения. Баффы в этом случае также убирались из левой трети, но получали достаточно пространства, чтобы отображаться вместе с названием и параметром времени действия. Таким образом экран стал значительно чище, а также сместил фокус на то, что это в первую очередь ролевая игра, а уже потом механическая.

Способности переместились на отдельную страницу. Это позволило использовать не одни только иконки, но и названия самих способностей. Впоследствии это оказалось очень важно, потому что для отрисовки иконок под каждую способность нам в итоге не хватило времени и ресурсов. Кроме того, закодировать смысл каждой способности в иконку, а уж тем более расшифровывать её потом игроку, это слишком сложная задача. Но, опять же, ретроспективно должен отметить, что сильно недооценил количество способностей в блоке Special Abilities и переоценил их количество в блоке Traits. В итоге это вылилось в весьма несбалансированную компоновку этого экрана. Что мы, к счастью, имеем возможность исправить в будущей игре Pathfinder:Wrath of The Righteous.

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

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

Артовое оформление

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

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

Портирование на консоль

От релиза игры до момента, когда мы приступили к портированию игры на консоль прошло чуть меньше года. За это время нам удалось добавить много фичей, детализаций, многое доделать и во многом разочароваться. Мы получили много фидбэка от игроков и определили для себя камни, о которые не хотелось больше спотыкаться. В большей степени камни касались кода, многие вещи стали трудно поддерживаемы и местами слишком тесно переплетались с механикой. Так что подходя к консольным интерфейсам у нас уже накопился некоторый багаж знаний, но была и проблема. Для нас это стал первый опыт разработки интерфейсов под консоль. Мы внимательно разобрали похожие проекты, выделили что нам в них нравится а что нет, прочитали Technical Requirements, взяли несколько консультаций у более опытных команд и приступили к разработке.

Консольный интерфейс в отличии от ПК имеет ряд особенностей:

1. Их смотрят на телевизоре, сидя на диване. Это повлекло за собой увеличения кегля текста во всей игре.
2. По TRC необходимо иметь 5% save-зону, в которой не должен располагаться важный контент.
3. Курсор это сложное решение для консоли. Поэтому у нас больше нет тултипа, в который можно поместить описание параметров и способностей.

При первом проходе по экранам персонажа была предпринята попытка наследовать расположение и разметку элементов.

Однако, при этом возникали неразрешённые проблемы. Непонятен принцип, что и когда разрешать выделять. К примеру, если я разрешаю выделять Ability Scores на главном экране, то должен ли я разрешать выделять их же на странице Progression?

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

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

Так что после попыток отнаследоваться от ПК-версии в качестве базового шаблона fullscreen-интерфейсов была предложена следующая структура:

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

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

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

Под перемещение между экранами листа персонажа мы определили бамперы R1-L1.
Переключение между персонажами осуществляется с помощью радиального меню группы при нажатии правого курка R2.

В результате у нас получилось разбиение интерфейса на 7 экранов.

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

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

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

Заключение

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

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

Спасибо людям, принимавшим участие в работе над листом персонажа:
Михаил Ротфорт Lead UI
Василий Левинов UI Artist
Василий Болдырев Programmer
Никита Великовский Programmer
Максим Савенков Programmer
Оксана Мергер UI Programmer
Алексей Гусев QA Engineer
Александр Мишулин Creative Director
Виктор Сурков Art Director
Олег Шпильчевский Head of Owlcat Games

Автор: Павел Турчин UI Developer

Подробнее..

Категории: Интерфейсы , Графический дизайн , Разработка игр , Дизайн интерфейсов , Игры и игровые приставки , Дизайн игр , Игры , Unity3d , Ретроспектива , Интерфейс пользователя , Разработка интерфейсов , Дневники разработчиков , Owlcat games

Проводим ретроспективы для распределенных команд (и как Trello в этом помогает)

19.04.2021 10:09:21 |

Автор: admin

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

Почему Trello

Я пользовался большим количеством инструментов, из которых можно выделить основные: Miro - как интерактивный флипчарт, с которым может взаимодействовать вся командa; Google Docs с секциями помапанными на стадии ретроспектив; Confluence (так как все мои проекты пронзены Atlassian-стеком); а также, порой, Jira (вау, это была достаточно плохая идея)!

Я думаю что все пытались нащупать тот самый инструмент, который можно применить фактически в любой области!

И вот я бы выделил основными критериями для проведения Ретро и собирания фидбека о Демо в подобных инструментах:

1. Насколько хорошо оно работает на уровне объектов (во время обсуждений). -> в идеале тут хотелось бы видеть карточки (все таки мы в физическом мире работаем со стикерами) :)

2. Быстрая и эффективная работа с карточками / объектами

3. Подсветка / теги для карточек / объектив (чтоб все могли), не важно как (цвет, тег, еще какая-то штука позволяющая дифференцировать карточки)

4. Перетасовка / изменение порядка карточек / объектов / айтемов

5. Как можно меньшее время, затраченное на следующую последовательность действий: создание секции (списка) -> добавление в него объектов / карточек -> тегирование / подсветка айтемов (членами команды) -> добавление комментария к айтему.

Miro

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

Google Docs

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

В этом плане, знаете, даже google sheets казалось бы удобно использовать, как инструмент более подходящий для нашей аналогии двухмерной-классической-ретро-доски (ну как двухмерной, скорее именно с точки зрения того, что у нас есть некие секции с контентом для хорошо/не оч/ улучшить). Но и тут нас поджидает неудобство - drag-n-drop для айтемов, и их линкование друг с другом работает ужасно. Я еще пробовал в свое время google slides, с подходом слайд-для-секции (например перечислить все те великие свершения, в которые мы шмогли с прошлого спринта) - но в итоге менеджить это было сложно, ввиду тяжеловесности решения, ну и на одном таком канвасе могло одновременно ну человека два работать может, не больше. Ну и подсвечивать айтемы там конечно можно, но оно для того не очень приспособлено.

Confluence

Ну вот же confluence, там же целый шаблон для ретро есть! Скажете вы. И будете правы!

Но хорош этот шаблон для документирования/стенографирования, для журнала принятия решений. А нам это в ретро не нужно! Нам нужна живая дискуссия где народ таскает карточки по колонкам, клонирует, обсуждает, помечает!

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

Trello

Ну вот а когда мы подходим к Trello - оно просто поддерживает карточки. И голосовалку для этих карточек с помощью power-up'ов (очень просто). Или через тегирование этого дела цветами (что работает просто и быстро).

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

Короче говоря: trello это самый простой в использовании аналог флипчарта со стикерами :)

Подготовка к самой ретроспективе, и ее начало

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

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

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

- Соединение должно быть отличное! Мы не хотим страдать из-за непонимания (особенно в мультиязычных командах :), и нам не нужны лаги

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

Сама Ретроспектива

В зависимости от зрелости и атмосферы в команде можно использовать Ice Breakers (чтобы настроить на легкое взаимодействие и убрать ощущение обязаловки). Ну и не забудьте проверить как команда чувствует себя после спринта (проверка температуры) - не ждите высокой оценки как данности.

Запланированные улучшения с прошлого спринта

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

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

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

Иногда эта стадия может затянуться (планировали улучшение - не смогли достичь - начинаем погружаться слишком сильно в детали почему). Как фасилитатор, ваша задача помочь команде найти продуктивный путь для выявления настоящей причины в достаточно короткий срок (у нас ведь есть таймбокс). Поэтому мы с вами планируем один обязательный пункт улучшения, два уже имеют риск затянуть начало ретроспективы. Также старайтесь просто запарковать это обсуждение на полее поздние части ретроспективы - если нужно действительно разобраться. А возможно это даже не относится к ретроспективе как к событию, а надо проводить RCA / Post-Mortem?

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

Цели спринта и метрики

Цели Спринта

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

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

Метрики

Метрики спринта важны и как внутренний-SLA для команды, и как общий индикатор, который в комплексе помогает команде понять динамику.

Обычно команда навскидку придумает с десяток факторов, которые для неё препятствия чтоб быть более эффективной. Если поддерживать ведение такой дискуссии в правильном русле (читай, фасилитировать), и помогать команде наводящими вопросами (читай, коучить), ребята сами соорудят путь к улучшению и как его измерять. Главное чтобы был запрос на улучшение, и была понята сама проблема (нафига оно нам вообще). Еще нюансик: не рассматривайте метрики отдельно друг от друга, и стройте связи между опережающими индикаторами (гипотезами) и запаздывающими индикаторами (результатом). Например, действительно ли увеличение покрытия кода тестами увеличивает уверенность в том, что на проде качество улучшается?

Стандарные метрики, которые я стараюсь использовать:

- Lead Time (время от запроса клиента до поставки)

- Cycle Time (время от начала работы над задачей до поставки). Когда объяснишь на примере донесения ценности до пользователя - как устроен весь пайплайн и где затыки, ребята сами будут мотивированы следить за этими метриками (если, конечно, они у вас общаются с клиентами постоянно),

- Время в Code Review (атож, сколько задача висит и сколько ее проверяют),

- Количество раз тикет был переоткрыт (помогает вместе с определением Definition of Ready),

- Mean Time to Recovery (инцидент-метрика для понимания среднего времени на устранение),

- Bug Escape Rate (сколько багов мы не поймали на тестовых стендах, но поймали после релиза на прод).

В целом все зависит от ситуации, но я считаю Cycle Time и Lead Time тем самым минимумом для всех. Cycle Time в целом дает вам понимание прозрачности и предсказуемости.

Активность на выявление дельты улучшения ~ 'Хорошо-Плохо-Улучшения

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

Собираем фидбек с команды о том, как прошла ретроспектива

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

Референсы и полезности

У Бена Линдерса (Ben Linders) есть хорошая трелло-доска, в которой люди краудсорсят ретроспективные техники для распределенных команд в трелло.

https://www.benlinders.com/news/trello-board-retrospective-techniques/ Это, наверное, и разговоры с самим Беном, были огромным подспорьем, чтобы написать этот пост.

Подробнее..

Категории: Управление проектами , Agile , Scrum , Удаленная работа , Devops , Развитие стартапа , Scrum-мастер , Гибкие методологии , Retrospective , Trello , Ретроспектива проекта , Ретроспектива

Из песочницы Развитие цифровой аудиозаписи или как музыка перешла с кассет и дисков в интернет

19.08.2020 12:13:25 |

Автор: admin

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

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

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

Часть первая. С 60-х годов 20 века до 2000-х
Начало цифровой звукозаписи. Первые разработки и новейшие для той эпохи устройства

В 1963 году компания Philips представила компакт кассету которая использовала для записи магнитную ленту, в последствии данный носитель аудио стал невероятно популярным из-за своей простоты и дешевизны, однако в последствии его вытеснили примерно в начале 2000-х годов.

В 1967 году (в этом же году кстати вышел дебютный альбом группы Pink Floyd) техническим институтом исследований NHK представлен первый цифровой катушечный стереорекордер на дюймовой видеоленте.

Разработанное тогда устройство дало старт развитию устройств для записи цифрового звука.
Позднее в 1969 году компания Sony представила миру 13-битный цифровой стереорекордер, запись в данном устройстве велась уже на 2-х дюймовую дискету, что позволило увеличить длительность и качество записи.

Стереорекордер Sony образца 1970 года. Такие использовали для студийной записи звука следующие лет 20-25.

Спустя восемь лет на аудиовыставке Mitsubishi, компании Sony и Hitachi представляют прототип цифровых аудиодисков, а также грампластинок.

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

Также в ходе данных событий формат диска был увеличен на 5 мм.

На данный диск можно было записать 74 минуты аудиозаписи.

Существует мнение, что компакт диск был изобретен физиком Джеймсом Расселом, работавшим в тот момент в компании Optical Recording, который создавал устройство число для себя чтобы предотвратить царапание грампластинок. Устройство было презентовано еще в 1971 году,
спустя восемь лет компания Philips презентовало похожее устройство.

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

В 1982 году в Японии и Европе был принят стандарт на систему компакт-дисков.

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

Проигрыватель компании Philips. Дизайн устройства тоже был впечатляющим.

Кстати дизайны современных виниловых проигрывателей частично схожи с дизайном этого проигрывателя.

Современный виниловый проигрыватель компании Yamaha.

Первым альбомом записанным на диск, стал последний альбом группы ABBA The Visitors.

Торжественная презентация первого серийно-выпущенного диска.

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

В 1984 году компания Sony выпускает первый портативный проигрыватель CD-дисков. Его стоимость составляла 350 долларов.

Первый портативный проигрыватель.

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

DAT-кассеты.

Также в 1987 популярности дискам прибавил CEO компании Apple (на тот момент носившей название Apple Computers Inc.) Джон Скалли (на тот момент Стив Джобс уже покинул компанию) сказал, что компакт-диски произведут революцию в мире персональных компьютеров.

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

До СССР же компакт диски добрались только в 1989 году.

В 1992 году были представлены кассеты с форматом записи Digital Compact Cassette. Они предлагались как домашняя альтернатива кассетам DAT, однако эти кассеты также потерпели неудачу в данном предприятии по противодействию компакт кассетам, которые
на тот момент все еще занимали большую часть рынка по продажам музыки.

В 1995 году был разработан такой формат сжатия аудиоданных как MPEG 1 Audio Layer 3 или попросту MP3.

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

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

В 1998 году мир увидел первый полноценный MP3 плеер MPMan, ценник стартовал с 400 долларов минимальный объем памяти составлял примерно 32 мегабайта.

Один из образцов плеера с минимальный объемом памяти.

Часть вторая. Начало 2000-х
Музыка покоряет интернет пространство

В 1999 году 18-летним Шоном Фэннингом и его друзьями Шоном Паркером(который после провала Napster'a примкнул к компании Facebook), а также Джордоном Риддером был запущен Napster. Он использовал протокол peer-to-peer(который в последствии стал основой для протокола bit-торрент) для обмена файлами.

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

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

Сервис просуществовал относительно спокойно чуть больше года. В 2000 году причиной для иска стало появление на сервисе демоверсии песни " I Disappear " группы Metallica.

Был подан иск, итогом которого в 2001 году стало покупка контрольного пакета акций компанией Private Media Group (компанией по производству контента для взрослых)
сервис был закрыт и позже перерос в легальный онлайн-магазин музыки(произошло это примерно в сентябре 2008 года).

В этом же году компанией Apple Computer Inc. был представлен Ipod устройство позволяющее записывать музыку в внутреннюю память устройства через компьютер, минимальный объем памяти составлял целых 5 гигабайт.

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

В 2002 году был запущен сервис интернет радио Last.fm. С помощью плагинов к медиаплеерам собирает информацию о музыке, которую слушают пользователи, и на основе полученных данных автоматически составляет индивидуальные плейлисты.

В 2003 году компания Apple представила миру легальный способ прослушивать музыку через интернет в виде сервиса iTunes Store, база композиций в онлайн-магазине на момент презентации составляла свыше 200 000 треков.

Следующим сервисом который позволял легально и в то же время бесплатно прослушивать музыку, аудиокниги и подкасты стал шведский сервис Spotify который был запущен в 2006 году. Одной из ключевых фигур компании также был Шон Паркер, который в то время искал стартап
который продолжал бы идеи Napster'a, но уже легальным путем, в последствии он вложил в Spotify примерно 15 млн. долларов и стал членом совета директоров Spotify.

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

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

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

В 2010 году компания Яндекс представила свой стриминговый сервис Яндекс.Музыка. Сервис является платным, без подписки доступен только в странах СНГ(за исключением Украины),
с платной подпиской доступен во всех странах мира.

В 2015 году, в ходе конференции WWDC компанией Apple был представлен сервис Apple Music.

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

Подробнее..

Категории: Звук , Гаджеты , Аудио , Облачные сервисы , Читальный зал , Музыка , Ретроспектива

Мы решили внедрить Agile-Lean принципы в процесс разработки на ходу и вот что из этого получилось

19.06.2021 12:05:20 |

Автор: admin

Термин бережливого производства (Lean) в настоящее время на слуху. Мы все знаем результаты применения данной идеи в компании Toyota, которые позволили выпускать малые партии комплектующих точно в срок (Just-In-Time, JIT).

В книге Microsoft Secrets (1995 года) авторы (Кузумано и Ричард Селби) описали подходы контроля качества схожие с Lean применяемым в Toyota.

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

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

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

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

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

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

Отправная точка

Изначально в команде применялась несколько упрощенная методология Scrum. Ниже приведу ее описание.

Набор артефактов:

Project backlog журнал требований, реализуемых в рамках проекта, обнаруженные в процессе эксплуатации инциденты. Обычно требования оформляются в виде User Story. В качестве инструмента для верхнеуровневого планирования использовали Excel. Там же, для удобства, чтобы все было в одном месте, на отдельной странице сделали диаграмму Ганта и диаграмму сгорания.
Sprint backlog журнал требований и инцидентов реализуемых за спринт.
Scrum-доска. В качестве инструмента использовали доску Trello с расширением Plus For Trello для контроля трудоемкости.

Роли в команде:

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

Совещания:

Ежедневный митинг команды.
Ретроспектива в конце спринта.
Ежеквартальные ретроспективы.

Параметры спринта:

Продолжительность: 1 месяц.
Ежедневные обновления продуктивной системы по итогам завершения работ по блокам задач.

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

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

Хьюстон, у нас проблемы

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

Для исправления ситуации было решено провести экстренную ретроспективу и собрать все существующие проблемы.

Удалось выявить следующие точки улучшения:

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

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

Именно в этот момент появилась идея использовать подход JIT для улучшения текущей ситуации.

Какие преимущества Agile-Lean мы попробуем использовать в нашем проекте

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

Сильные стороны:

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

Слабые стороны:

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

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

Адаптируем 7 принципов Lean

Согласно методологии Lean для разработки программных продуктов, выделяется 7 основных принципов:

Исключение потерь. Потерями считается все, что не добавляет ценности для потребителя: излишняя функциональность; ожидание (паузы) в процессе разработки; нечеткие требования; бюрократизация; медленное внутреннее сообщение.
Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.
Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов.
Предельно быстрая доставка заказчику. Короткие итерации.
Мотивация команды. Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий.
Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.
Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. Мыслить широко, делать быстро, ошибаться мало; учиться стремительно.

Проанализировав принципы, сформировали 7 своих, которые подошли к нашей текущей ситуации и должны были помочь закрыть существующие проблемы:

1. Убрать ненужное

Под ненужным будем понимать следующее:

Все, что не приносит пользы конечным пользователям. Сюда относятся непонятные и несрочные требования, редко проявляющиеся дефекты. Мы их откладываем или отказываемся вовсе после согласования с заказчиком.
Ненужный код, дублирование кода.
Нечеткие цели и требования. Если есть такие задачи, то их отправляем на проработку и исключаем из Backlog. После детальной проработки задача может быть снова помещена в Backlog.
Программные дефекты. Любые дефекты появляются, когда код не проходит достаточную проверку качества.
Переключение разработчика между задачами. Задача не должна быть слишком маленькой или слишком большой. Большие задачи приводят к низкому качеству проверки, маленькие увеличивают количество переключений, что в итоге сказывается на производительности.

Что мы сделали, чтобы решить задачу:

Детальная проработка требований и согласование описания требований с тимлидом разработки, дополнительная расшифровка требований тимлидом на понятный для разработчиков язык.
Ввели отдельную колонку в Trello Техдолг, в которую помещаются задачи с приоритетом, для устранения дублированного кода, для доработки найденных в процессе разработки потенциально сбойных участков и задачи с не оптимальным кодом.
Повышение взаимодействия разработчиков, консультантов и тимлида. Регулярные встречи 1:1, еженедельные встречи для мини-обучения и небольших вебинаров, еженедельная упрощенная ретроспектива для обсуждения и решения на месте текущих сложностей.
Формирование задач из набора требований в рамках одного реализуемого процесса. Расчет: разработчик загружен на одну задачу не менее 8 часов.

2. Создавать знания и обмениваться ими

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

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

3. Повышение качества кода

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

Для повышения качества были приняты следующие предложения:

Парное программирование. Непосредственное взаимодействие тимлида с разработчиками, совместный анализ требований, проектирование, решение сложных задач.
Степень готовности (Definition of Done, DoD). Задача считается завершенной только в том случае, когда разработчик обсудил реализацию с тимлидом и провел демонстрацию разработанной функциональности консультанту, который закреплен за данной задачей.
Максимальное количество задач в работе (Work In Progress, WIP) каждого разработчика. У разработчика в работе и в тестировании суммарно не может быть больше 3-ех задач. Если разработчик отправил на тестирование все 3 задачи, то он обязан довести эти задачи до публикации в продуктивную систему, для этого активно взаимодействует с консультантами, отвечает на возникающие вопросы, помогает в процессе тестирования.

4. Сокращение спринтов

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

Поэтому решили сделать ряд ограничений на спринт:

Спринт длится 1 рабочую неделю.
На спринт планируется трудоемкость, которую сможет закрыть команда разработки (на основе собранной статистики за предыдущие cпринты). Дополнительно закладывается время на устранение критических дефектов.
Все реализованные доработки тестируются на специальной копии продуктивной системы с продуктивными данными (PreProd), и только после успешной проверки публикуются на продуктивную среду (Prod).
Публикация на продуктивный стенд выполняется только один раз в последний день спринта.
После каждого спринта собирается сокращенная ретроспектива на 30 минут для сбора фидбека с команды.

5. Расширение полномочий команды

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

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

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

6. Не торопиться с принятием решений

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

Решение принятое под воздействием эмоций может породить к большому числу проблем.

7. Регулярная оптимизация процесса

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

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

Для реализации данного принципа с тимлида команды разработки были сняты все задачи по разработке и переданы команде, объем задач на спринт был сокращен, т.к. команда разработки фактически ослабла.

Тимлид команды теперь выступает в качестве наставника:

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

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

Основная проблема бережливого производства отодвигание сроков

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

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

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

Итоги

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

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

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

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

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

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

По итогам внедрения Lean получили следующие количественные изменения:

Скорость разработки стала прогнозируемой и составила примерно 4 крупные задачи (до 6 часов на задачу в среднем) на сотрудника в неделю, ранее мощность команды в среднем составляла до 2-3 завершенных задач в неделю на сотрудника. Да, задачи крупные и это не совсем по Agile, но это помогло в нашей ситуации.
Сократилось количество публикаций примерно вдвое. На самом деле это существенная экономия времени, поскольку процесс публикации многоэтапный и затрагивает большое множество сотрудников.
Уменьшилось вдвое количество задач, возвращаемых на доработку.
Еженедельно закрывалось по 3 крупные задачи из техдолга.
Втрое уменьшилось количество дефектов, фиксируемых конечными пользователями.

Данный опыт планируется транслировать на другие проекты компании.

Спасибо за внимание, коллеги! Хотелось бы увидеть в комментариях ваш опыт использования Agile-Lean (или их адаптации) на ваших проектах.

Подробнее..

Категории: Разработка , Agile , Bigdata , Блог компании directum , Проекты , Тимлид , Развитие , Agile development , Планирование , Agile results , Ретроспектива , Agilean

Как я хотел разнообразить ретроспективы, а сделал собственную карточную игру

13.11.2020 12:14:13 |

Автор: admin

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

Меня зовут Кирилл, я работаю в Wrike и почти всю сознательную жизнь разработчика я не верил в Scrum. При этом во всех местах, где я работал, его готовили как минимум неплохо.

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

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

Что мне не нравилось в ретроспективе и как я предложил это исправить

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

Только ретроспектива не давала мне покоя. На тот момент мы проводили ее по простым правилам:

Каждый пишет на отдельных листочках плюсы и минусы прошедшего спринта.
Каждый член команды комментирует написанное и вешает стикеры на доску.
Все члены команды ставят галочки на листочках с важными для них плюсами и минусами. У каждого есть ограниченное количество голосов: от трех до пяти в зависимости от количества вывешенных листков.
Все листочки сортируются от самых популярных до менее волнующих.
В конце вся команда пытается придумать action items для каждого пункта сверху вниз. Ближе к концу уже запал заканчивается, но это не так страшно, так как самые важные пункты рассматриваются первыми.

В целом, такой формат встречи действительно давал плоды. Мы заводили action item для каждой проблемы, которая требует единовременного действия, и правило для исправления проблемы, которая требует регулярности (например, расширение definition of done для задач).

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

Очень редко кто-то предлагает обсудить глобальные проблемы всей команды. А в масштабах двухнедельного спринта их вообще может и не быть. Чаще мы говорили про локальные вопросы департаментов или чьи-то личные недовольства и радости. В таких случаях я терялся и с трудом выдавливал на коленке придуманную проблему, которая на самом деле меня и не волновала. Лучше уж так, чем совсем ничего не написать. Тогда остальные подумают, что мне безразлична жизнь команды, думал я.
Подсвеченные плюсы обесцениваются. Каждый спринт мы писали о том, что вся команда или какой-то конкретный человек молодец. Это работает только только на нескольких начальных встречах. Спустя несколько месяцев такие похвалы уже не кажутся чем-то ценным.
Члены команды, которые быстро пишут и голосуют, всегда находят время достать телефон, проверить почту, запушить коммит. Фокус и вовлеченность теряются. У всех складывается чувство, что они участвуют в чем-то не очень важном.

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

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

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

Основные правила игры

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

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

Макет карточки Problems Detector

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

Макет карточки Strict Voter

После того, как все владельцы карт Problems Detector высказались, в игру выступают игроки с картами Strict Voter. Их задача проголосовать за наиболее важную проблему и объяснить свой выбор. Если количество голосующих четное и голоса разделились поровну, то остальная часть команды также получает право голоса.
Автор победившей в голосовании проблемы получает 2 балла.

Изначально непонятно, кому из игроков выпала карта Strict Voter и кто примет участие в голосовании. Поэтому владельцы карт Problems Detector должны рассказать про проблемы доходчиво и подробно, чтобы каждый член команды понял суть.

Макет карточки Positiveness

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

Макет карточки Troubleshooter

Третья фаза игры. Игроки с карточками Troubleshooter предлагают свои решения проблемы, которая была выбрана на голосовании в первой фазе. Последовательность и правила голосования остаются такими же. Решение проблемы, набравшее наибольшее количество голосов, становится action item на следующий спринт, а его автор получает 3 балла. В конце карточки собираются и отдаются следующему за первым игроку. Круг смещается.

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

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

Какую пользу приносит этот формат по сравнению с классической ретроспективой:

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

Производство карт для игры

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

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

Материал, на котором будут печататься карты.** Среднестатистический сервис по печати предоставляет достаточно широкий выбор: глянцевый картон, матовый картон, несколько видов сплендоргеля, перламутровая бумага, глянцевая бумага, крафтовая бумага и мелованная бумага.

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

Красочность (CMYK). Она обозначается набором цифр: 4+0, 1+1, 4+4. Цифры обозначают количество цветов CMYK, которые будут задействованы: 4 полноцветная печать, 1 черно-белая. В свою очередь цифра до нуля означает красочность лицевой стороны страницы, а цифра после обратную. Получается, что 1+0 это черно-белая односторонняя печать.

Размер карт. Я остановился на размере 70х100: такие карточки удобно лежат в руке и помещаются в карман.

Фотография распечатанных карточек

Результат

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

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

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

Спустя некоторое время наш скрам-мастер попробовал провести эту игру в соседней команде в онлайн-формате. Но отсутствие подходящей платформы и нехватка живого общения ударяют по общему впечатлению.

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

Ссылки для тех, кто захочет повторить мою игру:

Макет карточек

Генератор карт, который я использовал

Генератор паттернов для рубашки

Подробнее..

Категории: Agile , Управление разработкой , Блог компании wrike , Геймификация , Ретроспектива , Настольные игры

Большая ретроспектива на несколько команд. Зачем она нужна, и как ее провести с пользой

18.06.2021 14:19:30 |

Автор: admin

Часть 1. Вводная зачемная.

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

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

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

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

Может возникнуть вопрос, зачем мы в целом решили провести общее ретро. Цели у этой встречи были такие:

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

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

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

Часть 2. Как это было.

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

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

План на ретроспективу у нас был такой:

1. Небольшая разминка

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

3. Голосование

4. Поиск корневых причин выбранных карточек методом "5 почему"

5. Определение идей по работе с выявленными причинами

6. Сбор обратной связи по итогам ретро

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

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

Теперь чуть подробнее про каждый из этапов:

1. Небольшая разминка.

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

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

* Выбрать тему

* В каждую команду добавить фасилитатора

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

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

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

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

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

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

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

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

В связи с тем, что продукт разрабатывался долго, мы вместе с продакт оунерами еще договорились поделить процесс генерации карточек по кварталам, для этого заранее сформировав timeline такого вида:

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

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

3. Голосование.

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

Выигравшие карточки мы поместили в отдельную зону, разделенную на 4 блока.

4. Поиск корневых причин выбранных карточек методом "5 почему".

Обсуждать выигравшие карточки мы решили с помощью метода "5 почему". Про сам метод можно почитать здесь: http://personeltest.ru/aways/habr.com/ru/company/renins/blog/554896/

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

Изначально выигравшие в голосовании карточки были размещены в 4 блока в отдельной зоне на доске. Далее мы вновь поделили участников ретро на 4 группы. Правило "по одному фасилитатору в каждой группе" осталось неизменным.

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

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

5. Определение идей по работе с выявленными причинами.

Итак, получили причины. Что же дальше?

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

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

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

В результате должен получиться список задач, который озвучивается всем, кто присутствует на встрече. По нему можно также задать вопросы / дать комментарии.

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

6. Сбор обратной связи по итогам ретро.

Стандартный шаг - опрос всех, кто участвовал, насколько встреча прошла успешно, чего не хватило, все ли цели встречи были достигнуты, над чем еще стоит поработать.

Данная итерация - финал большой сложной проведенной работы.

ПЕРЕРВ

Были. Не упоминала по тексту, так как перерывы стоит регулировать в зависимости от длительности каждого блока. У нас они были запланированы изначально по 10 минут каждые 1 - 1,5 часа.

Часть 3. Результативное "что дальше-то".

Вот мы собрали список проблем, определили их причины, накидали идеи по улучшению процесса, а что дальше?

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

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

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

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

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

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

1. Не затягивать с ретро на несколько команд.

2. Делать такого формата ретро долгими, на весь день.

3. При делении на группы не определять всех специалистов одной роли в одну группу.

4. Давать больше времени на поиск причин проблем и на генерацию идей.

5. Звать всех, кто может быть ответственными за реализацию идей, на такие встречи.

Это несколько поинтов для улучшения на будущее и нам в том числе.

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

Подробнее..

Категории: Scrum , Ретро , Ретроспектива , Блог компании «ренессанс страхование»

Ретроспектива.BlackBerry

23.05.2021 12:20:57 |

Автор: admin

Всем привет. В своей прошлой статье я рассказывал о последнем творении компании BlackBerry BB OS 10. Судьба этой операционной системы сложилась не совсем удачно. На данный момент по популярности она уступает даже Windows Phone. Спустя несколько лет после выхода OS 10 растеряла основное количество пользователей. Да, остались энтузиасты, вроде меня. Но это уже другая история... А сегодня я бы хотел поговорить о тех временах, когда Research In Motion (так называлась компания BlackBerry до 2013 года) была на пике своей популярности. Речь идет о 2008 2009 годах. Так, в 2009 году журнал Fortune назвал RIM самой быстрорастущей компанией в мире. Рынок телефонов тогда был совершенно другим.

Сегодня я расскажу вам о двух девайсах. Оба мне удалось приобрести. ЭтоBlackBerry Curve 8900(вышел в конце 2008 года для избранных операторов, позже во всем остальном мире) иBlackBerry Storm 9520 (конец 2009 года). Первый представляет из себя типичную QWERTY модель от RIM, в то время как вторая модель сенсорная. На примере Storm попытаемся понять, почему компания не смогла составить конкуренцию Apple. Забегая наперед скажу, что данная модель оказалась провальной по многим причинам. К сожалению, символа успеха RIM (Bold 9000) у меня нет. В свое время это была очень популярная и ходовая модель. Даже сейчас линейка Bold для многих остается самой любимой среди всех телефонов BlackBerry. Все вышеперечисленные устройства работают на базе операционной системы BB OS 5. Её я, естественно, стороной не обойду.

Любопытный факт: именно моделью Bold 9000 во время предвыборной компании пользовался бывший президент США Барак Обама. Это сделало отличную рекламу бренду BlackBerry.

BlackBerry Curve 8900

BlackBerry Storm 9520

Внешний вид и качество сборки

Первое что ощущаешь, когда берешь эти телефоны в руки: Какие же они маленькие по сравнению с современными лопатами. И это действительно так. У Storm 9520 экран диагональю 3.25 дюйма, а у его QWERTY собрата 2.4 дюйма. Сегодня эти цифры кажутся просто смехотворными. Далее, я рассмотрю каждую из этих моделей по отдельности.

BlackBerry Curve 8900выполнен в привычном для RIM форм факторе. Габариты у телефона следующие: 109 x 60 x 13.5 мм и вес 110 г. В руке ощущается намного легче, чем Storm.

Лицевая часть. В самом верху расположена глянцевая вставка. На ней находится разговорный динамик, под которым расположилась надпись BlackBerry. Справа приютился LED индикатор. Ниже экрана расположены 4 кнопки (нажимаются приятно). По середине находится трекбол для управления устройством. Тактильно ощущается вполне себе неплохо, хотя первое время немного не привычно. В самом низу находится полноценная QWERTY клавиатура. Несмотря на немного кучное расположение клавиш, печатать очень даже удобно. Ход у кнопок приятный. Но о клавиатуре я более подробно расскажу в другом разделе. На лицевой части также присутствует серебряная окантовка.

Боковая часть.Сделана из софт-тач пластика. На правом боку располагается 3,5 мм разъем для наушников, клавиши регулировки громкости (прожимаются хорошо), кнопка для запуска камеры (как по мне, слишком маленький ход) и Micro USB разъем для зарядки. Я думаю, слишком много всего на одной части корпуса. Не совсем удачное решение.

Вот здесь хорошо видна перегруженная боковая часть

А вот налевой гранирасположилась лишь клавиша для активации голосового управления устройством. Её вы можете увидеть на самой первой фотографии.

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

На задней частимы видим камеру со вспышкой и гордой надписью 3.2 MP. Под ней расположен динамик. Задняя крышка, естественно, съёмная. На ней присутствует фирменный логотип компании. Крепится крышка к корпусу при помощи защёлки. И вот тут возникает проблема. Выглядит вроде надёжно, однако защёлка шатается и задняя часть периодически люфтит. В плюсы могу записать то, что крышка имеет приятную текстуру.

BlackBerry Curve 8900 сзади

Если мы ее снимем, то увидим следующую картину:

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

BlackBerry Storm 9520.Габариты у телефона следующие: 112.5x62.2x14 мм, вес 160г. Кажется значительно тяжелее Curve, однако в то же время ощущается более цельным.

Лицевая часть. Здесь присутствует уже знакомая нам глянцевая вставка с разговорным динамиком, надписью и LED лампочкой. В отличие от 8900, в данной модели большую часть занимает экран. Снизу расположены те самые 4 кнопки, однако тут они сенсорные.

Лицевая часть Storm 9520

Боковые частиимеют окантовку. Направойрасположен 3,5 мм разъем, кнопки регулировки громкости и клавиша для запуска приложения Камера. Ход у качелей регулировки громкости более маленький, чем у Curve. Зато боковая часть телефона полностью прорезинена. Благодаря этому телефон уверено лежит в руке и не выскальзывает. А вот Micro USB разъем вынесли на другую сторону к уже знакомой нам клавише запуска голосового управления. Такой подход мне нравится гораздо больше.

Боковая сторона BB Storm 9520

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

Сзадирасположился такой же, как и на Curve 8900 модуль камеры со вспышкой. На крышке присутствует логотип BlackBerry. Никакой защёлки тут нет. И это правильное решение. Благодаря этому задняя часть не люфтит. При этом она относительно легко снимается и имеет приятную текстуру.

BB Storm 9520 сзади

Снизуу телефона глянцевая вставка. Там же расположился динамик.

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

По итогу можно сделать вывод, что качество сборки и дизайн у обоих устройств на достойном уровне. У Curve 8900 и Storm 9520 очень много схожих элементов и деталей с точки зрения внешнего вида. Они присущи многим моделям BlackBerry и выделяют их среди конкурентов.

Любопытный факт: в те времена телефоны BlackBerry собирались на заводах в Венгрии.

Аппаратное оснащение

Тут всё достаточно стандартно для того времени. На обоих моделях установлен одноядерный процессор. Но из-за того, что Curve вышел раньше, у него частота пониже (512Мгц против 624Мгц). Камеры полностью схожи ( 3.2 МП, 2-ух кратный цифровой зум, вспышка и автофокус). Оба телефона поддерживают стандартный набор в виде WI-FI, Bluetooth 2-ой версии, GPS, Micro SD карт (для расширения памяти). Звук у обоих устройств средний. Однако у Storm 9520 он кажется более плоским. Экраны у телефонов имеют одинаковое разрешение: 480 x 360 пикселей (TFT матрица). Но из-за меньшей диагонали, однако, Curve 8900 имеет более высокую плотность пикселей. А вот в чем Storm 9520 выигрывает, так это в объеме встроенной памяти (256 Мб против 2Гб), а также в наличии сетей 3G. Аккумуляторы этих телефонов совместимы, емкостью 1400 мА*ч. Как видите, ничего необычного по сравнению с конкурентами. Но более подробно мне бы хотелось остановиться на технологии, применяемой в Storm 9520 Sure Press.

Данная разработка используется по отношению к экрану устройства. Когда вы нажимаете на сенсорный экран, то происходит физическая отдача (как будто он продавливается) и создается ощущение, будто вы нажимаете на кнопку. При этом возникает характерный звук, напоминающий хруст. Данную технологию RIM применила в первом поколении Storm, а во втором значительно ее улучшила. Так, если в первой версии нажать на экран, когда он выключен, то отдача будет. Грубо говоря, под дисплеем стоят большие механические кнопки. В то время, как у Storm 2 при отключенном экране отдачи не будет. Принцип работы значительно усложнился. Такая технология для меня представляет интерес. Из-за нее текст набирать немного приятнее. Ничего подобного у других производителей не наблюдал.

Проблемы в РФ

Нет, здесь не проблема с серверами BlackBerry, как на OS 10. Тут ситуация гораздо более серьезная. Если у вас РСТ телефон (т.е. куплен в России от нашего оператора), то у вас будут отсутствовать такие вещи, как: App World, BBM, приложение карты, браузер, Wi-Fi. То есть, покупая у нас телефон BB, вы получаете урезанную OS 5. Как узнать, что у вас именно такая модель? Тут есть два способа:

1) Снять заднюю крышку и аккумулятор, посмотреть наличие соответствующей наклейки.

2) Узнать Vendor ID вашего телефона. Если у вас 296 (МТС) или 297 (Билайн/Мегафон), то у вас РСТ модель.

Очень в редких случаях помогает сброс IT-политик на устройстве через программу BBSAK (о ней ниже). МойCurve 8900 именноРСТ. А вот вот на Storm 9520 все вышеуказанные приложения есть.

Экран блокировки BBM

Операционная система

Теперь давайте более подробно рассмотрим операционную систему (OS 5). У меня была возможность протестировать также 4-ую версию. Изменений в новой прошивке по сравнению с ней не так уж и много, но они всё же есть. Как уже писалось ранее, навигация по системе на Curve осуществляется при помощи трекбола, на Storm с помощью сенсорного экрана. Из-за этого отображение системы на устройствах иногда рознится. На моих телефонах установлены следующие версии ОС:

BlackBerry Curve 8900:5.0.0.1067, пакет 1728. Данная прошивка от оператора AT&T. Её до сих пор можно скачать с официального сайта BlackBerry по специальной ссылке.

BlackBerry Storm 9520: 5.0.0.713, пакет 1206. Данное обновление мне предложил установить Desktop Software (о нём ниже).

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

Главный экран

Меню с приложениями. Чтобы перейти в него, необходимо нажать кнопку со значком BlackBerry (у Storm можно также перевернуть телефон в горизонтальное положение). Здесь перед нами предстают все приложения и папки. Последние можно создавать, редактировать. При желании можно поменять иконки приложений местами и настроить их отображение (чтобы некоторые программы не отображались).

Меню с приложениями

При переходе в одну из папок увидим следующее:

Папка с играми

Если в любом приложении удерживать (не нажать) клавишу с логотипом BB, то откроется своеобразноеменю многозадачности. Благодаря ему можно переключаться между приложениями.

Меню многозадачности

На этом моменте вы могли подумать, что с дизайном у BB OS 5 все более менее в порядке. Однако это не совсем так. Система в этом плане очень неоднородна. Пока вы на главном экране, все хорошо. Однако стоит только перейти, например, в приложениенастройки, как тут же все меняется.

Приложение Настройки

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

При нажатии (не удержании) кнопки со значком BB открывается маленькоеменю. Благодаря ему совершается большинство действий и можно перейти в настройки приложения или справку. Значительная часть навигации по системе основана именно на этом меню.

Вот так оно выглядит в приложении "Задачи"

Понятное дело, присутствуют основные системные приложения. Например,калькулятор. Здесь, конечно, отсутствуют всякие логарифмы, факториалы и прочее. Однако основной функционал есть и плюс пускай и простенький, но всё же конвертер (доступно 9 вариантов для перевода из одной единицы измерения в другую).

Приложение Калькулятор на Storm

В систему встроен офисный пакет. Это такие приложения, как Word To Go, Sheet To Go, Slideshow To Go. Программы имеют стандартный для системы вид. Однако есть один нюанс. Можно просматривать файлы. А вот создавать свои нельзя. По умолчанию на устройство установлена стандартная версия офисных приложений. За премиум раньше нужно было платить.

Камера. Интерфейс данного приложения выполнен в стиле других нативных программ. Максимальный размер фото - 2048x1536. Минимальный соответствует разрешению экрана. Быстро открыть данную программу можно при помощи кнопки на телефоне.

Настройки приложения Камера

Календарь. Присутствуют привычные для BlackBerry работа со встречами, конференциями, синхронизация с LED индикатором, настраиваемые уведомления. Есть возможность настроить стартовую страницу (день/месяц/год). Из недостатков могу выделить отсутствие выбора темы. С точки зрения цветового оформления мне календарь не особо нравиться. К плюсам можно отнести количество лет, доступных к просмотру. Вы можете выбрать ЛЮБОЙ год. Хоть 100, хоть 4000. Также есть возможность синхронизации с почтой, просмотр вложенных к приглашению файлов.

Календарь

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

Менеджер паролей

Часы. Мне всегда нравилось, как данное приложение выглядит на телефонах BlackBerry. На выбор доступны 4 варианта циферблатов. Естественно, присутствует будильник, секундомер, таймер. В режиме ночного чтения есть синхронизация с LED. При подключении устройства к источнику питания, данное приложение само открывается (функцию можно отключить).

В операционной системе присутствует стандартный набормультимедиа возможностей.Музыка, видео (даже некоторые несконвертированные форматы поддерживаются), диктофон, мелодии (предустановлено их достаточно много, вполне себе неплохой набор). Все это расположено в отдельной папке, что достаточно удобно. Вообще, данным аспектом BB никогда не славились, однако в OS 5 мультимедийные возможности были расширены, что конечно же, важно для рядового пользователя.

Браузер.Наверно многим из вас интересно, как сегодня встроенный браузер отображает сайты. Однако я подсуетился, и установил Opera Mini 4-ой версии на свой Storm. Её я вам тоже покажу.

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

Яндекс

Настройки Обозревателя

А вот сOperaситуация иная. По сравнению со встроенным браузером, она просто летает. Да и с точки зрения дизайна Opera на две головы выше. Она открывает бОльшее количество страниц, и мне удалось даже зайти на ДТФ (правда выглядит он так себе). С ОЧЕНЬ БОЛЬШОЙ натяжкой данным приложением можно пользоваться.

Настройки Opera

Справка. Очень полезное приложение, особенно если вам необходимо ознакомиться с системой. По умолчанию она не установлена. Зато здесь присутствуют все основные разделы системы, а также решение самых распространённых проблем. Практически из любого приложения можно перейти в соответствующий пункт в справке. Работает она в режиме оффлайн, что является несомненным плюсом. Кстати, с данным приложением на Storm связан один нюанс. Оно ОЧЕНЬ СИЛЬНО лагает. Пользоваться практически невозможно.

Справка

И раз уж я упомянул работу системы, то хотелось бы остановиться на этом моменте поподробнее.

Начну сCurve 8900. Система работает очень отзывчиво. А с последней прошивкой от AT&T она стала еще более стабильной. Никаких зависаний и тормозов не наблюдал. Лишь иногда какое-нибудь приложение может заставить телефон "задуматься" буквально на пол секунды. Переключение между программами осуществляется быстро. С другой стороны, интерфейс в некоторых разделах системы очень простой. От этого и лагать там нечему. Из минусов могу выделить практически полное отсутствие анимаций (в отличие от Storm 9520). В целом, телефоном с комфортом можно пользоваться.

А вот соStorm 9520ситуация более неоднозначная. Из плюсов можно выделить наличие адаптации системы к горизонтальному использованию и присутствие некоторых анимаций (например, при запуске или выходе из приложения). Несмотря на более мощное железо, работа ОС на Storm оставляет желать лучшего. Многие покупатели жаловались именно на медленную работу данного телефона. Это хорошо видно в том же приложении "Справка". Может быть это связано с тем, что у меня установлена не последняя версия ПО. Если у кого она есть на Storm 9520 - отпишитесь. Пользоваться данной моделью в принципе можно (с точки зрения стабильности системы), но придется смириться с некоторыми недоработками и это далеко не такой опыт, как на QWERTY вариантах. В этом аспекте однозначно побеждает Curve 8900.

Blackberry ID, World, Messenger

Если вы читали мою прошлую статью, то наверно знакомы с данными сервисами.BlackBerry ID- учётная запись. Во времена OS 5 она использовалась лишь в BB World и BB Protect.

App World. Именно так назывался фирменный магазин приложений до 2013 года (был запущен в 2009). И если вы думаете, что для OS 10 мало софта, то сейчас вы поймете, что у OS 5 ситуация была намного хуже. Из известных приложений мне удалось найти всего три: Facebook, Opera и Facebook Messenger. Конечно, присутствуют годные приложения для решения локальных задач на устройстве. Но о чем-то большем и говорить не стоит. Плюс магазин был заблокирован в некоторых странах, в том числе и России. Если вы хотите сами ознакомиться с ассортиментом приложений/игр, то вы можете перейти на веб версию магазина и выбрать в качестве устройства Curve 8900.

BlackBerry Messenger. Фирменный мессенджер компании. Вышел в далёком 2005 году. В то время полноценно не работал без функции BIS (о ней в другом разделе). Идентификация пользователя происходит при помощи PIN (уникальный для каждого устройства номер, записываемый в шестнадцатиричной системе счисления) или логина пользователя. BBM славился своей конфиденциальностью и безопасностью. Присутствует возможность создания групп (вступить в уже существующие можно при помощи сканирования QR кода), отправки различных файлов и т.д. В общем, привычный для такого рода приложений функционал. Интерфейс на сегодняшний день выглядит, понятное дело, устаревшим. По моему мнению BBM - одно из самых годных приложений, созданных непосредственно RIM.

BBM

BlackBerry Protect. Фирменное приложение для защиты от краж. Доступно на версии OS 4.6 и выше. На специальном сайте можно произвести различные манипуляции с потерянным устройством (установить пароль, найти телефон на карте, удалить все содержимое и т.д). Данная функция не работает, если у вас подключен BES или нет BB ID.

Программное обеспечение для ПК

В OS 10 для синхронизации с компьютером использовалась программа BB Link. Здесь же её заменяетDesktop Software. Интерфейс у программы довольно стандартный. Присутствует полная синхронизация мультимедиа с устройством. Можно выполнить резервное копирование, восстановление или обновление устройства. Desktop Software сам предложит это сделать. В разделе "Приложения" можно просматривать программы и устанавливать их в формате alx. Никаких проблем с совместимостью на Windows 8 не наблюдал.

BB Desktop Software

Существую ещё две полезные программы.

Первая из них называетсяBBSAK. В ней вы можете полностью очистить устройство (в том числе и удалить OS), сделать даунгрейд ПО, сбросить IT - политики и т.д. Доступна работа с файлами cod и jad. Если вы собираетесь производить различные манипуляции с устройством, то данная программа является отличным вариантом.

BBSAK

Второе приложение -CrackUtil. Её функционал практически полностью аналогичен BBSAK. На Windows 8 лично у меня она работала только при запуске от имени администратора.

CrackUtil

Выше я вскользь упомянул об обновлении системы. Хотелось бы остановиться на данном моменте поподробнее.

Обновление системы (1 из способов)

Для OS 5 существует множество способов обновления программного обеспечения. Сейчас я покажу вам один из них (с полной очисткой данных).

1) Заходим в программу BBSAK и жмем Wipe Device. Все файлы вместе с ОС полностью удалятся, и при загрузке устройства будет выскакивать ошибка 507.

2) Скачиваем нужную нам прошивку.

3) Запускаем поиск по диску C. Нас интересует файл vendor.xml. Удаляем его отовсюду.

4) Переходим по следующему пути: C:\Program Files(x86)\Common Files\Research In Motion\AppLoader и запускаем Loader.exe.

5) Нажимаем "далее " до тех пор, пока не станет доступен выбор элементов ПО для установки.

6) Выбрав все необходимое, нажимаем ОК.

Однако с моимCurve 8900возникла неожиданная проблема. На 5 этапе у меня не показывались элементы установки, и высвечивалась ошибка. Решил данную проблему следующим способом:

1) Перед запуском Loader.exe дождался, пока Device Manager определит устройство.

2) Не запуская программу, вытащил аккумулятор из телефона.

3) Запустил Loader.exe, выбрал устройство для подключения (даже несмотря на то, что из него была вытащена батарея).

4) Наконец стал доступен выбор элементов для установки. Нажал ОК. Несколько минут программа пыталась установить ПО, но вскоре высветилась ошибка.

5) Вставил батарею обратно, включил устройство (там у нас ошибка 507) и нажал "Повторить". После этого все заработало.

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

BIS/BES

Уже неоднократно упоминались в данной статье. Предлагаю рассмотреть каждую из функций по отдельности.

BlackBerry Internet Service (BIS). Данная услуга дает вам конфиденциальность, безлимитный выход в интернет, а также предоставляет возможность работы с электронной почтой (до 10 аккаунтов). При этом присутствуют Push уведомления и вы мгновенно получаете письма. В качестве дополнения есть синхронизация с календарем и адресной книгой. Подключается данная услуга у оператора. Именно у него находится сервер, через который проходит весь ваш траффик. Данная услуга предназначена для физических лиц и маленьких компаний.

Blackberry Enterprise Server (BES).Данная услуга предназначена для корпоративных пользователей. Вышеупомянутый сервер находится не у оператора, а непосредственно внутри вашей компании. При этом возникает некая экосистема, в которой все BlackBerry взаимосвязаны между собой. Вы можете синхронизировать электронную почту, предоставить удаленный доступ к корпоративным приложениям, использовать поиск в корпоративной адресной книге. Предоставляется также возможность применения IT - политик к телефонам и удаленной блокировки. Естественно, защищенность находится на высшем уровне. Однако в России некоторые функции не работают.

BlackBerry Enterprise Server Express (BESx). Облегченная версия BES. BESx менее требователен к ресурсам и обслуживанию (при необходимости можно установить даже на почтовый сервер). При этом в нем сохранены все основные функции BES. Но в то же время некоторые фишки старшей версии все-таки не доступны. Зато отсутствует необходимость в покупке лицензий. Ну, и все это дело сопровождается комплексной безопасностью.

Сейчас, понятное дело, никто этими услугами не пользуется. Раньше BIS у нас в стране можно было подключить у Билайн, Мегафон, МТС.

Клавиатура

Одна из визитных карточек BlackBerry. Компания, в первую очередь, известна QWERTY моделями. Эталонного Bold у меня нет. Но это вряд ли помешает адекватно оценить клавиатуру на Curve и Storm.

Начну с модели с физической QWERTY. Как уже писалось выше, на8900кнопки расположены немного кучно. Но от этого случайные нажатия не возникают. Между кнопки есть небольшое расстояние (в отличие от Bold). Ход у кнопок хороший, они не люфтят. Есть такие дополнительные клавиши, как Alt, Shift, Space, Sys, Del. На клавиатуре присутствует подсветка. Так как у меня РСТ модель, то в наличии и гравировка. Присутствуют специальные комбинации клавиш (например, чтобы сменить язык, нажимаем левый Alt + Enter, для исключительно цифр Левый Alt + Левый Shift и т.д). На любую клавишу можно назначить быстрый набор. Связка клавиатура + трекбол используется для копирования/вставки/вырезания текста. Реализована данная вещь вполне себе неплохо. Если подытожить, то клавиатура на Curve не столь идеальна, как на Bold, однако она приличного качества по меркам других моделей RIM, и тем более, в сравнении с конкурентами.

А вот соStorm 9520ситуация иная. Лично я смог пользоваться только лишь в том случае, если телефон в горизонтальном положении или с полной раскладкой в вертикальном положении. Другие варианты раскладки (их можно выбрать) просто отвратительны. Работа с курсором (копирование, выделение и т.д) реализованы очень плохо. Хоть как-то спасает ситуацию технология Sure Press. А в целом ситуация плачевная. На Storm у меня происходят постоянные случайные нажатия и ошибки. Всё-таки BlackBerry - это про QWERTY.

Безопасность

Одно из главных преимуществ BlackBerry перед конкурентами. До OS 10 основу безопасности составляли вышеуказанные BIS/BES. Но и в самом устройстве на уровне системы все тоже достойно. Ниже вы можете взглянуть на соответствующий раздел в настройках и убедиться в этом.

Пускай речь сейчас пойдет не об OS 5, но все же. В 2012 году компания Trend Micro сравнила актуальные на тот момент OS с точки зрения безопасности. Результаты оказались следующими: BlackBerry OS 7 показала средний балл 2,89, далее, за ней iOS со средним баллом 1,7, Windows Phone 7.5 набрала в среднем 1,6 баллов, а Android 2.3 завершил тестирование с баллом 1,37. Думаю, примерный расклад вы понимаете.

Итог

Давайте сделаем выводы. Почему BlackBerry в конечном итоге перестали быть популярны. Как мне кажется, они не смогли адаптироваться под быстро меняющийся рынок (на это во многом повлияли ошибочные действия руководства). Весь этот процесс запустила компания Apple. BlackBerry и iPhone имели разные подходы. Канадская компания предлагала безопасность, хорошую автономность, работу с почтой, QWERTY клавиатуру. В большей степени RIM были ориентированы на корпоративный сегмент. А у Apple была передовая с точки зрения интерфейса система, наличие большого количества приложений. Американская компания хотела радикально изменить рынок. В то время руководство RIM не было способно принимать быстрые и верные решения. Тот же Storm первого поколения (который должен был стать убийцей яблочного телефона) вышел абсолютно провальным продуктом. У людей он не работал, и телефон массово возвращали в магазин. Вторая версия исправила многие ошибки, но тоже не получила особого признания. BB Curve 8900 и Bold 9000, как по мне, одни из последних устройств, которые были выпущены RIM, когда та была на коне. А вот с приходом линейки Storm начался крах компании, пусть по началу и не такой ярко-выраженный. Всем спасибо за прочтение статьи.

Подробнее..

Категории: Гаджеты , Ретроспектива , Blackberry , Os 5

	Русский
	English

Ретроспектива

Введение

Устройство

Создание прямоточного котла

Итог

Классический котёл

Изготовление

Итог

Пламя

Изготовление

Стиль

Заключение

Введение

Информационное проектирование

Поиск разметки

Финализация дизайна

Артовое оформление

Портирование на консоль

Заключение

Почему Trello

Miro

Google Docs

Confluence

Trello

Подготовка к самой ретроспективе, и ее начало

Сама Ретроспектива

Запланированные улучшения с прошлого спринта

Цели спринта и метрики

Цели Спринта

Метрики

Стандарные метрики, которые я стараюсь использовать:

Активность на выявление дельты улучшения ~ 'Хорошо-Плохо-Улучшения

Собираем фидбек с команды о том, как прошла ретроспектива

Референсы и полезности

Часть первая. С 60-х годов 20 века до 2000-х Начало цифровой звукозаписи. Первые разработки и новейшие для той эпохи устройства

Часть вторая. Начало 2000-х Музыка покоряет интернет пространство

Хьюстон, у нас проблемы

Какие преимущества Agile-Lean мы попробуем использовать в нашем проекте

Адаптируем 7 принципов Lean

1. Убрать ненужное

2. Создавать знания и обмениваться ими

3. Повышение качества кода

4. Сокращение спринтов

5. Расширение полномочий команды

6. Не торопиться с принятием решений

7. Регулярная оптимизация процесса

Основная проблема бережливого производства отодвигание сроков

Итоги

Что мне не нравилось в ретроспективе и как я предложил это исправить

Основные правила игры

Производство карт для игры

Результат

Внешний вид и качество сборки

Аппаратное оснащение

Проблемы в РФ

Операционная система

Blackberry ID, World, Messenger

Программное обеспечение для ПК

Обновление системы (1 из способов)

BIS/BES

Клавиатура

Безопасность

Итог

Категории

Последние комментарии

Часть первая. С 60-х годов 20 века до 2000-х
Начало цифровой звукозаписи. Первые разработки и новейшие для той эпохи устройства

Часть вторая. Начало 2000-х
Музыка покоряет интернет пространство