Обратная сторона 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 был организован неверно, но, так или иначе, свою черную сторону этот процесс имел.
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 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
                                                    Мне кажется, даже если тапок и вправду предназначен для забивания гвоздей, возможно в том числе и неправильное его применение. Как на кадрах 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% потому что «модно» (даже если на самом деле уже и не так). Результаты в этом случае почему-то тоже плачевные.
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                              • –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 (да и не только) есть такое прекрасное слово «Нет, мы не будем это делать».
                                                                                                            Но боль вашу прекрасно понимаю, у нас тоже так «удачно» внедрили «Девопс».