Как стать автором
Обновить

Опыт участия в Rails Rumble

Программирование *Ruby on Rails *
В прошедшие выходные (13 и 14 октября) мы с aishek и еще двумя нашими коллегами участвовали в хакатоне Rails Rumble 2012. По условиям конкурса за 48 часов нужно задеплоить готовое Rails-приложение.

Надо сказать, что кроме выпитого ящика пива и прочего фана мы получили действительно хороший опыт.
Читать дальше →
Всего голосов 19: ↑17 и ↓2 +15
Просмотры 4.3K
Комментарии 22

Лайфхак: в любой непонятной ситуации умножай на три

Управление проектами *


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


Хочу обсудить проблемы, связанные с предварительной оценкой времени и сроков проектов. В этой статье я расскажу как обстоят дела на проекте, который я веду немногим более 5 месяцев. Я приведу некоторые свои мысли, объясню какие эксперименты с оценками я делал и какие выводы получил по прошествию этого срока.
Читать дальше →
Всего голосов 33: ↑32 и ↓1 +31
Просмотры 32K
Комментарии 17

Как оценить длительность IT-проекта, а когда это вообще не стоит делать

Управление проектами *
Перевод


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

Селеста чувствовала давление. Её менеджер Барри хотел составить квартальный прогноз работы её команды. Задача усложнялась тем, что группа Селесты работала не над одним продуктом: Барри хотел получить прогноз сразу по трём. Каждый из них являлся частью другого проекта.

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

Селеста решила признаться Барри и посмотреть, к чему они придут. Она назначила встречу на следующий день и собрала данные.
Читать дальше →
Всего голосов 15: ↑14 и ↓1 +13
Просмотры 11K
Комментарии 4

Многие дедлайны придумывают специально с целью заставить инженеров работать бесплатно

Управление разработкой *Управление проектами *Управление продуктом *
Перевод
Работа инженера — сплошное разочарование. Возможно, потому что у нас нет власти, а менеджеры сбрасывают на инженеров все проблемы и ожидают, что они будут решены к вчерашнему дню.

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

Вот общий сценарий, который разыгрывается между инженером и его боссом, инженером-менеджером. Менеджер спрашивает, сколько времени займёт выполнение новой задачи. Бывает, что инженер не делал эту задачу раньше, поэтому честно отвечает, что понятия не имеет. Менеджер не принимает такой ответ — и снова спрашивает. Тогда инженер даёт оценку практически наугад, а босс отвечает: «Это слишком долго». Даже если инженер знает, сколько времени займёт выполнение задачи и даёт реалистичную оценку, менеджер часто отвечает: «Это слишком долго. У тебя есть время до пятницы». Когда инженер спрашивает, как давно стало известно об этой задаче, босс отвечает, что месяц назад. Когда инженер спрашивает, почему он не сказал ему об этом месяц назад, тот просто смотрит на инженера, как будто не понимает вопроса.
Читать дальше →
Всего голосов 113: ↑100 и ↓13 +87
Просмотры 62K
Комментарии 297