Вы видели, как хорошо отлаженная agile-команда выполняет свою работу? Приятно смотреть. У них есть ритм для поставки программного обеспечения - программисты работают в стабильном темпе и достигают бизнес-целей. Я думаю, это связано с тем, что гибкое управление проектами правильно делает две вещи: баллы за относительную оценку и прогнозирование будущей производительности с использованием прошлых средних значений (скорости и волатильности). Эти два метода учитывают тот факт, что отдельные оценки подвержены ошибкам, и позволяют их обойти.

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

«Когда вы отправите товар?» - спрашивает покупатель.

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

Это вопрос с подвохом, - говорите вы. Представьте, что вы решили« прогуляться по побережью от Сан-Франциско до Лос-Анджелеса… »

Но вас прервали.

«Постой, я никуда не пойду! Просто назначь мне свидание, ладно? »

Так начинается долгий разговор, первый из серии долгих разговоров.

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

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

Но сначала мы должны понять, с чем мы сталкиваемся.

Оценки - это обязательства перед самими собой

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

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

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

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

Различные исследования показали, что уклонения от якоря очень трудно избежать. Например, в одном исследовании студентам были даны явно неправильные якоря. Их спросили, умер ли Махатма Ганди до или после 9 лет, до или после 140 лет. Ясно, что ни один из этих якорей не может быть правильным, но две группы все же предположили значительно различающиеся (средний возраст 50 лет против среднего возраста 67 лет).

Дэн Ариэли провел значительные эксперименты с Anchoring, о которых он рассказывает в своей увлекательной книге Predictably Irrational.

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

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

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

Оценки - это обязательства перед нашими клиентами

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

Вы думаете: Всего рассказов около 45 баллов. Наша средняя недельная скорость составляет 16, а волатильность незначительна. У нас еще будет хороший буфер на четыре недели.

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

Ваш клиент слышит: бла-бла-бла, бла-бла, .. конец декабря ..

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

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

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

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

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

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

  • Повторите, что оценки не являются обязательствами.
  • Спросите, для чего будут использоваться наши оценки. Мы всегда должны знать полный смысл цифр, которые мы предоставляем.
  • Будьте осторожны, чтобы не подкреплять ожидания окружающих, потому что сегодняшняя хорошая погода не превратится в завтрашнюю. Но мы уважаем владельцев своего бизнеса и понимаем, что они способны справиться с реальностью. Мы держим их в курсе всех промахов в плане по мере их возникновения. Мы стоим перед лицом как прогресса, так и неудач.
  • Не работаю по выходным. Мы работали по выходным, и это не помогло. В конечном счете, этого никогда не происходит. Не работайте по выходным и не давайте оптимистичных оценок, думая, что будете.
  • Расслабьтесь и подумайте. Когда дела идут плохо, мы забываем думать. Стресс создает адреналин и затуманивает наши суждения. Фильтрация данных не помешала. Он мог бы подождать, и мы могли бы отправить товар вовремя, только если бы у нас хватило духа рассмотреть такую ​​возможность.

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

Случайные оценки

Случайные разговоры - это минное поле, когда дело доходит до опасно неверных оценок:

«Итак, насколько сложна эта функция? Это как час работы или несколько? »

И ты говоришь: «определенно не быстрый. Скорее всего, день ».

Остановитесь прямо здесь и обратите внимание:

  • Заказчик сделал вашу работу за вас и предоставил оценку в самом вопросе. Фактически, они начали с минимально возможного числа, заставляя вас закрепиться на нем. Это переговоры. Оценка никогда не должна быть предметом переговоров.
  • Мы подумали, что это случайный вопрос, и дали случайный (то есть неправильный) ответ. Но когда вы приближаетесь к фактической оценке этого, сказать покупателю, что предыдущая оценка была неверной, сродни отказу от взятого на себя обязательства. Неважно, что это приблизительное число, эта деталь будет забыта и покупателем, и вами. Тем не менее случайные обещания остаются обещаниями, поэтому не давайте их.
  • Разговаривайте о времени, а не о сюжетных точках. Очки истории - полезная абстракция, постарайтесь придерживаться ее, если можете. (Зачем использовать рассказы вместо часов для оценки).

Теперь этот же разговор будет выглядеть так:

«Итак, насколько сложна эта функция? Это как час работы или несколько? »

И вы могли бы подумать об этом и сказать:

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

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

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

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

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

Нечеткость

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

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

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

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

Планируйте, а не оценивайте.

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

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

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

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

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

Осознанное мышление - это мощный стимул для повышения производительности (ага!). Но генерация мысли требует больших затрат энергии. Поэтому мы сопротивляемся этому и полагаемся на интуицию, которая представляет собой просто мозг, работающий на автопилоте. Это не эффективная стратегия. Вот посмотрите, что некоторые предварительные планы сделали с писательницей Рэйчел Аарон (курсив ее):

Оглядываясь назад, я понимаю, что это было так просто, что я чувствую себя глупо из-за того, что не подумал об этом раньше. Если вы хотите писать быстрее, первым делом нужно знать, что вы пишете, прежде чем писать. Я даже не говорю о макросюжетных вещах, я имею в виду отработку обмена аргументами между персонажами, блокирование драк, написание быстрых описаний. Чтобы описать это словами, которые вы хотите, чтобы другие люди прочитали, особенно если вы все придумываете по ходу дела, потребуется НАВСЕГДА. Это ужасно неэффективно, и когда вы заходите в тупик, вы в конечном итоге выбрасываете сотни, а иногда и тысячи слов, чтобы найти выход. Но записать это в блокнот? Совершенно не требует времени. Если сцена, которую вы набрасываете, начинает развиваться не в том направлении, вы сразу это видите, и все, что вам нужно сделать, это вычеркнуть испорченные части и начать заново с самого начала. Вот и все. Ни слова не потеряны, ни время не потеряно. Это было чертовски красиво.

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

Ей удалось увеличить объем ежедневной работы с 2000 до 10 000 слов в день, в основном благодаря планированию. Программирование тоже в своей базовой форме, просто написание. Из этого ремесла можно извлечь много уроков, и этот как раз тому пример. Вместо того, чтобы часами валяться в коде - идти туда, куда ведет нас код, попадать в тупики и отступать, теряться в деревьях и терять из виду лес, немного размышлений и планирования могут творить чудеса для наших дней. как программисты.

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

Реализация становится легкой, когда у нас есть твердый план, которому нужно следовать. Когда это происходит, наступает прекрасный день для написания кода.

Оценка как побочный продукт плана

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

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

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

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

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

Первоначально опубликовано на www.jasimabasheer.com.