Никогда не оценивай проект в часах. Story Points лучше

Поділитися
Вставка
  • Опубліковано 26 бер 2023
  • Никогда нельзя оценивать проект в часах. Это ведет к переработкам, выгоранию и говнокоду. Story Points лучше!
    Подписывайся на
    📧 Телеграмм-канал: t.me/stringconcat
    ☝ Поваренная книга дядюшки боба: Как готовить Clean Architecture:
    🎓 Курс : howto.stringconcat.ru/cleanar...
    🎓 Разработка Приложений без Боли и Сожалений:
    howto.stringconcat.ru/enterpr...
  • Наука та технологія

КОМЕНТАРІ • 14

  • @kathwoo
    @kathwoo Місяць тому

    хехех, когда менеджер сидит и смотрит видос 😀

  • @user-jd4ym8sw8s
    @user-jd4ym8sw8s 9 місяців тому

    Прикольно конечно, но , как вообще планировать и закладывать сроки менеджеру при использовании сп?

  • @user-mj7zg4te9u
    @user-mj7zg4te9u Рік тому

    В целом работник или в вашем случае разработчик не Должен сам на вскидку называть срок выполнения работы - этим должен заниматься менеджер и не просто называть случайный срок, а считать сколько в сумме выйдет на все операции и сколько каждая операция отдельно займет по времени. Нужно учитывать изменения производительности труда со временем (обычно к концу дня/рабочей недели/ месяца эффективность снижается)
    Учитывать стаж каждого сотрудника, из-за разного стажа и опыты скорость выполнения одних и тех же задач будет разной.
    Нужно так же считать например сколько строк кода на разных этапах производства пишет один человек за час. (Цифра будет меняться от стажа, от фазы производительность труда и т.д.)
    Т.е. очень важно рассчитать параметры по которым можно будет оценить объем проделанной работы и скорость её выполнения.
    Т.е. менеджер по идее должен знать это и уметь считать, придумать способ как посчитать когда это новая или уникальная операция.

    • @bulsond
      @bulsond Рік тому

      "....сколько строк кода на разных этапах производства пишет один человек за час..." - так оценивали работу программистов в 70-х годах прошлого века. У программистов свои игрушки. Agile разработка называется, когда именно программеры, а не менеджеры оценивают задачи, которые берут(выбирают) в разработку.

  • @user-mj7zg4te9u
    @user-mj7zg4te9u Рік тому

    Интересный ролик, но такая проблема возникает когда нет формулы расчета трудоемкости выполняемой работы.
    Когда она есть то, задачи выполняются за то время которое просчитано и указано в плане.
    Собственно о том как посчитать трудоёмкость работы и на её основе составить план в человекочасах, человекоднях автор ролика и говорит.
    Менеджер должен уметь это считать.

    • @stringconcat
      @stringconcat  Рік тому

      Согласен, планирование - дело не легкое. А если не секрет, не покажите формулу по которой вы считаете?

    • @user-mj7zg4te9u
      @user-mj7zg4te9u Рік тому

      @@stringconcat Трудоёмкость это обратный показатель производительности труда.
      Производительность труда это количество продукции произведенное за определенное время, на каждого сотрудника участвовавшего в его производстве.
      Измеряется количеством продукции в штуках или в денежной стоимости.
      Трудоемкость это показатель деятельности предприятия отражающий затраты рабочей силы на производство единицы продукции. Т.е. он показывает сколько сотрудников и сколько времени потребовалось на производства товара.
      Существует много видов трудоёмкости и для каждого существует своя формула.
      Например фактическая трудоемкость считается так количество часов / объем произведённой продукции
      Средняя трудоемкость считается так время/число работников/ объём произведённой продукции
      Затем их сравнивают с плановым показателем трудоёмкости.
      Вот очень коротко в общих чертах.
      Я только учусь, так что подробнее ответить не могу. Но в целом я думаю, что расчет трудоемкости и планирование производственного процесса это не одна форма, а как минимум несколько а также это алгоритм действий которые необходимы для получения объективных данных. Для разных видов деятельности будет своя трудоемкость и своя скорость выполнения работы, а Также эти показатели будут разными для каждого коллектива.
      Но могу сказать, что вы нашли интересный метод для определения трудоёмкости задачи в условной сложности.
      Если бы я не знал трудоёмкость отдельных операций и всего процесса производства товара, то я также попытался спрогнозировать его через условные единицы сложности каждой операции.

  • @proofit404
    @proofit404 Рік тому

    Лучший 🎉

  • @sergey8366
    @sergey8366 Рік тому +1

    никогда не оценивате в sp - это не работает. просто смиритесь что сроки едут и все.

  • @YuliyaAnts
    @YuliyaAnts 9 місяців тому

    Как я могу поделиться этим видео если столько мата вначале? 😅 можно без мата записать тоже самое?))

    • @stringconcat
      @stringconcat  9 місяців тому

      Point Taken, что называется. Но простите, набитые шишки внесли свою окраску. Так же в свое оправдание могу сказать, что сквернословие применялось точечно и исключительно для внесения акцентов :)

    • @YuliyaAnts
      @YuliyaAnts 9 місяців тому

      @@stringconcat я понимаю, но к сожалению, не могу отправить коллегам такой ролик, хоть и информация в нем подана хорошо))

  • @akolchanov83
    @akolchanov83 Рік тому

    Анальные боли ))))