Как сделать инструкцию по сборке конструктора

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

Что такое LDraw?

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

На сайте LDraw есть установщик программ необходимых для моделирования, создания инструкций и других перечисленных возможностей. Найти ссылку для загрузки установщика можно здесь (ищите ссылку на файл с именем LDraw_AIOI_2016-01_setup_32bit_v1.exe или аналогичным). Установщик позволяет установить такие программы, как MLCad, LDView и LPub.

Здесь в двух статьях я кратко опишу процесс установки программ LDraw и создания модели робота LEGO Mindstorms Education EV3 с помощью программ MLCad, LSynth и LPub.

Установка программ LDraw

Скачайте инсталлятор LDraw All-In-One-Installer и запустите установку. Устанавливать программы рекомендуется на операционные системы Windows XP/Vista/7.

Не буду останавливаться подробно на установке, скажу лишь, что на шаге выбора устанавливаемых пакетов (Select Packages), проверьте, чтобы стояли галочки напротив программ MLCad, LDView и LPub. Обязательно установите галочку напротив программы LSynth, которая позволит нам рисовать гибкие провода.

После установки сразу обновите программу LPub. Скачать обновление можно здесь. Я скачивал файл LPub4_0_0_14_win32_update.zip.zip. Для обновления просто распакуйте файлы, находящиеся в архиве в папку, где установлена программа LPub (по умолчанию это папка C:\Program Files\LDraw\LPub или C:\Program Files (x86)\LDraw\LPub).

Интерфейс программы MLCad

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

1. Панельки со всеми возможными командами программы. Можно перетащить их и прикрепить не только к верхнему краю, но и по бокам. Если у вас маленький экран, имеет смысл убрать лишние панельки, щёлкнув по ним правой кнопкой мышки и убрав галочки напротив ненужных. Для моделирования часто нужны панельки с выбором цвета (Colorbar), панель трансформации объектов (Transformationbar) и панель режимов (Modebar). Без остальных вполне можно обойтись, т.к. они будут нужны нечасто и можно воспользоваться меню.

2. Это каталог всех деталей всех конструкторов LEGO. Часть деталей, как видите, сгруппирована по ключевым словам. Например, в группе Electric вы увидите все детали, название которых начинается со слова Electric, в группе Technic – детали, начинающиеся со слова Technic и т.д. Лучше перед началом работы убрать из этого древовидного списка ненужные группы и добавить свои. Чтобы настроить список, щёлкните по нему правой кнопкой мышки и выберите пункт контекстного меню «Parts Tree -> Tree Configuration…».

Мы можем удалить все группы, кроме Technic (т.к. детали Technic как раз используются в конструкторе LEGO Mindstorms EV3) и LSynth (используется для рисования проводов). Также нам понадобятся детали, в названии у которых есть слово EV3 (сюда попадут датчики, моторы, микрокомпьютер и т.п. специфические только для конструктора EV3), Wheel (здесь можно будет найти, например, большое колесо, использующееся в приводной платформе и гиробое), Gear (здесь будут шестерёнки), Pin (шпильки для соединения деталей с трением и без), Axle (оси и комбинированные шпильки), Plug (здесь будет вилка для проводов), Beam (здесь окажутся основные строительные элементы — балки).

Обратите внимание, чтобы искать слово только в начале названия ставится знак «<». А чтобы восстановить первоначальные группы вы можете щёлкнуть по пункту контекстного меню «Parts Tree -> Default».

Также в области 2 вы всегда сможете найти деталь по первой букве в названии (группа Other Parts). Часто используемые детали вы можете добавить в избранное, для этого щёлкните по детали правой кнопкой мышки и выберите пункт меню «Add to Favorites». Позже избранные детали вы можете посмотреть в группе «Favorites».

3. Здесь отображаются детали в группе, которую вы выбрали в списке деталей 2. Если вы щёлкаете по детали в области 2, то эта деталь будет нарисована слева сверху. Чтобы узнать название детали и имя файла детали наведите на неё мышкой и посмотрите на статус-бар внизу окна.

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

5, 6, 7 и 8. Здесь отображается ваша проектируемая модель под разными углами зрения. По умолчанию в области 5 модель отображается спереди (Front), в области 6 – слева (Left), в области 7 – сверху (Top), а в области 8 модель отображается в режиме 3D под любым углом. В каждой из этих областей можно поменять режим просмотра, можно сделать, чтобы аж все 4 показывали вашу модельку слева, если вам так хочется. Например, чтобы отобразить деталь снизу, щёлкните по нужной области правой кнопкой мышки и выберите пункт меню «View Angle -> Bottom».

В режимах, в которых вы смотрите на модель вдоль осей (Top, Bottom, Left, Right, Front, Back), вы можете редактировать вашу модель. Назовём их режимами редактирования. А вот в режиме 3D вы можете только смотреть на модель под разными углами. Здесь угол просмотра меняется с помощью левой кнопки мышки.

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

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

Активная область обведена красной линией. Именно для неё будет действовать изменение масштаба колёсиком мышки.

Создание модели в программе MLCad

Создание модели в программе MLCad сводится к тому, что вы постепенно собираете вашу модель из стандартных деталей конструктора. Каждую деталь вы ищите в списке деталей и перетаскиваете в любую область редактирования (5, 6, 7 или 8). После этого деталь нужно подкрасить нужным цветом (см. панель Colorbar), повернуть на нужный угол и подровнять.

Выделить несколько деталей, можно щелчком по ним удерживая клавишу Ctrl. Снять выделение можно щёлкнув по пустому пространству.

Детали можно группировать и разгруппировывать (см. пункты меню «Edit -> Group -> Group…» и «Edit -> Group -> Ungroup»). С группой вы сможете работать как с одной деталью. При группировке нужно будет задать имя группы.

Передвигать детали можно мышкой или с помощью панели Transformationbar, с помощью кнопок передвижения вдоль осей координат. С помощью аналогичных кнопок этой же панели можно крутить детали вдоль осей. Все передвижения и повороты производятся с определённым шагом. Для быстрой смены шага есть три предустановленных режима: Coarse (грубый и самый большой шаг), Medium (средний шаг) и Fine (самый мелкий и точный шаг). Все три режима включаются в меню «Settings -> Grid -> …», клавишами F9, F10, F11 или кнопками на панельке «Modebar».

Настроить шаг под себя можно в диалоге настроек программы «MLCad Settings» на закладке «Step, Grid, Snap» (меню «Settings -> General -> Change…»). Здесь можно указать не только целое число, но и дробное, см. картинку.

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

Добавляются шаги в области 4 с помощью контекстного меню (пункты меню «Add -> Step» или «Add -> Rotation Step…»), см. картинку.

После выбора пункта меню «Add -> Rotation Step…» вам ещё нужно будет выбрать угол зрения (см. картинку с диалогом «Rotation Step Angle»), под которым вы будете видеть модель в инструкции на текущем и всех последующих шагах, пока не измените этот угол с помощью следующего шага с поворотом. Обратите внимание, что мышкой меняются углы по осям X и Y, а мышкой с нажатой клавишей Shift – по осям X и Z. Здесь вы можете выбрать абсолютный угол (Absolute), угол относительно угла заданного по умолчанию (Relative) или угол относительно текущего угла (Additive). Угол по умолчанию вы можете посмотреть или изменить в настройках, вызвав пункт меню «Settings -> General -> Change» и открыв закладку «Document» — поля «Default 3D rotation angles». Режим «Additive» у меня отказался работать, поэтому я ничего не могу о нём сказать.

Чтобы проверить, как будут выглядеть шаги в будущей инструкции можно сохранить их в виде картинок. И хотя программа MLCad делает это непрезентабельно, но для оценки, правильно ли вы всё делаете, это подходит. Выберите пункт меню «File -> Save Image(s)…», затем в диалоге «Save Image(s) Options» выберите размер картинки, тип файла, выберите опцию «Image for each step» (Картинка для каждого шага) и нажмите «Save…». После этого программа спросит, в какую папку сохранить картинки, сохранит каждый шаг в отдельный файл и создаст ещё один файл с финальным видом. На каждом шаге добавляемые детали будут подсвечены чуть ярче остальных.

В моём примере получилось 3 картинки (2 шага и финиш):

Ещё один полезный режим, о котором нельзя не упомянуть, это режим «отрисовки до выделения», т.е. отрисовки только тех деталей, которые находятся в проекте до выделенной детали. Представьте себе ситуацию, когда вы строите большую модель, и часть деталей оказываются внутри и их не видно. Включив этот режим, вы находите нужную деталь, находящуюся внутри вашей конструкции в области 4, щёлкаете по ней и все детали, добавленные в проект позже становятся невидимыми. Так вы сможете беспрепятственно передвинуть эту деталь, поменять её цвет и т.п. Включение и выключение этого режима делается с помощью пункта меню «Settings -> Draw To Selection».

Использование стрелок и буфера обмена

Иногда на схеме нужно что-нибудь показать стрелками. Для добавления стрелок воспользуйтесь генератором стрелок, это пункт меню «Extras -> Generators -> Arrow…». После вызова этого пункта меню перед вами появится диалог настройки внешнего вида стрелки «Arrow Generator».

Здесь вы можете выбрать цвет, длину и форму стрелки. Можно сделать её закруглённой или прямой или оставить только указатель. После того как вы сделали стрелку можно нажать на кнопку «OK» и стрелка появится рядом с вашей моделью. Стрелка будет плоской, поэтому нужно будет повернуть её так, чтобы смотреть на неё перпендикулярно. Вы всегда сможете отредактировать стрелку позже, щёлкнув по ней правой кнопкой мышки и выбрав в контекстном меню пункт «Modify…».

При добавлении стрелок сразу возникает вопрос, как убрать её на последующих шагах. Ведь стрелкой нужно показать что-то на одном шаге, а затем её не должно быть видно. Решается это с помощью специального буфера обмена следующим образом. Перед добавлением стрелки нужно скопировать модель в буфер. Для этого щёлкните по строке правой кнопкой мышки и выберите пункт контекстного меню «Add -> Buffer Exchange…».

Далее в диалоге «Buffer Exchange» нажмите «OK» (здесь можно выбрать один из много численных буферов, но мы в примере оставим буфер A).

Теперь после стрелки добавьте шаг (пункт контекстного меню «Add -> Step»).

И после добавленного шага нужно прочитать сохранённую модель из буфера. Для этого щёлкните по добавленному шагу правой кнопкой мышки и опять выберите пункт контекстного меню «Add -> Buffer Exchange…». Только теперь в диалоге «Buffer Exchange» установите галочку «Retrieve» (Вернуть). Нажмите «OK».

Получилась последовательность, показанная на рисунке ниже. Работает это так: Первые две детали попадают в шаг 1, затем, на следующем шаге с поворотом добавляется третья деталь, далее результат сохраняется в буфер A (заметьте, что стрелки ещё нет, поэтому модель сохранится в буфер без стрелки), затем добавляется стрелка (три детали и стрелка попадут в шаг 2), а уже на следующем шаге мы считываем то, что сохранили из буфера A, т.е. нашу модель без стрелки.

Зеркалирование деталей

Очень часто в моделях нужно сделать правую часть, а затем, зеркально – левую. Отобразить несколько деталей с сохранением всех шагов можно очень легко. Для этого выделите все зеркалируемые детали (можно в области 4), затем щёлкните по ним правой кнопкой мышки в области редактирования и в контекстном меню выберите «Enter Pos. + Rot…».

Дальше в диалоге «Position & Orientation» уберите галочку «Use position values» и установите галочку «Use rotation matrix values» (использовать значения матрицы вращения). Матрица будет выглядеть так: «1 0 0 0 1 0 0 0 1». Теперь, чтобы зеркалировать детали по оси X замените первую 1 на -1 (см. картинку). Вторую единицу замените на -1 для зеркалирования по оси Y и третью – для зеркалирования по оси Z. После этого нажмите «OK».

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

Добавление подпроектов

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

Делается это следующим образом. Допустим, у вас уже есть основной проект (с туловищем робота) и подпроект (с головой робота). Чтобы на каком-то шаге добавить голову в проект, щёлкните правой кнопкой мышки по нужному месту в области 4 и из контекстного меню выберите пункт «Add -> Part…».

В появившемся диалоге поставьте галку «Custom Part» и выберите файл вставляемого подпроекта, щёлкнув по кнопке «Browse…». Щёлкните по кнопке «OK».

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

Замена детали

Заменить одну деталь на другую с сохранением координат, угла поворота и цвета в программе MLCad очень просто. Щёлкните по нужной детали правой кнопкой мышки и выберите пункт контекстного меню «Modify…». В поднявшемся диалоге «Select Part» выберите новую деталь и нажмите «OK».

Подключение проводов с помощью LSynch

Специальных инструментов для рисования проводов в программе MLCad нет и сделать это не так просто, как в других редакторах, например, LDCad или SR 3D Builder. Поэтому я приведу здесь короткую шпаргалку, как это сделать, и пример.

Вот план действий для создания провода:

1. Установка вилок RJ12 в розетки (полное название детали в каталоге «Electric Mindstorms NXT RJ12 Style Plug w/ Cable End (Complete)»);
2. Добавление команды LSynch PLI_ELECTRIC_NXT_CABLE_20CM;
3. Прокладка пути, по которому пойдёт провод, с помощью расстановки ограничителей (полное название ограничителя в каталоге «LSynth Constraint Part – Type 5 – «NXT Cable»»);
4. Выполнение программы LSynch.

Теперь посмотрим на примере как это сделать. Создадим новый проект и добавим в него двигатель, модуль EV3 и простой шаг.

Теперь добавим вилки RJ12 (в примере я сделал вилки белыми (White, номер цвета 15), но вы можете сделать их прозрачными, например, выставив им цвет Glitter_Trans_Clear, номер цвета — 117).

Теперь добавляем команду LSynch PLI_ELECTRIC_NXT_CABLE_20CM с помощью пункта меню «Extras -> LSynth -> Add Command…». Найдите команду PLI_ELECTRIC_NXT_CABLE_20CM (можно выбрать команду PLI_ELECTRIC_NXT_CABLE_35CM или PLI_ELECTRIC_NXT_CABLE_50CM, нам это абсолютно неважно) в диалоге «Add Synth Command».

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

Теперь расставляем ограничители NXT кабеля (NXT или EV3 – неважно, провода одинаковые). Автор программы LSynch рекомендует подкрасить ограничитель начала провода в зелёный цвет, ограничитель конца провода – в красный цвет, остальные ограничители — в любые другие цвета. Мы так и сделаем. Проследите также, чтобы ограничители стояли между комментариями SYNTH SHOW и SYNTH END. И учтите, что провод пойдёт через них в том же порядке, в котором они стоят в области 4.

Когда ограничители расставлены, обязательно сохраните проект (после запуска программы LSynth отмена работать не будет) и запустите программу LSynth, вызвав пункт меню «Extras -> LSynth -> Run LSynth». После того как программа отработает у вас появится провод.

Теперь давайте разберёмся, что сделала программа LSynth, см. область 4. Ограничители стали невидимыми, добавились комментарии, в том числе комментарии «SYNTH SYNTHESIZED BEGIN» и «SYNTH SYNTHESIZED END», между которыми теперь стоит большое количество деталей «~LSynth Electric Mindstorms NXT Cable Segment», из которых, собственно, провод и состоит.

Я рекомендую вам сразу покрасить все детали, из которых состоит провод, в чёрный цвет (хоть провод и выглядит чёрным в программе MLCad, в программе LPub он будет белым!). Все одинаковые детали можно выбрать следующим образом: выделите одну из деталей, из которых состоит провод, и вызовите пункт меню «Edit -> Select -> Same Type».

Если вам не понравилось, как вы проложили провод, вы можете удалить все появившиеся детали «~LSynth Electric Mindstorms NXT Cable Segment» вместе с комментариями «SYNTH SYNTHESIZED BEGIN» и «SYNTH SYNTHESIZED END», сделать ограничители опять видимымы (пункт контекстного меню «Visibility -> Unhide»), подвигать, покрутить их, добавить новые и запустить программу LSynth ещё раз. И так, пока не добьётесь нужного результата.

Итог использования программ MLCad и LSynth

На этом мы заканчиваем знакомство с программами MLCad и LSynth. Приведённых здесь рецептов, думаю, хватит для создания моделей любой сложности. В следующей статье мы рассмотрим, как сделать полноценную инструкцию в стиле LEGO с помощью программы LPub. Все вопросы по программам MLCad и LSynth можете оставлять в комментариях к этой статье.

Из современного конструктора LEGO можно собрать только одну модель игрушки, например, самолет. Кастомизировать? Можете поменять местами кресла пилотов — вот и вся кастомизация. Лет 30 назад из конструктора можно было собрать примерно все, от самолета до грузовика, при том же количестве деталей как и в современных. Создатели большинства современных методологий в детстве играли в старое Лего. Те, кто сейчас пользуется методологиями — играли уже в современный. Разница в инженерных практиках огромна.

Под катом Филипп Дельгядо (dph) расскажет об инженерном подходе к формированию методологии. Все проекты и команды разные, а лидеры — неповторимы. Подогнать одну методологию под всех не получится — таких просто нет. Придется брать конструктор и строить из него что-то свое, уникальное. В расшифровке одного из лучших докладов TeamLead Conf не будет секретных тайн шаолиньских монахов — только банальности, проверенные опытом. Нас ждет каталог деталей методологии разработки, на что обращать внимание при ее конструировании и внедрении, правила перестраивания методологий. Для всех идей приведены реальные примеры из опыта Филиппа. За свою карьеру он попробовал все — от Visual Basic до хардкорного SQL, разрабатывал крупнейший в России букмекерский движок и Яндекс.Деньги, а сейчас работает над нагруженными проектами на Java. Регулярно делает доклады на разных конференциях, в том числе и на HighLoad++.

Задача

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

Кент Бек в конце своей книги по SCRUM написал:

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

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

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

Разные страхи приводят к разным методологиям. Страх переплатить ведет к найму дешевых разработчиков, которых просто менять — это SCRUM. Страх ошибки приводит к ГОСТам или RUP с кучей формализованных документов.

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

Кроме страхов, у бизнеса есть и пожелания, под какие цели оптимизировать процессы:

• быстро;
• дешево;
• предсказуемо;
• контролируемо;
• качественно;
• масштабируемо;
• хайпово.

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

Обычно бизнес хочет все и сразу. Когда собираете требования — придерживайтесь пресуппозиции «пациент всегда врет». Когда бизнес хочет все, он врет. Попытайтесь понять, что бизнес действительно хочет и попытайтесь ему это продать. Это не самый стандартный для тимлида набор умений. Но если вы не умеете выяснять реальные требования бизнеса, то необходимо найти человека, который умеет.

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

• Жесткие сроки. В моем случае не было жесткого дедлайна, например, олимпиады, когда есть только два варианта: либо успеть, либо нет.
• Строгий контракт. Если вы работаете с госкомпанией, то договор — это то, что нельзя нарушать. Все остальное можно делать, как угодно. Это очень сильно влияет на методику.
• Регулярные отгрузки. Нужно постоянно выкатывать новые фичи, это принципиально для бизнеса.
• Сертификация: ЦБ, PCI DSS. Это основное ограничение проекта платежной системы. Самые большие риски и опасения связаны с сертификацией ЦБ, PCI DSS и другими.

Именно существенные ограничения отличают, например, процессы FixPrice от процессов Time&Material.

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

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

Строим методику для старта проекта

Но что такое методика? Что вообще мы хотим построить? Ответ на вопросы — прекрасная картинка Алистера Коуберна с кучей пунктов.

Из этой картинки в первую очередь нам важны три вещи: люди — те, кто делает; процессы — как делают; и артефакты — что должно быть сделано. Людей и процессов у нас пока нет, так что разберемся, какие нам нужны артефакты.

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

Выбираем артефакты

Берем страхи и разбираемся, какие артефакты какие страхи закрывают.

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

Формируем процессы

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

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

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

Отступление: о найме

При найме обычно смотрят на стандартные описания должностей и привычные градации уровней кандидатов, рисуя примерно такую карту ролей в команде:

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

Troubleshooter. Это человек, который может нырнуть в legacy-код с каким-то багом без документации и тестов на 2 дня, и вынырнуть с фразой: «В этой строчке замените + на –, и все заработает».

И оно заработает. Такие люди как четырёхлистный клевер — встречаются редко. К сожалению, рынок не ценит таких людей, сложно объяснить бизнесу, что troubleshooter критически нужен и достоит уважения и большой зарплаты. В результате большая часть из них уходит в тимлиды, и этот ресурс исчерпывается. Остается только пропагандировать полезность таких специалистов, и, возможно, через некоторое время ситуация изменится.

Integrator. Это человек, который умеет из нескольких разных компонент, библиотек, модулей создать что-то цельное. Это уже не программист на XML, а тот, кто понимает внутреннее устройство. Это крайне редкий навык, который обычно очень востребован в реальной разработке.

Guru: Framework, Security, Database, DevOps. Про гуру все понятно — это люди, к которым можно обратиться с вопросами на соответствующие темы.

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

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

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

Чем выше уровень кандидата, тем короче собеседование.

Какие еще нужны люди?

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

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

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

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

Вернемся к нашему проекту. Troubleshooter нам не нужен, потому что legacy еще нет. Нужны были Integrator и набор гуру. Security Guru фактически вырастили внутри.

Database Guru удачно нашли на аутсорсе. Идея «брать компетенцию по БД где-то снаружи» мне очень нравится — найти в штат такого человека обычно нереально, если у вас не огромная компания, а для поддержки важной базы данных 24*7 требуется минимум 5 человек. DevOps Guru мы тоже сначала взяли на аутсорс, но не столь удачно, эта роль сложнее выносится на внешних исполнителей.

Социальные роли тоже удалось заполнить (а критиков было даже несколько).

Практики

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

• Планируем крупными мазками. У нас нет постановок, поэтому невозможно планировать точнее. Есть необходимость сделать личный кабинет за три месяца — и все. Планы ведем в Confluence.
• Каждый немножко аналитик. Нет нормальных постановок и компетенцию по предметной области держат люди, которые не умеют писать постановки. Их никто не научил, надо с них эту информацию снимать. Зато у нас есть «экстраверты».
• Трекер не нужен. У нас на проект всего 20 крупных задач — зачем заводить трекер.
• Одна ветка в VCS. На начальном этапе сложная работа с контролем версий не потребуется.
• Процессы приблизительные. Людей еще мало, коммуникаций и проблем нет, да и сам проект зыбкий. Не нужно ничего подробно описывать.

Когда рассказывают про подобные не слишком формализованные методики, то часто говорят просто: «У нас аджайл».

У нас тоже получился классический «У нас аджайл». Но я четко понимал, почему именно такая методика и почему это именно «agile», а не что-то более конкретное и сложное. И меня (и бизнес) эта методика вполне устраивала.

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

Отступление: Матрица Коуберна

В 1980 году Алистер Коуберн нарисовал матрицу сложности проекта.

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

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

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

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

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

Команда у нас около 20 человек, так что попадаем в квадрат Е30. Это плохо, потому что хорошим примером методики в этом квадрате будет полноценный Rational Unified Process — формальные процессы, много документов, четкие постановки. С этим не справиться силами 20-30 человек. Придется нанимать 50, и сложность будет расти как снежный ком. Подобные системы в таких методологиях обычно писали сотни и больше людей.

Что делать? Беда? Нет, не весь проект одинаково критичен. У нас есть только несколько критичных частей.

• Проверка на отмывание денег — за что Центробанк сильно бьет по голове.
• Работа с банковскими картами — за что мировые платежные системы сильно бьют по голове.
• Хранение персональных данных — за это государство сильно бьет по голове.

Давайте выделим отдельные критичные модули. Пропишем для них специальные практики работы именно с этими частями нашего проекта: полноценный PCI DSS Audit на каждый commit, хорошее документирование, двойной Code Review, специальный процесс выкладки и еще куча всего. Пусть эти части проекта пишут только senior developers.

Но таких частей мало. Поэтому матрица Коуберна для проекта получается такая.

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

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

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

Подытожим

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

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

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

Практики первой стадии проекта

Немножко практик, чтобы отвлечься от теории на реальность.

Право на «Зачем?»

Это моя любимая практика.

Каждый сотрудник имеет право спросить про любую задачу: зачем ее делать, зачем делать именно так и кому она вообще нужна?

Люди бояться спрашивать «зачем» — возможно, потому что в детстве на такие вопросы все равно не отвечали. Если у вас где-то явно записано и много раз повторено «можно и нужно», люди это делают. Как только начинаете спрашивать «зачем» на всех уровнях, включая бизнес, в разы уменьшается объем задач и так же увеличивается мотивация. Люди понимают смысл работы и выполняют ее быстрее и экономнее, срезая углы.

До трех не обобщать

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

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

IDE Driven Development

JetBrains всемогущий дал нам в руки хороший инструмент — давайте его использовать на полную! Реализуйте то, что легко сделать и проверить в IDE.

Не используйте вообще то, что не поддерживается в IDE.

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

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

Простейшее использование IDE — вместо длинного стандарта оформления кода написать набор настроек и утвердить его как стандарт кодирования.

Пятничный тортик

В новой команде, в которой люди еще не очень знакомы, проводить классические ретроспективы по скрамовским образцам не получается. Люди не понимают зачем это. Человек думает: «Зачем я вообще пришел в эту компанию и что я тут делаю?» Проще в пятницу купить за свои деньги тортик и попить чай, параллельно незаметно выясняя проблемы в проекте. Люди охотнее открываются, когда их кормят чем-то сладеньким вечером и неофициально. Можно пиво, но это уж зависит от компании и команды.

Через 3–4 месяца можно переходить от тортиков к нормальным ретроспективам и рефлексии. Но начинать с практики пятничного тортика удобнее.

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

Запуск

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

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

Много неожиданных требований — наши планы столкнулись с реальностью.

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

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

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

Новые страхи

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

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

• Нормальный трекер. У нас бывают баги, и если до этого трекер был не нужен, то теперь необходим.
• Ручное тестирование. Мы не успеваем все покрыть автотестами, и есть вещи, которые сложно покрыть автотестами, например, изменение цвета кнопочки под чей-то корпоративный стиль.
• Командная работа. До этого можно было пилить 3 месяца свою большую мега-фичу, а потом аккуратно смержиться, и все это были отдельные интерфейсы, отдельные сервисы, поэтому проблем не было. Сейчас если упал продакшн, его поднимают все.
• Мотивация. В этот момент люди точно будут перерабатывать, иногда выходить в выходные. Чтобы просить людей разбираться с багами ночью в выходные, их надо как-то мотивировать — хотя бы премией или тройной оплатой переработок.

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

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

Практики стадии запуска

Нам особенно пригодилось две практики.

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

Чек-лист позволяет не думать.

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

Дежурства. Это не формальные дежурства типа «я сижу и жду, когда сервер упадет», а понимание планов людей в команде. Если выясняется, что половина команды в пятницу 1 сентября идет на линейку к своим детям и берет на это время отгул — мы заранее узнаем, кто из команды может при этом все-таки быть рядом с компьютером. Если человека попросить заранее изменить планы, он может их изменить. Если у вас shit happens прямо сейчас, а сотрудник при этом в театре — он будет недоволен, если его оторвут. Если его попросить перенести поход в театр на неделю, он, скорее всего, согласится, особенно если это компенсировать.

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

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

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

Еще новый страх — сделать неподдерживаемое. Теперь команда растет, «старые» люди уже не так важны, нужно как-то повышать bus factor — мы же нормальный бизнес, все должно быть серьезно.

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

Получается куча новых процессов. Краткосрочные планы и регулярные выкладки, потому что нужно предсказуемо. Документация, потому что масштабируемо, чтобы новые люди могли быстрее обучаться и встраиваться. Нормальные постановки, по которым легко пилить не очень дорогим разработчикам, и регулярные показы, потому что страшно сделать лишнее. Style guides и code review нужны не для того, чтобы разработчики не сделали чего-нибудь тотально плохого, а чтобы проще поддерживать код.

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

Выбор практик

Рассмотрим Planning poker. Это хорошая практика для создания артефакта «краткосрочный план» — давайте ее использовать. Но сначала разберёмся, что нужно, чтобы эта практика работала. Planning poker хорошо работает при условиях отсортированного и качественного бэклога, коротких задач и команды универсалов.

Это нормальные условия для внедрения практики. Бывают и другие условия внедрения практик:

• единый офис;
• product owner под рукой;
• фиксированные планы;
• редкие обновления.

Хорошо, у нас есть нормальный бэклог, короткие задачи, все универсалы — но зачем тогда отвлекать всю команду на планирование? Можно поручить планирование тимлиду, он раскидает все задачи за 2 часа и сэкономит 10% от общей производительности команды. Зачем нам так много тратить времени?

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

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

Если бы у программистов был профсоюз, то Agile, SCRUM и XP запретили бы.

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

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

Картина мира

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

— Мне все просто, и вообще я не хочу заниматься этой вашей ерундой, дайте мне программировать!

В этом случае Planning poker работать не будет. Он работает только если каждому разработчику важно мнение команды о нем. Эта практика эффективна только в такой картине мира.

В разных методиках можно найти следы разных картин мира их создателей:

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

Отслеживайте картины мира в используемых вами практиках.

Есть простой критерий: если вы не можете вычленить картину мира, значит, вы с ней согласны.

Практики развитой системы

Насколько часто у вас в Jira программисты пишут время, которое потратили на задачи «от балды» в конце недели? Насколько часто они регулярно неправильно заполняют какую-нибудь хитрую заявку на что-нибудь? Насколько часто забывают ответить на письма в переписке?

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

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

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

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

Как менять методику и не убить проект

Итак, за 9 месяцев мы поменяли 3 методики: «У нас Agile», однодневный SCRUM и Kanban. Как сделать так, чтобы при этом не терять ресурсы? Как вообще менять методику, и не убить при этом проект в ноль?

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

Главное — понять, когда менять.

Если вы понимаете «зачем». Часто методики меняют, потому что пришел новый технический директор, которому хочется все переделать. Это плохой повод. Лучше возьмите старую и переименуйте — все, методика другая, стало лучше. Если не можете ответить на вопрос зачем, лучше не меняйте. Я вообще люблю спрашивать зачем.

Если продумали «как». Если понимаете, как будете приходить из точки А в точку В, то меняйте. Пока не придумали — не надо.

Если устраивает «почём». Смена методики — почти всегда дорогая процедура. Если делать хорошо, замена обойдется в несколько человеко-месяцев затрат тимлидов, HR, настраивателей Jira. Если плохо — несколько месяцев работы всей компании. Я часто видел переход с Kanban на SCRUM, потом обратно, каждый из которых стоил месяц работы всей разработки. Если не готовы к таким затратам — не начинайте.

Подготовка

Начинаем заранее. Для маленькой команды подготовка начинается за месяц до cмены.

Рисуем User Stories. Такой же подход, что и в проектировании приложений. Вы же пользуетесь User Stories при описании требований, надеюсь?

Например:

• User Story: как разработчик я хочу найти свою следующую задачу и приступить к ее реализации.
• Acceptance Criteria: как разработчик я могу посмотреть все мои актуальные задачи и оценить срочность и приоритет задач.
• Exceptions: если задач нет, то разработчик знает, кого спросить.
• Links: сценарии подготовки краткосрочного плана, в которых видно где брать следующую задачу.

Таким способом проходите по всем вашим основным деятельностям, возникающим внутри вашей методики, и пишете User Stories.

Как менеджеру посмотреть эффективность работы по плану? Как топ-менеджер поймет, что все хорошо? Пишете User Stories, потом дополняете конкретикой: сделали dashboard для пользователей и для топ-менеджеров — Acceptance Criteria проходит, все замечательно.

Когда уже есть User Stories, можете начать превращать их в практики.

Замените все роли на реальных людей. Реальный человек всегда умеет больше, чем роль. Тогда вы сразу найдете узкое место. Например, все ваши User Stories используют одного конкретного человека, хотя он просто в разных шапках, в разных ролях. Это плохо — придумайте, как его разгружать.

Уменьшайте количество артефактов и коммуникаций. Если их слишком много — каждая User Story предполагает свои артефакты и коммуникации — надо с этим что-то делать.

Ищите узкие места. Когда есть такая карта историй, можно начать с ней что-то делать.

Выбираем инструменты

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

Если инструментом неудобно пользоваться — пользоваться им не будут.

Больше того, вендоры всегда врут. Если они говорят, что их инструмент умеет делать «1, 2 и 3», то, скорее всего, «1» он делать не умеет, «2» — иногда, а «3» делает, но очень плохо. Все обязательно проверяйте.

Активно обсуждаем

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

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

— А, ерунда! У нас уже было такое и ничего не вышло.

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

Не повторяйте негативный опыт. Ретроспектива не пошла? Теперь это «пятничный тортик». Стендапы в 7 утра не пошли? Теперь это «зарядка». Давать разные названия одним и тем же практикам, чтобы люди не ассоциировали с ними свой прошлый негативный опыт, часто помогает.

К сожалению, нет универсальных решений. Отталкивайтесь от своей ситуации.

Внедрение

Главная ценность в управлении IT — уважение.

Бережем чужое время. Если нужно переносить задачи с одной системы трекеров в другую — напишите скрипт, наймите Mechanical Turk, чтобы он это сделал за вас. Решите эту проблему, чтобы не разработчик переносил неделю все свои таски с одной системы в другую — это проявление уважения.

Помогаем при переходе. Если внедряем новую практику — сидим рядом с человеком и помогаем ему разобраться в новой системе. Готовим инструкции заранее.

Описываем конкретные действия. Делаем очень конкретную документацию, как раз по нашим User Stories: «Нужно взять в работу новую задачу. Как это сделать написано в документации — открываешь такую-то страничку в вики, в ней читаешь то-то и то-то».
Внедряем постепенно — не все практики сразу. Наши разработчики не заметили смены методик, потому что мы внедряли не все практики одновременно. Когда мы хотели плавно перейти от однодневного SCRUM к чему-то другому, я проводил ретроспективы не каждый день, задачки появлялись чуть дольше, потихонечку мигрировал ежедневные утренние встречи в более стандартный стендап. Людям казалось, что все идет постепенно. Потом практика как раз изменилась достаточно существенно. Про какие-то вещи, конечно, я им рассказывал: «Теперь у нас чуть-чуть изменится процесс работы с Jira — он будет теперь такой».

Тропинки протаптываются сами. Не прописывайте сразу жесткий workflow — пусть люди сами найдут тропинки. Как им удобно переводить задачу в трекере из состояния в состояние, пусть так и переводят, а потом уже вы это зафиксируете. Сразу предугадать, что будет удобно — сложно, а запретить востребованный переход — легко. Но потом придется долго мучиться, чтобы все вернуть обратно.

KISS. Сделайте все просто, хотя бы в начале. Не переусложняйте.

Поддерживаем

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

Заключение

Проекты бывают разные, люди тоже — всем нужны совершенно разные методики! Все счастливые семьи счастливы одинаково, все несчастные — по-своему. Так же и с проектами — двух одинаковых не бывает.

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

Смена методики — это классический SMART-проект. Используйте все, что вы знаете про управление проектами: определяйте критерии успешности, проверяйте в конце соответствие поставленным задачам, помните о ограниченности во времени и т.п.

Мой личный манифест

Люди важнее процессов, потому что процессы приходится делать под людей. Если в компании средний возраст сотрудников 50 лет, и они пришли из военки, а вы пытаетесь сразу быстро внедрить Kanban — скорее всего не взлетит. Люди просто привыкли к другому.

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

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

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

А иногда вообще задачи настолько многообразны, что привычки становятся опасны. Например при общении с живыми людьми.

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

Все три принципа — моя личная картина мира. Если у вас другие пресуппозиции, наверное, вам нужна другая методика построения методик.

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

Вчера я закончил собирать в LDD модель, состоящую из 2500 деталей.
Остро встал вопрос: как же теперь это всё собрать из реальных деталей? Как облегчить процесс сборки?
Как известно, встроенный в LDD генератор инструкций, работает очень коряво.
И пользоваться им при большой и сложной модели просто нет смысла: даже если модель построена «правильно» (т.е. все соединения можно собрать последовательно), всё равно начнёт вставлять детали сквозь друг друга.
И тут меня осенило! Есть способ, с помощью которого можно создать инструкцию по сборке моделей technic ЛЮБОЙ сложности и с любым количеством деталей.
Необходимо просто последовательно РАЗОБРАТЬ всю модель так, как вы делали бы это с реальным конструктором. Процесс разборки запишите на видео.
После этого надо развернуть видео задом-наперёд и у вас будет последовательная инструкция сборки модели деталь за деталью.
Несколько советов при разборке и записи:

1. Достаточно установить 15 кадров в секунду.
2. Выбирайте удобный ракурс перед удалением детали.
3. Задерживайте курсор над удаляемой деталью около секунды, потом выделяйте её, а ещё через секунду — удаляйте.
Практика показала, что двух секунд достаточно, что-бы на видео было понятно какая деталь куда вставляется.
4. Если при разборке вы дошли до момента, когда невозможно нормально удалить деталь, проверьте ориентацию синих пинов на 3. Иногда достаточно развернуть пин нужной стороной и деталь можно вытащить.
5. Если манипуляции из пункта 4 не помогли, проверьте — может можно отсоединить сразу группу деталей (модуль), а потом разбирать уже его.
6. Если же и пятый пункт не помог — поздравляю, вы создали «невозможную» конструкцию. Проверяйте и изменяйте расположение деталей.

Удачной постройки всем.

Главная проблема здесь в неуместности мэйнстрима(«mainstream»). Это щас мода такая — по-больше «комиксов» сделаешь — круче выглядишь. На самом деле разжовывая [и так] понятные процедуры, затеняются [теряются в ворохе других] толкования нетривиальных операций.

Помню в прошлом веке разглядывал инструкцию на пылесос — там был пылесос в разрезе, и всё его устройство было понятно. Сейчас считается, что разрез (и понимание как устройство работает) — лишнее. Типа «не ваше дело, блюдите последовательность сборки, обезьяны !». Но если исходить из принципа хорошего отношения к людям, а инструкцию делать для помощи сборщику, а не для «отмазки» — «всё показано, читай мануал !», то требуется нечто иное, чем инженерная подготовка и CAD-soft.

В своей практике придерживаюсь такого порядка:

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

2. Если сборку необходимо начинать с выверки положения какого-то компонента — изображаю выверку компонента (выделяю в чертеже всё, снимаю 1-2 выделения, гашу).

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

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

5. Если надо показать, как обвязать верёвкой, куда подсунуть домкарат, то надо делать (моделить) домкрат и верёвку.

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