В начале января я писал (перевод) о введении новых методов работы в этом году. Мы решили объединить отдельных разработчиков в команды из 3 человек: двух программистов и дизайнера. Состав команд будет оставаться неизменным в течение 2 месяцев. Каждый двухмесячный модуль будет разбит на 4 последовательные итерации, по две недели каждая. Мы поставили цель добиться сокращения списка задач для каждой итерации, строгого следования сжатым срокам и улучшения нашего продукта.Что из этого получилось?
Закончился февраль и наступил март, а значит, мы можем подвести итоги первых двух месяцев работы по новой методике. Так что же из этого получилось?
Изменение методики работы прошло отлично. Январь и февраль были двумя самыми продуктивными месяцами за долгое время. Несмотря на то, что не все было гладко, и нам пришлось внести некоторые коррективы, в целом мы сочли это изменение правильным ходом.
Результаты
Вот некоторые задачи, которые нам удалось выполнить в эти два месяца:
- HIGHRISE: Переработка «потока событий» в Highrise
- HIGHRISE: Добавление прямого перехода от поиска к записи сделки или прецедента
- HIGHRISE: Добавление функциональности объединения данных компаний
- HIGHRISE: E-mail уведомления, ежедневные обзоры, vCard-информация для дропбоксов
- BASECAMP: Обновление дизайна для e-mail с HTML, комментариев, списков задач и файлов
- BASECAMP: Отправка сообщений через e-mail
- BASECAMP: Изменен дизайн страницы обсуждения
- BASECAMP: Ответы к письмам по задачам добавляются как комментарии
- CAMPFIRE: Форматирование сообщение из Twitter в чатах
- CAMPFIRE: Предпросмотр изображений в чатах, изменение дизайна истории чата, добавление закладок в чатах
- LAUNCHPAD: Улучшение навигации между проектами и главной страницей
- 37id: Новая секция помощи
- ANSWERS: Запущен 37singnals Answers
Кроме этого, было множество баг фиксов, небольших обновлений, улучшений инфраструктуры, дизайна и содержания.
Чему мы научились?
Мы научились многому. Ниже мы приводим некоторые уроки из тех, что нам пришлось усвоить за эти два месяца. Конечно, нам придется узнать еще многое, но уже это, надеемся, позволит пройти следующий модуль еще успешнее.
Урок: Начинайте с интерфейса
Мы верим в необходимость начинать разработку с интерфейса, поэтому мы решили, что в первую неделю итерации, в понедельник, среду и пятницу, в то время как дизайнер будет заниматься разработкой интерфейсных решений для основной задачи, программисты будут выполнять небольшие задачи и задачи, связанные с исправлением багов. Таким образом, никому не придется просиживать в ожидании готовности дизайна. В условиях двухнедельной итерации попросту нет времени ждать чьего-то шага, чтобы приступить к собственной задаче.
Урок: Выкатывайте сделанное по мере готовности
Выпускайте результат работы, как только у вас он появился. В течение первой итерации мы попытались дождаться последней пятницы, чтобы выкатить все обновления. Это привело к излишним проблемам и стрессу. После этого мы предпочли перейти к развертыванию обновлений непосредственно по мере их готовности.
Урок: Не ждите пятницы
Выкатывать обновления в пятницу ужасно. Чтобы дать командам максимальное время на выполнение задачи, мы расписывали ее с понедельника по пятницу, после чего развертывали созданное решение. Однако это обернулось тем, что с проблемами, которые были упущены, приходилось работать на выходных. Нам это совершенно не нравилось. Вместо пятниц мы стали выпускать решения в четверг: так мы получили полный рабочий день на решение непредвиденных трудностей.
Урок: Корректируйте задачи как можно раньше
В двухнедельных итерациях, цели и задачи должны быть точно определены не позднее, чем к концу первой недели. Несколько раз нам пришлось оказаться в напряженной рабочей обстановке из-за ошибок в оценке сложности задач. Мы решили, что в двухнедельных итерациях мы будем пересматривать список задач во второй понедельник и следующую за ним среду; при необходимости, мы будем обрезать список задач. Мы готовы поступиться частью работы, а не сном или рассудком. Частые «ночные марафоны», постоянная необходимость геройствовать для выполнения задач — плохие признаки. Истощение не делится на итерации. Да, новый план работ к итерации составляется каждые две недели, но истощение переходит из одной в следующую. Корректировка и уменьшение списка задач помогает справиться со «сгоранием» на рабочем месте.
Урок: Одна, две, три — твердо реши со старта
Опытным путем было обнаружено, что иногда имеет смысл менять длину итерации. Эксперимент был поставлен в последние три недели нашего двухмесячного модуля. Решение было разумным для одного из наших проектов, готовящегося к выпуску, но определенно добавило небрежности и перерасходу времени в работе над другим проектом. Дополнительная неделя расхолаживает и дает возможность сказать «Этим мы займемся завтра» или «Я позабочусь об этом на следующей неделе». Эти две фразы уже говорят о том, что возникнут проблемы. Без четкого понимания сроков сдачи работы (а срок в две недели чувствуется гораздо яснее, чем в три недели) цели расплываются, выполнение задач уходит на второй план. В следующий раз мы хотим попробовать с итерациями в одну, две и три недели — но решение о длине итерации должно быть принято заранее. Нельзя запланировать задачи на две недели, а затем продлить итерацию. Команды разработчиков должны будут сразу сказать: «Это недельная итерация», «Это двухнедельная итерация» и так далее.
Что дальше?
Новый двухмесячный модуль начался вчера, первого марта. Мы рады применить знания, полученные с начала года, к следующим двум месяцам. Ждите отчета в мае.
комментарии (24)