Баги в используемых инструментах — это нормальная история, но это риски.
Профачил сроки в 10 раз, собрались на ретро — обсудили, что на задачи, требующие использования сторонних инструментов нужно закладывать больше буффер, потому что грустненько.
Если такие истории случаются каждый раз — искать более подходящие инструменты.
Затем, что это так работает только если предположить, что команда делает только запланированные задачи.
Не отвлекаясь на багфиксы продакшена, сторонние задачи, вопросы поступающие из вне и прочие неспринтовые таски. Да банальным «релиз не раскатывался».
А такие задачи почти всегда есть, их количество неконстантно, а время на них потраченное может варьироваться очень сильно и непрогнозируемо. Т.е. включать их в «сделано за спринт» — малополезно и ломает всю картину.
Таким образом проще потрекать грубые трудозатраты на спринтовые задачи и получить примерное понимание сразу двух вещей:
1) Сколько времени в спринте (и какой объем) отжирается незапланированными задачами (а это тоже история, над которой надо работать).
2) То, что я описывал выше.
Производительность команды — это то, сколько изменений в системе команда успевает делать за спринт.
Количество стори поинтов в задаче — абстрактная оценка объема изменений в системе, необходимых для реализации задачи.
Эти вещи по умолчанию связаны. Их нельзя «развязать».
Как мерить — вполне понятно. Есть коэффициент команды — N поинтов за спринт. Он меняется от спринта к спринту. Может меняться по естественным причинам, может по искусственным. Отфильтровать одно от другого довольно просто и это, в том числе, отлично делается на ретро.
Цели сделать так, что бы 1 стори поинт был равент 1 человекочасу нет и не должно быть. Цель — понимать, какой (примерный) объем изменений в систему может быть внесен командой за время спринта.
И для того, что бы это сделать — совсем не нужно отказываться ни от оценок, ни от приведения чего-то к чему-то.
Нужно, что бы все участники процесса (разработчики, продукт овнер, стейкхолдеры) хорошо понимали, зачем и почему оценка дается и зачем эта производительность мерить. Нужно понимать, что оценка это не инструмент для того, что бы потом потыкать человека носом «атата, ты не успел».
Это инструмент для того, что бы взять команда могла сказать «вот это мы успеем сделать за спринт, а вот это уже вряд ли — слишком большой объем изменений, больше — не получится, сорян».
Давление — не результат перевода поинтов в часы и не вина таблички на кухне. Давление — результат атмосферы в компании и напряженности отношений.
По поводу «разработчики начнут завышать оценки». Есть два сценария, когда это имеет смысл для разработчика.
1) Он видит большое количество потенциальных рисков и закладывает «буффер». Это имеет смысл, хотя следует объяснить разработчикам что это лучше делать в рамках всего спринта, а не в рамках конкретных задач. Типа «Ребята, мы вот в прошлом спринте успели сделать 120 сторипоинтов. Поэтому в этом спринте берем продуктовых задач на 70, ещё 30 на технический долг, а 20 — буффер на всякие риски».
Команда говорит «не, рисков дофига, давай 40 на риски заложим потому что интеграции много и вообще ад». На этом сошлись и всем хорошо.
2) Он считает, что продукт овнер ему враг и опасается, что если назовет реальную оценку — его потом вздрючат в случае чего. Аджайл так не работает, да и вообще работать в коллективах с такими настроениями вредно для психического здоровья.
Ну, и в обоих случаях завышение оценок повредит оценки производительности только если разработчики будут с каждым спринтом оценивать одинаковые по сложности задачи всё более объемно. Т.е. типовой CRUD в первом спринте был 3 поинта, во втором — 6, в третьем — 12.
В итоге коэффициент «производительности» будет постоянно расти (т.к. команда успевает делать всё больше поинтов из-за того, что задачи «переоценены») и это отлично разбирается на ретроспективе с объяснением «почему так делать ненадо».
Во первых, сильно зависит от исследовательских задач. Для большинства из них можно дать вполне конкретные сроки сколько ресурсов съест, например, знакомство с возможными технологиями для использования и их comparison.
Во вторых, для исследовательских задач эстимейт — не значит, что «через N часов у меня будет алгоритм».
Это значит что в этом спринте вы потратите N часов на исследование этого вопроса, а оставшиеся M будете заниматься другими задачами.
При этом по истечении этого эстимейта вполне нормальным (и ожидаемым) результатов будет являться «Попробовал следующие варианты, ни один из них не подходит для наших целей потому-то, потому-то. Есть ещё такие варианты, но на их исследование нужно ещё X времени».
А по какой причине одна и та же задача может занять 1 день, а может неделю?
Не сарказм, правда интересно. Я могу понять разброс в два раза, может даже в три. Ошибка в оценке в 7 раз по понятным и не меняющимся требованиям?
Я вот вижу три возможные причины:
1) Неполные и меняющиеся требования. Т.е. хотели одно (и делать это 1 день), потом захотели другое (и делать это неделю).
На этот случай скоуп спринта фиксируется и меняется только ценой жизни менеджеров по средством выкидывания других задач из спринта, и то только в случае, если работы можно распараллеливать.
2) Неясность реализации. Т.е. задача выглядит простой (на 1 день), но в процессе реализации всплывает много побочных факторов, требующих доработки.
И тут два пути: если есть подозрение, что такие проблемы могут возникнуть — сначала берется задача на исследование, что бы точно понимать объем работы, и только потом берется задача на реализацию.
Если с точки зрения разработчика проблем возникнуть не должно, понятно как это укладывается в текущую архитектуру и никаких рисков нет, а потом они появляются — значит есть высокая связанность и слабая прозрачность архитектуры приложения. Такие случаи пост-фактум разбираются на ретро, заводятся задачи на рефакторинг и редизайн кода.
3) Проблема оценки. Человек, оценивавший задачу не компетентен и\или страдает завышенным ЧСВ «я сделаю это с трёх нот».
С обоими случаями надо работать внутри команды — учить людей оценивать нормально, обеспечивать знакомство людей с кодом, оценивать задачи командой. Вариантов довольно много.
В ПО есть баги, получается везде ПО пишут неправильно?
Идеальных процессов не бывает. Есть команды, которые больше преуспели на пути к «идеальному», есть команды, у которых не получилось.
К сожалению, факторов по которым «что-то может пойти не так» слишком много, поэтому ребят проваливающих этот путь значительно больше, чем успешно его прошедших.
На пару комментов выше уже ответил на эту тему, не совсем с вами согласен.
Стори поинты, в итоге, всё равно привязываются к реальному времени, потому что так или иначе производительность мерить придётся. Любая система оценок, будь это часы, поинты, майки или попугаи всё равно придет к этому, потому что есть такая потребность.
Другое дело, что итоговое сведение поинтов в часы весьма приблизительное, несет характер «прогноза», а не клятвы на крови младенцев, и должно использоваться только как внутренний инструмент планирования в команде, а не как инструмент для давления на команду или охоты на медленно программирующих ведьм.
Нет, теоретический коэффициент 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
Временные «оценки» в аджайле всё равно есть, просто используются они совсем по другому, нежели в случае автора.
отдел разработки превратился из ядра компании, приносящего деньги, просто в инструмент, наподобие отвертки или молотка.
Понимаю, обидненько. Только процессы тут не при чем.
почасовой отчет по времени оставлял привкус того, что за твоей спиной непрерывно кто-то стоит и наблюдает, как ты нажимаешь кнопки.
Вообще никакого отношения к agile не имеет. Аджайл учит менеджеров очень трепетно и бережно относиться к эстимейтам разработчиков и ни в коем случае не считать их последним дедлайном.
Единственный срок который есть — конец спринта, который должен закончиться поставкой работающего функционала. И то, это только значит, что к концу спринта продукт должен получить позитивные изменения. Это не значит, что все задачи обязаны быть в Done.
Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде, не учитывает того, что некоторые вещи в компании могут делаться только из-за энтузиазма сотрудников, и не могут быть завернуты в UserStory.
Во первых, нет вещей и задач, которые не могут быть завернуты в UserStory. Просто источником этих юзерстори может быть не только стейкхолдер, но и сама команда.
Во вторых, если вы откроете agilemanifesto.org вы во втором же абзаце увидите, что
Individuals and interactions over processes and tools
А это напрямую противоречит вашему утверждению.
Так может быть, проблема не в аджайле, а во внедренцах?
P.S. Наконец-то хоть кто-то упомянул TargetProccess, который лично мной нежно любим и почитаем, как один из наиболее удобных таск-менеджмент систем.
Проблема всплывающих подсказок предельно проста.
На пк они, обычно, появляются при наведении. При пользовании мобильным девайсом такого понятие как «навел курсор» — нет. Ты сразу взаимодействуешь с элементами интерфейса.
И упаси боже кого-нибудь создать приложение, в котором надо будет сначала тапнуть по элементу, что бы увидеть всплывающую подсказку, а потом ещё раз тапнуть — что бы на него нажать. Это же ад.
Теоретически, так называемые wizard'ы, ака небольшой мануал при первом использовании приложения\функционала должны решать проблему.
Но визарды рождают массу проблем. Основная — их никто не читает, а тупо прокликивают (это помимо того, что их нужно уметь создавать, а ещё поддерживать и актуализировать при малейшем редизайне или изменении приложения).
Можно бесконечно долго обвинять разработчиков в глупости и равнодушности к боли пользователей (хотя есть и таки). Но… пример из моей практики: продукт — бизнес инструмент, т.е. помогает человеку зарабатывать деньги. Есть отдельный человек, который пишет классные мануалы и анонсы, которые доступны как внутри приложения так и из вне (ссылки, письма и прочее). Мануалы действительно приятно написаны, лаконичны, по делу, с хорошим языком и иллюстрацией. Он (человек этот) только и делает что 40 часов в неделю готовит эту документацию и анонсы, стараясь поспевать за темпами разработки.
При этом читают эти мануалы единицы людей, даже когда им даешь ссылку на конкретный абзац. Люди предпочитают ломиться саппорту в скайп, писать гневные письма из-за очевидных проблем на их стороне и прочее. Лишь бы не читать мануал.
Спрашивается, зачем компании это всё?
Ввести законодательно далеко не всегда подразумевает «всё, ребята, завтра можете уходить на 2 часа раньше, а работодатель пусть вертится как хочет».
Обычно у таких законов (когда они затрагивают гос. предприятия) есть довольно длинное приложение с требованиями по внедрению.
Типа к MM.YY работодатели должны подготовить планы перехода на 6 часовой рабочий день, к MM+X.YY должны подготовить инфраструктуру и нанять людей для закрытия потребностей.
Потом ещё Z месяцев «переходного периода», а потом уже полноценное функционирование рабочей недели.
Так нет, подождите. Вы говорите, что концепция «работать 6 часов, вместо 8» увеличивает стрессовость работы де факто.
Я говорю, что она может увеличивать стрессовость работы только при неправильном внедрении.
Негибкая система, которую так просто не изменишь — это проблема внедрения, а не изъян концепции сокращенного рабочего дня.
Никто и не спорит, что внедрить такую систему в перегруженной, забюрократизированной и требующей высокой квалификации кадров больнице значительно сложнее, чем в стартапчике клепающем сайты. Это настолько очевидно, что не требует обсуждения.
Я говорю про то, что внедрение такой системы возможно, просто требуется это делать вдумчиво, правильно и неспешно. И, естественно, вполне вероятно что получится не с первого раза.
Просто то, что один раз Шведы (а точнее, скорее, отдельно взятые учереждения и чиновники) накосячили с внедрением — ещё не повод кричать «идея провальная, не взлетит».
Плотность работы никуда не девается, но она и не растёт (как утверждали выше).
Т.е. если ты работаешь в перегруженном режиме, то ты продолжишь работать в таком режиме.
Но при этом ты будешь это делать 6 часов в день, а не 8. А это значительно проще, согласитесь?
«Авралы» которые возникают случайным (непрогнозируемым) образом — во первых, скорее, исключение, чем правило. Во вторых, они всегда привязаны ко времени. Он (аврал) может случиться в вашу смену, может случиться в чужую смену. Меньше продолжительность смены -> меньше шансов что аврал попадёт на вас.
Работаете в немецкой клинике это здорово, рад за вас.
Ещё раз. У вас сокращается рабочий день на 2 часа. Эти два часа, которые у вас сократили, за вас должен работать какой-то другой человек.
Предположим, ранее вы работали с 10 до 18, после чего передавали смену человеку, который работал с 18 до 2, а пиковая нагрузка приходилась с 10 до 22.
Теперь вы работаете с 8 до 14, передаете смену человеку, работающему с 14 до 20, а он — ещё одному.
Таким образом пиковая нагрузка размазана по вам троим.
Количество пациентов (нагрузка) при этом не меняется.
Скажите, пожалуйста, почему нагрузка на вас в данном случае возрастает?
Я вижу несколько возможных сценариев:
1) Смена заканчивается, а у вас дел не в проворот и передать вы их не можете. Приходится овертаймить.
Овертаймить плохо, нужно лучше организовывать процесс смены смен (простите за тавтологию) в клинике.
2) Смена заканчивается, а подменить вас некому (условно — человека ещё не наняли). Приходится овертаймить и\или стараться делать работу быстрее, что бы потом не овертаймить.
Овертаймить плохо, клиника должна лучше готовиться к изменениям графика работы сотрудников и искать людей на доп. смену заранее.
3) Длительность вашей смены сократилась, но поменялся и график работы организации, т.е. те, кто не успеет к вам за 6 часов — не успеют вообще. И тогда опять же нагрузка возрастает.
Это понятная ситуация, но «переход на 6 часовой рабочий день» это не «давайте пятилетку за три года».
Все три сценарии связаны не с тем, что идея 6 часовых рабочих смен не жизнеспособна в мед.сфере, а с тем, что организовано отвратительно.
Во всех остальных сценариях ваш объем работы _должен_ уменьшаться пропорционально уменьшению количества рабочего времени.
Не очень понимаю, как вы пришли к такому выводу.
Нагрузка в общем не меняется, просто размазывается не на 3 смены, а на 4.
Пиковая нагрузка, которая ранее условно приходилась на 1.5 смены (часть утренней + дневную, условно), теперь приходится на 2 (а на самом деле на 3 — часть утренней, дневную и часть вечерней).
Почему вдруг кто-то должен начать нагружаться больше — непонятно. Тут два варианта:
1) Плохо налажен переход из смены в смену, т.е. передача дел
2) Смены сократили, а новых людей ещё не нашли.
Единственный неплохой способ заработать на форексе — создать торговую площадку. И то, неплохой он если не считать этической и кармической составляющих.
Эти две вещи, на самом деле, весьма спорные.
8-hour people такое же зло, как корпорации считающие, что сотрудники должны впахивать 24\7 за зарплату, предполагающую 40 часовую рабочую неделю. Тем более, когда официально неделя 40 часовая, но «условно» — ты в рабстве и на всех, кто не овертаймит смотрят как на говно. Во всём нужен баланс.
Я готов предложить компании свою готовность решать её проблемы в любое нужное время, но сам ожидаю от компании ответного отношения (и речь сейчас не обязательно о деньгах). Иначе это буллшит.
По поводу мессенджеров как средства коммуникации внутри компании. Тут всё сильно зависит от ситуации и «порядков» в компании. Кого-то бесит, когда им пишут в мессенджер, кому-то не ок на почту, кому-то плохо когда проблемы «продакшен в огне, сервер лежит» решаются не через задачу в джире.
Например, когда обсуждение и решение проблемы занимает месяц и требует пересылки цепочки писем через 10 отделов — оптимальным решением выглядит почта. Но, тут есть проблема, что все кто вне этой цепочки не получают доступа к этой информации (и отдельный вопрос- должны ли получать).
Когда обсуждение проблемы занимает 15 минут и интересно внутри команды — то командный чатик больше походит на идеальный инструмент.
Мне, лично, больше хочется убивать тех, кому пишешь «Вася, обсудили с N проблему M, пришли к такому-то решению, нужно сделать вот так, вот задача», а тебе в ответ «продублируй на почту».
Проблема таких сервисов вот в чём: отсутствие подходящего железа можно исправить. Заказать из-за бугра, если не продается рядом с домом. Взять в кредит, если нет денег. Всячески соптимизировать и собрать приемлемую комплектацию за разумные деньги. В общем варианты есть.
Но с паршивым коннектом (а то, что это боттлнек вы сами признаете в статье) ты ничего не сделаешь.
Нельзя просто позвонить в условный Ростелеком и сказать «пацаны, выключите там свой СОРМ, у меня тут трансляция овервотча лагает».
И для пользователя это никогда не будет проблемой на его стороне (потому, что она не на его стороне, на самом-то деле). Для пользователя это будет Вашей проблемой.
Профачил сроки в 10 раз, собрались на ретро — обсудили, что на задачи, требующие использования сторонних инструментов нужно закладывать больше буффер, потому что грустненько.
Если такие истории случаются каждый раз — искать более подходящие инструменты.
Не отвлекаясь на багфиксы продакшена, сторонние задачи, вопросы поступающие из вне и прочие неспринтовые таски. Да банальным «релиз не раскатывался».
А такие задачи почти всегда есть, их количество неконстантно, а время на них потраченное может варьироваться очень сильно и непрогнозируемо. Т.е. включать их в «сделано за спринт» — малополезно и ломает всю картину.
Таким образом проще потрекать грубые трудозатраты на спринтовые задачи и получить примерное понимание сразу двух вещей:
1) Сколько времени в спринте (и какой объем) отжирается незапланированными задачами (а это тоже история, над которой надо работать).
2) То, что я описывал выше.
Количество стори поинтов в задаче — абстрактная оценка объема изменений в системе, необходимых для реализации задачи.
Эти вещи по умолчанию связаны. Их нельзя «развязать».
Как мерить — вполне понятно. Есть коэффициент команды — N поинтов за спринт. Он меняется от спринта к спринту. Может меняться по естественным причинам, может по искусственным. Отфильтровать одно от другого довольно просто и это, в том числе, отлично делается на ретро.
Цели сделать так, что бы 1 стори поинт был равент 1 человекочасу нет и не должно быть. Цель — понимать, какой (примерный) объем изменений в систему может быть внесен командой за время спринта.
И для того, что бы это сделать — совсем не нужно отказываться ни от оценок, ни от приведения чего-то к чему-то.
Нужно, что бы все участники процесса (разработчики, продукт овнер, стейкхолдеры) хорошо понимали, зачем и почему оценка дается и зачем эта производительность мерить. Нужно понимать, что оценка это не инструмент для того, что бы потом потыкать человека носом «атата, ты не успел».
Это инструмент для того, что бы взять команда могла сказать «вот это мы успеем сделать за спринт, а вот это уже вряд ли — слишком большой объем изменений, больше — не получится, сорян».
Давление — не результат перевода поинтов в часы и не вина таблички на кухне. Давление — результат атмосферы в компании и напряженности отношений.
По поводу «разработчики начнут завышать оценки». Есть два сценария, когда это имеет смысл для разработчика.
1) Он видит большое количество потенциальных рисков и закладывает «буффер». Это имеет смысл, хотя следует объяснить разработчикам что это лучше делать в рамках всего спринта, а не в рамках конкретных задач. Типа «Ребята, мы вот в прошлом спринте успели сделать 120 сторипоинтов. Поэтому в этом спринте берем продуктовых задач на 70, ещё 30 на технический долг, а 20 — буффер на всякие риски».
Команда говорит «не, рисков дофига, давай 40 на риски заложим потому что интеграции много и вообще ад». На этом сошлись и всем хорошо.
2) Он считает, что продукт овнер ему враг и опасается, что если назовет реальную оценку — его потом вздрючат в случае чего. Аджайл так не работает, да и вообще работать в коллективах с такими настроениями вредно для психического здоровья.
Ну, и в обоих случаях завышение оценок повредит оценки производительности только если разработчики будут с каждым спринтом оценивать одинаковые по сложности задачи всё более объемно. Т.е. типовой CRUD в первом спринте был 3 поинта, во втором — 6, в третьем — 12.
В итоге коэффициент «производительности» будет постоянно расти (т.к. команда успевает делать всё больше поинтов из-за того, что задачи «переоценены») и это отлично разбирается на ретроспективе с объяснением «почему так делать ненадо».
Во вторых, для исследовательских задач эстимейт — не значит, что «через N часов у меня будет алгоритм».
Это значит что в этом спринте вы потратите N часов на исследование этого вопроса, а оставшиеся M будете заниматься другими задачами.
При этом по истечении этого эстимейта вполне нормальным (и ожидаемым) результатов будет являться «Попробовал следующие варианты, ни один из них не подходит для наших целей потому-то, потому-то. Есть ещё такие варианты, но на их исследование нужно ещё X времени».
Не сарказм, правда интересно. Я могу понять разброс в два раза, может даже в три. Ошибка в оценке в 7 раз по понятным и не меняющимся требованиям?
Я вот вижу три возможные причины:
1) Неполные и меняющиеся требования. Т.е. хотели одно (и делать это 1 день), потом захотели другое (и делать это неделю).
На этот случай скоуп спринта фиксируется и меняется только
ценой жизни менеджеровпо средством выкидывания других задач из спринта, и то только в случае, если работы можно распараллеливать.2) Неясность реализации. Т.е. задача выглядит простой (на 1 день), но в процессе реализации всплывает много побочных факторов, требующих доработки.
И тут два пути: если есть подозрение, что такие проблемы могут возникнуть — сначала берется задача на исследование, что бы точно понимать объем работы, и только потом берется задача на реализацию.
Если с точки зрения разработчика проблем возникнуть не должно, понятно как это укладывается в текущую архитектуру и никаких рисков нет, а потом они появляются — значит есть высокая связанность и слабая прозрачность архитектуры приложения. Такие случаи пост-фактум разбираются на ретро, заводятся задачи на рефакторинг и редизайн кода.
3) Проблема оценки. Человек, оценивавший задачу не компетентен и\или страдает завышенным ЧСВ «я сделаю это с трёх нот».
С обоими случаями надо работать внутри команды — учить людей оценивать нормально, обеспечивать знакомство людей с кодом, оценивать задачи командой. Вариантов довольно много.
Идеальных процессов не бывает. Есть команды, которые больше преуспели на пути к «идеальному», есть команды, у которых не получилось.
К сожалению, факторов по которым «что-то может пойти не так» слишком много, поэтому ребят проваливающих этот путь значительно больше, чем успешно его прошедших.
Стори поинты, в итоге, всё равно привязываются к реальному времени, потому что так или иначе производительность мерить придётся. Любая система оценок, будь это часы, поинты, майки или попугаи всё равно придет к этому, потому что есть такая потребность.
Другое дело, что итоговое сведение поинтов в часы весьма приблизительное, несет характер «прогноза», а не клятвы на крови младенцев, и должно использоваться только как внутренний инструмент планирования в команде, а не как инструмент для давления на команду или охоты на медленно программирующих ведьм.
Это важная и нужная метрика, позволяющая более-менее нормально планировать работу в команде.
Другое дело, что этот коэффициент всегда динамичен и меняется от спринта к спринту.
Цель команды — выдать максимум SP в продакшен к концу спринта без овертаймов, стресса и баттхёртов. Цель «менеджмента» и процессов — создать условия для этого роста производительности.
Например, если выполнение 1 SP у команды занимает с каждым спринтом всё больше времени, то тут есть ряд возможных причин:
1) Калибруется оценка задач в SP и «элементарная задача», являющаяся одним сторипоинтом, разрастается.
2) Мотивация команды падает и работают медленнее.
3) Накапливается легаси и костыли и внесение даже простых правок начинает занимать больше времени.
4-999) ещё много возможных причин.
Для анализа этих причин есть ретроспектива, как и для анализа того, что в текущем спринте позволило нам сделать больше SP, чем в предыдущем.
Есть ещё более сложные сценарии, типа SP/day у команды растёт, а у конкретного человека падает. Это может быть потому, что он задолбался, а остальные фигачат за него. А может быть потому, что он стал больше времени тратить на саппорт коллегам, ревью и прочие не функциональные задачи.
Подсчёт SP\day, безусловно, требует от разработчиков как-то трекать время (а мы с вами знаем, что никто не любит трекать время).
Но, прежде чем внедрять трекинг времени, нужно чётко и ясно донести до команды зачем это делается. Что бы все (включая «менеджеров») понимали, что это делается не для того, что бы посмотреть что ты делал 8 часов рабочего дня (не дай бог читал хабр), и не для того, что бы потом кого-нибудь уволить «потому что слишком мало сторипоинтов делаешь». А для того, что бы более комфортно _для команды_ планировать объем спринтов.
При этом для этих целей:
1) Вполне допустима определенная «погрешность» в оценке затраченного времени. Точность до часов тут нафиг не сдалась. Т.е. шкала оценок «1 час — 4 часа — 1 день — 3 дня — неделя» вполне ясно дает понять ситуацию.
2) Ни в коем случае не намекает нерадивым менеджерам, что разработчик обязательно должен натрекать 40 часов в неделю на задачи, и не дай бог он там хабр читал. Это простое самодурство и синдром вахтёра, аджайл тут ни при чём.
TLDR
Временные «оценки» в аджайле всё равно есть, просто используются они совсем по другому, нежели в случае автора.
Понимаю, обидненько. Только процессы тут не при чем.
Вообще никакого отношения к agile не имеет. Аджайл учит менеджеров очень трепетно и бережно относиться к эстимейтам разработчиков и ни в коем случае не считать их последним дедлайном.
Единственный срок который есть — конец спринта, который должен закончиться поставкой работающего функционала. И то, это только значит, что к концу спринта продукт должен получить позитивные изменения. Это не значит, что все задачи обязаны быть в Done.
Во первых, нет вещей и задач, которые не могут быть завернуты в UserStory. Просто источником этих юзерстори может быть не только стейкхолдер, но и сама команда.
Во вторых, если вы откроете agilemanifesto.org вы во втором же абзаце увидите, что
А это напрямую противоречит вашему утверждению.
Так может быть, проблема не в аджайле, а во внедренцах?
P.S. Наконец-то хоть кто-то упомянул TargetProccess, который лично мной нежно любим и почитаем, как один из наиболее удобных таск-менеджмент систем.
На пк они, обычно, появляются при наведении. При пользовании мобильным девайсом такого понятие как «навел курсор» — нет. Ты сразу взаимодействуешь с элементами интерфейса.
И упаси боже кого-нибудь создать приложение, в котором надо будет сначала тапнуть по элементу, что бы увидеть всплывающую подсказку, а потом ещё раз тапнуть — что бы на него нажать. Это же ад.
Теоретически, так называемые wizard'ы, ака небольшой мануал при первом использовании приложения\функционала должны решать проблему.
Но визарды рождают массу проблем. Основная — их никто не читает, а тупо прокликивают (это помимо того, что их нужно уметь создавать, а ещё поддерживать и актуализировать при малейшем редизайне или изменении приложения).
Можно бесконечно долго обвинять разработчиков в глупости и равнодушности к боли пользователей (хотя есть и таки). Но… пример из моей практики: продукт — бизнес инструмент, т.е. помогает человеку зарабатывать деньги. Есть отдельный человек, который пишет классные мануалы и анонсы, которые доступны как внутри приложения так и из вне (ссылки, письма и прочее). Мануалы действительно приятно написаны, лаконичны, по делу, с хорошим языком и иллюстрацией. Он (человек этот) только и делает что 40 часов в неделю готовит эту документацию и анонсы, стараясь поспевать за темпами разработки.
При этом читают эти мануалы единицы людей, даже когда им даешь ссылку на конкретный абзац. Люди предпочитают ломиться саппорту в скайп, писать гневные письма из-за очевидных проблем на их стороне и прочее. Лишь бы не читать мануал.
Спрашивается, зачем компании это всё?
Обычно у таких законов (когда они затрагивают гос. предприятия) есть довольно длинное приложение с требованиями по внедрению.
Типа к MM.YY работодатели должны подготовить планы перехода на 6 часовой рабочий день, к MM+X.YY должны подготовить инфраструктуру и нанять людей для закрытия потребностей.
Потом ещё Z месяцев «переходного периода», а потом уже полноценное функционирование рабочей недели.
Я говорю, что она может увеличивать стрессовость работы только при неправильном внедрении.
Негибкая система, которую так просто не изменишь — это проблема внедрения, а не изъян концепции сокращенного рабочего дня.
Никто и не спорит, что внедрить такую систему в перегруженной, забюрократизированной и требующей высокой квалификации кадров больнице значительно сложнее, чем в стартапчике клепающем сайты. Это настолько очевидно, что не требует обсуждения.
Я говорю про то, что внедрение такой системы возможно, просто требуется это делать вдумчиво, правильно и неспешно. И, естественно, вполне вероятно что получится не с первого раза.
Просто то, что один раз Шведы (а точнее, скорее, отдельно взятые учереждения и чиновники) накосячили с внедрением — ещё не повод кричать «идея провальная, не взлетит».
Т.е. если ты работаешь в перегруженном режиме, то ты продолжишь работать в таком режиме.
Но при этом ты будешь это делать 6 часов в день, а не 8. А это значительно проще, согласитесь?
«Авралы» которые возникают случайным (непрогнозируемым) образом — во первых, скорее, исключение, чем правило. Во вторых, они всегда привязаны ко времени. Он (аврал) может случиться в вашу смену, может случиться в чужую смену. Меньше продолжительность смены -> меньше шансов что аврал попадёт на вас.
Ещё раз. У вас сокращается рабочий день на 2 часа. Эти два часа, которые у вас сократили, за вас должен работать какой-то другой человек.
Предположим, ранее вы работали с 10 до 18, после чего передавали смену человеку, который работал с 18 до 2, а пиковая нагрузка приходилась с 10 до 22.
Теперь вы работаете с 8 до 14, передаете смену человеку, работающему с 14 до 20, а он — ещё одному.
Таким образом пиковая нагрузка размазана по вам троим.
Количество пациентов (нагрузка) при этом не меняется.
Скажите, пожалуйста, почему нагрузка на вас в данном случае возрастает?
Я вижу несколько возможных сценариев:
1) Смена заканчивается, а у вас дел не в проворот и передать вы их не можете. Приходится овертаймить.
Овертаймить плохо, нужно лучше организовывать процесс смены смен (простите за тавтологию) в клинике.
2) Смена заканчивается, а подменить вас некому (условно — человека ещё не наняли). Приходится овертаймить и\или стараться делать работу быстрее, что бы потом не овертаймить.
Овертаймить плохо, клиника должна лучше готовиться к изменениям графика работы сотрудников и искать людей на доп. смену заранее.
3) Длительность вашей смены сократилась, но поменялся и график работы организации, т.е. те, кто не успеет к вам за 6 часов — не успеют вообще. И тогда опять же нагрузка возрастает.
Это понятная ситуация, но «переход на 6 часовой рабочий день» это не «давайте пятилетку за три года».
Все три сценарии связаны не с тем, что идея 6 часовых рабочих смен не жизнеспособна в мед.сфере, а с тем, что организовано отвратительно.
Во всех остальных сценариях ваш объем работы _должен_ уменьшаться пропорционально уменьшению количества рабочего времени.
Нагрузка в общем не меняется, просто размазывается не на 3 смены, а на 4.
Пиковая нагрузка, которая ранее условно приходилась на 1.5 смены (часть утренней + дневную, условно), теперь приходится на 2 (а на самом деле на 3 — часть утренней, дневную и часть вечерней).
Почему вдруг кто-то должен начать нагружаться больше — непонятно. Тут два варианта:
1) Плохо налажен переход из смены в смену, т.е. передача дел
2) Смены сократили, а новых людей ещё не нашли.
8-hour people такое же зло, как корпорации считающие, что сотрудники должны впахивать 24\7 за зарплату, предполагающую 40 часовую рабочую неделю. Тем более, когда официально неделя 40 часовая, но «условно» — ты в рабстве и на всех, кто не овертаймит смотрят как на говно. Во всём нужен баланс.
Я готов предложить компании свою готовность решать её проблемы в любое нужное время, но сам ожидаю от компании ответного отношения (и речь сейчас не обязательно о деньгах). Иначе это буллшит.
По поводу мессенджеров как средства коммуникации внутри компании. Тут всё сильно зависит от ситуации и «порядков» в компании. Кого-то бесит, когда им пишут в мессенджер, кому-то не ок на почту, кому-то плохо когда проблемы «продакшен в огне, сервер лежит» решаются не через задачу в джире.
Например, когда обсуждение и решение проблемы занимает месяц и требует пересылки цепочки писем через 10 отделов — оптимальным решением выглядит почта. Но, тут есть проблема, что все кто вне этой цепочки не получают доступа к этой информации (и отдельный вопрос- должны ли получать).
Когда обсуждение проблемы занимает 15 минут и интересно внутри команды — то командный чатик больше походит на идеальный инструмент.
Мне, лично, больше хочется убивать тех, кому пишешь «Вася, обсудили с N проблему M, пришли к такому-то решению, нужно сделать вот так, вот задача», а тебе в ответ «продублируй на почту».
Но с паршивым коннектом (а то, что это боттлнек вы сами признаете в статье) ты ничего не сделаешь.
Нельзя просто позвонить в условный Ростелеком и сказать «пацаны, выключите там свой СОРМ, у меня тут трансляция овервотча лагает».
И для пользователя это никогда не будет проблемой на его стороне (потому, что она не на его стороне, на самом-то деле). Для пользователя это будет Вашей проблемой.