Рубрика «оценка времени»
Кто быстрее создаёт списки в Python, list() или []
2022-06-15 в 20:36, admin, рубрики: python, исследование, оценка времени, сравнение производительности![Кто быстрее создаёт списки в Python, list() или [] - 1](https://www.pvsm.ru/images/2022/06/16/kto-bystree-sozdayot-spiski-v-Python-list-ili.jpg "Кто быстрее создаёт списки в Python, list() или [] - 1")
Лучше оценивай, пока сторипоинты не запретили
2022-04-30 в 8:06, admin, рубрики: Trello, оценка, оценка времени, оценка трудозатрат, управление проектами
От нас, разработчиков, постоянно требуют дать оценку той или иной задаче. Зачем управленцам оценки, они вам сами расскажут. Зачем клиентам оценки — вам расскажут управленцы. Но нужны ли оценки самим разработчикам?
Об оценках сроков в разработке ПО
2020-06-12 в 19:40, admin, рубрики: agile, estimate, scrum, оценка времени, оценка трудозатрат, управление проектами, управление разработкойВ течение всей истории разработки ПО, мы искали надежные способы оценки времени на реализацию задач и проектов. Но и спустя более чем 60 лет существования отрасли, наши прогнозы все еще оставляют желать лучшего. Может быть, дело не в том, как именно мы пытаемся оценивать, а в том, что мы вообще опираемся на оценки?
К примеру, возьмите методологию Scrum, по которой сегодня работают многие компании. Центральная идея Scrum — брать в спринт не больше задач, чем ваша команда способна за это время выполнить. На первый взгляд, звучит разумно. К сожалению, слишком часто на практике этот подход приводит к замедлению работы команды в обмен на иллюзию планирования. Позвольте объяснить, почему.
Читать полностью »
Оценка сроков на разработку и тестирование задачи (не нужна)
2019-03-27 в 7:31, admin, рубрики: deadline, peopleware, Блог компании Контур, Демарко, деминг, джедайские техники, дорофеев, Матчасть, оценка времени, сроки реализации, Тестирование веб-сервисов, Управление продуктом, управление проектами, управление разработкойЯ в тестировании 12 лет, работал в Naumen и Яндексе. Сейчас руковожу отделом тестирования из 150 человек в Контуре и продолжаю работать тестировщиком в одной из команд.
После полугодовых performance review менеджеры из разных команд рассказали, какие цели поставили своим тестировщикам. У каждого пятого была такая: «Научиться оценивать сроки на тестирование задач». Часто такой «оценки сроков» хотят не только от тестировщиков, но и от разработчиков.
Оценка сроков в 95 % случаев. Спасибо, xkcd.
Я считаю абсолютно вредной практику, когда исполнитель оценивает сроки на выполнение отдельной задачи. Это напрямую связано с отсутствием системного образования и низкими требованиями к менеджерам.
Сейчас объясню, как это работает.
Оценка затрат на разработку через TDD
2019-01-20 в 16:49, admin, рубрики: tdd, оценка времени, простые принципы, управление разработкойСкромная дискуссия по мотивам моей вчерашней публикации на тему прогнозирования времени на разработку, в очередной раз пробудила во мне ощущение некоей неправильности на тему использования чисто умозрительного подхода к разбиению истории на задачи. На мой взгляд, когда мы пишем задачи в списке, даже когда мы используем объектную или функциональную терминологию, мы не вполне представляем себе все модули с кодом, которые нам потребуется разработать или доработать.
Тогда мне пришла в голову идея, после разбиения пользовательской истории на задачи, попробовать набросать черновики модульных тестов, для классов или методов, которые я упоминаю в задачах. Мне даже не нужно выдумывать пользовательскую историю, я могу взять одну из моей текущей работы. Например:Читать полностью »
Простые практики прогнозирования временных затрат
2019-01-19 в 18:45, admin, рубрики: оценка времени, простые принципы, управление персоналом, управление разработкой, управление разработчикамиСпособность качественно оценивать временные затраты на разработку — один из ключевых навыков хорошего управляющего процессом разработки. Ошибочные прогнозы сроков завершения задач, как свидетельствует мой личный опыт, является одним из если не основных источников боли для руководителей, то весьма масштабным.
Практики, позволяющие не полагаться в этом вопросе на удачу и попытки угадать время, требуемое для реализации той или иной идеи в коде просты и доступны всем. Планирование — это вполне себе обычная работа, и для ее выполнения требуются вполне определенные действия. Читать полностью »
Цена изменений: во сколько на самом деле обойдется переработка кода
2018-12-26 в 11:23, admin, рубрики: Wirex, Блог компании Wirex, дедлайн, оценка времени, оценка стоимости проекта, оценка трудозатрат, Программирование, сроки, Статистика в IT, управление разработкойАвтор этого материала делится способом оценки времени, которое будет затрачено на переписывание уже внедренного проекта.
По мере разрастания кода работать с ним становится все труднее. Годы разработки и отлавливания багов приводят к желанию перечеркнуть все и начать с чистого листа. Действительно, очень заманчива мысль о том, чтобы оставить ошибки в прошлом, вооружиться новыми технологиями и на этот раз все сделать правильно. Однако перед прыжком в бездну я все же предлагаю внимательнее присмотреться к реальной стоимости этого шага.
Модель оценки объема работ
Вы можете свести в один список все фичи своего приложения, а после оценить этапы и приблизительное время их переработки. Большинство именно так и поступает перед тем, как приступить к работе. Но почему тогда на практике выходит, что подобные проекты занимают в 4, 8 или даже 10 раз больше времени, чем разработчики заложили на старте?
Публикация о временных затратах на написание программного кода, которая пригодится при оценке объема работ: «Правило 10:1 в программировании и писательстве»
Есть три ключевых фактора, которые существенно растягивают процесс. И обычно при оценке затрат их игнорируют. Речь идет о
1) необходимости наверстать разницу между уровнями текущего и нового приложений,
2) объеме непредусмотренных изменений,
3) улучшениях, которые придется сделать, чтобы пользователи захотели перейти на новое приложение.
Сокращение разницы
Первый фактор — новому приложению необходимо догнать текущее.Читать полностью »
Как оценивать большие задачи
2017-02-06 в 13:40, admin, рубрики: agile, Блог компании Mindbox, оценка времени, оценка задачи, оценка трудозатрат, проектированиеСуществует множество способов оценить пользовательские истории. Мы используем собственную методологию, чтобы оценить и проработать задачи перед тем, как писать код. Как мы до этого дошли и почему наш подход лучше, чем Planing Poker, читайте под катом.
Как дать адекватную оценку времени, когда неопределённость бьёт по башке
2016-08-25 в 9:53, admin, рубрики: agile, planning poker, scrum, оценка времени, управление временем, управление людьми, управление персоналом, управление проектами, управление разработкойБольшинство людей не умеют адекватно оценивать сроки выполнения задач. Ой как это заставляет порой понервничать… Тут и «дэдлайн подкрадывается незаметно». И перестраховка в 500% на всякий случай (все равно не хватает). И отжимание «заведомо раздутых сроков», чтобы исполнитель пообещал чего-то более приемлемого. И невнятные бормотания вместо конкретных цифр.
В этой статье собраны и структурированы принципы и методы, с помощью которых можно научить себя и других давать адекватные оценки. В начале — общие принципы и чуть-чуть математики. В конце — конкретика для студий.
Читать полностью »
Как оценивать задачи без помощи разработчиков?
2015-11-30 в 8:52, admin, рубрики: оценка времени, управление проектами Несмотря на то, что в нашей небольшой компании никто не обращает внимания на сроки (заказчику это не важно), я время от времени сталкиваюсь с необходимостью оценить сколько времени займёт разработка той или иной функциональности или набора задач. Помимо оценки методами «на глаз» и «при помощи разработчиков», которые часто дают большую погрешность, я пользуюсь ещё одним несложным подходом. Подход заключается в измерении среднего времени выполнения одной задачи в прошлом.
Читать полностью »