Евгения Фирсова. Скорость разработки

Я вообще записывала на Whale Rider - 2010 много, и на диктофон, и текстом, но сегодня меня хватит только на один доклад. Один из лучших докладов конференции - и по полезности, и по подготовленности, и по уровню докладчика с точки зрения ораторского мастерства. Истории и аналогии, которые проводила Евгения, останутся за кадром, надеюсь, они войдут в статью, которую она обещала написать на эту актуальную. для себя тему.

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

Скорость - это ощущение

Если заказчикам не нравится, то скорость не имеет значения.

Комфортность работы с нами важна, если ее не будет, то скорость будет смазана.

Если в дорогом ресторане принесут еду быстро - это будет подозрительно. Время ожидания должно быть чем-то оправданно.

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

Иногда приходится ждать и клиента. Ради скорости можно взять и не полную постановку, но надо знать, когда будет все.

Ожидание - это не всегда ожидание работы разработчика, и это важно зафиксировать.

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

Сделать неопределенность максимально определенной. Чем больше тестеры знают, тем гибче они могут планировать.

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

Не только ощущение, но и мы на самом деле мы должны работать быстро.

Разработка должна быть прозрачной.

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

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

Информация о затратах ресурсов. Планировать ресурсы - бессмысленно. Но на основании истории можно оценивать будущую скорость

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

Шаблонизатор витрин Яндекс.Денег уже умнее меня - столько в нем интеллекта.

Менеджер понимает технологические вещи, если им в принципе объяснить, где что может быть долго и сложно.

Люди это принимают с благодарностью и тоже дают информацию, которая помогает определять приоритеты.

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

Когда будет готово?

Критериев оценки входящих задач я насчитала 14. (Если я правильно понимаю, то Евгения имела ввиду запись Поняла я неправильно, но это тоже хорошая запись, я не буду убирать ссылку: о лжи и планах)

Надо понять, сколько времени займет процесс, если начать сейчас.

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

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

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

Если я за 5 минут готовлю релиз к выкладке, то тратить 2 часа на оформление я не буду. Накладные расходы надо уменьшать.

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

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

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

Разработчик в идеале дает свою оценку и сам делит на этапы.

Скорость написания кода не принципиальна, важно, чтобы они оценивали задачи так же, как я.

Мы нацелены на скорость, но мы не должны торопиться, нам не нужен аврал.

Скорость чего-то стоит - и мы расплачиваемся планированием. Честное планирование - на неделю. Планирование на месяц - что мы успеем сделать не срочное, если не возникнет чего-то срочного.

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

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

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

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

Живые ответы на актуальные вопросы

Когда мне приходит задача, использующая новую технологию, сначала надо точно понять, а надо ли это. Потому что дорого и непредсказуемо. А непредсказуемость я не люблю.

Потом надо сесть, оценить, по аналогии угадать. Потом умножить на сколько-то, на сколько - по разному.

Риск оценить срок неправильно - есть, и я, бывает, ошибаюсь. Главное - объяснение. Что мы успели сделать вместо этого.

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

Я не видела людей, которые выдают на-гора в разы больше, чем другие.

Я часть времени занимаюсь разработкой, часть - работой тим-лида.

Правка багов на проекте в тестировании - приоритет.

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

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

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

Люди ценные, их не так просто заменить.

Слабое место работы с ветками - что бывает работа с тем, что уже изменено. Я много времени уделяю тому, чтобы это минимизировать. Возможно, лучше позже начать, чем потом долго объединять.