A labs 2009 - внедрение agile
•Télécharger en tant que PPS, PDF•
0 j'aime•535 vues
http://akorsun.ru
![[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à A labs 2009 - внедрение agile
Similaire à A labs 2009 - внедрение agile (20)
A labs 2009 - внедрение agile
- 1. Внедрение Agile Алексей Корсун консультант , менеджер проектов akorsun.ru 31 марта 200 9
- 6. Scrumboard
- 8. ScrumBoard - Сигналы
Notes de l'éditeur
- Добрый день. Меня зовут Алексей Корсун. Я хочу рассказать о том, как различные методики Agile, связанные в единое целое, помогли нам в процессе строительства стартапа ewwwo.com. Стартап сейчас находится в стадии закрытой беты, регулярно обновляется - жизнь кипит. Начну с очень короткой предыстории. Стартап ewwwo.com начался в 2006 году. Наша команда состояла всего из 3-х человек, включая меня, как руководителя проекта, взятых в стартап из проданной фирмы. Мы активно применяли в своей работе такие методики, как автоматическое юнит-тестирование, короткие 2-3-х недельные итерации и несмотря на малую численность вполне успешно применяли парное программирование, чередуясь между собой. Некоторое время прошло в пробах пера - мы создавали простые прототипы "на выброс" - пробовали идеи. Потом остановились на примерной концепции проекта, как рабочей тетради в веб, к тому времени в команду вошли ещё два человека и встал вопрос о более структурированной, но простой организации разработки. Я выбрал Scrum. Я не буду вдаваться в технические подробности вроде того, как считается фокус-фактор, как определяется скорость команды - так как предполагаю что аудитория знакома с этим. Если появятся вопросы - запишите - задавайте в конце.
- Итак, Scrum мы начали внедрять постепенно, но у меня был достаточный опыт работы с XP до этого, чтобы понимать, что практики внедрять надо согласованно, чтобы они не приносили минусы, покрываемые другими практиками. Чтобы были общие термины - моё представление о Scrum - как о framework .
- Начали мы с регулярных приоритезаций Product Owner'ом и командой наших задач. Приоритезацию проводили по всем новым появившимся за итерацию фичам. Поначалу пока кол-во багов было небольшим весь учёт и багов и фич вели в Bugzilla и приоритезировали скопом, но быстро поняли, что приоритезируя баги занимаемся микроменеджментом. Стали приоритезировать только фичи. Backlog - выборка по фичам. В багзилле очень неудобно менять приоритеты задач, да и не сделать там удобно абсолютную нумерацию, поэтому мы избавились от неудобного инструмента и для удобства приоритезации: Backlog - в GoogleSpreadsheet Как разобрались с багами - расскажу позже. А вот Backlog изменился и дальше. Появился Technical Backlog. Потом: Research Backlog. Причина - нет SRS, непонятно как оценивать и планировать. Потом очень удачно все бэклоги перенеслись на белые доски, которых к тому времени в офисе стало три. Про это позже, когда буду рассказывать про ScrumBoard. Вынос задач из Bugzilla на свет земной очень помогла пониманию будущего командой.
- Использовали обсуждение. Перешли на Planning Poker - очень сильно помогло в уточнении и описании задачи - правило - если оценка отличается больше чем на 2 дня, то обсуждаем ещё раз. Потом стали использовать WBS для оценки - очень хорошо помогло для мелких задач.
- В ходе итерации выполнение фич надо было отслеживать, да и инвестор-пользователь (который в лучших традициях Customer On Site сидел у нас в офисе) жаловался на непрозрачность внутри итерации. Я с некоторой боязнью попробовал тогда вынести фичи из электронного формата на недолговечный бумажный носитель. Сработало - супер! Нам так понравилась идея. Scrumboard - пульс итерации. вели на доске простой показатель кол-во открытых за итерацию багов к кол-ву закрытых за итерацию. Старались, чтобы вторых было больше. Кроме того был список Unverified - так как тестер удалённый и некоторые баги постила команда. На stand-up'ах смотрели эти счётчики.
- Тревожные сигналы.
- Как мотивирующе сработало Видение и метафора системы. Как замечательно и неожиданно сработала метафора проекта "Рабочая тетрадь". Сэкономила очень много времени на объяснениях и спорах - включать ли эту функцию в систему. Я описал процесс управления требованиями и изменениями. Всё попадает в Bugzilla - где на приоритезации мы разбираем отдельно новые баги, отдельно фичи - фичи в бэклоге. Если фичу реализуем - ей ставим в Reasearch Backlog. Оттуда в Product Backlog. Долгое время именно SRS - бутылочное горлышко. Стремились к кроссфункциональности - для этого нужна была простота и доступность. Требования документируем в достаточно удобной системе SpringNote - глючит местами правда, но тем не менее удобнее Google Docs И всего остального онлайн. Специалные системы управления требованиями и изменениями пробовали - RequisitePro - показалась слишком перегруженной. Главное было разделять на функциональные и нефункциональные требования (например, к интерфейсу). Это дало возможность легко поддерживать SRS и по нему добиться кроссфункциональности. Но это отдельная тема.
- очень джолго старался внедрить эволюционный дизайн. Test-driven - сам лично его поклонник. Но не поддались :) Остановились просто на tes-driven development. Тесты до - но проектироване всё-таки по контракту.
- Причины: ScrumBoard - делать в порядке приоритетов. Концентрация на самом важном. Оценку делать вместе. Устанить риски отпусков и незнания кода. Как решали: Такая пролема была с javascript и вёрсткой. Молодцы.Провели две итерации парного программирования на javascript. Бедные коллеги кололись, плакали, но мужественно продолжали есть кактус. Молодцы! Зато эффект от этого был огромный!!!
- Определения Что используем у нас и почему. Вёрстку делать не все могут - могут сломать, то же и JS кроссфункциональный. Ревьюви код тот кто смотрит.
- Очень здорово, конечно получать отчёты о прохождении тестов каждый час. Приёмочные тесты Их написание вперёд согласно XP сделать не получилось, но к этому почти пришли. В итоге пишутся по существующей вёрстке, но при отсутствующей реализации. Predeploy и Production. Баги фиксятся в этой же итерации, чтобы не создавать эффекта запаздывания и появления багов в другой итерации. благодаря введению кроссфукциональности мы смогли организовать по багам общий список - не иметь конкретных Assignee - а правят все в порядке приоритета - это сильно увеличило скорость работы по багам, так как убрало бутылочное горлышко - висящие давным давно баги на javascript. Баги вынесли на Scrumboard.
- в конце каждой итерации - считаю одной из самых важных практик в agile - даёт положительную обратную связь. большая ретроспектива - очень много дало проблем более высокого уровня - надо проводить раз в квартал я считаю. Тут не обсуждаются технические проблемы, а в основном ретроспектива по деятельности организации вообще.
- Команда не пергружена инструментами, продукт выходит вовремя, Всё работает настолько замечательно, что менеджер стал не нужен ))) Так что ищу работу - мои контакты :) Задавайте вопросы =)