10 января в 15:37

Обратная сторона Agile из песочницы

imageХочу поделиться историей, ну и заодно услышать мнения других участников хабрасообщества. Это небольшая история о том, как агрессивное внедрение методологии разработки Agile (Scrum) в отдельно взятой российской IT компании послужило началом исхода из компании лучших разработчиков. Обычно в статьях про Agile рассказывают, какая это классная и полезная методология, и вообще — это лучшее, что было придумано в этом направлении. Возможно, эта статья поможет взглянуть на Agile с другой стороны, ведь у любой монеты, как оказалось, есть две стороны.

В общем, в 2010-м году была основана одна российская компания (что-за компания конкретизировать смысла нет), работала она в сфере IT-разработки (ПО для банковских продуктов).

Как водится, поначалу всё работало практически в режиме стартапа, но, тем не менее, компания уверенно стояла на ногах и быстро себя окупила. Постепенно число сотрудников компании росло, менеджеры, фронт и веб-разработчики, вот их уже перевалило за 50 человек и открылись первые представительства за рубежом.

По мере того, как росло число непосредственно разработчиков, проект привлекал инвестиции и нанимал новый управленческий персонал; появлялись технические директора, HR-отделы, куча административного персонала и бесчисленная армия менеджеров всех мастей.

Разработчики делали своё дело, проект был отлажен до мелочей; вроде бы всё было хорошо и ничего не предвещало резких изменений. Задачи ставились и выполнялись, за пять лет состав разработчиков сильно не изменился, через 5 лет после основания компании из неё не ушел почти ни один разработчик, стоявший у истоков. А это как по мне показатель того, что людям было комфортно работать в компании.

В один прекрасный момент руководство компании решило попробовать новомодную для России методологию разработки. Был выбран Agile (Scrum), в компанию нанят скрам-мастер, все разработки были переведены в TargetProcess. С точки зрения менеджмента это было сделано для того, чтобы улучшить скорость и качество разработки, а так-же получить понимание, на что тратят время разработчики. К слову, о разработчиках. Это действительно гениальные люди, владеющие поистине не малым стеком технологий и действительно переживающие за свой проект, знающие о сути самого проекта гораздо больше, чем менеджмент.

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

Поначалу, после внедрения новомодного Скрама, все радовались его логичности и внешней простоте. Всё понятно, делим процесс разработки на спринты, получаем от менеджеров user-story (задачи что делать), включаем их в те или иные спринты, в конце спринта делаем ретроспективу (смотрим что сделали, и что пошло не так) и зацикливаем этот процесс.

Но потом всё переросло в то, что отдел разработки превратился из ядра компании, приносящего деньги, просто в инструмент, наподобие отвертки или молотка. Менеджеры придумывали задачу, скидывали в IT-отдел и ждали реализации, попутно считая время, затраченное на разработку и тестирование. Разработчикам и тестировщикам было велено списывать время на выполнение задачи в TargetProcess. Менеджмент начал конвертировать задачи во время их выполнения и естественно в стоимость. Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками. Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика, ведь это просто обновление с одной версии на другую? Возможно, отдел разработки с точки зрения бизнеса всегда выглядит как ленивые сотрудники, которые хорошо, если бы смогли работать втрое, а лучше в пять раз быстрее, чтобы снизить расходы на разработку и увеличить её скорость.

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

После месячного негодования страсти немного поутихли, и отдел разработки понемногу свыкся с участью «отвертки».

Разработка ПО – это такое ремесло, которое тесно связано с творчеством, одну и ту-же задачу можно сделать либо хорошо, либо подойти творчески и сделать очень-хорошо.

Тут вспоминается выступление bobuk о том, как нужно обращаться с разработчиками. Ответ: как с детьми. Я, конечно, не считаю, что так нужно обращаться со всеми подряд, но нужно учитывать, что резкое изменение правил игры в компании может понравиться не всем.

Результатом внедрения такой методологии послужило то, что энтузиазм разработчиков поутих. Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало. Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами. Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.

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

Естественно, с точки зрения Менеджмента ситуация была более радужной, они получили полный отчет по времени, затраченном на разработку любого проекта, и понимание того, кто чем занимается почти в реал-тайм.

Но разработчики — тоже люди, и начали не выдерживать. Буквально за месяц компанию покинули 3 ключевых разработчика ядра. Замену которым в настоящий момент взять просто негде. Они работали в компании с самого момента основания и фактически сделали компанию тем, чем она является сейчас. Нагрузка на остальных разработчиков стала возрастать в геометрической прогрессии; отдел разработки зашатался как карточный домик, разработчики, которые работали в компании по 5 лет, стали уходить, т.к. перестали чувствовать себя частью компании, превратившись в «отвертку».

Резюме


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

Агрессивный переход на такие потоковые методологии разработки приводит к «формализации» отношений внутри компании. Результатом резких внедрений стало то, что менеджмент теперь лучше видит, что происходит в компании, но ключевых разработчиков в компании уже нет.

Говорить о том, что эти сотрудники виноваты сами, тем, что не смогли адаптироваться, или поступили высокомерно – как по мне, так это ошибка. Возможно, сам процесс внедрения Agile был организован неверно, но, так или иначе, свою черную сторону этот процесс имел.
@Keks650
карма
22,0
рейтинг 0,0
Похожие публикации
Самое читаемое Управление

Комментарии (580)

  • +5
    Т.е. людской ресурс — ошибка
    Человеческий потенциал — верно
    • 0
      Типичный Agile по-русски… Почему-то все забывают про то что «Люди и взаимодействие важнее процессов и инструментов». У меня про такой «scrum» целый набор историй и выводов. Я сам являюсь сертифицированным скрам мастером и agile специалистом. Тут еще вопрос к скрам мастеру — он должен не просто «внедрять процесс», но и защищать людей от менеджмента и объективно рисовать текущую картину как команде так и заказчику.
  • +40

    У меня только один вопрос: при чем тут Scrum/Agile? Ровно тот же эффект получается с любой (неправильно примененной методологией) с оценкой времени и внешней постановкой задачи. Какие специфичные для скрама особенности привели к описанному в посте результату?

    • +27
      Кажется, я понял автора. Попробую описать свой опыт до и после прихода скрама.

      Самое главное, скрам — это постоянный стресс. Разработчик сам оценил задачи (допустим, он это делает честно), и сам пообещал, что к концу спринта он их все сделает. Это давление собственного обещания можно выдержать неделю, месяц, но жить под ним годами тяжело.

      Второе — нет времени остановиться и посмотреть/подумать. Мне нравится исследовать логи, находить в них закономерности, проходить под отладчиком сложные места и убеждаться, что всё идёт правильно и ничего не сломалось, даже если никто не жалуется. Это даёт понимание, куда развивать проект, где были применены сильные и слабые решения. А если вдруг машина призадумывается, то это повод рассмотреть этот момент поближе. Но такой перерывчик может затянуться часа на 2-4, а что я завтра на утреннем митинге скажу, что ворон считал?

      Далее, тут отмечают, что большие рефакторинги и исследования новых фреймворков нужно выносить в задачи, обосновывая это погашением технического долга. Но я не знаю, как оно пойдёт! Вся магия в этом — может, я за 1.5 часа перелопачу 250 файлов, а может завязну на 2 дня, и сделаю revert changes, отложив до следующего раза (а в следующий раз сделаю за 1.5 часа, потому что оно варилось у меня в голове целый месяц и пришло понимание, как это должно быть сделано). Через планирование и приоритеты вся магия пропадает. Может, у меня плохое настроение я бы сегодня поковырял старые баги из трекера. Но нет — наверху висит рефакторинг, который я выпрашивал целый месяц — будь добр, вперёд и с песней, или что я скажу завтра на митинге? Нет, спасибо, я не предложу взять такую фичу в спринт. Остаётся только свободное время (вечера и выходные), что не всем подходит. Да и после хронического ощущения выжатости от спринтов уже мало хочется заниматься проектом на собственном энтузиазме.

      Тут ещё упоминали, что нужно 20% времени оставлять свободным, не загружать людей на 100%. Скажу, что этот мизер легко съедается разговорами с теми же бизнес-аналитиками («ты в прошлом спринте сделал доработку, что-то я не могу её проверить, покажи, как её пользоваться»), помощью коллегам и прочей текучкой.
      • +6

        Ну так и в вашем случае — при чем тут скрам? Возьмите любую методологию планирования, которая выглядит (грубо) как:


        1. дай разработчику оценить задачи
        2. выбери период времени
        3. накидай задач в этот период в соответствии с приоритетами и оценкой
        4. в конце периода проверь выполнение
        5. повторить

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


        Ну и дальше немного общих рассуждений, никак не связанных со скрамом:


        Это давление собственного обещания можно выдержать неделю, месяц, но жить под ним годами тяжело.

        Ээээ. Вы это серьезно? А мне казалось, что давать и выполнять собственные обещания — это нормально, а не тяжело. Собственно, это наша работа, нет? (это неплохо описано у Мартина в Clean Coder, кстати)


        Второе — нет времени остановиться и посмотреть/подумать.

        Есть. Оно должно быть заложено в оценку задач, которые вы выполняете.


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

        Ну так если вы не знаете, как оно пойдет, то и ваш менеджмент не знает, чего от вас ожидать. А это в бизнесе очень неудобно. Кто-то готов на такие риски, кто-то нет.


        Да и после хронического ощущения выжатости от спринтов уже мало хочется заниматься проектом на собственном энтузиазме.

        Аналогично, если спринты у вас оставляют ощущение выжатости — вы (или ваш менеджмент) что-то делаете не так.


        Скажу, что этот мизер легко съедается разговорами с теми же бизнес-аналитиками («ты в прошлом спринте сделал доработку, что-то я не могу её проверить, покажи, как её пользоваться»)

        Подобные "разговоры" тоже должны закладываться в оценку времени той же задачи. А если у вас и после этого не хватает времени на исследовательские работы, а они объективно нужны — значит, вам нужно не 20%, а 40.


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

        • +4
          Вы всё правильно написали, но много где называют «скрамом» то, что им не является.
          >>Второе — нет времени остановиться и посмотреть/подумать.
          Есть. Оно должно быть заложено в оценку задач, которые вы выполняете.
          Это убивает творческое начало. В любой момент мне в голову может прийти любая идея. И если её не проверить в ближайшие дни, она уже протухнет.

          Идеология скрама подавляет спонтанные идеи?

          вы (или ваш менеджмент) что-то делаете не так.
          Конечно, всё не так. Каждый спринт меняется состав задач и приоритеты в середине спринта. Часто берём задачи без полного понимания и оценки, потому что это очень важная задача важного человека, надо её в спринт пропихнуть, а там определимся по ходу дела. Часто возвращаемся к срочному мелкому (и крупному) допиливанию фич прошлого спринта, потому что то, что сделано, пользователям не понравилось (ну вот так, они думали, что хотят это а оказалось, что это выглядит не так, как они представляли и уже хотят другое).

          Менеджемент знает обо всех проблемах, но не может пойти против избалованных пользователей. Ведь «мы (IT) — сервис и должны быть клиентоориентированными». Так что скрам у нас — чистая фикция.
          • 0
            Вы всё правильно написали, но много где называют «скрамом» то, что им не является.

            Если кто-то где-то что-то не так называет, то это проблема того, кто не так называет, а не того, чем называют.


            В любой момент мне в голову может прийти любая идея. И если её не проверить в ближайшие дни, она уже протухнет.

            20% свободного времени. Или просто подойти к менеджменту и поговорить.


            Идеология скрама подавляет спонтанные идеи?

            Идеология предварительного планирования подавляет спонтанные идеи.


            Конечно, всё не так.

            Ну вот видите. И скрам у вас — чистая фикция, и описанные вами проблемы — не от скрама. Но почему-то претензии все равно к скраму.

            • 0
              Идеология предварительного планирования подавляет спонтанные идеи.

              Идеология предварительного абсолютно точного планирования 100% времени со буквальным следованием плану без пересмотра убивает спонтанные идеи :)


              Агилисты часто цитируют:


              План — ничто. Планирование — все. – Дуайт Эйзенхауэр
          • +1
            Ваш (ну, или не ваш) стартап просто превратился в бизнес.
            Из творческой мастерской, где можно в любой момент переключиться на проверку идей, просмотр логов, тестирование новых интересных плюшек — в инструмент по зарабатыванию денег. Программистов переставили от художественного холста к конвейеру.
            А по скраму вы работаете или ещё по какой методике — не имеет никакого значения.
          • 0
            Это убивает творческое начало. В любой момент мне в голову может прийти любая идея. И если её не проверить в ближайшие дни, она уже протухнет.

            Идеология скрама подавляет спонтанные идеи?


            Если ваша творческая идея требует совсем уж много времени — у нас это прекрасно согласовывается с руководством. Обсуждается на митингах (еще чего коллеги и посоветовать умного могут).

            Учитесь общаться с людьми.
            Руководство не заинтересовано просто выжать из вас соки.
            Руководство заинтересовано получить результат.
            Если ваше творческое исследование направлено на развитие коммерческого проекта и у проекта есть небольшая финансовая подушка — то вас поддержат, будьте уверены.

            Если будете молчать — то исход очевиден.

            По этому поводу анекдот:

            — У меня плохие отношения с женой.
            Я после операции, мне нужно кашки есть, а она готовит мне котлеты.
            Доктор сказал мне что нужно следить за питанием.
            У меня развилась изжога.
            Жена, гадюка такая, виновата.

            — А ты сказал жене, что доктор тебе велел придерживаться строгой диеты?

            — Нет.

            — И почему тогда жена виновата?

            • +1
              Да ну нафиг, объяснительные давать. Если продакт-оунеру надо, пусть сам ставит задачу.
              Простейший пример — немного подтормаживает какая-то операция. Может, кеш какой поставить, может сложность алгоритма уменьшить. Поковыряться надо часа 2-4.

              Ладно, когда это место прижмёт, вот тогда и поставят задачу. Причём разработчику, который не любит оптимизациями заниматься (потому что у него загрузка меньше).
              • 0

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

              • +1
                Да ну нафиг, объяснительные давать. Если продакт-оунеру надо, пусть сам ставит задачу.
                Простейший пример — немного подтормаживает какая-то операция. Может, кеш какой поставить, может сложность алгоритма уменьшить. Поковыряться надо часа 2-4.


                Что значит: «пусть сам ставит задачу, если ему надо»?
                Это же только ты, закопавшись в детали, изнутри видишь, где это тормозит и всего 2-4 работы.
                Видишь — скажи.
                • +2
                  Если видят, что тормозит все, то поставить задачу должно руководство, если считает это проблемой. Если видишь только ты (понимаешь, например, что поиск по индексированному полю не должен быть таким долгим), то и проблемы нет :)
                  • 0

                    Это может быть проблема, невидимая руководству. В данный конкретный момент.

                  • 0
                    Вижу такую проблему, которая приведёт к таким последствиям для пользователя. И пусть решают.
        • +2

          Вы случайно не срам-мастер из вышеописанной конторы?

          • +2

            Случайно, нет.


            Я, если что, не считаю, что в конторе "все было хорошо", я просто считаю, что эти проблемы были вызваны не скрамом.

        • +2
          Есть. Оно должно быть заложено в оценку задач, которые вы выполняете.

          Подобные «разговоры» тоже должны закладываться в оценку времени той же задачи. А если у вас и после этого не хватает времени на исследовательские работы, а они объективно нужны — значит, вам нужно не 20%, а 40.

          Что-то у вас слишком много времени «закладывается». Это ваше соотношение 80/20, 40/60, или даже 90/10 всегда будет таким для каждой задачи, или это всё-таки зависит (от погоды, от настроения разработчика, да хоть от магнитных бурь на Солнце)?
          • 0

            "Закладывается" столько, сколько нужно, чтобы оценка приближалась к реальности. Если разработчик знает, что после дня собственно разработки ему еще нужен день "походить под отладчиком" и "посмотреть на логи", значит оценка задачи — не день, а два. Если разработчик — или тимлид, или менеджмент — знает, что после завершения задачи еще полдня неизбежно уйдет на объяснения, как тестировать — значит, надо приплюсовать эти полдня к оценке.


            (а 20/80 и так далее — это не для задачи, это вообще свободное время, оставляемое в итерации на исследования)

            • 0
              Оценивать задачу путем вопроса «сколько это займет времени?» — ущербный подход.
              Гораздо более хороший подход — Due Date. Т.е. «сколько ты успеешь к такому-то времени?». На практике эта методика оценки ведет к менее частым срывам сроков. Не очень понятно зачем скрам-мастерам требуется знать сколько времени уйдет на каждую отдельную задачу. Гораздо важнее знать что и к какому сроку человек успеет сделать. Если на то пошло, то от этого и надо плясать, а не выдавливать из разработчиков человеко-часы, играя на их неспособности к адекватной оценке и риск-анализу за 5 минут в голове.
              Все равно что пытаться выдавить из токаря на станке оценку того, сколько времени он будет точить одну болванку. Он не может сказать. Зато может сказать сколько болванок он сделает к следующему понедельнику, если вы прямо сейчас от него отлупитесь.

              К тому же, на сколько я понмю, в скраме же нет «времени», есть же «поинты» и во всех книжках одно время талдычили что поинты != время, и вообще оценка сравнительная, чтобы определить что сложнее, а что легче.
              • 0
                Оценивать задачу путем вопроса «сколько это займет времени?» — ущербный подход.

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


                К тому же, на сколько я понмю, в скраме же нет «времени», есть же «поинты»

                Так я и не про скрам говорю, а про абстрактную систему планирования в вакууме.

                • 0
                  одно легко выводимо из другого.


                  Теоретически да. Практически — такой подход переворачивает в голове разработчика процесс оценки с попытки определить объем работ по задаче и проанализировать риски на «набрать себе лукошко задач и разгребаться с ними». Вы можете поделить время до дедлайна разделив кол-во дней в часах на кол-во задач и получить нужную вам (а не разработчику) оценку. Разработчик (как и любой человек) не способен к быстрой оценке объемов работы. Однако оценивалка в режиме «успею-не успею» работает у людей куда лучше. Рекомендую попробовать.
                  • +1

                    Проблема в том, что у меня регулярно бывает ситуация "вот есть десять задач из роадмапа, надо оценить, какая сколько займет, чтобы понять, в каком порядке их выгодно делать, и на какие версии делать анонс". Задачи, очевидно, не одинаковые по сложности (иногда на порядок).

                    • 0
                      Собственно, это основная причина для чего нужна оценка времени — составить план работ на текущий список задач.
                      • 0
                        Боюсь, вы путаете приоритеты и оценку по времени.
                        Бывает что задача на 15 минут, но сделать её надо вотпрямщас, а бывает что месячный трип по мозгу заказчика задачи может быть в целом несрочным. Равно как и наоборот.
                        В любом случае оценивать мелочевку смысла не имеет — имеет смысл делать её сразу же пачкой.
                        А да, еще есть задачи-детонаторы, выполняемые например в режиме «сделать первую версию — а там посмотрим» и/или с пометкой «уточнить требования».
                        • 0
                          Не путаю. Приоритеты зависят от оценок. Грубо, задача очень важная, но при оценке в неделю другие задачи от 15 минут до пары часов всего дня на 3 подождут, но при оценке в месяц — сначала сделать их.

                          Это бизнесу решать к какой мелочевке надо приступать моментально, а какую можно копить годами.
                  • +1
                    Однако оценивалка в режиме «успею-не успею» работает у людей куда лучше.


                    Простите, но не верю. Если человек не может приблизительно оценить отдельно задачи А, Б и В, на чем основана его оценка «успею все три сегодня»?
                    • +1
                      Простите, но не верю. Если человек не может приблизительно оценить отдельно задачи А, Б и В, на чем основана его оценка «успею все три сегодня»?


                      На безудержном оптимизме разработчиков в своих оценках
                      Читайте Брукс «Мифический человеко-месяц».
                      • +1
                        Везде эти оптимисты… И в скрамовском planning poker оптимисты насчет оценок, и в настоящем покере тоже оптимисты, у которых дырявый стрит из 3 карт обязательно соберется на ривере.
                        • 0
                          Везде эти оптимисты… И в скрамовском planning poker оптимисты насчет оценок, и в настоящем покере тоже оптимисты, у которых дырявый стрит из 3 карт обязательно соберется на ривере.



                          Настоящий покер — не тот пример.
                          В покере-то как раз в этом весь смысл (ну 50% смысла) игры.
                          Это же игра!
                          А если рассматривать покер с финансовой точки зрения — покер без блефа не даст вам превратить его в источник заработка, а навсегда останется всего лишь хобби (к слову, даже неинтересным хобби, ибо без блефа покер не покер).

                          А название planning poker отражает всего лишь юмор создателей, не стоит тащить в Scrum принципы покера из реальной жизни. Они всего лишь отдаленно похожи, не более того.

                          • 0
                            В покере-то как раз в этом весь смысл (ну 50% смысла) игры.
                            Это же игра!


                            Для хорошего игрока партнер с таким мышлением — отличный источник заработка (fish).
                          • 0
                            Можно рассматривать «planning poker» Scrum, как идентификацию и оценку риском методом методом экспертной оценки и прецедентов.
                            Тогда все становится на свои места :)
                • 0
                  Я, прямо скажем, вообще не очень не понимаю, почему противопоставляется «сколько времени займет эта задача» и «к когда ты сделаешь эту задачу» — одно легко выводимо из другого.

                  Например, мне надо подготовить 6 бумажек, которые я бы сделал за 3 часа + час запаса. Но так как начало года — это безумие, когда меня разрывают по телефону, а кто не дозванивается приходит лично — то я сделал эти бумажки в тот же день только потому что задержался на работе. Или делал бы их два дня.
                  То есть в среднем надо 4 часа, но реальность — это не сферический конь в вакууме.
                  • 0

                    … и как вам поможет оценка "успеешь к такому-то времени"?


                    (Но вообще, конечно, приведенная вами ситуация — классический пример несовпадения планируемых оценок с реальностью. Ну да, бывает. Не повод не планироваться вообще.)

                    • 0
                      и как вам поможет оценка «успеешь к такому-то времени»?

                      Обычно я представляю «внезапную» нагрузку неким средним числом по времени. Также очень помогает ориентироваться сколько человек сейчас в отделе и все ли работают полный день, чтобы делегировать некоторые работы другим.
                      Но вообще да, лучше взять в два раза больше времени чем требуется и сделать не торопясь, передохнуть и перепроверить, чем ограничить себя во времени заранее.
                      при этом ориентир «это требуется завтра после обеда», значительно понятнее, чем «данная работа займёт два часа». Причина — я не фрилансер и выполняю более чем одну задачу за день. В моём рабочем дне надо выделить два часа.
                      • 0
                        В моём рабочем дне надо выделить два часа.

                        Разве не в этом цель планирования?

                        • 0
                          Разве не в этом цель планирования?

                          Цель планирования в контексте обсуждения — это менеджеру, который совсем не шарит в моей работе определится за какое время я выполню конкретную задачу. Моя задача выполнять работу из моей должностной инструкции, в которой множество пунктов «следить, чтобы всё работало». Обратите внимание, я работаю по принципу первой части статьи.
                          Если у нас спор, то хочется узнать суть спора.
                          • 0
                            это менеджеру, который совсем не шарит в моей работе определится за какое время я выполню конкретную задачу.

                            Это не конечная цель. Конечная цель все же определиться успевает ли команда сделать скоуп работы, или что именно успевает сделать команда. Оценка от разработчика — это очень примерное число которое дает какое-то представление о временных затратах. Есть еще масса переменных которые влияют на конечный результат но как правило типичный менеджер (да и разработчики) их не учитывает.

                            • 0
                              А может цель изначально определить когда конкретный скоуп будет закончен?
                              • 0

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


                                Если же у нас фиксированный бюджет и фиксированный скоуп (как делает наверное большинство), то тут уже скрамы не помогут ничем, поскольку будет все хорошо или нет уже зависит только от оценки данной на самом раннем этапе при выборе этого фиксированного скоупа/бюджета.

                                • 0
                                  Если же у нас фиксированный бюджет и фиксированный скоуп (как делает наверное большинство)
                                  В момент когда так начинает делать ваше начальство — пора искать другую работу.

                                  Разработка тем и отличается от других видов деятельности, что так сделать — не получается. Вернее получается — но за счёт «выдавливания» из разработчиков всех соков (почти все проекты почти во всех областях выходят за рамки изначального бюджета — это просто факт).

                                  И дальше — уже неважно, какие умные слова вы на это вешаете…
                                  • 0
                                    В момент когда так начинает делать ваше начальство — пора искать другую работу.

                                    Разработка тем и отличается от других видов деятельности, что так сделать — не получается. Вернее получается — но за счёт «выдавливания» из разработчиков всех соков (почти все проекты почти во всех областях выходят за рамки изначального бюджета — это просто факт).


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

                                    RAD-development, фреймворки и т.п.
                                    Например фрейморк был придуман именно для того, чтобы поддерживать быструю разработку в крупном СМИ, где постоянные изменения.

                                    • 0

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

                                    • +1
                                      Например фрейморк был придуман именно для того, чтобы поддерживать быструю разработку в крупном СМИ, где постоянные изменения.
                                      Там был скрам?
                                      — Ну как продвигается спринт?
                                      — Да никак, отстаньте, я фреймворк пилю. Через 2 месяца будет готов, тогда и полетим…
                                • 0
                                  С фиксированным скоупом и бюджет есть, как минимум, вариант поиграть рейтами.
                • 0
                  Это вопрос, скажем так, неочевидный. Я, прямо скажем, вообще не очень не понимаю, почему противопоставляется «сколько времени займет эта задача» и «к когда ты сделаешь эту задачу» — одно легко выводимо из другого.


                  У меня был один знакомый разработчик, которое сие сильно затрудняло.

                  Загадка быстро открылась: он делал «левую» работу и ему было проще в голове посчитать «до какого», чем «сколько займет».
              • +1
                Если на вопрос «сколько это займет времени?» я ещё хоть как-то могу прикинуть ответ в человеко-часах, то на вопрос «сколько ты успеешь к такому-то времени?» только один ответ: «не знаю, может я к этой задаче вообще не приступлю к такому-то времени».
              • 0
                Если на то пошло, то от этого и надо плясать, а не выдавливать из разработчиков человеко-часы, играя на их неспособности к адекватной оценке и риск-анализу за 5 минут в голове.

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


                Пример с токорем не корректный.
                Он их в день 100 штук точит, потому и не знает сколько уйдет на одну, тут ему больше подумать нужно, разделить арифметически.

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

                Проблема оценки сроков имеется только до уровня middle.
                Ты не senior, если не знаешь, что любой оцененный тобой срок прежде чем озвучать, нужно умножить на 3.
                • 0
                  Ты не senior, если не знаешь, что любой оцененный тобой срок прежде чем озвучать, нужно умножить на 3.

                  Зависит от последствий этого озвучивания. Иногда лучше разделить на три.
                • 0
                  Как говорил один мой знакомый — как раз — CEO — не умножай оценку. Ни на 2, ни на 3 — не спасет. И-таки да, в большинстве случаев не спасает.
                  • 0
                    Как говорил один мой знакомый — как раз — CEO — не умножай оценку.


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

                    Или он имел ввиду другое: разработчик, сообщай мне исходные оценки, я сам умножу их на 3. То есть во избежание коэффициента 9 в итоге.

                    Правило об оптимистичности разработчиков в оценках известно уже 50 лет как.
                    Детально рассказано об этом из опыта разработки операционной системы в IBM.
                    Книга Брукса «Мифический человеко-месяц» — книга тоненькая, можно легко прочитать.

          • 0
            Что-то у вас слишком много времени «закладывается». Это ваше соотношение 80/20, 40/60, или даже 90/10 всегда будет таким для каждой задачи, или это всё-таки зависит (от погоды, от настроения разработчика, да хоть от магнитных бурь на Солнце)?


            Вообще не проблема.

            Для проверки какой-то серьезной гипотезы у нас менеджер проекта явным образом выделяет время.

            Не только автоматически 10/20/30%, а еще и явным образом — «проверишь? да. когда результат? послезавтра скажу» — и все, человек официально занят делом, проверяет гипотезу.

            Просто беседуйте с коллегами, с руководством, говорите, что вам нужно.
            Они ваши мысли не читают.

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

      • +3
        Большие рефакторинги надо относить на отдельную стадию разработки и согласовывать с управленческим звеном/клиентами. Т.е. «пока нет срочных задач». Исследование фреймворков надо относить на отдельных людей вне команды работы над продуктом, а потом вливать эти знания обратно в команду через тех самых отдельных людей. Но это особая управленческая магия, которая многим не по зубам.

        А в остальном lair прав. Agile/Scrum тут ни при чем. Как раз процесс — это отвертка и инструмент. Внедряющий должен хорошо понимать границы его применимости для данной конкретной команды разработчиков и для данного проекта. И лично я не раз отмечал в отечественных компаниях отношение к методологии управления как к волшебной таблетке, которая может починить разом все огрехи проекта, превратить разработчиков в добрых паладинов, а заказчиков — в белых котяток, ну а бонусом прекратить войну на ближнем востоке и предотвратить кризисы капитализма. Очевидно, оно так не работает. Любая методология управления в любой компании де-факто гибридна и претерпевает множество поправок на объективную реальность, а то и вообще собрана из кусков разных методологий. Кто не умеет этого признавать — получает по голове в долгосрочной перспективе и обречен ходить по граблям.
        • +2
          А в остальном lair прав. Agile/Scrum тут ни при чем. Как раз процесс — это отвертка и инструмент.

          Угу. Если процесс позиционируется как средство решения конкретных проблем, но в подавляющем большинстве случаев их не решает, а только усугубляет, то дело, конечно, в погоде на марсе, а не в процессе! Верующие в скрам, такие верующие…

          • –1

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


            В целом мыслить категориями "скарам всегда хорош просто вы не умеете его готовить" это тоже так себе идея. Если бы это было так, никто бы не придумывал XP/FDD/Kanban. Но и говорить что скрам никогда не работает это уже другая крайность.


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

            • 0
              В целом мыслить категориями "скарам всегда хорош просто вы не умеете его готовить" это тоже так себе идея.

              Я понимаю, почему нельзя считать такой постулат догматом, но почему нельзя мыслить этими катерогиями?


              Почему хотя бы нельзя задаться вопросом, "А скрам ли это?" "А правильно ли мы его готовим?"?


              Если бы это было так, никто бы не придумывал XP/FDD/Kanban.

              Может их придумали не потому, что скрам нехорош, а потому что он хорош, но можно лучше :)

              • 0
                Почему хотя бы нельзя задаться вопросом, «А скрам ли это?» «А правильно ли мы его готовим?»?


                К нам пришёл ПМ и сказал: «Да будет скрам, а я будут продакт аунером и скрам-мастером.» И увидели мы, что скрам это плохо для нас. Что имеете в виду под скрамом вы — мы не знаем. То, что было у нас — практически совпадает с описанием на вики. Если вы считаете, что там неправильно, то поправьте, чтобы мы не называли скрамом, то, что было у нас.
                • 0
                  практически совпадает с описанием на вики

                  Надеюсь, это была не русскоязычная википедия?

                  • 0
                    Зря )
          • 0
            Поверьте, если вы пытаетесь тапком забивать гвозди, а они не забиваются — то это ваша и только ваша вина.
            • 0

              Если на тапке написано — предназначен для забивания гвоздей, то виноват тапок и те религиозные фанатики, которые веруют и проповедуют, что тапок способен забивать гвозди, а те, у кого не получилось — сами виноваты. Даже несмотря на то, что тапком таки иногда можно забить гвоздь в неслишком замороженное сливочное масло. У вас отличная аналогия — спасибо!

              • 0
                Мне кажется, даже если тапок и вправду предназначен для забивания гвоздей, возможно в том числе и неправильное его применение. Как на кадрах 11 и 12.
                Широко известный в узких кругах источнник
                image
              • 0
                Ну у вас же своя голова на плечах есть? Вы же можете визуально отличить тапок от молотка, а масло от бетонной стены, верно?
                Я не агитирую за скрам, поверьте, нет. Я лишь говорю что скрам — это инструмент, все холивары вокруг которого рождаются от того, что натянуть его пытаются туда, куда он не налазиет. И делают это всегда конкретные люди, которые, видимо, не отличают тапок от молотка.
                В то же время, я не исключаю что для некоторых инструментов множество случаев, где их можно успешно применить — пустое ;)
                • +1
                  Ну у вас же своя голова на плечах есть? Вы же можете визуально отличить тапок от молотка, а масло от бетонной стены, верно?

                  Отчего же? Я — могу. Поэтому и считаю скрам антиаджайлом. А вот верующие не могут. Они считают, что если им удалось забить гвоздь тапком в масло, то им можно забивать и в бетонную стену, а если не получилось — ну, не тапок же виноват, в самом деле — значит у вас был "неправильный" скрам.

                • +1
                  Вы же можете визуально отличить тапок от молотка, а масло от бетонной стены, верно?

                  В бетонную стену и молотком лучше гвозди не забивать…

      • 0
        Самое главное, скрам — это постоянный стресс.

        Постоянный стресс свидетельствует о плохом планировании а никак не следствие какой-то методологии.


        Разработчик сам оценил задачи (допустим, он это делает честно), и сам пообещал, что к концу спринта он их все сделает.

        Если разработчик не закладывает время на митинги, попить кофе, подумать… то он сам себе злой буратино. Есть еще риски которые тоже имеет смысл закладывать.


        В целом неспроста многие оценивают все это добро в относительных единицах измерения (стори поинты, t-shirt sizes и т.д.) что бы уйти от времени и упростить оценку. Лично мне больше всего нравится t-shirt sizes (small, medium, large, xlarge, etc) на основе которого оценивается сложность. А сколько это займет по времени — это уже менеджер может из джирки посчитать (если задачи нормально дробятся).


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

        Закладывайте просто 20% времени на погашение технического долга. Не хватает — 30%. Больше — тогда есть вопрос что вы там устраняете. Возможно те рефакторинги которые вы делаете просто не нужны. Разработчики очень часто болеют подобным.


        Вся магия в этом — может, я за 1.5 часа перелопачу 250 файлов, а может завязну на 2 дня

        Подобные волшебные рефакторинги допускаются только если у вас система покрыта автотестами на 100% иначе шанс схлопотать регрессию заоблочный. Вы не сможете руками все проверить. И опять же очень большой вопрос почему у вас возникает необходимость в таких рефакторингах. Есть задачи которые затрагивают все 250 файлов? Сильно в этом сомневаюсь. Чаще всего разработчику просто хочется пострадать перфекционизмом.


        Скажу, что этот мизер легко съедается разговорами с теми же бизнес-аналитиками

        Разговоры/митинги закладываются в оценку. И все становится чуть проще.


        p.s. Есть еще очень крутая штука для оптимизации процессов — теория ограничений называется.

      • 0
        Самое главное, скрам — это постоянный стресс. Разработчик сам оценил задачи (допустим, он это делает честно), и сам пообещал, что к концу спринта он их все сделает. Это давление собственного обещания можно выдержать неделю, месяц, но жить под ним годами тяжело.

        Второе — нет времени остановиться и посмотреть/подумать. Мне нравится исследовать логи, находить в них закономерности, проходить под отладчиком сложные места и убеждаться, что всё идёт правильно и ничего не сломалось, даже если никто не жалуется. Это даёт понимание, куда развивать проект, где были применены сильные и слабые решения. А если вдруг машина призадумывается, то это повод рассмотреть этот момент поближе. Но такой перерывчик может затянуться часа на 2-4, а что я завтра на утреннем митинге скажу, что ворон считал?


        Читайте классику: Брукс «Мифический человеко-месяц».

        И просто оценивайте проект с коэффициентом 3.
        Тогда у Вас будет время на логи.
        ;)

        А если вдруг машина призадумывается, то это повод рассмотреть этот момент поближе. Но такой перерывчик может затянуться часа на 2-4, а что я завтра на утреннем митинге скажу, что ворон считал?


        Вы не «Вася вышел в поле погулять да ворон посчитать», а "инженер по разработке программного обеспечения".

        И ваша задача — все это учитывать, вас для этого и наняли. Потому оклады разработчикам нынче и существенно выше средних зарплат в других профессиях.
      • 0
        Тут ещё упоминали, что нужно 20% времени оставлять свободным, не загружать людей на 100%. Скажу, что этот мизер легко съедается разговорами с теми же бизнес-аналитиками («ты в прошлом спринте сделал доработку, что-то я не могу её проверить, покажи, как её пользоваться»), помощью коллегам и прочей текучкой.


        Когда хотят 20% рабочего времени в танчики играть да в контактике шариться, то забывают упомянуть, что это взято по примеру Google:

        1. А у них изначально высококвалифицированнейшие специалисты работают.
        2. У Google есть финансовая подушка.

        Мы проводили этот эксперимент.
        Львинная доля сотрудников восприняла 20% как возможность заниматься совсем уж не относящимися к делу вещами. Да, да, да — танчики и вконтактик.

        Только самые высококвалифицированные и высокооплачиваемые у нас поняли все правильно. И развивали себя и наш проект и родственное ПО.
      • +1
        Разработчик сам оценил задачи (допустим, он это делает честно), и сам пообещал, что к концу спринта он их все сделает. Это давление собственного обещания можно выдержать неделю, месяц, но жить под ним годами тяжело.


        Вы путаете, в SCRUM'е нет понятия commitment, в нем есть понятие прогноз. Т.е. возможно задача будет сделана, возможно и нет. При этом это не проблема если какая-то задача не войдёт в спринт или «вывалится» из него.

        Основная проблема в данном топике, а точнее их две:
        1. Это куча stakeholder'ов, которые переросли в Product Owner'ов, коих как раз должен быть один и только один(!).
        2. Итальянская забастовка, устроенная разработчиками.
        при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача
        . Возможно в данном вопросе я и не прав, но походу скрам мастера у них не было или работал он через ректум, бо подобные вопросы с менеджментом должен утрясать именно он.
    • +2
      Особенности… э, ну, никакие, Кроме того, что какая-то методология все-таки была изначально, пусть и не была нигде формализована, но работала, и ее изменение (без какого-то реального обоснования) на «перспективную», а прямо сказать — на «модную» и вызвало то что вызвало.

      Т.е. буквально — да, Agile тут не при чем. А фактически — очень даже.
      • 0

        А теперь представьте, что старую методологию заменили не на Agile, а просто на строгое формальное планирование (я как раз комментарием выше его описал). Что-то изменится в посте? Думаю, нет.


        Так что "при чем" тут не Agile, а (неумело сделанное) планирование.

        • +2
          Ну в общем да. Фактически тоже самое наверное было бы при попытке внедрить любую другую методологию.

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

          И очень редко, если вообще когда-либо понимают, что эффективнее работают довольные работой люди.
          • 0
            Впрочем, я видел примеры когда пытаются внедрить Agile разработчики. В этом случае — в 100% потому что «модно» (даже если на самом деле уже и не так). Результаты в этом случае почему-то тоже плачевные.
            • +2
              А тут как с прокалыванием уха.
              Если не знаешь как правильно — останешься без половины уха.

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

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

              Хоть автор и не указал этого, но уверен у менеджмента был KPI. И с самым менеджментом никто не церемонился…
              Если кто и виноват — то это не просто менеджмент, а топ-менеджмент (генеральный и прочие бесы совета директоров). В конце концов, неужели никто не предпринимал попыток решить данный конфликт сверху?
              Всегда можно докопаться до перво причин, и их исправить.
              Не докопались? Не исправили? Сами виноваты…
          • –1

            … вот и выходит — что Agile/Scrum тут ни при чем. И пост не про "обратную сторону Agile", а про (обратную ли?) сторону плохого руководства.

            • +2
              Читая статьи про Agile/Scrum и разбор полетов в комментариях, всегда встречаю такой вывод — если не сработало, значит, делали неправильно.
              Подозреваю, что это неверное суждение.
              • 0

                Но в данном случае и правда хорошо видно, что делали неправильно. И дело не в том, что Scrum/Agile хорошие — про это у меня нет достаточно собственного опыта обсуждать, — а в том, что описанное в статье можно получить и без их применения, достаточно просто использовать ту же тактику.

    • +4
      Agile при том, что в данной реальной истории внедряли именно его. И автор, на мой взгляд отлично проанализировал последствия этого «внедрения».
      • 0

        Вы считаете, что если бы те же люди внедряли другой процесс (скажем, CMMI), ситуация была бы радикально другой?

        • –1
          Думаю, что та же.
          • 0

            Ну то есть описанное в посте — это "обратная сторона" Agile, CMMI, MSF и так далее… да?

      • +1
        В то же самое время там упомянут и переход с Symfony 2.6 на Symfony 3.0. Может, если бы не переходили, ничего подобного не случилось бы? Может, это — причина бед?

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

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

        Не конкретная методология виновата, а стадия развития компании.
        • –1
          В то же самое время там упомянут и переход с Symfony 2.6 на Symfony 3.0. Может, если бы не переходили, ничего подобного не случилось бы? Может, это — причина бед?


          Переход в целом мягче чем переход между Ubuntu 14.04 и 16.04 на которых Symfony крутится. Проблемы с BC конечно были и есть, но в принципе ничего такого, чтобы сорвать работу целого отдела надолго.
          • +1
            Это был риторический вопрос. :)
    • 0

      После прочтения та же мысль. Проблема не в фреймворка, а в менеджменте в целом. Не просчитали риски изменений. Ну и логирование времени совершенно обычная практика для аутсерса. Странно что это вызвало такой коллапс в отделе. А в серами вообще нет времени, есть только SP, которые про сложность задач. Оценка в часах и привязка к 40 часам в рабочей неделе от бизнеса.

  • +25
    Проблема не нова и типична. Беда не в скраме, а в набранных с улицы менеджерах. Которые, естественно, стали выяснять отношения кто тут главный методом запрягания разработчиков. Ведь оценка менеджера в глазах начальства — это именно количество выполенных с подачи данного менеджера «фич». Больше фич — выше менеджер в иерархии, и побоку на их срочность/важность.
    • +2
      И можно возобновить дискуссию о том, что управленец обязан разбираться в том, чем управляет и при необходимости заменить того, кем управляет.

      Перефразирую, сегодня в фаворе не безкорыстные творческие созидающие личности, а подхалимы, показушники и вот грустно… каков итог этого процесса?
      • +4
        Сказано же: «Задачам стали присваивать приоритеты»
        Если менеджер сам не знает и при этом не консультируется у разработчика как надо разрабатывать, то какого качества от него приоритеты будут приходить?
        Конечно будут ставить наименьший приоритет всем задачам сопровождения — обновлению библиотек и фреймворков, рефакторинг, исследование киллер-фичи и т.д.
        Вменяемые разработчики или будут отстаивать свою позицию (но недолго) или уйдут.
        Останутся те, которые уйти не могут/не хотят и те, которым наплевать на задачи сопровождения.
        И да, никакого отношения к Agile это не имеет.
        • +3
          Ну, понимаете, отношения-то не имеет, и менеджеров в Agile вроде как не предусмотрено — но вся беда в том, что внедряют-то зачастую именно они. При этом как резонно отмечено уже я нескольких комментах — ничего не понимая в том, чем управляют.
          • 0
            и менеджеров в Agile вроде как не предусмотрено — но вся беда в том, что внедряют-то зачастую именно они

            Есть Product Owner, с ОБЯЗАННОСТЬЮ сформировать backlog спринта.
            Этого более чем достаточно. Если он не в состоянии этого сделать, то утопить такого менеджера, что бы не мучался…
            Команда, в данном случае, выступает как инструмент оценки для product owner-а
    • +1
      Соглашусь, что я вижу в данном случае больше проблему со стороны внедренцев и менеждеров, от себя добавлю, что устроив срач они полностью убили внутреннюю атмосферу, хотя изначально надо было приходить, смотреть как оно работает и по чуть-чуть что-либо менять и за каждым изменением наблюдать, какое оно дает результат.
    • +1
      Скорее беда в тех кто этих менеджеров набирал. Обычная, в общем то история. Нанимается некий специалист из числа узнанных на конференции с жаром рассказывающий как он внедрял и какую выгоду получила компания. Тот не имея представления о истории и сложившейся внутренней культуре компании начинает «роботизировать» рабочий процесс.
      В этой истории смущает одно. Если компания формировалась с уровня стартапа, то почему внедрение системы шло без участия разработчиков. Откуда взялся такой упёртый и оторванный топ-менеджмент.
    • 0
      Вот блин на все 100% согласен, особенно при том, что Scrum подразумевает то, что в процесс разработки менеджмент вообще не должен лезть к разработчикам, для этого есть скраммастер, а это вообще специфическая должность, поскольку он должен с одно стороны пинать разработчиков с другой зад им подтирать, и это только малая доля идеологии Scrum. А получается так, что повесили доску со стикирами и стали каждый день пинать программистов и обозвали это все модным словом.
    • 0
      Проблема не нова и типична. Беда не в скраме, а в набранных с улицы менеджерах. Которые, естественно, стали выяснять отношения кто тут главный методом запрягания разработчиков. Ведь оценка менеджера в глазах начальства — это именно количество выполенных с подачи данного менеджера «фич». Больше фич — выше менеджер в иерархии, и побоку на их срочность/важность.


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

      Но реально заинтересованное лицо (владелец-управлящий) или просто компетентный менеджер прекрасно понимает что «все в этом мире что-то стоит».

      Давайте я вам пример попроще продемонстрирую:

      Менеджеры-продажники должны продавать.
      Им разрешается продавать в кредит.
      Круче тот, кто больше продал? Да. Но факт продажи проверяется не про отданным покупателям без денег в кредит товарам, а по реально полученным от покупателей деньгам.

      Так же и здесь:
      Зачем, думаете, все эти часы считаются? Только чтобы разработчиков в зарплатах урезать?
      Нет, в том числе и чтобы оценивать себестоимость.
      Чтобы было видно и в том числе такую вещь как: менеджер протолкнул 100500 фич принесших 1 млн. долларов, но стоивших в разработке при этом 2 млн. долларов. А другой менеджер протолкнул фич на 500 000 при себестоимости разработки фич в 300 000.
      Кто из этих менеджеров полезнее для фирмы?

      Менеджеров с дурной инициативой — прекрасно и быстро увольняют/понижают. Видел неоднократно.
  • +15
    Скрам даже слова такого не знает «менеджер».
  • +17
    Заголовок про скрам и аджайл, в тексте про:
    отдел разработки превратился из ядра компании, приносящего деньги, просто в инструмент, наподобие отвертки или молотка.

    Понимаю, обидненько. Только процессы тут не при чем.

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

    Вообще никакого отношения к agile не имеет. Аджайл учит менеджеров очень трепетно и бережно относиться к эстимейтам разработчиков и ни в коем случае не считать их последним дедлайном.
    Единственный срок который есть — конец спринта, который должен закончиться поставкой работающего функционала. И то, это только значит, что к концу спринта продукт должен получить позитивные изменения. Это не значит, что все задачи обязаны быть в Done.

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

    Во первых, нет вещей и задач, которые не могут быть завернуты в UserStory. Просто источником этих юзерстори может быть не только стейкхолдер, но и сама команда.
    Во вторых, если вы откроете agilemanifesto.org вы во втором же абзаце увидите, что
    Individuals and interactions over processes and tools

    А это напрямую противоречит вашему утверждению.

    Так может быть, проблема не в аджайле, а во внедренцах?

    P.S. Наконец-то хоть кто-то упомянул TargetProccess, который лично мной нежно любим и почитаем, как один из наиболее удобных таск-менеджмент систем.
    • +1
      Просто источником этих юзерстори может быть не только стейкхолдер, но и сама команда.

      То есть обновить фреймоворк это считается за юзер-стори?

      нет вещей и задач, которые не могут быть завернуты в UserStory

      А я наблюдаю, как PO считают за юзер-стори только видимый пользователю функционал. Если таска не начинается с слов «Я как пользователь хочу ...», то это не юзер-стори. Добавить поле ввода и кнопку, которые затрагивают всё, от БД до UI становится юзер-стори только из-за UI, а все слои ниже, это вам технические задачи, которые как бы не совсем юзер-стори.
      • 0
        «То есть обновить фреймоворк это считается за юзер-стори?»

        Я, как эксплуататор/разработчик, делаю *pm outdated в корне и вижу всё зеленое :)
      • +1
        А я наблюдаю, как PO считают за юзер-стори только видимый пользователю функционал. Если таска не начинается с слов «Я как пользователь хочу ...», то это не юзер-стори. Добавить поле ввода и кнопку, которые затрагивают всё, от БД до UI становится юзер-стори только из-за UI, а все слои ниже, это вам технические задачи, которые как бы не совсем юзер-стори.

        Есть такая штука, как «декомпозиция задач». И есть рекомендация «делать задачи короткими». Из практики 8...24 часа, иначе просто теряется контроль.
        Если команда разработки нарежет/декомпозирует UserStory «Все Хорошо» на перечень измеримых и вменяемых задач — значит так надо. Согласен менеджер с этим подходом или нет — это только проблема менеджера.
        • +2
          Согласен менеджер с этим подходом или нет — это только проблема менеджера.
          Объясните менеджеру что происходит на понятном ему языке — и проблема станет проще.

          Пример. Приходите вы в автосалон, приносите лампочу фиолетового цвета и говорите «хочу чтобы фары так светили».

          Не проблема — получаете счёт на $100500. Датализация примерно такая:
          1. Демонтаж двигателя.
          2. Сьём бампера.
          3. Замена лампочики ($0.05).
          4. Установка бампера на место.
          5. Монтаж двигателя.
          6. Юстировка колёс.

          Дальше — можно обсуждать почему так получилось, что вместо одного пункта «3», который хотел увидеть заказчик у нас появилось вот это вот всё и почему лампочку можно сменить только сняв бампер, а снять его можно только демонтировав двигатель… Но главный-то вопрос: делать будем или нет?

          И также можно показать «на пальцах» что такое «рефакторинг» и зачем он нужен: ну дырки мы в бампере в других местах просверлим и вот тогда замена лампочки будет $0.05. Но для этого нам нужно этот бампер снять, то есть демонтировать двигатель и т.п.

          Так что любая UserStory «уходит корнями» в то, что видит пользователь. Любая. А вот размер у них может быть совсем не таким, как того хотят менеджеры, но вот это вот — уже таки их проблемы.

          Ваша задача — правдиво оценить «масштаб бедствия».

          P.S. Кстати предложение «дяди Васи» сделать всё за пять минут и один доллар также можно вписать в эту модель: он просто фару отвёрткой расковырять предлагает и вытащить из ниши. То, что потом фары могут вывалиться в момент остановки — его не волнует. Мы так тоже можем — но… под вашу ответственность.
          • 0
            Так что любая UserStory «уходит корнями» в то, что видит пользователь. Любая. А вот размер у них может быть совсем не таким, как того хотят менеджеры, но вот это вот — уже таки их проблемы

            Это навык менджера «считать косты». Если они игнорирует этот этап, или ему не нравится «счет» — уволить его нафиг.
            • +1
              Менеджеры ведь тоже не идиоты. Они же уже подписались на замену лампочки за $5. А тут… Ну и начинается вышеописанное.

              После нескольких подходов «дяди Васи» (который ведь ещё и премии получит) желание работать дальше над этой системой того… улетучивается.
              • 0
                Менеджеры ведь тоже не идиоты. Они же уже подписались на замену лампочки за $5.

                Это как раз и есть «идиоты за 5$». За чей счет банкет, если ценник 50$? За счет разработчика? Компании?
                Подписался за 5, а стоит 50? Ну так выплати из своего кармана остальные 45 :)
                А что бы такого не было, и прописали процессы типа «мойте руки после туалета....», что бы не было "… а то г@вн# в вентилятор снег в башка попадет, совсем мертвый будешь".
    • –1
      Единственный срок который есть — конец спринта

      Конец спринта не должен восприниматься как дедлайн. Это метка в календаре и не более. Если вы завалили очередной спринт, просто берете меньше работы. Первые пару спринтов полюбому завалятся пока мы команду формируем. Причем даже если команда уже сработанная для каждого проекта все по новому может быть.

      • 0
        Не совсем. В качестве результатов каждого спринта ожидается положительный прирост функциональности приложения. Это, в общем-то, довольно прямым текстом задекларировано.
        Это, естественно, не значит, что конец спринта — это дедлайн, к которому все задачи должны быть в продакшене.
        Это значит, что какое-то развитие по результатам спринта продукт всё равно должен получить (т.е. сделали меньше, чем запланировали -> неприятный, но валидный исход. Ни одной задачи нет в продакшене -> спринт провален).
        • 0
          Поправка: не в продакшене, а в продакшене и готовое к нему.
          • 0
            Не очень понимаю суть поправки. То, что что-то оказалось в продакшене подразумевает, что это «что-то» прошло весь SDLC и соответствует всем критериям для попадания в продакшен. Разве нет?

            «Готовое к нему, но не в продакшене» — не считается. То, чем не может пользоваться бизнес — не сделано.
            • 0
              Бизнес может пользоваться, когда захочет. Но пока не захотел. Простой пример — какую-то важную фичу приурочили к какой-то важной дате, менеджер сильно перестраховался со сроками, но всё прошло хорошо. Фича передана эксплуататорам, а они ждут этой даты для деплоя.
  • +6
    Увольте скрам-мастера, в скраме нет времени на выполнение задач, там оно заменено на story points.
    • +1
      В конечном-то итоге в спринт можно набрать Х story-points, положить длину спринта в Y дней и получить размер:
      1 story point = Y / X.
      Но в описании методологии времени нет, это да, и story point — сложность элементарной задачи. Однако, кому какое дело :)
      • 0
        Такое, во первых, можно использовать, когда есть только один разработчик. Потому, как время выполнения задачи у разных разработчиков будет разным. В пределе в десятки раз. Во вторых, мы рассчитаем понятие средней продолжительности SP команды, которая будет плавать из спринта в спринт с отклонением в пару-тройку размеров средней продолжительности SP ))). Т.е. сказать что мы запланировали на спринт 21 SP со средней продолжительностью 3 часов каждая, итого 63 часа, а по сути от 40 до 180 часов.
        По сути SP является нефизическим вознаграждением команды. Т.е. на ретроспективе можно поздравить команду и сказать, что по SP мы повысили производительность по сравнению с прошлым спринтом, в 2 раза. Ну или наоборот.
        • +1
          Нет, теоретический коэффициент SP/day есть и у каждого человека, и у команды в целом.
          Это важная и нужная метрика, позволяющая более-менее нормально планировать работу в команде.
          Другое дело, что этот коэффициент всегда динамичен и меняется от спринта к спринту.
          Цель команды — выдать максимум SP в продакшен к концу спринта без овертаймов, стресса и баттхёртов. Цель «менеджмента» и процессов — создать условия для этого роста производительности.

          Например, если выполнение 1 SP у команды занимает с каждым спринтом всё больше времени, то тут есть ряд возможных причин:
          1) Калибруется оценка задач в SP и «элементарная задача», являющаяся одним сторипоинтом, разрастается.
          2) Мотивация команды падает и работают медленнее.
          3) Накапливается легаси и костыли и внесение даже простых правок начинает занимать больше времени.
          4-999) ещё много возможных причин.
          Для анализа этих причин есть ретроспектива, как и для анализа того, что в текущем спринте позволило нам сделать больше SP, чем в предыдущем.

          Есть ещё более сложные сценарии, типа SP/day у команды растёт, а у конкретного человека падает. Это может быть потому, что он задолбался, а остальные фигачат за него. А может быть потому, что он стал больше времени тратить на саппорт коллегам, ревью и прочие не функциональные задачи.

          Подсчёт SP\day, безусловно, требует от разработчиков как-то трекать время (а мы с вами знаем, что никто не любит трекать время).
          Но, прежде чем внедрять трекинг времени, нужно чётко и ясно донести до команды зачем это делается. Что бы все (включая «менеджеров») понимали, что это делается не для того, что бы посмотреть что ты делал 8 часов рабочего дня (не дай бог читал хабр), и не для того, что бы потом кого-нибудь уволить «потому что слишком мало сторипоинтов делаешь». А для того, что бы более комфортно _для команды_ планировать объем спринтов.
          При этом для этих целей:
          1) Вполне допустима определенная «погрешность» в оценке затраченного времени. Точность до часов тут нафиг не сдалась. Т.е. шкала оценок «1 час — 4 часа — 1 день — 3 дня — неделя» вполне ясно дает понять ситуацию.

          2) Ни в коем случае не намекает нерадивым менеджерам, что разработчик обязательно должен натрекать 40 часов в неделю на задачи, и не дай бог он там хабр читал. Это простое самодурство и синдром вахтёра, аджайл тут ни при чём.

          TLDR
          Временные «оценки» в аджайле всё равно есть, просто используются они совсем по другому, нежели в случае автора.
          • 0
            Подсчёт SP\day, безусловно, требует от разработчиков как-то трекать время (а мы с вами знаем, что никто не любит трекать время).

            Зачем? Есть спринт 2 недели, команда из 4 человек сделала за спринт задач на 90 СП, лид — 20, синьйор — 30, мидл — 25, джун — 15.
            SP\day = 9 у команды, синьйор не очень убежал от мидла из-за того, что делает значительно качественнее, а лид загружен коммуникацией и обучением джуна.
            Где тут трекинг времени?)
            • +1
              Затем, что это так работает только если предположить, что команда делает только запланированные задачи.
              Не отвлекаясь на багфиксы продакшена, сторонние задачи, вопросы поступающие из вне и прочие неспринтовые таски. Да банальным «релиз не раскатывался».
              А такие задачи почти всегда есть, их количество неконстантно, а время на них потраченное может варьироваться очень сильно и непрогнозируемо. Т.е. включать их в «сделано за спринт» — малополезно и ломает всю картину.
              Таким образом проще потрекать грубые трудозатраты на спринтовые задачи и получить примерное понимание сразу двух вещей:
              1) Сколько времени в спринте (и какой объем) отжирается незапланированными задачами (а это тоже история, над которой надо работать).
              2) То, что я описывал выше.
              • 0
                Вообще это и есть задача ретроспективы. За спринт сделали 60, а не 90, как обычно? Почему? Было много багфиксов? Как можно уменьшить количество багфиксов? Трекать стоит только незапланированные задачи и то — достаточно на доверии к программисту:
                — Как думаешь, почему твоя эффективность в СП в этом спринте вдвое меньше?
                — Всунули 5 багофиксов, один из которых съел 2 дня, было 3 двухчасовых митинга и ещё полдня котенка для дочки директора рисовал.

                Но обычно количество таких задач стабильно и отражается соответствующе на стори-поинтах. Повысили качество кода, ввели код-ревью, лучше протестировали, как результат — меньше багофиксов в след спринте и +10 сп производительности.
                • 0
                  По-хорошему должно закладываться сколько-то процентов времени под то, что обязательно впихнут какой-нить багофикс или еще чего.
                  Т.е. если у вас в неделе условно 10sp, то задач планируется на 8sp, с учетом того что обязательно что-то пойдет не так. Во время ретроспективы эти проценты если надо корректируются.
                  • 0
                    Альтернативный способ — есть «задачи, которые сделаем гарантированно» и «задачи, которые постараемся». Вот «задачи, которые постараемся» и скидываем в случае необходимости багфикса.
                • 0
                  Вы предлагаете постфактум разбирать, почему успели меньше, чем запланировали.
                  Я предлагаю стараться заранее закладывать буффер на такие задачи, что бы уменьшить стрессовость всплывающих задач.

                  Работает и тот, и другой вариант. Я пробовал оба, мне проще трекать время, хотя у меня, как QA, значительно ежедневных больше задач, чем у разработчика.
                  • 0
                    А еще при оценке пользоваться планнинг покером, с целью максимально быстро оценить затраты на выполнение задач всей командой, нежели ориентироваться на «Я выполню задачу за 5 часов», и накидывать еще 20% потому что «это не точно»
              • +1
                Т.е. включать их в «сделано за спринт» — малополезно и ломает всю картину.

                Как по мне, то наоборот их надо включать в спринт по мере возникновения, чтобы как раз получать реальную картину: «сделано за спринт 90 SP из запланированных 100SP, из них 50 SP запланированных в начале спринта задач, 20 SP — внезапно вытащенных из бэклога новых, 20 SP — технических задач типа багфиксов»
                • +1
                  Есть разные мнения на этот счёт.
                  По мне проще и удобнее трекать время на плановые задачи, чем оценивать неплановые постфактум в сторипоинтах.
                  По поводу включения\выключения из спринта — мне в этом плане вообще ближе всего канбан доска, с бэклогом задач в порядке приоритетов и весьма условным понятием спринта как периода некоторых командных активити.
                  Это значительно упрощает всем жизнь, на мой взгляд.

                  В рамках жестких спринтов и чёткого скрама — да, такие задачи надо включать в спринт, а что-то из него выкидывать. Когда их оценивать — заранее или постфактум — тоже открытый вопрос.
                  В общем, зависит от команды, продукта и множество факторов, надо смотреть и адаптировать под свои реалии. Серебряной пули, как и везде, нет.
      • 0
        Я по скраму работал мало, но когда 9-10 лет назад его вводили там где я работал, то объясняли, что story points не прямо пропорционально времени. У нас использовались, кажется, первые 7 простых чисел. Хотя могу ошибаться, давно было.
      • 0
        Как считать трудозатраты в элементарных задачах? Что вообще считать элементарной задачей? Как сравнить две задачи на элементарность?
        • 0
          О, интересную тему подняли.

          Когда я столкнулся с такой задачей — то набросал на WPF дивный инструмент для разбиения проекта на подзадачи (Work Breakdown Structure это называется в некоторых источниках), которым бил целые проекты на задачи вплоть до «добавить такой-то файл» (попутно я собирал потихоньку собственную «библиотеку элементарных задач» с хорошо известными оценками), которые оценивались PERT-ом с точностью до 10 минут.
          В итоге получался excel-файл на потеху заказчику, в котором содержалось 400-600 мелких задач, складывающихся в недели и месяцы разработки. С таковым заказчику очень трудно аргументированно спорить, но оценка на сферическую в вакууме разработку получается дюже точной (в рамках оценок точности PERT-а), да и детальный план что делать — вот он вот. Хоть в JIRA выливай. Бонусом идет проектирование на ранних этапах.

          Как водится, у подобного подхода есть одна сложность — это ж надо сидеть и работать. Оценка делается напряженным умственным трудом группы людей на протяжении 2-3 дней. А менеджер работать не любит. Менеджер, как правило, поговорить любит.
    • 0
      Себя увольте. Нет в скраме никаких стори поинтс, потому как в скраме вообще элементы бэклога/спринтлога могут быть вовсе не в формате User Story описаны.
      В скрам гайде написано, что должна быть оценка, а в чём — как обычно на усмотрение команды, будь то юзер стори, человеко-часы или попугаи. Другое дело, что на каждом углу все скрам-евангелисты всячески рекомендуют не прибегать к использованию человеко-часов, но нигде жёстких правил что конкретно должно использовать нет, если это конечно не внутренние правила скрам-команды.
  • –3
    Если вы запутались в трех ролях Scrum, страшно даже подумать, что бы было, если бы вы попытались примерить что-нибудь типа RUP, с его тремя десятками ролей. Там-то действительно предписывается с десяток менеджеров.
    Рефлектируйте дальше, это полезно :)
  • +11
    Проблема в менеджерах, а не аджайле, как собственно и сказали практически в каждом комментарии. Оценивать работу нужно в стори поинтах, всячески избегая их привязки к реальному времени. Т.е. они нужны только для относительной оценки юзер стори — «А сложнее/проще Б» — не более. Другими словами, А (2 стори поинта) не в десять раз сложнее Б (20 стори поинтов), а просто сложнее. Если руководство упорно привязывается к цифрам, можно от них вовсе отказаться, перейдя к чему-то более абстрактному типа размеров одежды. Очень опасны сравнительные графики производительности команд в стори поинтах, так как одни могут оценивать задачи как 1-2-3-.., а другие 100-1000-10000, но это совсем не значит, что задачи второй команды серьезнее — просто им так комфортнее и нагляднее… Без подготовленного менеджемта, аджайл неминуемо превращается в цирк.
    • +2
      На пару комментов выше уже ответил на эту тему, не совсем с вами согласен.
      Стори поинты, в итоге, всё равно привязываются к реальному времени, потому что так или иначе производительность мерить придётся. Любая система оценок, будь это часы, поинты, майки или попугаи всё равно придет к этому, потому что есть такая потребность.
      Другое дело, что итоговое сведение поинтов в часы весьма приблизительное, несет характер «прогноза», а не клятвы на крови младенцев, и должно использоваться только как внутренний инструмент планирования в команде, а не как инструмент для давления на команду или охоты на медленно программирующих ведьм.
      • 0
        Ну фраза «производительность мерить придется» звучит, конечно красиво… Да только как мерить — непонятно. В идеале со временем аджайл позволяет приблизить стори поинты к реальным человекочасам. Но для этого нужен полный отказ от подобной привязки на начальном этапе. Любое давление (а этом может быть просто табличка «Команда-количество стори поинтов» на кухне) приведет к удушению всех возможных бонусов в зародыше. Например, если изначально производительность команды привязывается к стори поинтам, разработчики просто начнут завышать оценки («Раскидаем по ходу дела»), чтобы сдержать это, придется ограничить максимальное количество поинтов на спринт, но тогда можно просто брать этот максимум и делить на количество юзер стори, а тогда зачем вообще тратить время на планирование…
        • 0
          Производительность команды — это то, сколько изменений в системе команда успевает делать за спринт.
          Количество стори поинтов в задаче — абстрактная оценка объема изменений в системе, необходимых для реализации задачи.
          Эти вещи по умолчанию связаны. Их нельзя «развязать».

          Как мерить — вполне понятно. Есть коэффициент команды — N поинтов за спринт. Он меняется от спринта к спринту. Может меняться по естественным причинам, может по искусственным. Отфильтровать одно от другого довольно просто и это, в том числе, отлично делается на ретро.
          Цели сделать так, что бы 1 стори поинт был равент 1 человекочасу нет и не должно быть. Цель — понимать, какой (примерный) объем изменений в систему может быть внесен командой за время спринта.
          И для того, что бы это сделать — совсем не нужно отказываться ни от оценок, ни от приведения чего-то к чему-то.
          Нужно, что бы все участники процесса (разработчики, продукт овнер, стейкхолдеры) хорошо понимали, зачем и почему оценка дается и зачем эта производительность мерить. Нужно понимать, что оценка это не инструмент для того, что бы потом потыкать человека носом «атата, ты не успел».
          Это инструмент для того, что бы взять команда могла сказать «вот это мы успеем сделать за спринт, а вот это уже вряд ли — слишком большой объем изменений, больше — не получится, сорян».
          Давление — не результат перевода поинтов в часы и не вина таблички на кухне. Давление — результат атмосферы в компании и напряженности отношений.

          По поводу «разработчики начнут завышать оценки». Есть два сценария, когда это имеет смысл для разработчика.
          1) Он видит большое количество потенциальных рисков и закладывает «буффер». Это имеет смысл, хотя следует объяснить разработчикам что это лучше делать в рамках всего спринта, а не в рамках конкретных задач. Типа «Ребята, мы вот в прошлом спринте успели сделать 120 сторипоинтов. Поэтому в этом спринте берем продуктовых задач на 70, ещё 30 на технический долг, а 20 — буффер на всякие риски».
          Команда говорит «не, рисков дофига, давай 40 на риски заложим потому что интеграции много и вообще ад». На этом сошлись и всем хорошо.

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

          Ну, и в обоих случаях завышение оценок повредит оценки производительности только если разработчики будут с каждым спринтом оценивать одинаковые по сложности задачи всё более объемно. Т.е. типовой CRUD в первом спринте был 3 поинта, во втором — 6, в третьем — 12.
          В итоге коэффициент «производительности» будет постоянно расти (т.к. команда успевает делать всё больше поинтов из-за того, что задачи «переоценены») и это отлично разбирается на ретроспективе с объяснением «почему так делать ненадо».
        • +2
          Собственно аджайл — это еще способ переложить заботу о пересчете стори пойнтов в календарные дни из голов разработчиков в голову product owner. И он же должен изолировать команду от внешнего давления. За то ему и деньги платят (причем обычно больше, чем разработчикам). В описанном случае product owner толи отсутствовал вообще, толи провалил свою работу целиком и полностью. И да, скрам мастера тоже не надо по объявлению набирать. Если он видит, что такой трэш происходит и ничего не делает — ему не грош цена, а меньше. В описанном случае у него отрицательная стоимость.
          Так что в описанном случае аджайла как такового вообще не было. Был довольно стандарный провал в управлении компанией в фазе превращения из стартапа во взрослый бизнес. Не они первые, ни они последние с такими проблемами.

          Следующий вопрос к менеджменту компании — смогут ли они переломить ситуацию, так или иначе наладить работу по-новой и спасти бизнес, либо бизнес скатится в обычное УГ, покоптит небо еще какое-то время и развалится.
        • 0
          Да только как мерить — непонятно. В идеале со временем аджайл позволяет приблизить стори поинты к реальным человекочасам. Но для этого нужен полный отказ от подобной привязки на начальном этапе

          Ну так если начали вводить методологию — для этого были предпосылки, например отсутствие возможности планирования. А если такая возможность отсутствует, то нету никакого шанса родить её за две недели. Хоть вы заставите программиста в минутах все оценить и подписать кровью — это из разряда написать себе в штаны чтобы согреться.
    • +4
      можно от них вовсе отказаться, перейдя к чему-то более абстрактному типа размеров одежды

      когда команде было сложно перейти от оценки времени к новой системе мы использовали такие стори-поинты:
      — задача элементарная
      — задача легкая
      — задача средняя
      — задача тяжелая
      — задача очень тяжелая
      А менеджер уже приводил эти к значениям 2-3-5-8-13 или как там ему необходимо для своих менеджерских дел.
  • +1

    Боюсь у нас та же проблема, ввели недавно agile и много ключевых людей поуходило, хорошо что не все, а то бы конец. Правда у нас не так всё печально, отчёты надо писать только раз в день и немного больше свободы дают по времени, но т.к. мы работаем с железом то тут всё не просто, потому что железо по умолчанию непредсказуемо.

  • +1

    Проблемы внедрения Скрама хорошо разобраны в книге Майкла Кона "Succeeding with Agile: Software Development Using Scrum"


    image

    В том числе и трансфер ролей там разобран.

  • +1
    Уважаемый Keks650, боюсь проблема компании не в самом Скрам, а в идиотизме управленцев (то что вы описали, кроме как идиотизмом назвать нельзя). В Скраме есть стори поинты описывающие сложность задачи — при чем тут вообще «время»?.. Во-вторых половину задач в нашем беклоге генерируем мы сами, не ожидая ничего от бизнеса. И в конце концов в Agile (да и не только) есть такое прекрасное слово «Нет, мы не будем это делать».
    Но боль вашу прекрасно понимаю, у нас тоже так «удачно» внедрили «Девопс».
    • 0
      у нас тоже так «удачно» внедрили «Девопс»

      это как? (правда интересно)
      • +3
        Сидели мы, бед не знали, как нашего начальника (директор по инфраструктуре) убрали, и наняли «директора по девопсу». Дядя пришел, раздал всем опросники с вопросами про культуру и вот это вот все, поставил задачу изучать модные тулзы по автоматизации и так далее… и ничего из этого не вышло, т.к. менеджменту удобнее было держать огороженные друг от друга отделы инфраструктуры, тестировщиков и разработки. Никаких объединений над общей задачей, никакой blameless культуры (когда случался факап, вместо решения проблемы искали крайних, которых поставить проблему решить, а потом всенародно отчитывали. Про «проблема не на нашей стороне» вообще молчу — классика.
        Закончил девопс дядя тем, что когда из хэд офиса уволили единственного хелпдеска, сидел и людям почту настраивал.
        А затем и его уволили и наняли «директора по инфраструктуре».
        • 0
          А как и почему вы уволили «директора по инфраструктуре»?
          Или до этого еще не дошло?
          • 0
            Уволили очень просто — предложили несколько окладов и сказали, что в услугах более не нуждаются.
            По оф версии директор по инфраструктуре мыслил классическим подходом со всеми этими чейндж реквестами, многоуровневой валидацией и тд, и якобы не мог переобуться в супергибкий девопс. Потому его убрали и нашли дядю, который знает все модные подходы и технологии.
            Проблема в том, что девопс подразумевает тесное взаимодействие. Можно сколько угодно совать тулзы по автоматизации, деплоить код по нажатии кнопки в джире, но blameless culture в мозгах некомпетентных (мягко говоря) управленцев не ложилась никак.
            А по неоф данным, старый (изначальный) директор по инфре был слишком упертый и слишком яростно защищал свою команду (т.е. меня и моих коллег), вот его и турнули, но это уже условности.
            А новый директор по инфраструктуре сидит и так же хелпдеском в хэд офисе занимается, насколько мне известно от несчастных, кто до сих пор в конторе работает. Меня убрали задолго до нынешних времен (как и 90% штата в центре разработки), заменив аутсорсерами из одной «богатой» «крутыми» и «дешевыми» «инженерами». В головах нерадивых менеджеров «передать все в аутсорс и в облако» решает проблемы культурные и расходов.
            • 0
              > В головах нерадивых менеджеров

              1) заводишь аутсорс компанию.
              2) знакомым менеджерам рассылаешь предложение о сотрудничестве с откатом в 1.5%
              3)…
              4) профит

              > и в облако

              Чес слово, я сам не хочу серваками заниматься. И на мой взгляд облако вполне себе нормальный выход.
              Облоко дороже до первого затопления;)
            • 0
              А новый директор по инфраструктуре сидит и так же хелпдеском в хэд офисе занимается, насколько мне известно от несчастных, кто до сих пор в конторе работает. Меня убрали задолго до нынешних времен (как и 90% штата в центре разработки), заменив аутсорсерами из одной «богатой» «крутыми» и «дешевыми» «инженерами». В головах нерадивых менеджеров «передать все в аутсорс и в облако» решает проблемы культурные и расходов.


              И?
              Сталкивался — как закачивается период активной разработки/развертывания, так меняется организационная структура, убираются куча ставшими не нужными работников, а потом опять активизируется, нанимают заново — это целесообразно, это бизнес. Она за ради денег, а не за ради «поразрабатывать бы что нибудь крутое задорого, не взирая на себестоимость».
              • +1
                как закачивается период активной разработки/развертывания, так меняется организационная структура, убираются куча ставшими не нужными работников, а потом опять активизируется, нанимают заново — это целесообразно, это бизнес.

                Вы считаете, что если уволить специалиста, например, программиста работающего с основания компании, а затем через полгода нанять программиста на то же место — то это выгодно. Так как вы полгода зарплату не платили, а за воротами программистов немеряно.
                Чаще всё иначе. Программисты стоящие за воротами лучше бы за ними и оставались. Новый программист не может править чужой код и начинает его переписывать (топчется на месте). Вы не только полгода не платили зарплату, но и не имели возможности заработать на опытном программисте.
                Как итог сокращаете фонд заработной платы, через год — два закрываете компанию или на место одного программиста нанимаете 20 (условно).
                Может проще сразу эффектного менеджера увольнять?
                • 0
                  Вы считаете, что если уволить специалиста, например, программиста работающего с основания компании, а затем через полгода нанять программиста на то же место — то это выгодно. Так как вы полгода зарплату не платили, а за воротами программистов немеряно.


                  Смотрите шире — разработчик сам закиснет на работе по поддержке.

                  Новый программист не может править чужой код и начинает его переписывать (топчется на месте).


                  Это отдельная проблема.
                  Но.

                  Но неужели вы думаете, что огромные коллективы разработчиков, создающие большие системы, сумели каким-то чудесным образом избежать текучки в коллективе?
                  Чем больше народу работает, — тем больше «потоки свежей крови», это естественный факт.

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

                  Как итог сокращаете фонд заработной платы, через год — два закрываете компанию или на место одного программиста нанимаете 20 (условно).
                  Может проще сразу эффектного менеджера увольнять?


                  Конкретный пример приведу:

                  Была разработана платежная система.
                  3 человека разработчиков. Очень высокая квалификация.

                  Под конец разработки был нанят один попроще квалификацией.

                  Разработка была завершена.

                  Оставалось следить за системой, баги редкие фиксить — этим и занялся тот последний принятый на работу «квалификацией попроще».

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

                  Зачем там 3 высококвалифицированных спеца на этом этапе?

                  Прошло не полгода, а 2 года…

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

                  Снова наняли высококвалифицированных разработчиков — других, естественно, а не тех, что систему изначально создали.

                  Это конкретный пример из жизни.
                  • 0
                    Новых трёх высококвалифицированных специалистов уже уволили?
                    • 0
                      Новых трёх высококвалифицированных специалистов уже уволили?


                      Для локализации и пр. задач нанимали всего двух высококвалифицированных.
                      Задача выполнена.
                      Да, давно уволены.

                      Они бы и сами ушли — им же не интересно работать по мелким текущим задачкам.
                      Тем более коих мало на такую толпу народа.
                      • 0
                        Я с подобным встречался только в не сложных web проектах. Значит я ошибался.
                        • +1
                          По сути, это и есть несложный веб-проект. У большого проекта нескончаемый список нереализованных хотелок.
                          • –2
                            По сути, это и есть несложный веб-проект. У большого проекта нескончаемый список нереализованных хотелок.


                            Хотелок у всех нескончаемо.
                            Все дело в бабле. Никто вечно не будет спонсировать хотелки на полную катушку.
                            Разделение жизненного цикла продукта на более и менее интенсивную разработку — совершенно естественно.

                            Аналогия с домом:

                            Дом построен — каменщики ушли.
                            Пришли маляры.
                            Прошли годы.
                            Еще раз пришли маляры.
                            Прошли годы
                            Еще раз пришли маляры.
                            Прошли годы
                            Еще раз пришли маляры.
                            Прошли годы
                            Еще раз пришли маляры.

                            Но каменщики не вернуться уже никогда.
                            • +1
                              Но каменщики не вернуться уже никогда.

                              В моём городе каменщиков возвращали через суд. Эксперименты с зарплатой строителям во время бума строек привели к тому, что работяги много воровали, например, цемента. В результате новый дом и внешняя стена лопнула. Мужик подал в суд и выиграл, вернулись краны, каменщики и блок стены поменяли. Но аналогия совсем не к месту!
                              У программистов своя работа. Пишет, например, программист ХХ тысяч строк кода. И вы можете как Ванга нагадать, что в этом коде есть ошибки, при чём много критических. Далее, посмотрев на результат большая часть заказчиков осознаёт, что делать надо было совсем иначе. Плюс много хотелок.
                              Для многих сайтов программисты после создания сайта не нужны совсем. Логика простая (обработать запрос юзера и сформировать ему хтмл страницу с БД), самописы без внешних непредсказуемых библиотек и всё… Нужны модераторы, корректоры, юристы, рекламщики. Но не программисты.
                              Но мой опыт показывать, что если после написания программ начинают увольнять программистов — то это всё. Ваш опыт другой.
                              • 0
                                Но аналогия совсем не к месту!
                                У программистов своя работа.


                                Есть этапы создания ПО и этапы его эксплуатации.

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

                                Делают просто:

                                1. Нельзя работать, ПО не позволяет.
                                2. Делаем ПО.
                                3. Запускаем ПО в эксплуатацию
                                4. Пользуемся ПО.
                                5. Фиксим баги

                                Пункты 2 и 3 несообразно дороги.
                                Но их терпят ради пункта 4.
                                Пункт 5 должен быть копеечным, иначе это плохое ПО.

                                Зависит от проекта. И его конкурентов. Грубо, Гуглу и Яндексу надо постоянно развиваться.


                                Это все же не типичные заказчики. Их бизнес и есть ПО.

                                А все что существует в нашем виде материального — сделано предприятиями традиционного типа.

                                Для них экономически лучше будет купить новый крутой станок, чем очередной раз переписывать программу управления производством.
                            • +2
                              Но каменщики не вернуться уже никогда.

                              Пока не придет чейнджреквест от владельцев здания, например достроить еще одно крыло или связать два рядом стоящих здания переходом.


                              Когда разработку ПО сравнивают со страительством есть одна простая ошибка восприятия, которая ломает все дальнейшие аналогии. Как правило в инженерном деле можно выделить две стадии — проектирование и собственно постройка (design + build) причем фаза строительства не очень то дешевая и исправлять ошибки проектирования на этой фазе очень дорого.


                              В разработке ПО же "сборка" процесс незатратный. По сути это время работы компилятора/деплоймент. То есть с точки зрения трудозатрат разработка ПО это только процесс "проектирования", что сильно меняет подход к этому делу в плане процессов и разработки. Мы в любой момент можем вызвать "каменщиков" и изменить проект.

                              • 0
                                Пока не придет чейнджреквест от владельцев здания, например достроить еще одно крыло или связать два рядом стоящих здания переходом.


                                Если это не ИТ-фирма, а ИТ только обслуживающая служба, то реквест придет ой как не скоро.
                                Годами держать ненужный штат предлагаете?
                                • 0
                                  Годами держать ненужный штат предлагаете?

                                  Аутсорс не зря придумывали. Если изменения происходят раз два в год, то держать штат смысла нет. Но если риски от того, что изменения не будут сделаны вовремя высоки (каждый день задержки будет приносить убытков компании больше чем посадить человека в штат) то имеет смысл держать в штате человека.

                                  • +1
                                    Аутсорс не зря придумывали. Если изменения происходят раз два в год, то держать штат смысла нет. Но если риски от того, что изменения не будут сделаны вовремя высоки (каждый день задержки будет приносить убытков компании больше чем посадить человека в штат) то имеет смысл держать в штате человека.


                                    Абсолютно бессмысленно это обсуждать в отрыве от конкретного проекта.
                                    Я привел вполне конкретный пример выше — с него обсуждение и идет:

                                    Крупные переделки в платежной системе, которые делаются раз в 2 года.
                                    Но длина каждой переделки опять таки по паре лет.

                                    Что до аутсорса:

                                    Занимаюсь аутсорсом — ровно та же ситуация. Доработки идут волнами. Большими волнами.

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

                                    Иногда, после месяцев поддержки по аутсорсу, предпочитают нанимать программиста (другого, не переманивают, все честно). Потом отдел. Потом сокращают. Опять возвращаются на аутсорс.

                                    Это жизнь. Это бизнес. Потребности меняются. Штат меняется в зависимости от ситуации.

                            • 0
                              Зависит от проекта. И его конкурентов. Грубо, Гуглу и Яндексу надо постоянно развиваться.
  • +7
    Не методология виновата. Виноваты манагеры. Ради достижения своих целей одна группа, не очень нужных в компании лиц, решила поставить раком людей, действительно в компании нужных. Так уж повелось у «эффективных менеджеров», считать людей «отвёртками», забывая, что как только разработчик начинает чувствовать себя отвёрткой, к проекту он начинается относиться соответственно. Пока у них есть уверенность, что любого можно заменить, это будет продолжаться до бесконечности.
  • +2
    Творчество и формализация плохо совместимые понятия.
  • 0

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


    Люблю SCRUM как раз за то что УЧИТЫВАЕТ взаимоотношения в команде, знаю что напишу банальщину, но есть подозрение что у вас не правильно приготовили SCRUM.

    • +3
      получается везде scrum готовят неправильно? Может быть проблема в нем самом?
      • 0
        Возможно Вам просто не везло, у нас вся компания(порядка 27 команд) работают по SCRUM и таких проблем нет.
      • +2
        В ПО есть баги, получается везде ПО пишут неправильно?
        Идеальных процессов не бывает. Есть команды, которые больше преуспели на пути к «идеальному», есть команды, у которых не получилось.
        К сожалению, факторов по которым «что-то может пойти не так» слишком много, поэтому ребят проваливающих этот путь значительно больше, чем успешно его прошедших.
        • +1
          В ПО есть баги, получается везде ПО пишут неправильно?

          Именно так. Иначе не существовало бы такого разнообразия серебряных пуль методологий разработки и индустрии впариветелей этих методологий.

          • 0
            Нет, это не так. Потому что термин «неправильно» подразумевает существование термина «правильно».
            Ни в случае с ПО, ни в случае процессов разработки — нельзя построить идеально. Всегда будут проблемы.
            Важна их частота и степень их влияния.
            На примере с ПО — вы никогда не выпустите ПО, которое будет работать без ошибок. Даже если у вас будет неограниченное время и бюджет. Но, вы можете приблизить качество ПО к тому уровню, когда количество мешающих пользователю ошибок будет сведено к минимуму, а обнаружение и исправление пропущенного на продакшен — будет безболезненным.
            На примере с процессами — нет идеальных процессов. И речь даже не об универсальности для всех продуктов и компаний. Даже в разрезе одной конкретной компании факторов, которые могут «всё сломать» — слишком много. Пытаться сделать идеально — это борьба с энтропией.
            Цель же совсем не в этом. Цель в том, что бы, сначала, максимально эффективно отладить нормальный workflow команды, а затем сделать всё необходимое для максимально безболезненного устранения форс-мажоров. Начиная от бас-фактора среди команды и незапланированных задач и заканчивая падением атомной бомбы на датацентр вашего хостера.
            • 0
              На примере с ПО — вы никогда не выпустите ПО, которое будет работать без ошибок

              Бездоказательное утверждение.


              Даже если у вас будет неограниченное время и бюджет.

              Прро формальное доказательство правильности программ слыхали? Иногда оно бывает даже автоматическим.


              Ни в случае с ПО, ни в случае процессов разработки — нельзя построить идеально. Всегда будут проблемы

              Можно использовать инструмент с которым скорее всего будут проблемы. А можно его не использовать и этих проблем избежать

              • +1
                Да, и формальное доказательство предполагает либо слабую логическую сложность программы, либо доказательство в рамках одной тестовой модели.
                Это, ни в коем случае, не гарантирует её безошибочную работу с любыми данными, на любых девайсах и в любой ситуации.

                Ваша фраза про инструменты вполне правильна. Только с парой поправок. Методология разработки — это не инструмент. Это набор методик и рекомендаций, как использовать инструменты.
                Это не значит, что эти методики и рекомендации подходят для всех инструментов, всех условий, всех работников идеально.
                Это значит, что некогда схававшие на проблемах разработки пуд лиха люди собрались, обсудили и сформировали рекомендации, как стоит использовать инструменты, что бы по максимуму избежать проблем.
                Вполне возможно, что вы знаете и умеете готовить процесс разработки лучше. Тогда, у вас не должно возникать поводов внедрять аджайл. Его внедряют, в большинстве случаев, тогда, когда в процессе разработки есть проблемы, которые он призван решать.
                Будет он их решать или нет — зависит только от тех, кто его внедряет. Т.е. команды.
                • 0
                  Проблема в том, что:
                  а) у каждой методологии есть области применимости, но обычно явно они не описаны
                  б) список решаемых проблем тоже часто явно не обозначен
                  в) а уж цена, которую придётся платить, тем более не обозначена

                  Ну или, может, всё это есть в толстых книжках, но внедрятели их не читают. Или читают, но плохо. И внедряет, обычно, не команда, а руководство. Команд — это объект внедрения, а не субъект.
              • +2
                Прро формальное доказательство правильности программ слыхали?

                Формальное доказательство только про соответсвие формальному описанию, но никто не говорил, что:
                — формальное описание корректное
                — формальное описание полное

                Обычно баги получаются не из-за механической ошибки, а из-за неправильной или неполной обработки данных. А тут часто вступает в дело комбинаторная сложность из-за это все ветви проверить нельзя.
                • +1
                  Формальное доказательство только про соответсвие формальному описанию, но никто не говорил, что:

                  Угу. Вы ещё скажите, что наше восприятие мира не соответствует действительности и поэтому не бывает по без ошибок. Отделяйте мух от котлет. Написать правильную программу (полностью соответствующую формальному описанию) можно. В исходной формулировке ничего не было про правильность постановке задачи.


                  А тут часто вступает в дело комбинаторная сложность из-за это все ветви проверить нельзя

                  (пожимая плечами) в вашей постановке были бесконечные ресурсы. (И при чём здесь проверка всех ветвей? Как и теоремы, программы доказываются не брутфорсом, как правило) Но раз вы меняете правила и формулировки по ходу дела, то конкретно вам ничего доказать нельзя. Продолжение беседы на таких условиях не кажется мне осмысленным.

                  • 0
                    В исходной формулировке ничего не было про правильность постановке задачи.
                    Но и про наличие готового формального описания тоже ничего не было. Чтобы этим способом написать правильную программу, нужно правильное формальное описание, а получить его (гарантированно правильное) неизвестно как.
                    • 0
                      Правильная программа — программа, соответствующая формальному описанию. Даже если оно неправильное, то программа ему соответствующая всё равно правильная. Может бесполезная, может даже вредоносная в каких-то кейсах, но правильная.
                      • +2
                        Осталось понять, как это поможет на практике.
                      • +1
                        То есть, правильное ПО не относится к
                        ПО, которое будет работать без ошибок
                        • 0
                          Оно работает без ошибок — полностью согласно формальному описанию.
                          • 0
                            Предположим, что ваше трактова термина «ошибка» верная. Тогда почти всё современное ПО не содержит ошибок, потому что не составлено формальное описание. Однако, множество существует множество дефектов, которые признаны ошибками. Противоречие. Исходное предположение неверно.
                            • 0
                              Раз не составлено формального описания, значит ПО не может ему соответствовать, а значит не может считаться безошибочным.
                              • 0
                                Ошибка — несоответствие формальному описанию.
                                Если нет формального описания, то ошибок тоже нет?
                                • +1
                                  Значит есть несоответствие. Вся программа — формально большая ошибка, если что-то принимает на вход и что-то отдаёт, хотя формальное описание пустое.
                                  • 0
                                    С таким убеждением можно подходить к любой команде разработчиков и заявлять: «вся ваша программа — большая ошибка».
                                    — А в чём ошибка?
                                    — Не скажу, сначала сделайте формальное описание.

                                    Интересно, куда вас пошлют после такого диалога…
                                    • +1

                                      Хм, а кто-то всерьёз начнёт доказывать, что их программа безошибочна? Отсутствие формального описания означает наличие N неизвестных ошибок в программе, где N нелинейно растёт вслед за ростом сложности, объёма кода и т.д. Учитывая невозможность обнаружения всех N ошибок без формального описания, действительно можно сказать, что вся программа ошибочна.

                                      • 0
                                        Хм, а кто-то всерьёз начнёт доказывать, что их программа безошибочна? Отсутствие формального описания означает наличие N неизвестных ошибок в программе, где N нелинейно растёт вслед за ростом сложности, объёма кода и т.д. Учитывая невозможность обнаружения всех N ошибок без формального описания, действительно можно сказать, что вся программа ошибочна.


                                        Мы (комментирующие тут) что — все до единого в космической индустрии служим?
                                        Откуда такие вопросы вообще в голову пришли?
                                      • 0
                                        Учитывая невозможность обнаружения всех N ошибок без формального описания, действительно можно сказать, что вся программа ошибочна.
                                        А если для программы составлено формальное описание, и проведено доказательство корректности, но вам об этом не сообщили, вы всё равно с порога будете утверждать, что наверняка программа ошибочная?
                                        • 0
                                          «У меня нет оснований считать, что программа безошибочна».
                                          • 0
                                            Но зато у вас нет оснований считать, что программа ошибочная, если интуитивно понятно, что она работает неправильно, а формального описания нет.
                                            • 0
                                              Если есть какое-то описание и поведение ему не соответствует, значит программа ошибочная. Если нет никакого описания, то нет никаких оснований считать ошибочная она или нет. Может ТЗ состояло в выдаче kernel panic.
                                        • 0
                                          но вам об этом не сообщили, вы всё равно с порога будете утверждать, что наверняка программа ошибочная?

                                          Вы меняете условия на ходу. Обсуждался случай, когда достоверно известно об отсутствии формального описания, цитата: "Если нет формального описания, то ошибок тоже нет?"

                      • 0
                        Даже если оно неправильное, то программа ему соответствующая всё равно правильная

                        То есть ответственность за корректное с точки зрения бизнес-логики поведение мы перекладываем с программы на формальное описание? Теперь вопрос — можем ли мы (как вид) создать безбажное формальное описание нетривиального продукта?
                        • 0
                          Теперь вопрос — можем ли мы (как вид) создать безбажное формальное описание нетривиального продукта?

                          Да можем конечно… С математикой же мы как вид как-то справляемся. Так же и программа может быть представлена в декларативном виде. Есть особо сложные случаи, но подавляющее большинство программ реально формализовать… Другой вопрос, что это кучу времени займёт при текущем состоянии IT-индустрии (что не говори, а она ещё только на начальном уровне развития).

                          • +1
                            С математикой же мы как вид как-то справляемся.


                            Справиться с математикой гораздо проще, т.к. она, вообще говоря, не описывает реальный мир.
                            • 0

                              Вообще говоря, в описании реального мира математика продвинулась куда дальше, чем программирование (см. математическая физика). Но по сути и то и то работает с упрощенными моделями реальности. Формальное описание — это и есть модель.

                            • –1
                              Справиться с математикой гораздо проще, т.к. она, вообще говоря, не описывает реальный мир.


                              Точно, точно.
                              То-то мы строим высоченные здания и уверены (из расчетов), что они не рухнут.
                              Или на каждом шагу в быту, даже без перепроверок, суммируем и умножаем и не пересчитываем соответствие на деле сумм и произведений нашим расчетам.
                              Точно точно — математические расчеты не относятся к реальному миру.
                              И 2*пи*р никакого отношения к кругу не имеет — нужно линейкой перемерять.

                              Вы путаете:

                              Математика априори абстрактна. Но это не означает, что она не имеет отношения к реальному миру.

                              Тут все дело в модели, а не в математике как таковой.
                              Именно модель и связывает реальный мир и математику.

                              Бизнес-процессы в больших масштабах ложаться на математику (на статистику, если быть точным).

                              • 0
                                Но это не означает, что она не имеет отношения к реальному миру.


                                Где я утверждал, что математика не имеет отношения к реальному миру?

                                Еще раз: математика не описывает реальный мир. В реальном мире нет точек, треугольников и числа пи. И тем не менее математический аппарат успешно применяется для моделирования реальности. Тут нет противоречия.

                                Математика априори абстрактна.


                                Физика тоже абстрактна (вспомните хотя бы «материальную точку»), и тем не менее она описывает реальный мир, хоть и неточно.
                                • 0
                                  Физика тоже абстрактна (вспомните хотя бы «материальную точку»), и тем не менее она описывает реальный мир, хоть и неточно.


                                  Очевидно ж — почему.
                                  Ведь физика — это именно что моделирование реальности.
                                  А модели — это как раз то, что связывает математику с реальностью.
                                  • 0

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


                                    На эту тему есть неплохой докладик: https://youtu.be/9IPn5Gk_OiM?t=11m29s


                                    там как раз про устранение человеческого фактора в разработке ПО за счет использования формальных методов.

                        • 0
                          Да, разделение ответственностей. Описание отвечает за описание :) бизнес-логики, а программа за реализацию описанного.

                          Полноценного продукта с UI, взаимодействием с ОС и т.п. — только в теории, наверное. Конкретно бизнес-логики — думаю, вполне возможно. Вернее, возможно создать полностью верифицируемое формальное описание проходящее тесты на полноту и не противоречивость. Естественно, если эксперты или аналитики что-то напутают, то такое описание будет с ошибками.
                    • 0
                      а получить его (гарантированно правильное) неизвестно как.

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


                      То есть если у вас нет четкого формального описания программы, его можно составить путем получение обратной связи от клиентов (пользователей системы по хорошему). А из этого мы можем сделать логическое заключение — нам нужно выстраивать работу таким образом, чтобы цикл обратной связи был меньше. И есть целая масса способов собирать фидбэк не вкладывая безумные усилия в разработку. Начиная прототипами и мокапами и заканчивая gherkin сценариями с описанием поведения системы (specification by example, bdd).

                      • 0
                        из которых это формальное описание можно будет сформировать.
                        Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать формальное описание?

                        Напомню, формальное описание это машинночитаемый документ, из которого логическими правилами можно вывести требуемое поведение (output) при заданном входе (input).

                        То есть, если у нас конвертор из doc в png (для простоты — первая страница), то имеем входной предикат D(x,y) — утверждение, что x-й байт входного документа есть y, и с помощью правил формального описания можно доказать набор P(x,y) — утверждений, что x-й байт выходного документа есть y. Как думаете, сколько миллионов страниц логических формул потребуется, чтобы вывести P(x,y) из D(x,y) для всех возможных ворд-документов? Кто напишет эти формулы и где гарантии, что в них не будет ошибок?

                        И это ещё пакетное преобразование. С интерактивными программами вообще ужас.
                        • +1
                          Напомню, формальное описание это машинночитаемый документ, из которого логическими правилами можно вывести требуемое поведение

                          Нет конечно. Вообще пожалуй мой комментарий лишь говорил о том что можно получить вменяемые требования по которым можно делать работу. Некое "абстрактное в вакууме" описание будет оставаться все таким же абстрактным.


                          Как думаете, сколько миллионов страниц логических формул потребуется, чтобы вывести P(x,y) из D(x,y) для всех возможных ворд-документов?

                          То что вы описали никому не нужно. Вообще на эту тему есть неплохой доклад Грэга Янга. Там как раз про "миллионы формул" и "все возможные word документы" найдутся тезисы.


                          В целом же я не вижу никакого смысла в "формальном описании" которое сложнее реализации. Реализация задачи может считаться формальным описанием?

                          • 0
                            я не вижу никакого смысла в «формальном описании» которое сложнее реализации
                            Мы в этой ветке обсуждаем доказательство правильности программ системами логического вывода.

                            А что есть «формальное описание» в ваших терминах?
                          • 0
                            Реализация задачи может считаться формальным описанием?
                            Да. Но чтобы сделать правильную реализацию нужна другая правильная реализация?
                            • 0

                              Прототипы, мокапы, модели и т.д. могут восприниматься как "другая" возможно правильная реализация. Эта реализация должна быть на порядки дешевле "настоящей" и должна служить источником фидбэка для уточнения требований дабы со временем сформировать уже итоговый продукт или отдельные его фичи.

                              • 0
                                Прототип, как правило, не учитывает всякие сложные случаи, на тяп-ляп относится к безопасности (отсутствует супер-тщательная валидация входных данных), на него равняться нельзя.
                                • 0

                                  и тут в дело вступает управление рисками. Лучше делать систему так, чтобы быстро реагировать на риски а не пытаться их все предотвратить. Зачем тратить человекомесяцы на кейс, который будет возникать один раз на миллион?

                                  • +1
                                    Зачем тратить человекомесяцы на кейс, который будет возникать один раз на миллион?


                                    Чтобы этот один раз не нанес гораздо больший ущерб, чем стоимость нескольких человекомесяцев.
                                    • 0
                                      Зачем тратить человекомесяцы на кейс, который будет возникать один раз на миллион?

                                      Чтобы этот один раз не нанес гораздо больший ущерб, чем стоимость нескольких человекомесяцев


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

                                      Это вопросы менеджеров и выходит за тему данной статьи.
                          • 0
                            В целом же я не вижу никакого смысла в «формальном описании» которое сложнее реализации. Реализация задачи может считаться формальным описанием?

                            Извиняюсь, что сломаю ваше мнение о «невозможно» и "… дороже чем..".
                            Логика тут немного другая. Есть бюджет проекта, скажем 100 денег.
                            Есть два варианта решения:
                            • 10 денег — аналитика «тяп-ляп»
                            • 20 денег — срач/менеджемент по ходу проекта
                            • 60 денег — ваять-кодить решение (пару-тройку раз переделав)
                            • 10 денег — тестить

                            или
                            • 40 денег — аналитика «формально корректная»
                            • 10 денег — срач/менеджемент по ходу проекта
                            • 30 денег — ваять-кодить решение (сделано сразу верно)
                            • 20 денег — тестить


                            Так получилость, что у меня было штук 6 похожих проектов сделанные этими двумя разными подходами и мог сравнить метрики проектов.
                            Фактически получалась «перемена мест слагаемых» :)

                            Выбор решения состоит в балансе между знанием предметной области и предоставлением MVP.
                            В большинстве случаев этот выбор — проблема психологии. Клиенту все равно «куда говорить» — в draft проекта или «формальную бумажку», главное что бы его слушали и записывали. А в код или UML- ему пофиг. Главое что бы к моменту Х все было готово.
                        • 0
                          Напомню, формальное описание это машинночитаемый документ, из которого логическими правилами можно вывести требуемое поведение (output) при заданном входе (input).


                          Согласно этому определению, исходный код любой программы — формальное описание этой программы.

                          Теперь вы сможете ответить на свой вопрос согласно своему определению формального описания.

                          Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать формальное описание?
                          • 0
                            Ладно, поправлюсь
                            Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать гарантированно правильное формальное описание?
                            • 0
                              Ладно, поправлюсь

                              Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать гарантированно правильное формальное описание?


                              Программы пишутся не просто так, не только ради удовольствия.
                              Посему всегда нужно ставить вопрос: а это надо, это кому надо, это действительно надо?

                              Описания (вполне себе нормальные) существуют в мире ПО.
                              Вот только до абсурда их доводить не надо никому.
                              • 0
                                Довольно забавно, что который раз вы без знания предмета появляетесь в этой ветке и отвешиваете комментарии. Вроде как если бы беседовали PHP-шники, а к ним всё время лез си-шник и поправлял: «а чего это у вас доллары перед переменными, это же не будет компилироваться».
                                • –1
                                  Довольно забавно, что который раз вы без знания предмета появляетесь в этой ветке и отвешиваете комментарии. Вроде как если бы беседовали PHP-шники, а к ним всё время лез си-шник и поправлял: «а чего это у вас доллары перед переменными, это же не будет компилироваться».


                                  Я просто много лет как не джун. И знаю, что рулит практическая польза. И только она.

                                  Это только джунов и студентов может всерьез интересовать «правота абсолютно формального описания».

                                  Кто поопытнее — могут это обсуждать только в качестве стёба или троллинга.

                                  И так будет до тех пор, пока компьютерные программы не начали писать сами себя в индустриальных масштабах.

                                  Программистам абсолютно формальное описание нужно только для того, чтобы прикрыть свою задницу (программа написана согласно описанию — отвалите с вашими претензиями, лучше дайте денег за выполненную работу).

                                  Но ведь никто не будет применять для вашего наказания абсолютного оружия. Так что абсолютно формальное описания — явный перебор и напрасная трата времени.

                                  Согласитесь, что даже в внутри вашего предприятия никто не будет всерьез на официальных совещаниях тратить на это время. Разве что в курилках. Единственная возможность обсосать эту тематику — на формах типа этого.

                                  Программируем мы для удовольствия или для денег.

                                  В коллективе программирующих ради удовольствия вас также далеко пошлют с этим формальным описанием — вы все удовольствие коллегам испортите.

                                  В коммерческом проекте бизнес сначала посмотрит на абсолютно формальное описание с интересом и спросит — а как оно себя окупает. После получения ответа (никак) бизнес также потеряет всякий интерес к абсолютно формальному описанию.
                        • 0
                          Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать формальное описание?


                          Даже более того…

                          Вы никогда не слышали слово «бриф»? Эта штука используется, чтобы формализовать требования к чисто творческим вещам: фотография, графика, дизайн, видео.

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

                          Пример брифа.
                          Вы в курсе как планируется сериал «Игра престолов»? Да, да, да там бесстыдно написано в плане серии «показать голую женщину в полный рост спереди». Что в результате реализуется в виде исполнения наемником с сидящей на коленях проституткой песни Rains of Castamere (S05E09)

                          Так что формализовать можно даже такие не формализуемые, казалось бы вещи.

                          А вы про какие-то программы.

                          Разумеется, не будет 100% взаимооднозначного соответствия программы и её формального описания. Но это никому и не нужно. Программы реализуются ради того, чтобы они пользу приносили, а не ради формального соответствия.

                          Индустрия ПО существует. Еще ой как существует.

                          И бизнес требует определенности, поэтому формальные описания вполне себе существуют.

                          Если вы о них не знаете, — это просто объясняется тем, что вы еще не senior, а то может и не крепкий middle.

                          Все к вам придет в свое время, не нужно бежать впереди паровоза.
                          • +1
                            Разумеется, не будет 100% взаимооднозначного соответствия программы и её формального описания.

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

                            • 0
                              Кхм, в этой ветке речь идёт о формальном доказательстве отсутствия ошибок в программах. А Вы говорите об обычной спецификации, это совсем другая тема.


                              Это уже придумано до нас.

                              Просто посмотрите как это реализовано в космической индустрии (стоимость ошибки страшно высока, бюджеты же на реализацию достаточно хороши). Почти 50 лет как.
                              ;)

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

                              • +1

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

                                • –2
                                  Вы умеете внимательно читать? Перечитайте, пожалуйста, эту ветку с начала и поймите, что тут обсуждают теоретическую возможность формального доказательства при условии неограниченного времени и бюджета, а не его практическую целесообразность.


                                  Что тут обсуждать-то?
                                  Невозможно.

                                  Ибо:

                                  1. Программа получает числа на входе.
                                  2. На выходе отдает квадраты входных чисел.
                                  3. С вероятность 0,00000000000000001 выдает в ответ всегда 0, вне зависимости от входного числа.

                                  Пункты 1,2 соответствуют формальному описанию.
                                  Пункт 3 — специально вложенная ошибка, боящимся не получить свои деньги программистом (ну делают так некоторые козлы).

                                  Финиш.
                                  • +2
                                    Верификация выявит третий пункт.
                                    • –2
                                      Верификация выявит третий пункт.


                                      Если бы верификация все выявляла, то не требовалось бы «формальное описание программы».
                                      • 0
                                        Формальное описание для того и нужно, чтобы верифицировать программу на соответствие ему.
                                        • 0
                                          Ну не выявит, не выявит 100%. Пример выше.
                                          Выявит только формальное описание равнозначное самой программе. Что лишает его всяческого смысла.

                                          • 0

                                            Пример выше легко решается символьным вычислением.

                                          • 0
                                            Верификация выявит ваш третий пункт. Не путайте верификацию с тестированием.
                                            • 0
                                              Верификация выявит ваш третий пункт. Не путайте верификацию с тестированием.


                                              Если верификация реальна и она проще программного кода (а иначе какой в ней практический смысл) и при этом 100% гарантировано все режимы работы программы проверяет — давайте писать верификационный код. А ПО и будет переводить его в программный уже.

                                              ;)

                                              • 0
                                                Верификация — процесс, код — объект этого процесса. Сравнивать, что сложнее — это как сравнивать тёплое и длинное.
                                                • 0
                                                  Верификация — процесс, код — объект этого процесса. Сравнивать, что сложнее — это как сравнивать тёплое и длинное.


                                                  Формальное описание, на основании которого, как вы писали, будет делаться верификация — это совсем не процесс. А тоже объект.

                                                  Вот вы хотите верифицировать.
                                                  И у вас для этого есть формальное описание.
                                                  Верификация 100%.
                                                  Вывод: если вы можете верифицировать программу, то вам ее и писать не нужно. Ее из 100% формального описания выведет автоматика за вас.

                                                  То есть куда не погляди — практического смысла это лишено.

                                                  Потренироваться тут в комментариях в слепом десятипальцевом методе набора текста на клавиатуре только?
                                                  • 0
                                                    «Вывод: если вы можете верифицировать программу, то вам ее и писать не нужно.»

                                                    Ложный вывод. Одно дело проверить конкретное решение на соответствие описанию, а совсем другое — найти. Да ещё и выбрать из практически бесчисленного множества. Это как уравнение — проверить является ли число его корнем просто по сравнению с поиском всех корней.
                                                    • 0
                                                      Ложный вывод. Одно дело проверить конкретное решение на соответствие описанию, а совсем другое — найти. Да ещё и выбрать из практически бесчисленного множества. Это как уравнение — проверить является ли число его корнем просто по сравнению с поиском всех корней.


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

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

                                                      Вот я и спрашиваю, если программы пока еще пишут люди, а не другие программы — то какой в этом смысл? Ну кроме как языком побалякать.
                                                      • 0
                                                        Общая проверка со 100% гарантией, что программа соответствует описанию. Число программ ему соответствующих бесконечно множество в теории. Нам же надо проверить одну конкретную.
                                                        • 0
                                                          Общая проверка со 100% гарантией, что программа соответствует описанию. Число программ ему соответствующих бесконечно множество в теории. Нам же надо проверить одну конкретную.


                                                          Это если бы вы под проверкой подразумевали простое тестирование частных случаев — было бы просто.

                                                          Если же мы рассматриваем, как тут, «доказательство» — это другой коленкор.
                                                          • 0
                                                            Доказательство соответствия программы формальному описанию — это то же самое, что доказательство верности уравнения при каком-то одном из множества корней.

                                                            По одному формальному описанию можно написать бесконечное множество корректных программ. У нас не стоит задача найти всё это множество, у нас задача проверки, что данная конкретная программа ему принадлежит. Сама программа — это частный случай. Это как проверка продуктов на сантребования — требования одни, продуктов много, какие-то соответствуют, какие-то нет. Нас, как производителя продукта, интересует только чтобы наш продукт требованиям соответствовал.
                                                            • –1
                                                              Доказательство соответствия программы формальному описанию — это то же самое, что доказательство верности уравнения при каком-то одном из множества корней.

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


                                                              Прошло уж 20 лет как Пролог умер, а человечество еще не продвинулось в индустриальных масштабах к таким проверкам даже для консольных утилит, не говоря уж про GUI.
                                                              • +1
                                                                Пролог не умер. Логику предикатов обязательно преподают на математических факультетах, а Пролог — вполне нормальный язык её моделирования.

                                                                Другое дело, он в тырпрайзах не применяется. Но он и раньше не применялся, когда был якобы жив.
                                                                • 0
                                                                  Пролог не умер. Логику предикатов обязательно преподают на математических факультетах, а Пролог — вполне нормальный язык её моделирования.


                                                                  Преподают.
                                                                  Но это не имеет к Прологу отношения.
                                                                  Учился на математическом.
                                                                  Ничего мы на Прологе не моделировали.
                                                                  Даже более древний Фортран где-то там ограниченно применялся (в математической физике, вроде), но уж не как не Пролог.
                                                                  Я его так, для себя почитал.
                                                      • +1
                                                        Это сродни найти доказательство теоремы, что ничуть не проще нахождения конкретного решения, а даже — наоборот, сложнее.

                                                        Естественно написать корректную (с гарантированным отсутствием багов) программу сложнее, чем некорректную. И, разумеется, писать корректные программы экономически невыгодно, по крайней мере на текущем этапе развития индустрии. Какой смысл в ваших капитанских вопросах не по теме?
                                                        А практический смысл формальной верификации — то самое ПО без багов, пусть пока в теории. Но если не развивать теорию, то оно никогда в реальности и не появится.

                                                        • 0
                                                          акой смысл в ваших капитанских вопросах не по теме?
                                                          А практический смысл формальной верификации — то самое ПО без багов, пусть пока в теории. Но если не развивать теорию, то оно никогда в реальности и не появится.


                                                          Еще раз:

                                                          В комментариях никто даже не вышел на верную постановку задачи.
                                                          О каком развитии теории по решению задачи тут может идти речь?

                                                          • +2

                                                            А Вы ждали развития теории формального доказательства в комментариях на Хабре?.. смешной Вы однако.
                                                            Когда Вы уже ветку с начала перечитаете и осознаете, что тут никто и не собирался никаких задач ставить.
                                                            Сформулируйте лучше цель вашего активного оффтопика… Вы хотите привести доказательство, что формальная верификация невозможна никогда и ни при каких условиях или тупо покапитанить что это долго, дорого и не во всех случаях возможно?

                                                            • –2
                                                              А Вы ждали развития теории формального доказательства в комментариях на Хабре?.. смешной Вы однако.


                                                              Разумеется, не ожидал.

                                                              Если бы вы начали (если бы вы могли) обсуждать всерьез — 99% ваших собеседников бы скисло и вышло из беседы.

                                                              Интересно ведь просто языком побалякать, а не думать.
                                                              А тут думать пришлось серьезно, хотя бы чтоб прочитать и понять комментарий.

                                                              Я другого ожидал (ожидаю)
                                                              На Хабре частенько можно почитать упоминания об интересных вещах.
                                                              А дальше уже самому пойти копать.

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

                                                              Да и не старались.

                                                              Вот я и говорю — пустопорожняя беседа. В которой по сути проблемы никто ничего сказать и не может. Ни фразы.

                                                              • +1

                                                                Вам не кажется забавным, что эта "пустопорожняя беседа" по большей части состоит из Ваших собственных комментариев, на которые Вам изредка отвечают разные люди?
                                                                А по поводу ссылок, я Вам дал ссылки на Agda, на символьное выполнение программ и т.п. Уже успели ознакомиться?
                                                                В качестве практического применения символьное выполнение используется для автоматической генерации юнит-тестов.
                                                                Что касается Agda, то на основе его идей пилят язык общего назначения Idris, в феврале версию 1.0 собираются зарелизить.

                                                                • –1
                                                                  то на основе его идей пилят язык общего назначения Idris, в феврале версию 1.0 собираются зарелизить.


                                                                  Ну вот наконец-то, единственное золотое зерно.
                                                                  Все остальное — тлен и плевелы (плевела? плевел? )

                                                                  И почему мне нужно было ваш шпинять два дня, чтобы его получить?
                                                                  Отчего бы вам сразу не выставить такой (легчайший, что вполне достаточно) акцент на Idris?
                                                                  • +1

                                                                    Ну, Вы ворвались в ветку с заявлениями типа формальное описание — это бриф, а формальное доказательство — то же самое, что тестирование. Исходя из этого сложно сделать вывод, что тема Вам хоть капельку интересна, т.к. все заявления мимо кассы.
                                                                    На самом деле тема очень обширная. Хоть пока и не мейнстримная. И то, что Eiffel, Coq и Prolog не используются широко в повседневной разработке вовсе не значит, что они умерли, идеи их живут и развиваются. Рано или поздно это всё придёт и в мейнстрим, т.к. цена ошибок в ПО с каждым годом только растёт.

                                              • 0
                                                Если верификация реальна и она проще программного кода (а иначе какой в ней практический смысл) и при этом 100% гарантировано все режимы работы программы проверяет — давайте писать верификационный код. А ПО и будет переводить его в программный уже.


                                                Слышали о проблеме P и NP? Полагаю, нет.
                                                • 0
                                                  Слышали о проблеме P и NP? Полагаю, нет.


                                                  Ага. Имею не техническое программистское, а математическое ВУЗовское образование. Так что напрасно умничайте терминами.

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

                                                  Ибо понимает — есть пределы его ума. P и NP — а дальше сказать нечего.
                                                  Но этих букв достаточно, чтобы зрители благововели?

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

                                                  • +2
                                                    Имею не техническое программистское, а математическое ВУЗовское образование


                                                    … наличие которого не мешаем вам нести феерический бред вроде «давайте писать верификационный код. А ПО и будет переводить его в программный уже» или «Ее из 100% формального описания выведет автоматика за вас».

                                                    Так что напрасно умничайте терминами


                                                    Обычно слово «умничать» употребляют люди, которые не в теме и хотят, чтобы за это почему-то было стыдно собеседнику. Так вот, мне ни капельки не стыдно за ваше невежество.

                                                    P и NP — а дальше сказать нечего.
                                                    Но этих букв достаточно, чтобы зрители благововели?


                                                    Я думал, что этих букв достаточно, чтобы собеседник с якобы высшим математическим догадался, что логика «найти решение не сложнее, чем проверить его» не работает. Ну или хотя бы погуглил, если не в теме.
                                                  • 0
                                                    Господа, вы тут уже не первый день из пустого в порожнее переливаете.
                                                    Ни в практическом смысле пользы нет ни в математическо-теоретическом вы даже к правильным словам так подойти и не можете.


                                                    Ну так уйдите из этой ветки, раз не видите пользы. Останутся те, кто видит.
                                  • 0

                                    Что-то Вы опять какую-то несуразицу написали… Понятно что Вам лень изучать Agda, Prolog и т.д. Но какой смысл оффтопить, когда Вы совсем не в теме?

                                    • –2
                                      Что-то Вы опять какую-то несуразицу написали… Понятно что Вам лень изучать Agda, Prolog и т.д. Но какой смысл оффтопить, когда Вы совсем не в теме?


                                      Prolog умер лет 20 назад.

                                      Вы здесь занимаете пустопорожней беседой, господа.
                        • –1
                          Напомню, формальное описание это машинночитаемый документ, из которого логическими правилами можно вывести требуемое поведение (output) при заданном входе (input).


                          И такое существует и активно применяется
                          Скажем, http://swagger.io/ мы используем.

                          Только зачем вам машиночитаемое формальное описание?
                          Вам же с ним жить, кому это нужно в реальной практики постановки задач, кроме таких вещей как API

                          Как думаете, сколько миллионов страниц логических формул потребуется, чтобы вывести P(x,y) из D(x,y) для всех возможных ворд-документов? Кто напишет эти формулы и где гарантии, что в них не будет ошибок?


                          Ничего этого не нужно.
                          OCR существует. Делаем обратное преобразование и проверяем (даже тестами можно, автоматически).

                    • 0

                      Отчего же неизвестно? В очень многих случаях очень даже известно. Почти вся автоматика от микроволновок до "вояджеров" так работает.

  • +8

    На мой взгляд дело не в методологии а в цели ее внедрения. Если стали внедрять — значит недовольны текущим положением. Предположу, что хотели сократить расходы на разработку. Видимо цели добились — самые старые и наверное самые высокооплачиваемые ушли. Экономия налицо.


    Далее вероятно будет как в этом сценарии.

    • +1
      Не, обычно внедряют не потому, что не довольны, а потому что *модно*. Смотрите-ка, а у %условныйгугл% СКРАМ и нас на курсах MBA ему учили — это круто! надо внедрять! А! И, ни коем случае не забыть теперь считать человекочасы!
      Ну, а дальше по накатанной — найм эффективного манагера(главное умеющего красиво ссать в уши и петь диферамбы) и спуск в тартарары
      • 0
        Может и так.
  • +3
    Рискну сказать, что если методологию внедряют повсеместно плохо, может быть все-таки что-то не так с методологией? Постоянно слышу про «вы неправильно используете Agile/Scrum/...» — покажите мне, где они используются правильно?
    P.S. Сколько работал в компаниях, где был «Scrum» — работать было не очень приятно.
    P.P.S. Как можно оценить задачу в SP, если она может занять 1 день, а может 1 неделю?
    • –2
      Считается, что в команде есть хотя бы один компетентный разработчик, способный оценить задачу с минимальной погрешностью. В процессе игры в «планнинг покер» он может разъяснить свое видение решения остальным членам команды, а также помочь в разбиении этой задачи на подзадачи. Ошибка в неделю — это фокус фактор уровня джуниоров, которые только вчера увидели код, который им предстоит написать.
      Исключением могут быть задачи на исследование, но даже в этом случае обычно можно разбить задачу на несколько этапов и реализацию оставить на следующий спринт, когда будет известен подход.
      • +1
        Вы действительно считаете, что определение подхода исследовательской задачи (даже без реализации) может быть оценено? Если да — скажите область, интересно. В моей области это нереально, к сожалению.
        • 0
          Область эта именуется software development, где, собственно, и применяется Agile. Сложно оценить научные задачи, бывает сложно оценить производственные задачи, но это предметная область и этим занимаются отдельные люди. На agile-доску программистам попадают уже готовые ответы, которые необходимо перевести в код. Алгоритмы все известны, не думаю, что вы изобретаете новые. Оценить применимость того или иного алгоритма, а также композицию этих алгоритмов для решения конкретной проблемы — посильная задача.
          • +3
            >> программистам попадают уже готовые ответы, которые необходимо перевести в код. Алгоритмы все известны.
            Ну вот собственно и область применимости Agile. Да, согласен, в таком environment'е Agile будет в самый раз.
            • +1
              Да нет же, никаких «готовых» ответов нету — есть бизнес задачи, а разработчиков просят оценить их «примерно»
              Поэтому поинты обычно идут в геометрической прогрессии: 2, 4, 8, 16 (ну или там размеры футболок), чтобы не было соблазна пытаться давать точные оценки трудозатрат. Просто чтобы у бизнеса складывалось понимание что вот эта задача вроде как простая, займет максимум день, а вот эта посложнее, дня на 2-3 и т.д.
              Чтобы у менеджеров было примерное представление о сложности заданий. Ну и заодно насколько трезво члены команды оценивают свои силы.
            • 0
              Это же очевидно. На доске оказываются конкретные задачи после планирования и оценки, эти задачи содержат в себе информацию о том, что нужно сделать. Это уже ответ. Вопросы были немногим ранее, во время планирования спринта и обсуждения требований. Согласен, что Agile не применим в случаях, когда команда сидит свесив руки и асболютно не понимая, что нужно предпринять для достижения результата. Agile и Scrum — это о взаимодействий заказчиков и исполнителей, а также внутри команды исполнителей. Нигде не прописано, что если задача оказалась больше и перекочевала еще в пару спринтов после, то нужно отрубать кому-то руки. Прописано лишь то, что все заинтересованные лица будут об этом информированны как можно раньше. Одна из важнейших особенностей Agile в том, что команда учится и развивается, поэтому ошибки в оценках несмертельны.
          • +1
            ---На agile-доску программистам