Рубрика «оценка трудозатрат»

Лучше оценивай, пока сторипоинты не запретили!
Лучше оценивай, пока сторипоинты не запретили!

От нас, разработчиков, постоянно требуют дать оценку той или иной задаче. Зачем управленцам оценки, они вам сами расскажут. Зачем клиентам оценки — вам расскажут управленцы. Но нужны ли оценки самим разработчикам?

Читать полностью »

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

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

С этой темой я выступал на Читать полностью »

В течение всей истории разработки ПО, мы искали надежные способы оценки времени на реализацию задач и проектов. Но и спустя более чем 60 лет существования отрасли, наши прогнозы все еще оставляют желать лучшего. Может быть, дело не в том, как именно мы пытаемся оценивать, а в том, что мы вообще опираемся на оценки?

К примеру, возьмите методологию Scrum, по которой сегодня работают многие компании. Центральная идея Scrum — брать в спринт не больше задач, чем ваша команда способна за это время выполнить. На первый взгляд, звучит разумно. К сожалению, слишком часто на практике этот подход приводит к замедлению работы команды в обмен на иллюзию планирования. Позвольте объяснить, почему.
Читать полностью »

Я, где-то с 2005 года, с перерывами, работаю в компаниях, которые решают задачи за деньги. Ну это когда клиент приходит, просит чего-то ему запрограммировать, мы делаем, и он нам платит. Там есть и проекты, но в тексте – только про разовые задачи. Да, это про 1С. Не про какую-то конкретную компанию – проблема одна для всех, нигде ее не решили нормально.

Так вот, самая скользкая тема в нашей работе – оценка трудоемкости задач. И гадость в том, что, какую бы оценку мы не давали, она будет казаться нечестной.Читать полностью »

Автор этого материала делится способом оценки времени, которое будет затрачено на переписывание уже внедренного проекта.

Цена изменений: во сколько на самом деле обойдется переработка кода - 1

По мере разрастания кода работать с ним становится все труднее. Годы разработки и отлавливания багов приводят к желанию перечеркнуть все и начать с чистого листа. Действительно, очень заманчива мысль о том, чтобы оставить ошибки в прошлом, вооружиться новыми технологиями и на этот раз все сделать правильно. Однако перед прыжком в бездну я все же предлагаю внимательнее присмотреться к реальной стоимости этого шага.

Модель оценки объема работ

Вы можете свести в один список все фичи своего приложения, а после оценить этапы и приблизительное время их переработки. Большинство именно так и поступает перед тем, как приступить к работе. Но почему тогда на практике выходит, что подобные проекты занимают в 4, 8 или даже 10 раз больше времени, чем разработчики заложили на старте?

Читайте также

Публикация о временных затратах на написание программного кода, которая пригодится при оценке объема работ: «Правило 10:1 в программировании и писательстве»

Есть три ключевых фактора, которые существенно растягивают процесс. И обычно при оценке затрат их игнорируют. Речь идет о
1) необходимости наверстать разницу между уровнями текущего и нового приложений,
2) объеме непредусмотренных изменений,
3) улучшениях, которые придется сделать, чтобы пользователи захотели перейти на новое приложение.

Цена изменений: во сколько на самом деле обойдется переработка кода - 2

Сокращение разницы

Первый фактор — новому приложению необходимо догнать текущее.Читать полностью »

Друзья, добрый день!

Мы продолжаем серию публикаций «без купюр» о проектах, связанных с разработкой, часто с приставкой «веб». Сегодня поговорим о том, как наиболее правильно и быстро проводить оценки работ и планировать релизы программной системы. Скорее всего, начинающие менеджеры и энергичные и ищущие себя разработчики будут шокированы рекомендациями, но, поверьте — цель стоит одна и только одна: помочь и сделать из вас настоящего джедая, который и пользу компании приносит, и проекты двигает, да и людей развивает одновременно. Такого джедая, который искренне не заслуживает быть обнаруженным в виде мумии в темной серверной между стойками с веб-серверами и базами данных веб-проекта, летящего в будущее без душевно документированного кода, ТЗ — лишь на энергии чистого «ХЗ». Итак, поехали!
Читать полностью »

«Почему Я?!»

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

Начнем по порядку. За время работы в ИТ ко мне, как в принципе, и к любому ИТ специалисту, приходят с просьбами оценить ту или иную задачу, функциональность или проект. Первая реакция у всех одна и та же: «Почему я?!». На такой вопрос идут типизированные ответы: «Ты же хотел чего-то нового?!», «Ты классный специалист!», «Это твое развитие!» и т. д. и т.п. Можете сами продолжить смысловой ряд, почему жребий судьбы пал именно на вас.

Все это конечно хорошо, но что делать, если тема для вас новая и оценивать не приходилось часто, а тут задача поражающая воображение: «Оцени нам, как отвезти человека на Марс!».
Читать полностью »

Существует множество способов оценить пользовательские истории. Мы используем собственную методологию, чтобы оценить и проработать задачи перед тем, как писать код. Как мы до этого дошли и почему наш подход лучше, чем Planing Poker, читайте под катом.

image
Читать полностью »

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

Позднее, конечно, я обнаружил, что по теме прогнозов написано несколько умных книжек, которые в сумме с некоторым опытом делают оценку задач хоть и неблагодарным, но и небезнадёжным занятием. Самым удобным способом, конечно, является оценка по аналогии: когда ты уже делал нечто подобное, ты довольно точно знаешь, каких усилий эта задача потребует. Но как быть в ситуации, когда опыта сравнительно немного или аналогии брать неоткуда, а оценить все же хочется?

В одной из команд, где я работал, мы придумали оригинальный метод для предварительной оценки задач. Метод синтезирует некоторые известные из литературы приёмы, но в приведённой форме, пожалуй, никем не описан. Концепция была следующей: объективность (связь с измеримыми показателями); интегрируемость с Agile; повторяемость; быстрота оценки (меньше 0.5% от объема задачи); доступность для начинающих разработчиков. Я буду рад обсудить нашу идею и не исключаю, что кому-то из Хабрааудитории она придётся по душе.
Читать полностью »

Лет 10 назад, когда я только начинал свой путь в игровой индустрии, слово инди ещё никто не произносил, а игровые корпорации на постсоветском пространстве казались всем мифической сказкой. В те прекрасные времена, когда на игровом рынке только расцветали первые российские браузерки, мы с другом начали делать свой проект. Мы не считали себя предпринимателями или стартаперами. Нет. Вчерашние студенты, обычные игроки, фанатеющие по Варкрафту, Героям и другим классическим играм. Сегодня я хочу поделиться с вами личным опытом, полученным за время инди-разработки браузерной игры с нуля. Начинающие разработчики, это статья для вас.

10 тезисов инди-разработки, которые привели к успеху - 1

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js