Задачи не более двух часов - Управление проектами

На проектах какого типа удается выполнять данную рекомендацию — задачи не более двух часов?

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

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

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

Здравствуйте, Аноним, Вы писали:

А>На нашем проекте я просто представить такого не могу, чтобы получилось это сделать даже отдаленно. Максимум 0,1% задач можно вписать заранее в это время, обычно же до начала задачи просто неизвестно, что конкретно придется делать, так как это само по себе требует исследования, а это исследование практически эквивалентно реализации. Потому что решение задач подобно поиску пути на неизвестной местности. И вроде как это нормально, иначе это были бы не задачи, а какое-то производство на конвейере.

А что за проект, на котором каждая задача это многодневное исследование? Может быть у вас просто разработчики неопытные? Что в программировании можно исследовать? ТЗ есть, архитектура есть, сиди и педаль код.

Здравствуйте, vsb, Вы писали:

vsb>А что за проект, на котором каждая задача это многодневное исследование? Может быть у вас просто разработчики неопытные? Что в программировании можно исследовать?
vsb> ТЗ есть, архитектура есть, сиди и педаль код.

Кто сказал, что есть ТЗ и архитектура?

vsb> Что в программировании можно исследовать?

Это вброс?

А>На проектах какого типа удается выполнять данную рекомендацию — задачи не более двух часов?

support & maintenance. Багфиксы, поддержка, локализация (i18n которая). На исследовательских проектах задачи обычно длиннее. Но в любом случае не превышают 6 часов (суть 1 день). Но эта граница условна и взята из требования отчитываться хотя бы раз в день.

Для чего вам нужно разбивать задачи "до 2х часов" конкретно на вашем проекте?

Здравствуйте, Аноним, Вы писали:

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

Зачем разбивать именно на два часа? Задача оценки/распределения времени делается не так.

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

Второе: этапы работы оценивается не в часах (т.к. производительность Васи сегодня и Пети завтра не связаны абсолютно никак), а в условных относительных единицах; оценка решения задач основывается на опыте предыдущих итераций. Из полярных вариантов — оценка сроков командой (пример по скраму очень хорошо описал SkyDance), или (при наличии хороших аналитиков в команде) — банальная очередь тикетов в таск-трекере, описывающая отдельные этапы большой задачи. В любом из случаев задачи не измеряются в человекочасах.

Третье (и самое главное): ни при каких обстоятельствах не пытайтесь подогнать стиль работы команды под абстрактные рекомендации. Это культ карго в самом худшем виде: все ритуалы соблюдены, толку 0. Два часа выглядит цифрой взятой с потолка. Типовая мелочь (опечатки в текстах, пропуск пункта в техническом задании) правятся и тестируются обычно пачками и закрывают их так же. Большие задачи — от 3-4 часов и до недели, причём заранее не угадаешь.

Здравствуйте, vsb, Вы писали:

vsb>А что за проект, на котором каждая задача это многодневное исследование? Может быть у вас просто разработчики неопытные? Что в программировании можно исследовать? ТЗ есть, архитектура есть, сиди и педаль код.

А что это за проект, на котором архитектура и ТЗ уже заранее на 100% детально разработаны и осталось только напедалить код? Это же идеальный waterfall. Неужели такие бывают?

Здравствуйте, SkyDance, Вы писали:

SD>Для чего вам нужно разбивать задачи "до 2х часов" конкретно на вашем проекте?

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

Здравствуйте, Аноним, Вы писали:

SD>>Для чего вам нужно разбивать задачи "до 2х часов" конкретно на вашем проекте?

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

Два часа — это скорее психологическая и физиологическая граница. Это средний "по больнице" период одного цикла работы в стиле "упал — отжался — вернулся в реальность". После которой надо осознать сделанное, отвлечься чуть крупнее, чем на короткий перекур, и составить хотя бы себе и мысленно отчёт о сделанном, чтобы двигаться дальше. Эти рекомендации agile "абьюзят" эту норму для того, чтобы поставить точку координации. Сам по себе подход неплохой, просто надо понимать, что мероприятия по отчёту, координации, сверке понимания и т.п. после такого периода — должны быть крайне короткими и ненапряжными (грубо говоря, уложиться в 1 минуту, или в 5, если проходят в курилке с чашкой кофе), и что это только в среднем. Что-то может быть сделано за 10 минут, а что-то может потребовать вообще уехать на речку с удочкой на 2 дня (для тех, кто доказал полезность такого подхода).

Для начала можно попробовать опрашивать людей каждые 2 часа, но ненавязчиво (ни в коем случае не отрывать от работы, если видно, что кто-то в работе). Обычно сам по себе доклад о состоянии помогает вглянуть со стороны и заметить что-то ранее не замеченное, ну и сам по себе разговор является точкой синхронизации и корректировки. Более детально просить на входе/выходе (граница рабочего дня, обед). Но сделать это надо так, чтобы никому не было напряжно рассказывать. Это тут самый сложный и тонкий момент — если будут делать через силу, может быть хуже.

12/2/2013 9:16 AM, Аноним 281 пишет:

> На моем проекте мне просто хочется сделать задачи короче и
> предсказуемей, чтобы как минимум никогда не было задач длиннее одного
> дня. А про два часа просто слышал такую рекомендацию от одного знатока
> Agile. Вот и задумался, что я чего-то не понимаю.
С таким подходом ты гарантировано добьешься нулевой работы от
подчиненных. И да у тебя может получиться заставить их отчитываться
каждые 2 часа и "планировать" так же. Вот только этим они и будут
заниматься и больше не чем. Но, если хочешь свернуть деятельность
подразделения или конторы и расформировать его, то это самое то.
Хотя, может у тебя роботизированная линия и ты планируешь задачи для
роботов? Так там же всегда известны затраты времени на конкретную операцию.