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

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

На высшую истину и полное раскрытие темы не претендуем, спорить ни с кем не собираемся, мы этот путь прошли. Хотите – тоже проходите.

Если согласны – под кат.

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

Подходы – это базовые принципы, применяя которые, можно найти решения. Применяя подходы, решения можно внедрить. Подходы + решения дают 4X.

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

Все, хватит ходить вокруг да около, все всё поняли, погнали к делу.

Главное, что надо сделать для ускорения 4X – создать изменяемую среду в своей команде. Сразу скажу – если у вас нет команды, вы один, то считайте командой себя. Часть принципов окажутся для вас неприменимыми, часть – наоборот, будут более эффективными.

Часто спрашивают – а если у нас удаленная команда? А это то, что надо. У нас тоже была и есть удаленная команда. Но мы иногда встречаемся. Классический скрам говорит, что встречаться надо каждый день, но у нас не классический скрам, а «немецкий». Ну, надо было как-то назвать наш fork.

Если вы с командой не встречаетесь, то считайте себя одиночкой+, т.к. некоторые методы командной работы для вас применимы – есть же скайп, например.

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

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

Наверное, любят потому, что сами занимаются созданием алгоритмов.

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

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

Важно, что в режиме отладки все понимают – это временно. Цель – как раз создать алгоритм, но работающий и проверенный, вместо никакого.

Это надо доходчиво и честно объяснить команде. Если вы пишете код, который, как вы точно знаете, не сможете отлаживать, то вы будете делать это очень долго и все равно наделаете ошибок. Если вам кажется надуманной ситуация «писать код, который нельзя отладить», то вы, наверное, очень молоды. В наше время мы такой код писали на экзаменах в институте – на бумаге, и только один раз.

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

В том, что они не программисты. А значит, они не понимают, что такое отладка и зачем она нужна. Они пишут снапшот – снимок реальности «как есть», который устаревает через минуту. И им, в общем-то, насрать, будет он работать или нет.

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

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

Ну да и хрен с ними, у нас своих дел полно.

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

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

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

Если скрам-мастер решил, что с этой минуты мы не отвечает на телефонные звонки – значит, мы не отвечаем на телефонные звонки. Никто, никому, никогда. Пока не поступит новая инструкция.

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

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

А в жизни, при отладке человеко-систем, так и происходит. Вас не пускают к отладке. Говорят – пиши код (правила, бизнес-процесс), присылай, мы почитаем, зададим вопросы, уточним, и т.д. И внешние, и внутренние люди говорят.

Ладно внешние – везде полно бюрократов. Но и внутренние сопротивляются.

Представьте, как изменится скорость отладки, если вы для теста объявляете в коде переменную, присваиваете ей значение, запускаете отладчик, доходите до этой строчки и видите, что значение не присвоилось. Почему? Открываете консоль, а там написано: «не удалось присвоить значение переменной qty1, потому что она не хочет».

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

Есть хороший пример, который демонстрирует такое поведение – фильм «Человек, который изменил все». Там буквально так и происходит. Инициатор изменений говорит человеку – с этого дня делай так. Тот гривой машет, уходит, и не делает. Раз не делает, два не делает, потом его выпинывают.

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

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

Всех с наступающим Новым Годом!