Billy от компании Agfa
Принтсервер
Волею судеб попал ко мне в дом принтер. Принтера у меня не водилось уже очень давно, со студенчества. А тут попал, хороший такой, лазерный принтер от компании HP. Отказываться от такого было грех, поэтому я его даже попросил, потому что мне его и не предлагали сначала.
Встал вопрос: куда же деть такое богатство? Нужно заметить, что компьютер у меня в доме один, да и тот ноутбук, не имеющий постоянного места дислокации. Таскаем его по квартире, как колхозник жену по огороду. Поэтому решил, что принтер должен стоять в кладовке, рядом с роутером и другим компьютерно-сетевым хламом. Поскольку принтер довольно старый, он подключается не по USB, как все нынешние девайсы, а по экзотическом и раритетном LPT. Пришлось покупать отдельную коробочку, принт-сервер D-Link DP-301P+. У меня довольно негативное отношение к продукции этой компании. Первый WiFi-роутер у меня был ДЛинковский и вызывает он только грустные воспоминания. Какое-то все китайско-недоделано-дешёвое. Хотя, чего же ждать за такие деньги.
Но я про принт-сервер... Наверное, выводы делать ещё рано, напечатав 5 страничек вряд ли можно судить о качестве. Настройка и подключение достаточно примитивные. Лично мне было бы удобнее, если бы в коробочке был не статический IP адрес, а она сразу бы получила его по DHCP. Повозился с кабельками минут 5, перенастроил сеть на ноуте и зашёл в веб-админку сервера, дабы поменять настройки. Настройки стандартные, что радует. Но вот что удивило, так это дополнительный функционал. Коробочка умеет сообщать о своём состоянии (вернее, о состоянии принтера) по электронной почте. Кончилась бумага? Лови е-мейл! Перегрузилось питание? Снова мыло! Такая маленькая, а спамит почти как Центр Американского английского. По этой же электронной почте она умеет что-то получать и распечатывать. Для эксперимента завёл ящик на Яндексе, прописал параметры доступа к нему внутри коробочки и получил возможность общаться со своим принтером по е-мейл. Да, видать совсем недолго осталось ждать и сбудется предсказание Б.Гейтса, настанет день, когда каждый холодильник будет иметь доступ в Сеть.
Встал вопрос: куда же деть такое богатство? Нужно заметить, что компьютер у меня в доме один, да и тот ноутбук, не имеющий постоянного места дислокации. Таскаем его по квартире, как колхозник жену по огороду. Поэтому решил, что принтер должен стоять в кладовке, рядом с роутером и другим компьютерно-сетевым хламом. Поскольку принтер довольно старый, он подключается не по USB, как все нынешние девайсы, а по экзотическом и раритетном LPT. Пришлось покупать отдельную коробочку, принт-сервер D-Link DP-301P+. У меня довольно негативное отношение к продукции этой компании. Первый WiFi-роутер у меня был ДЛинковский и вызывает он только грустные воспоминания. Какое-то все китайско-недоделано-дешёвое. Хотя, чего же ждать за такие деньги.
Но я про принт-сервер... Наверное, выводы делать ещё рано, напечатав 5 страничек вряд ли можно судить о качестве. Настройка и подключение достаточно примитивные. Лично мне было бы удобнее, если бы в коробочке был не статический IP адрес, а она сразу бы получила его по DHCP. Повозился с кабельками минут 5, перенастроил сеть на ноуте и зашёл в веб-админку сервера, дабы поменять настройки. Настройки стандартные, что радует. Но вот что удивило, так это дополнительный функционал. Коробочка умеет сообщать о своём состоянии (вернее, о состоянии принтера) по электронной почте. Кончилась бумага? Лови е-мейл! Перегрузилось питание? Снова мыло! Такая маленькая, а спамит почти как Центр Американского английского. По этой же электронной почте она умеет что-то получать и распечатывать. Для эксперимента завёл ящик на Яндексе, прописал параметры доступа к нему внутри коробочки и получил возможность общаться со своим принтером по е-мейл. Да, видать совсем недолго осталось ждать и сбудется предсказание Б.Гейтса, настанет день, когда каждый холодильник будет иметь доступ в Сеть.
Интересно про Холдена
Пусть наши и вылетели из Олимпийского турнира, но всё равно, Холден молодец! Уж точно его нельзя винить в случившемся. Баскетбол командная игра и очень обидно, что несмотря на усилия одного-двух игроков ничего хорошего не выходит.
Неприятная правда
Канал Fox News. Какая-то аналитическая программа, в которую позвали 12-летнюю девочку из Сан-Франциско, которая оказалась в Осетии во время начала войны. Девочка и её тётя обвиняют Саакашвили и грузинское правительство в развязывание войны и благодарят русских военных. Ведущий явно не ожидает такого поворота событий. Облажались редактора этой программы, не тех людей позвали в студию, надо было позвать кого-нибудь из грузинской диаспоры и они-то бы рассказали "всю правду про злых русских".
Информационная война, фигли.
Видео нашёл у Мио
Учусь раскручивать блоги
Наверное, я чуть попозже опишу "как всё было на самом деле" с запуском новой версии Хабрахабра. Сейчас немного не до этого, многое нужно ещё сделать из того, что лучше было сделать до запуска.
Всей компанией, естественно, отслеживали реакцию Рунета на нашу забаву с "хаком Хабра". Честно говоря, за прошедшие выходные это была практически единственное развлечение. Иногда, сворачивая консоль, нажимал Ф5 в окошке поиска по блогам от Яндекса и радовался каждому новому обсуждению. Потом появилась заметка о взломе Хабра от одного неизвестного мне блоггера. Даже обсуждение у него в блоге развернулось, как мне сначала показалось интересное. Люди высказывали предположения и строили гипотезы. Естественно, нашлись специалисты, которые с первого взгляда поняли, что всё это фейк и "шутка юмора". Честно говоря, это мы сами допустили такую промашку :) Когда писали код фейк_хабра в самом главном файле, "в начале всех начал", в index.php, допустили ошибку и написали строчку
$superhabr->index.php($params);
Конечно же, такое просто не будет работать в PHP из-за синтаксической ошибки. Да и не было у нас цели сделать что-то работающее! Мы хотели создать видимость исходного кода и мы её создали! Мы хотели распространить коды к Блогистану и они распространились! Мы хотели развлечь Хабрапользователей, ну, а получилось это у нас или нет, судить вам.
Но, не смотря на все эти ляпы, не смотря на то, что разные файлы имеют разные корни (один модуль из Друпала, другой - Джумла, третий - писаный на коленке), не смотря на всё это нашлись люди, убежденные в том, что мы прокололись и просто недосмотрели за сервером. Наверное, кому-то приятно видеть, как кто-то другой "облажался". Хочется верить, что это не розыгрыш, на который ты клюнул, а просто чужая криворукость, которую ты, молодчина, заметил.
Но, опять я отвлёкся. На том самом бложике, где развернулось обсуждение всего происходящего, автор упорно утверждает, что это была наша ошибка, приводит смехотворные, с технической точки зрения, доводы. Конечно, не все же должны понимать, как работает веб-сервер, суть не в этом. Суть в том, что хитрый блоггер развесил ссылки на свой блог всюду, где только мог. Он до сих пор продолжает упорствовать в своей неправоте, на все, с моей точки зрения, здравые комментарии он не реагирует и твердит одно и тоже: "Денискин и Ко облажались и пытаются скрыть свой позор за ширмой штуки" (не цитата). Я думаю, что делает он это только для того, что бы поддержать обсуждение, что бы люди продолжали с ним спорить, что бы размещали ссылки у себя в блогах: "Смотрите, в Сети кто-то неправ!" Чем больше ссылок, тем длиннее ТИЦ... Продолжаю следить за хитрым упрямцем, уверен, он подскажет и другие хитрые способы раскрутки.
Добавлю пару ссылок. Рассказ Игоря обо всём произошедшем. Денискин показал как включить режим бога на Хабрахабре.
Всей компанией, естественно, отслеживали реакцию Рунета на нашу забаву с "хаком Хабра". Честно говоря, за прошедшие выходные это была практически единственное развлечение. Иногда, сворачивая консоль, нажимал Ф5 в окошке поиска по блогам от Яндекса и радовался каждому новому обсуждению. Потом появилась заметка о взломе Хабра от одного неизвестного мне блоггера. Даже обсуждение у него в блоге развернулось, как мне сначала показалось интересное. Люди высказывали предположения и строили гипотезы. Естественно, нашлись специалисты, которые с первого взгляда поняли, что всё это фейк и "шутка юмора". Честно говоря, это мы сами допустили такую промашку :) Когда писали код фейк_хабра в самом главном файле, "в начале всех начал", в index.php, допустили ошибку и написали строчку
$superhabr->index.php($params);
Конечно же, такое просто не будет работать в PHP из-за синтаксической ошибки. Да и не было у нас цели сделать что-то работающее! Мы хотели создать видимость исходного кода и мы её создали! Мы хотели распространить коды к Блогистану и они распространились! Мы хотели развлечь Хабрапользователей, ну, а получилось это у нас или нет, судить вам.
Но, не смотря на все эти ляпы, не смотря на то, что разные файлы имеют разные корни (один модуль из Друпала, другой - Джумла, третий - писаный на коленке), не смотря на всё это нашлись люди, убежденные в том, что мы прокололись и просто недосмотрели за сервером. Наверное, кому-то приятно видеть, как кто-то другой "облажался". Хочется верить, что это не розыгрыш, на который ты клюнул, а просто чужая криворукость, которую ты, молодчина, заметил.
Но, опять я отвлёкся. На том самом бложике, где развернулось обсуждение всего происходящего, автор упорно утверждает, что это была наша ошибка, приводит смехотворные, с технической точки зрения, доводы. Конечно, не все же должны понимать, как работает веб-сервер, суть не в этом. Суть в том, что хитрый блоггер развесил ссылки на свой блог всюду, где только мог. Он до сих пор продолжает упорствовать в своей неправоте, на все, с моей точки зрения, здравые комментарии он не реагирует и твердит одно и тоже: "Денискин и Ко облажались и пытаются скрыть свой позор за ширмой штуки" (не цитата). Я думаю, что делает он это только для того, что бы поддержать обсуждение, что бы люди продолжали с ним спорить, что бы размещали ссылки у себя в блогах: "Смотрите, в Сети кто-то неправ!" Чем больше ссылок, тем длиннее ТИЦ... Продолжаю следить за хитрым упрямцем, уверен, он подскажет и другие хитрые способы раскрутки.
Добавлю пару ссылок. Рассказ Игоря обо всём произошедшем. Денискин показал как включить режим бога на Хабрахабре.
Scrum доска
Вот такой вот у нас scrum в конторе творится. Не устаю повторять, что вам стоит это попробовать!
Сигнал "Атомная тревога"
Хорошая, толковая инструкция. Как себя вести в случае атомной атаки со стороны США. В какое время дня это вероятнее всего произойдёт. Что и как будет происходить. Кто и что будет делать и что нужно делать, что бы спасти свою жизнь и жизнь своих близких.
Кстати, если в момент атаки я буду находиться на работе, то мучиться вообще не придется. Убежать за 15 минут достаточно далеко не получится, хотя, можно попробовать укрыться в метро. Но метро, скорее всего, будет завалено в пределах Кольцевой линии. Так что, будучи на работе в момент атаки шансов выжить у меня просто нет. За доли секунды перейду в плазменное состояние, благо Лубянка у меня в двух шагах от офиса, а эпицентр взрыва будет как раз в близлежащих районах. Так говорится в инструкции по ссылке. Ещё раз повторю, что инструкция хорошая, апокалипсическая, но хорошая. Явно не полная, возможно, фейковая, но познавательная в любом случае.
Wii Sports Resort
Следующая версия спортивных игр от Нинтендо для консоли Wii. Отличается тем, что требует дополнительного устройства Wii Motion Plus (фигулька, вставляемая в разъем обычного моута, служит дополнительным акселерометром и гироскопом, позволяет более точно оценивать положение джойстика в пространстве). Игрушки, если честно, меня не очень вдохновили. Хотя, подраться на мечах я бы хотел попробовать!
Scrum и что у нас получается
Написал много, интересно будет далеко не всем, но уж извиняйте. И да, нужно делать nanocut по-любому!
Прошло несколько недель, как мы решили работать в соответствии с идеологией agile. Scrum, нужно заметить, приживался у нас не просто. Во-первых, внутренние противники внедрения этой методологии. Споры о том, нужно это или нет, утверждение, что мы и сами умные и можем всё придумать своими головами, дай только волю. Во-вторых, количество проектов и количество людей, занятых не этих проектах. Когда один проект делает один человек, доводит его до некоего состояния завершенности и функционирования, а тут подтягивается еще три человека, которые начинают своими руками все трогать и крутить. По началу казалось, что переключение контекстов с одного проекта на другой, в головах разработчиков, будет происходить с трудом. В-третьих, контора отличается демократизмом. На мой вкус, даже излишним демократизмом. Отсюда проистекают чисто организационные проблемы, когда нам сложно бывает собраться в одно время в одном месте, что бы что-то обсудить или сделать. Дисциплина как в лагере у хиппи.
Уже завершилось несколько итераций разработки. Чуваки, это очень прикольно! Но обо всём постараюсь рассказать по-порядку.
Описывать саму методологию я не буду, все интересующиеся могут поискать информацию в сети. В двух словах расскажу, как это работает у нас. Имеется две команды: команда разработки и команда менеджеров. Команда разработки состоит из разработчиков серверной части и разработчика клиентской части (к сожалению, у нас это так, хотя в идеале хорошо иметь однородный состав, способный к взаимному замещению). Менеджеры подготавливают список пожеланий (Product Backlog) по каждому из проектов. Список может быть обширным и содержать описание желаемых фич и функций, которые необходимо реализовать в проекте. Команда разработки получает этот список на руки и начинается довольно непростая на первый взгляд процедура: оценка трудозатрат на каждый пункт бэклога. Грубо говоря, берется одна фича из списка, обсуждается способ её реализации в первом приближении. Естественно, находятся люди, которые делали что-то похожее или близкое, именно они и начинают рассказ о том, как нужно/можно всё делать. Особого углубления в детали не происходит, всё довольно поверхностно. Но по ходу обсуждения возникают дополнительные вопросы, которые обсуждаются с менеджером (Product Owner), появляются какие-то технические и функциональные уточнения, которые записываются, что бы не быть потерянными. Когда задача ясна и обсуждена команда оценивает срок её выполнения. Каждый участник сообщает, за сколько часов, по его мнению, можно сделать эту задачу. Если оценки расходятся, то обсуждение задачи продолжается, после чего сново происходит оценивание. У нас, как показывает опыт, переоценивать задачу приходится не больше 2-х раз. Как-то мы не особо упорствуем в отстаивание своих точек зрения в данном вопросе. Наверное, это не плохо...
Таким образом, обрабатывая каждую фичу из бэклога разработчики дают менеджерам представление о том, что и сколько времени займет. Забавно наблюдать, как удивляются манагеры, узнав, что реализация плёвой, на их взгляд, фичи занимает 8 и более часов. Менеджер, обладая такими данными, определяет в какой последовательности выполнять задачи, что необходимо сделать в ближайшую неделю (длина итерации у нас такая), а что можно отложить на потом.
Еще один интересный момент. Работать 8 часов над поставленной задачей получается далеко не всегда. Да ладно, кого я обманываю, практически никогда не получается. Во-первых, чисто человеческий фактор. Чуваки за соседним столом нашли смешной ролик на youtube. "В интернете кто-то не прав" и ты не можешь этого стерпеть, бросаясь во флуд с головой. Плечо ноет и все мысли только о том, чем бы его помазать или лучше сразу отрезать. Да мало ли что может быть! Во-вторых, работая над одной задачей тебя будут отвлекать с вопросами по другим задачам, тебя будут дергать просьбами что-то быстренько подправить или добавить, дать доступ к серверу, изменить какие-нить права, создать запись в базе и т.п.. Это тоже ни для кого не секрет, как мне кажется. Дергать будут не только коллеги, но и сам менеджер, который ждет выполнения одной задачи, но в тот же момент, не может ждать с какой-то другой задачей, более мелкой, но неотложной.
Поэтому, менеджер, считающий, что задачу на 5 часов можно сделать за один день и еще останется время на небольшую задачку на 3 часа - дурак. Такого не бывает! Ладно, бывает, но что бы каждый день так - фантастика и недостижимый идеал. В scrum это всё предусмотрено. Есть такое понятие, как focus factor (в простонародье fuckup factor). Это некий поправочный коэффициент, позволяющий заложить время на всяческий факапы и риски. ФФ равный 1 - идеальный работник, которому нужно выписать массажистку и давать молоко за вредность, потому что такой работник, чисто физически, долго не протянет. Я думаю, что ФФ равный 0,7 - это очень и очень хорошо. Просто замечательно (относительно web-разработки). Наш нынешний fuckup factor колеблется в районе 0,35 - 0,37. Это плохо и нужно расти! Честно говоря, я даже не думал, что у нас будет так мало...
Что же мы имеем в цифрах. Допустим, нас в команде 3 человека. Работаем мы 4 дня в неделю (один день у нас уходит на демонстрацию выполненной итерации и на планирование следующей) по 8 часов. ФФ берём равный 0,35. Сколько часов у нас есть с учетом всех этих факторов: 3 х 4 х 8 х 0,35 = 35 часов. Из бэклога менеджер может дать нам задач на 35 часов и быть уверенным, что мы их сделаем. Ужас, каждый раз пугаюсь таких маленьких чисел.
Когда все задачи сформулированы и определены, количество их ограничено нашими разработчискими возможностями, они формализуются и выписываются на бумажках. Бумажки крепятся на доску, которая имеет 4 вертикальные зоны (столика): свободные задачи; задачи в работе; задачи, готовые к тестированию; завершенные задачи. Постепенно, каждая задача должна продвинуться по доске слева на право. Из раздела свободных задач в раздел завершенных.
Хороший момент - тестирование. Когда ты сделал задачу, ты вешаешь ее в тестирование. Она там висит до тех пор, пока кто-нибудь не возьмёт её и не протестирует, убедившись, что всё работает так, как требуется. Естественно, это очень сильно повышает качество продукта.
Чуть выше я писал о некой демонстрации выполненной итерации. Необходимости этого момента я не понимаю. Каждая задача оформлена в виде отдельной карточки, которая висит на доске. В этой карточке имеется описание задачи, описание того, как проверить, что задача выполнена и прочая служебная информация (оценка трудозатрат, исполнитель и т.п.). Так вот почему бы продукт овнеру (ака менеджеру) самому не взять эту бумажку и не посмотреть, выполнена задача и насколько хорошо она выполнена? Наверное, есть какой-то глубинный смысл в том, что сами разработчики проводят демонстрацию, показывая, что они сделали и как это работает. Но мне просто жалко времени, которое на это уходит.
После демонстрации проводится ещё один митинг - ретроспектива. Это некое действо, происходящее внутри команды и направленное на то, что бы решить проблемы, возникшие в ходе работы. Проблемы эти могут быть как техническими (сервера падали, нужно подумать, как этого избежать в дальнейшем), так и организационные (менеджеры отвлекали задачами, не относящимися к итерации, как сократить такие обращения или выделить на них время). В ходе ретроспективы формулируются проблемы, придумываются пути их решения и контролируется выполнение принятых ранее решений. Грубо говоря, некий "разговор за жизнь" внутри компании. Вещь, безусловно, полезная, но у нас она происходит периодически в течении всей недели, а не только одни раз, в назначенное время.
Кроме всего этого, ежедневно, примерно в одно и тоже время, проводятся небольшие собрания команды (Daily Scrum Meeting). На них каждый разработчик рассказывает, что он сделал вчера, что он делает сегодня, какие проблемы у него возникли. Обычно, такие собрания проходят за 5-10 минут. Они позволяют быть в курсе событий, выявлять проблемы в самой ранней стадии их зарождения, оперативно реагировать на изменение каких-то факторов разработки. Полезная штука!
Промежуточные итоги. Стали ли мы работать быстрее? Не знаю, чисто субъективно - нет. Зато появилось больше понимания того, что делается, как делается, кем делается и почему так, а не иначе. Стали ли мы работать лучше (качественнее)? Да! Вот это бесспорно и очевидно. Если раньше некоторые вещи писались "что бы работало", то теперь подход меняется. Во-первых, всегда можно обратится за консультацией к коллегам, чтобы совместно придумать более красивое решение. Конечно, раньше тоже можно было общаться, но scrum как-то стимулирует и всячески поощряет такие коммуникации. Во-вторых, фактор того, что твою работу будут проверять твои же коллеги заставляет тщательнее думать и лучше писать.
Мне кажется, что такой процесс разработки довольно продуктивен и лучше того, что доводилось видеть.
Прошло несколько недель, как мы решили работать в соответствии с идеологией agile. Scrum, нужно заметить, приживался у нас не просто. Во-первых, внутренние противники внедрения этой методологии. Споры о том, нужно это или нет, утверждение, что мы и сами умные и можем всё придумать своими головами, дай только волю. Во-вторых, количество проектов и количество людей, занятых не этих проектах. Когда один проект делает один человек, доводит его до некоего состояния завершенности и функционирования, а тут подтягивается еще три человека, которые начинают своими руками все трогать и крутить. По началу казалось, что переключение контекстов с одного проекта на другой, в головах разработчиков, будет происходить с трудом. В-третьих, контора отличается демократизмом. На мой вкус, даже излишним демократизмом. Отсюда проистекают чисто организационные проблемы, когда нам сложно бывает собраться в одно время в одном месте, что бы что-то обсудить или сделать. Дисциплина как в лагере у хиппи.
Уже завершилось несколько итераций разработки. Чуваки, это очень прикольно! Но обо всём постараюсь рассказать по-порядку.
Описывать саму методологию я не буду, все интересующиеся могут поискать информацию в сети. В двух словах расскажу, как это работает у нас. Имеется две команды: команда разработки и команда менеджеров. Команда разработки состоит из разработчиков серверной части и разработчика клиентской части (к сожалению, у нас это так, хотя в идеале хорошо иметь однородный состав, способный к взаимному замещению). Менеджеры подготавливают список пожеланий (Product Backlog) по каждому из проектов. Список может быть обширным и содержать описание желаемых фич и функций, которые необходимо реализовать в проекте. Команда разработки получает этот список на руки и начинается довольно непростая на первый взгляд процедура: оценка трудозатрат на каждый пункт бэклога. Грубо говоря, берется одна фича из списка, обсуждается способ её реализации в первом приближении. Естественно, находятся люди, которые делали что-то похожее или близкое, именно они и начинают рассказ о том, как нужно/можно всё делать. Особого углубления в детали не происходит, всё довольно поверхностно. Но по ходу обсуждения возникают дополнительные вопросы, которые обсуждаются с менеджером (Product Owner), появляются какие-то технические и функциональные уточнения, которые записываются, что бы не быть потерянными. Когда задача ясна и обсуждена команда оценивает срок её выполнения. Каждый участник сообщает, за сколько часов, по его мнению, можно сделать эту задачу. Если оценки расходятся, то обсуждение задачи продолжается, после чего сново происходит оценивание. У нас, как показывает опыт, переоценивать задачу приходится не больше 2-х раз. Как-то мы не особо упорствуем в отстаивание своих точек зрения в данном вопросе. Наверное, это не плохо...
Таким образом, обрабатывая каждую фичу из бэклога разработчики дают менеджерам представление о том, что и сколько времени займет. Забавно наблюдать, как удивляются манагеры, узнав, что реализация плёвой, на их взгляд, фичи занимает 8 и более часов. Менеджер, обладая такими данными, определяет в какой последовательности выполнять задачи, что необходимо сделать в ближайшую неделю (длина итерации у нас такая), а что можно отложить на потом.
Еще один интересный момент. Работать 8 часов над поставленной задачей получается далеко не всегда. Да ладно, кого я обманываю, практически никогда не получается. Во-первых, чисто человеческий фактор. Чуваки за соседним столом нашли смешной ролик на youtube. "В интернете кто-то не прав" и ты не можешь этого стерпеть, бросаясь во флуд с головой. Плечо ноет и все мысли только о том, чем бы его помазать или лучше сразу отрезать. Да мало ли что может быть! Во-вторых, работая над одной задачей тебя будут отвлекать с вопросами по другим задачам, тебя будут дергать просьбами что-то быстренько подправить или добавить, дать доступ к серверу, изменить какие-нить права, создать запись в базе и т.п.. Это тоже ни для кого не секрет, как мне кажется. Дергать будут не только коллеги, но и сам менеджер, который ждет выполнения одной задачи, но в тот же момент, не может ждать с какой-то другой задачей, более мелкой, но неотложной.
Поэтому, менеджер, считающий, что задачу на 5 часов можно сделать за один день и еще останется время на небольшую задачку на 3 часа - дурак. Такого не бывает! Ладно, бывает, но что бы каждый день так - фантастика и недостижимый идеал. В scrum это всё предусмотрено. Есть такое понятие, как focus factor (в простонародье fuckup factor). Это некий поправочный коэффициент, позволяющий заложить время на всяческий факапы и риски. ФФ равный 1 - идеальный работник, которому нужно выписать массажистку и давать молоко за вредность, потому что такой работник, чисто физически, долго не протянет. Я думаю, что ФФ равный 0,7 - это очень и очень хорошо. Просто замечательно (относительно web-разработки). Наш нынешний fuckup factor колеблется в районе 0,35 - 0,37. Это плохо и нужно расти! Честно говоря, я даже не думал, что у нас будет так мало...
Что же мы имеем в цифрах. Допустим, нас в команде 3 человека. Работаем мы 4 дня в неделю (один день у нас уходит на демонстрацию выполненной итерации и на планирование следующей) по 8 часов. ФФ берём равный 0,35. Сколько часов у нас есть с учетом всех этих факторов: 3 х 4 х 8 х 0,35 = 35 часов. Из бэклога менеджер может дать нам задач на 35 часов и быть уверенным, что мы их сделаем. Ужас, каждый раз пугаюсь таких маленьких чисел.
Когда все задачи сформулированы и определены, количество их ограничено нашими разработчискими возможностями, они формализуются и выписываются на бумажках. Бумажки крепятся на доску, которая имеет 4 вертикальные зоны (столика): свободные задачи; задачи в работе; задачи, готовые к тестированию; завершенные задачи. Постепенно, каждая задача должна продвинуться по доске слева на право. Из раздела свободных задач в раздел завершенных.
Хороший момент - тестирование. Когда ты сделал задачу, ты вешаешь ее в тестирование. Она там висит до тех пор, пока кто-нибудь не возьмёт её и не протестирует, убедившись, что всё работает так, как требуется. Естественно, это очень сильно повышает качество продукта.
Чуть выше я писал о некой демонстрации выполненной итерации. Необходимости этого момента я не понимаю. Каждая задача оформлена в виде отдельной карточки, которая висит на доске. В этой карточке имеется описание задачи, описание того, как проверить, что задача выполнена и прочая служебная информация (оценка трудозатрат, исполнитель и т.п.). Так вот почему бы продукт овнеру (ака менеджеру) самому не взять эту бумажку и не посмотреть, выполнена задача и насколько хорошо она выполнена? Наверное, есть какой-то глубинный смысл в том, что сами разработчики проводят демонстрацию, показывая, что они сделали и как это работает. Но мне просто жалко времени, которое на это уходит.
После демонстрации проводится ещё один митинг - ретроспектива. Это некое действо, происходящее внутри команды и направленное на то, что бы решить проблемы, возникшие в ходе работы. Проблемы эти могут быть как техническими (сервера падали, нужно подумать, как этого избежать в дальнейшем), так и организационные (менеджеры отвлекали задачами, не относящимися к итерации, как сократить такие обращения или выделить на них время). В ходе ретроспективы формулируются проблемы, придумываются пути их решения и контролируется выполнение принятых ранее решений. Грубо говоря, некий "разговор за жизнь" внутри компании. Вещь, безусловно, полезная, но у нас она происходит периодически в течении всей недели, а не только одни раз, в назначенное время.
Кроме всего этого, ежедневно, примерно в одно и тоже время, проводятся небольшие собрания команды (Daily Scrum Meeting). На них каждый разработчик рассказывает, что он сделал вчера, что он делает сегодня, какие проблемы у него возникли. Обычно, такие собрания проходят за 5-10 минут. Они позволяют быть в курсе событий, выявлять проблемы в самой ранней стадии их зарождения, оперативно реагировать на изменение каких-то факторов разработки. Полезная штука!
Промежуточные итоги. Стали ли мы работать быстрее? Не знаю, чисто субъективно - нет. Зато появилось больше понимания того, что делается, как делается, кем делается и почему так, а не иначе. Стали ли мы работать лучше (качественнее)? Да! Вот это бесспорно и очевидно. Если раньше некоторые вещи писались "что бы работало", то теперь подход меняется. Во-первых, всегда можно обратится за консультацией к коллегам, чтобы совместно придумать более красивое решение. Конечно, раньше тоже можно было общаться, но scrum как-то стимулирует и всячески поощряет такие коммуникации. Во-вторых, фактор того, что твою работу будут проверять твои же коллеги заставляет тщательнее думать и лучше писать.
Мне кажется, что такой процесс разработки довольно продуктивен и лучше того, что доводилось видеть.
RSS: