Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 6
Со времен книги Брукса про миф человеко-месяца было предложено много подходов, т.к. тема действительно очень актуальная. Хотелось бы посмотреть, как работает Ваш метод на реальном, хотя бы небольшом проекте — думаю, это будет интересно многим читателям. Могу для этого предложить примеры своих уже сделанных мини-проектов:
2 игровых бота: 1 и 2
и маленькая игровая задачка
Прикиньте по своей методике, сколько человеко-дней на какие этапы нужно, риски и т.д. А я скажу, как оказалось в реальности.
2 игровых бота: 1 и 2
и маленькая игровая задачка
Прикиньте по своей методике, сколько человеко-дней на какие этапы нужно, риски и т.д. А я скажу, как оказалось в реальности.
Наверное, я вас разочарую, но описанные практики не совсем методика, а скорее некоторые практические дополнения к той методике, которая применяется в проекте.
Важно отметить, что эти практики больше ориентированны на командую разработку в «кровавом enterprise» с средним/низким уровнем неопределенности. Как правило доработка банковской системы/системы управления складом или чего-то подобного представляет собой развитие функционала, а не революцию в нем. Отсюда поход с унификацией, стандартизацией и так далее. Оценка и планирование в таких проектах — воспроизводимый процесс.
Но мы можем потренироваться и на ваших проектах. Только оценивать будете вы, потому что опыт и экспертиза на вашей стороне. Для начала договоримся, в чем будем оценивать (человеко-дни, чистые часы, а может быть «попугаи»). Затем определимся с конечной целью и будем разбивать работы на подзадачи. С учетом уровня неопределенности можно не пытаться съесть слона целиком, а начать с прототипирования. Оценим ограничения и риски. В общем, я думаю во многих проектах можно применить эти практики.
Важно отметить, что эти практики больше ориентированны на командую разработку в «кровавом enterprise» с средним/низким уровнем неопределенности. Как правило доработка банковской системы/системы управления складом или чего-то подобного представляет собой развитие функционала, а не революцию в нем. Отсюда поход с унификацией, стандартизацией и так далее. Оценка и планирование в таких проектах — воспроизводимый процесс.
Но мы можем потренироваться и на ваших проектах. Только оценивать будете вы, потому что опыт и экспертиза на вашей стороне. Для начала договоримся, в чем будем оценивать (человеко-дни, чистые часы, а может быть «попугаи»). Затем определимся с конечной целью и будем разбивать работы на подзадачи. С учетом уровня неопределенности можно не пытаться съесть слона целиком, а начать с прототипирования. Оценим ограничения и риски. В общем, я думаю во многих проектах можно применить эти практики.
Но мы можем потренироваться и на ваших проектах. Только оценивать будете вы, потому что опыт и экспертиза на вашей стороне. Для начала договоримся, в чем будем оценивать (человеко-дни, чистые часы, а может быть «попугаи»).
Ok. Предлагаю «человеко-дни» по Вашему определению:
задача на 1 человеко-день решается за 1 рабочий день. 0,5 человеко-дня – это начать утром и завершить к обеду. В этот человеко-день включена планерка, помощь коллегам, чай с печеньками и так далее;
Договорились.
Теперь выберем, что будем оценивать. У вас есть какой-нибудь новый проект?
Потому что по старым проектам правильные ответы вы уже знаете. Оценивать придется вам, так как исполнителем в итоге будете тоже вы. А это очень хорошо, когда оценивает тот, кто будет реализовывать. Да и отсутствие у меня опыта работы с ИИ и указанными инструментами не позволит мне корректно оценивать ваши задачи.
Теперь выберем, что будем оценивать. У вас есть какой-нибудь новый проект?
Потому что по старым проектам правильные ответы вы уже знаете. Оценивать придется вам, так как исполнителем в итоге будете тоже вы. А это очень хорошо, когда оценивает тот, кто будет реализовывать. Да и отсутствие у меня опыта работы с ИИ и указанными инструментами не позволит мне корректно оценивать ваши задачи.
>У вас есть какой-нибудь новый проект?
Думаю, что для демонстрации возможностей Вашего подхода имеет смысл сравнение только с уже сделанным. Допустим, новый проект получит суммарную оценку в 1 человеко-год. При одном исполнителе будем ждать год, пока я сделаю этот проект? За это время Вы успеете усовершенствовать Ваш подход, и устаревшая оценка будет никому не интересна. Кроме того, было бы неправильным разглашать основные детали еще несделанного проекта.
> по старым проектам правильные ответы вы уже знаете.
Строго говоря, правильных ответов я не знаю, а знаю, как получилось у меня (или у нас, т.к. один из проектов исполнялся вдвоем). И было бы интересно сравнить со сторонней оценкой. Понятно, что у каждого исполнителя разная производительность, но, насколько я понимаю, для оценки берется средняя: столько-то строк кода написать за 1 человеко-день, столько-то отладить и т.д. Более того: из того, что мне удалось удачно выполнить какой-то проект, совсем не следует, что я его правильно выполнял – оптимальным образом провел декомпозицию, правильно оценил риски и т.д. Может, мне просто повезло. А может, тот же результат я мог бы получить гораздо быстрее.
Что касается отсутствия опыта работы с ИИ, в моих проектах, конечно, есть своя специфика, но не столь большая, как, нпр., в случае нейронных сетей. При том, что «маленькая игровая задачка» по сути не является задачей ИИ, и в моем решении ИИ не используется, что и отмечено в публикации. Очень часто производитель ПО – будь это отдельный программист или целая фирма – сталкивается с необходимостью решить задачу, для которой у него отсутствует опыт. Как же оценивать и планировать в этом случае? Неужели Ваш подход не поможет?
> А это очень хорошо, когда оценивает тот, кто будет реализовывать.
Давайте поставим задачу иначе. Предположим, что некой фирме Х так понравились три моих вышеуказанных программных продукта, что она хочет получить на них права (не будем при этом обсуждать юридическую сторону вопроса о правах на открытое ПО). Так же фирме Х понравился Ваш подход, и она обратилась к Вам с просьбой быть независимым экспертом для приблизительной оценки трудоемкости создания подобного ПО. Используя эту оценку, как некий средний объективный критерий, фирма Х определит примерный размер компенсации, которую она считает разумным мне предложить. Конечно, в подобной модельной ситуации я могу не соглашаться с какими-либо оценками, возражая, что на подзадачу, оцененную в 2 человеко-дня, потратил 20. Но и мне резонно возразят, что это мои проблемы организации работ и если у меня плохая организация, то все равно никто не будет платить мне за элементарную подзадачу в 10 раз выше среднего. Если я продолжу упорствовать и заломлю слишком высокую, по мнению Х, цену, то фирма Х, опять же учитывая Вашу оценку, может решить ничего мне не компенсировать, и что для нее будет выгоднее написать свой собственный код с похожей функциональностью (юридическую сторону такого решения тоже обсуждать не будем).
Думаю, что для демонстрации возможностей Вашего подхода имеет смысл сравнение только с уже сделанным. Допустим, новый проект получит суммарную оценку в 1 человеко-год. При одном исполнителе будем ждать год, пока я сделаю этот проект? За это время Вы успеете усовершенствовать Ваш подход, и устаревшая оценка будет никому не интересна. Кроме того, было бы неправильным разглашать основные детали еще несделанного проекта.
> по старым проектам правильные ответы вы уже знаете.
Строго говоря, правильных ответов я не знаю, а знаю, как получилось у меня (или у нас, т.к. один из проектов исполнялся вдвоем). И было бы интересно сравнить со сторонней оценкой. Понятно, что у каждого исполнителя разная производительность, но, насколько я понимаю, для оценки берется средняя: столько-то строк кода написать за 1 человеко-день, столько-то отладить и т.д. Более того: из того, что мне удалось удачно выполнить какой-то проект, совсем не следует, что я его правильно выполнял – оптимальным образом провел декомпозицию, правильно оценил риски и т.д. Может, мне просто повезло. А может, тот же результат я мог бы получить гораздо быстрее.
Что касается отсутствия опыта работы с ИИ, в моих проектах, конечно, есть своя специфика, но не столь большая, как, нпр., в случае нейронных сетей. При том, что «маленькая игровая задачка» по сути не является задачей ИИ, и в моем решении ИИ не используется, что и отмечено в публикации. Очень часто производитель ПО – будь это отдельный программист или целая фирма – сталкивается с необходимостью решить задачу, для которой у него отсутствует опыт. Как же оценивать и планировать в этом случае? Неужели Ваш подход не поможет?
> А это очень хорошо, когда оценивает тот, кто будет реализовывать.
Давайте поставим задачу иначе. Предположим, что некой фирме Х так понравились три моих вышеуказанных программных продукта, что она хочет получить на них права (не будем при этом обсуждать юридическую сторону вопроса о правах на открытое ПО). Так же фирме Х понравился Ваш подход, и она обратилась к Вам с просьбой быть независимым экспертом для приблизительной оценки трудоемкости создания подобного ПО. Используя эту оценку, как некий средний объективный критерий, фирма Х определит примерный размер компенсации, которую она считает разумным мне предложить. Конечно, в подобной модельной ситуации я могу не соглашаться с какими-либо оценками, возражая, что на подзадачу, оцененную в 2 человеко-дня, потратил 20. Но и мне резонно возразят, что это мои проблемы организации работ и если у меня плохая организация, то все равно никто не будет платить мне за элементарную подзадачу в 10 раз выше среднего. Если я продолжу упорствовать и заломлю слишком высокую, по мнению Х, цену, то фирма Х, опять же учитывая Вашу оценку, может решить ничего мне не компенсировать, и что для нее будет выгоднее написать свой собственный код с похожей функциональностью (юридическую сторону такого решения тоже обсуждать не будем).
есть 3 вида лжи: ложь, наглая ложь и оценка трудозатрат
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практики планирования. Оценка задач