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

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

Меня часто спрашивают, как соотносятся единицы истории (story points) и часы. Спрашивающие обычно ожидают от меня, чтобы я сказал что-то вроде «1 единица истории = 8,3 часа». Суть-то не в этом (тем более, что 8,3 я выдумал). Давайте посмотрим, как в действительности система единиц по гибкой методологии соотносится с системой часов. Предположим, что вы по какой-то причине отслеживали, сколько времени разработки занимает каждая история длиной в одну единицу у отдельной команды. Если вы составите график по этим данным, то получите примерно следующее:

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

Они говорят: переходим на гибкую разработку (Agile). Все будет просто супер. Они, разумеется, не технические писатели.

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