Пользовательские истории. Искусство гибкой разработки ПО

«Зачем они вообще тратили на это время?» – можете удивиться вы. Действительно, предъявить треть от того, что нужно заказчикам, – это примерно как продавать одну треть спортивного автомобиля: никто не сможет на нем ездить. Но Майк владелец продукта. Он не может отойти в сторону после того, как найдено хорошее решение. Его роль немного меняется, и сейчас он больше похож на режиссера в кино: должен присутствовать при съемках каждой сцены. И ему нужно решить, какие сцены должны быть отсняты первыми, а какие – последними. Он знает, что к концу съемок фильма все сцены сложатся вместе и составят одно последовательное повествование.

Поэтому Майк и работал со своей командой над составлением плана разработки. Вот что они сделали – разделили карту тремя поперечными срезами.

Первый срез включает в себя основные функциональные элементы. Как только все фрагменты, входящие в этот срез, будут реализованы, работа с функциональностью может быть проделана в приложении шаг за шагом. Функциональность будет работать не во всех ситуациях, где запланировано, поэтому предъявлять ее пользователям на этом этапе нельзя: последует лавина жалоб и возмущений. Но зато Майк и его команда смогут понаблюдать за работой функциональности с начала до конца. Они смогут ввести реальные данные и оценить производительность приложения, а также применить некоторые средства автоматизированного тестирования, чтобы оценить способность к масштабированию нагрузки. Можно узнать многое о технических рисках, которые способны вызвать значительные проблемы позднее. Таким образом, двигаясь вперед, команда будет более уверена в своевременном окончании разработки. Или по крайней мере будут выявлены непредвиденные трудности, которые могут замедлить работу. Первый срез я называю функциональным ходячим скелетом

– этот термин я позаимствовал у Алистера Коберна. Я слышал также, что в этом значении употребляются слова «стальной каркас» или «трассирующая пуля».

Второй срез нужен для дополнения функциональности и приведения ее в состояние, близкое к готовности для релиза. Кроме того, без сомнения, в процессе этого возникнет что-то непредусмотренное, например, упущенные характеристики, необходимые для работы функциональности, важные детали, которые невозможно было выявить, работая с прототипом. Возможно, обнаружится, что производительность системы ниже ожидаемой и необходима дополнительная работа, чтобы довести скорость до нужной величины. Все эти так называемые предсказуемые неожиданности – концепция, близкая к «неизвестным неизвестным» Дональда Рамсфилда. Не думайте, что ничего такого не обнаружится. Вы же знаете: они существуют.

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

Не каждый срез достоин релиза

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

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

Еще один секрет верной оценки временных затрат

Еще один страшный секрет оценки (который на самом деле вовсе не должен быть секретом) заключается в том, что оценки… оцениваются заранее. Я уверен: порывшись как следует в сборниках оксюморонов, выложенных в Интернете, вы непременно найдете там термин «точная оценка»

. Если нам точно известно, сколько времени займет какая-то работа, разве мы вообще называли бы это оценкой?

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

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