?

Log in

Discreet · and · not · discrete.


Do you want to crack jokes about it or do you want me to go?

Recent Entries · Archive · Friends · Profile

* * *
В PSP/TSP время работы над задачей подлежит учёту. Буквально, сел работать - запускаешь секундомер, идёшь курить - останавливаешь. В результате можно точно учесть время работы. По словам работавших в таком режиме, 4 часа работы над задачами в день растягиваются на восемь часов и ощущаются, как полные восемь часов. Растягиваются они так потому, что есть деятельности, имеющие более высокий приоритет, чем выполнение задачи. Например, написание и проверка документации, включая ТЗ - документация затрагивает большее количество людей, чем написание кода.

В обычной компании никто так не делает. Поэтому когда вы в обычной компании сидите 8 часов в день на стуле перед монитором, то вы пишите те самые 20-25 строк в час, примерно 4 часа в день, выдавая 80-100 строк отлаженного кода в день, в среднем (с плотностью N ошибок на 1000 строк, N, обычно, 3-5). Если вы пишите больше, то у вас плотность ошибок выше.

Особенно так не делают в игровых компаниях. Растянуть 8 часов в 10-12 это самое милое дело.

В комментариях к предыдущей записи я описал эксперимент, в котором план был составлен из расчёта 5 часов работы над задачами в день. В переводе на обычный язык, это 10 рабочих часов в день надо высидеть, 50 часов в неделю. Результаты эксперимента предсказуемы - проект был сдан в срок, который получался при планировании 4 часов работы в день (после исправления недоработок), это раз, а во-вторых, разработчикам пришлось неоднократно выходить в выходные, добивая время до тех самых 50 часов в неделю в среднем.

Почему так получается? В обычной разработке используется воронка фильтров - компилятор ловит 10% ошибок, просмотр кода 10%, локальные тесты 10%, просмотр кода перед передачей на разбор коллегам ещё 10%, разбор коллегами 10%, функциональные тесты ещё 10%... 0,96=0,53, 47% ошибок выловлено до передачи на тестирование. Из этих шести шагов только два выполняются автоматически - компилирование и функциональные тесты. Всё остальное работа людей. И если люди устали, то их воронка расширяется и они уже ловят не 10%, а 5%, а то и меньше. 0,92×0,954=0,66, 34% ошибок отловлено уставшими людьми. Разница вроде бы небольшая, 13%, но это ошибки, попавшие к тестировщикам или пользователям, они выпали из узкого контекста небольшого изменения и для них надо проводить более масштабное исследование. Время для них увеличивается заметно - не на проценты, а в разы.

Вот и получается, что при запланированной переработке в 20% настоящая переработка будет полтора раза. Что говорить про игровую индустрию с переработкой в полтора раза просто по часам в день.
* * *
Я считаю, что общение в разработке ПО полностью аналогично трению - оно совершенно необходимо для движения и управления, однако должно быть уменьшено всеми возможными способами для уменьшения энергетических затрат. Дополню, что уменьшение трения от общения не должно сопровождаться (существенным) замедлением или (существенной) потерей управления.

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

Например, 15 минут standup meeting ежедневно приводят к потере полного восьмичасового рабочего дня одного человека для средней команды в шесть человек, а с учётом времени возврата внимания - два дня. Поскольку человек может работать над задачей всего 4 часа в сутки, то мы теряем, практически, неделю работы одного человека. И вместо команды из шести человек мы получаем команду в пять. Однако, управляемость здесь на высоте - заказчик может отказаться от команды в любой момент и потеряет всего 1 рабочий день оплаты, это основное. Дополнительными преимуществами является знание всех обо всём, над чем работают и знание о проблемах.

Что будет, если мы уменьшим частоту совещаний?

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

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

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

Примерно так в жизни и получается - баланс между расходами на общение (совещания) и самим трудом.

Теперь мне надо вернуться к ТЗ.

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

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

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

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

Способности к вовлечению внешних ограничений при рассмотрении решения задачи по ТЗ (или при составлении ТЗ) вполне себе тренируются. Как и многое другое, они тренируются пересмотром опыта.
* * *
* * *
Если вам дали задачу перед интервью, попросите ваших будущих интервьюеров решить задачу К: http://thesz.livejournal.com/280784.html

Ну, чтобы было интересней на возможном интервью. ;)

А то что это такое - вас изучают активными пробами, а вы играете пассивную роль "черного ящика".

* * *
На выходе на Царицыно приметил пару кавказцев - один из них долго на меня смотрел по какой-то причине.

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

У меня мораль только Байесовского-статистического плана получается.

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

Господа, но выдавать ошибку "file name too long" в 2016 году это не то, что моветон, это расстрельная статья.

* * *
* * *
Это ужасное днище.

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

* * *
(спустили $200, по-моему, такого плана)

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

Поскольку я довольно хорошо помню "таблицу ходов" блекджека и даже умею считать карты, то мы некоторое время были в прибыли - ажно до $120 дошло, со стартовых $100. И тут наш стол посетил охранник.

Было довольно забавно.

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

Охранник крякнул и пошёл дальше. ;)

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

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

Статистика про богатых и бедных на ТитаникеCollapse )
* * *
* * *

Previous