Внедрение scrum в командах разработчиков

Мой опыт внедрения scrum в командах разработчика.

Процесс внедрения
1. Посадить людей вместе.
Люди не любят перемен. Даже если это перемены к лучшему. Простая задача - рассадить 5 существующих команд в одной большой комнате, чтобы каждая команда была вместе - очевидно полезное решение. Люди будут меньше мешать друг другу. Но в процессе перестановке получили часть недовольных изменениями. Через некоторое время (2 недели) люди оценили плюсы и согласились, что так лучше. Еще пара изменений составов команд и перемещений по комнате прошли уже достаточно гладко.
2. Купить доску.
В большой организации это, оказывается, проблема. Купил доску и позже выбил с организации деньги. Для команды из 2 человек хватает доски 60 на 90 см. Для команды 5 человек нужна доска 90*180 см. У одних команд были пробковые доски, у других пластиковые магнитные с возможностью на них писать. Лучше всего 2 доски - 1 для крепления задач, другая для рисования на ней.
3. Выделить роли в команде.
Определить, кто является членом команды, кто product owner, кто заказчиком. Что делать, если несколько product owner - найти главного product owner.
4. Составить плоский список задач.
Все любят создавать сложные иерархии работ. Так логичнее, есть логика и т.д. Но создать простой плоский список работ - непривычный опыт.
5. Product owner расставляет приоритеты
Вначале команда не сработана, никто не кому не доверяет. Product owner ставит разные приоритеты у задач, жестко определяя порядок. Через некоторое время (2-3 месяца) Product owner начинает доверять команды и ставить у нескольких задач одинаковый приоритет, доверяя команде в определении последовательности
6. Оценка работа командой
Product owner присутствует, но желательно поменьше вмешиваться. Можно использовать карты для оценки, можно нет, работает оба варианта, надо пробовать, что лучше для вашей команды.
7. После оценки приоритеты могут изменяться
8. Стартуем итерацию.
9. Понимаем, что нужны критерии Test, WIP, Test, Done. Пишем и печатаем на доску. Понимаем, что в задачах нужен критерий How to demo: не берем в план, если не описано.
10. По окончании итерации считаем фокус фактор как отношение суммы первоначальных оценок задач в Done к общему рабочему времени команды.
11. Проводим ретроспективу.
Первые 2 месяца все жалуются на бытовые условия. После надо начинать фиксировать проблемы в процессах и в технологиях.
12. Планируем 2 итерацию, уже есть фокус фактор, можем оценить, сколько задач выполним.
Фокус фактор стабилизируется через 3 недели совместной работы над одинаковыми задачами.
13. Дотачиваем процесс
Уточняем критерии Plan, WIP, Test, Done. Регулярно добиваемся работы по приоритетам. Добиваемся фиксации технического лога и регулярное включение его в итерацию. Увеличиваем размер команды.

Результаты
У нас были недельные итерации.
По моему опыту шаги 1-12 занимают минимум 3 - 12 недель.
Чтобы внедрение успешно прошло, внедряющий scrum должен первые 2 недели быть в команде. Затем периодически следить за изменением фокус фактора.
В результате фокус фактор стабилизировался на отметке 40-70%.
Непривычным оказалось, что неважно, в чем оценивать задачи: в днях, часах, идеальных днях. С помощью фокус фактора это все переводится в часы.
Чтобы все это работало Product Owner должен понять, что если он хочет добавить что-то, то он должен убрать что-то. Если он будет давить на команду, то команда сделает то, что он просит, но не сделает что-то другое и scrum позволяет это видеть до завершения итерации.
Важно - не делать лишнего. Если что-то в пределах не требует фиксации в электронном виде - не фиксируйте. Клейте листочки, но не фиксируйте. Но когда итерация закончена, все оставшееся надо зафиксировать.

Динамика цен на УПН - добавил просмотр снижения цен

Добавил просмотр снижения цен на квартиры.
Из интересного - люди могут и по 30% от стоимости квартир скидывать.

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

Очередная фича к http://tekezi.appspot.com

Добавил отображение дома на карте к сервису изменений данных по квартирам Екатеринбурга http://tekezi.appspot.com.

В качестве карты использую Google Maps.

Google Maps API оказался вполне удобным, к GWT прикручивается через отдельную библиотеку, поддерживаемую опять же Google.

Из неожиданностей: оказывается, надо получать отдельный ключ для каждого сайта, который использует Google Maps. Получение - бесплатно.

Rietveld - средство для code review от Google

Сегодня нашел ссылку на http://code.google.com/p/rietveld/ - средство для code review.

Система позволяет быстро запустить процесс code review, удобно добавлять комментарии, просматривать код и изменения, рассылает приглашения на review. 

Интерфейс можно посмотреть на живой системе http://codereview.appspot.com./640042/diff2/1:6001/7002

Можно поставить на свое приложение Google App Engine и использовать как сервис ревью кода.

Примечательна тем, что написана неким Guido van Rossum, который, по совместительству, является создателем языка Python.

Guido стал в 2005 году работать в Google, и первым проектом в Google у него стал  Mondrian - система code review Google.

Реализованная система оказалась сильно связана с инфраструктурой Google - Perforce как SCM и BigTable как хранилище данных, поэтому переход в разряд OpenSource систем не произошел.

Тогда он сделал проект Rietveld, в котором использовал часть кода Mondrian.

Система написана на Python + Django, предназначена для хостинга на Google App Engine.

Но народные умельцы давно научились запускать ее локально в development mode, использовать в качестве хранилища данных PostgreSQL, для снижения нагрузки ставить за Apache Web Server.

На http://codereview.appspot.com находится версия Rietveld, в которой ведут code review некоторые OpenSource проекты (из мне известных это Python, gwt, subversion, gcc, Django,  zend framework, jQuery), полный список http://codereview.appspot.com./repos.

Для пользователей Google Apps имеется бесплатное приложение, устанавливаемое из Google Marketplace (http://www.google.com/enterprise/marketplace/viewVendorListings?vendorId=1012)

И, наконец, в 2006 написана отличная презентация, зачем нужен Code Review http://rietveld.googlecode.com/files/Mondrian2006.pdf.

Google запускает Google App Marketplace - рынок приложений, интегрированных с Google Apps

Google решил начать продажу сервисов, интегрированных с Google Apps.
Разработчики получают интеграцию с сервисами с Google и готовую инфраструктуру продаж. В связке с Google App Engine получается облачное решение для хостинга и продаж сервисов.

За это Google просит скромные 20% с поступлений от пользователей за пользование вашим сервисом. При этом, я так понял, если ты хостишься на Google App Engine, ты должен еще платить и за пользование этим ресурсом (если выходишь за рамки квот, конечно).
При этом предоставляются бесплатные обращения к API Google, гаджетам и сервису OpenID.

Для сравнения - amazon web services просят лишь 3% от добавленной стоимости приложения, смотри здесь.

Из текущих приложений в топе OffiSync - Интеграция Microsoft Office с  Google Apps. Позволяет работать с документами Google Docs прямо из Word или PowerPoint.

Из интересных приложений - JIRA Studio - интегрированный онлайн сервис разработки, включает svn, "гибкий" планировщик задач, Jira как багтрекер, wiki, систему непрерывной интеграции, систему code review. В wiki интегрируются документы. Интегрируется с Google Apps для отбражения информации о сборке, уведомления по задачам. Стоит 25$ в месяц на пользователя.

Для пользователей - http://www.google.com/enterprise/marketplace/home, для разработчиков - http://developer.googleapps.com/marketplace.

Доработка tekezi.appspot.com

Небольшие изменения дизайна

• Сделал отображение таблицы с историей изменений поприятнее.
• Красным выделяются изменения.
• Добавил ссылку на upn.ru

В ближайших планах - рассылка уведомлений об изменении цен на интересующие квартиры.

Появление беты http://tekezi.appspot.com/ - история изменения цен на квартиры Екатеринбурга

Решил открыть миру творение http://tekezi.appspot.com/
По сути это портал к данным по недвижимости Екатеринбурга с сайта upn.ru.
Данные на upn.ru хорошо представлены, но там нет истории.А это очень интересно!
Предположим, вы хотите:

1.  узнать как изменялась цена за время экспозиции квартиры;
2.  узнать о снижении цены на интересуемую квартиру;
3.  узнать о квартирах, цены на которые были снижены за последнюю неделю. Есть предположение, что квартиры, на которые существенно снижают цены уходят за неделю. Так почему же и нам не быть такими экономными?

На текущий момент есть база по истории изменений данных по квартирам с октября 2009 года.

Пока доступна лишь функция 1 - узнать об изменении по конкретной квартире.

Смотрите, комментируйте.