A labs 2009 - внедрение agile

745 views

Published on

http://akorsun.ru

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
745
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Добрый день. Меня зовут Алексей Корсун. Я хочу рассказать о том, как различные методики 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 - даёт положительную обратную связь. большая ретроспектива - очень много дало проблем более высокого уровня - надо проводить раз в квартал я считаю. Тут не обсуждаются технические проблемы, а в основном ретроспектива по деятельности организации вообще.
  • Команда не пергружена инструментами, продукт выходит вовремя, Всё работает настолько замечательно, что менеджер стал не нужен ))) Так что ищу работу - мои контакты :) Задавайте вопросы =)
  • A labs 2009 - внедрение agile

    1. 1. Внедрение Agile Алексей Корсун консультант , менеджер проектов akorsun.ru 31 марта 200 9
    2. 2. <ul><li>Практика внедрения Agile- методик на примере стартапа ewwwo.com </li></ul><ul><li>Ewwwo - веб-сервис для хранения заметок . </li></ul><ul><li>Команда : </li></ul><ul><li>6 разработчиков , </li></ul><ul><li>удалённый тестер , </li></ul><ul><li>менеджер проекта </li></ul><ul><li>Процесс : Scrum </li></ul>
    3. 3. Scrum - framework
    4. 4. Планирование спринта <ul><li>Работает : </li></ul><ul><li>Приоритезация Product Backlog’ а - изменения </li></ul><ul><li>Метафора системы - ускоряет </li></ul><ul><li>Product Backlog и Technical Backlog </li></ul><ul><li>Необходимость в Research Backlog’ е </li></ul><ul><li>Осторожно : </li></ul><ul><li>how to demo </li></ul><ul><li>микроменеджмент </li></ul>
    5. 5. Декомпозиция и оценка <ul><li>Работает : </li></ul><ul><li>Work-breakdown structure </li></ul><ul><li>Planning Poker </li></ul><ul><li>Необходимо : </li></ul><ul><li>Инструменты для оценки </li></ul><ul><li>Декомпозиция </li></ul>
    6. 6. Scrumboard
    7. 7. Scrumboard <ul><li>Основное средство визуализации </li></ul><ul><li>Следим за сигналами </li></ul><ul><li>Осторожно : </li></ul><ul><li>Не очень много бумажек </li></ul><ul><li>Купите хорошие стикеры ;) </li></ul><ul><li>Не беспокойтесь за историю </li></ul>
    8. 8. ScrumBoard - Сигналы
    9. 9. Работа в течение спринта <ul><li>Управление требованиями и изменениями </li></ul><ul><li>Проектирование </li></ul><ul><li>Реализация </li></ul><ul><li>Тестирование </li></ul>
    10. 10. Управление требованиями <ul><li>Сработало : </li></ul><ul><li>Видение и Метафора системы </li></ul><ul><li>Процесс управления изменениями – общедоступен - кроссфункциональность </li></ul><ul><li>Требования – в wiki – backlinks </li></ul><ul><li>Чёткое деление на функц . и нефункц . требования </li></ul><ul><li>Осторожно : </li></ul><ul><li>Требования – бутылочное горлышко </li></ul><ul><li>Нет backlinks </li></ul>
    11. 11. Проектирование <ul><li>Test-driven design </li></ul><ul><li>Контракты </li></ul><ul><li>Drive-a-spike </li></ul>
    12. 12. Разработка <ul><li>Проблема : </li></ul><ul><li>Ajax, javascript - много. </li></ul><ul><li>Вёрстка под 4 браузера: FF 3, IE 6, IR 7, Opera. </li></ul><ul><li>СУБД – высокая нагрузка </li></ul><ul><li>Из-за этого – очень специфичные знания во многих областях </li></ul>
    13. 13. Кроссфункциональность <ul><li>Необходимо добиваться . Даёт возможности : </li></ul><ul><li>Фокусирование всех на главной задаче </li></ul><ul><li>Оценка – вместе . Прояснение тонких мест помогает пониманию . </li></ul><ul><li>Устраняет риски отсутствия людей </li></ul><ul><li>Устраняет “ бутылочные горлышки ” </li></ul>
    14. 14. Владение кодом <ul><li>Сильное – есть ответственный за модуль . Изменения – только в своей зоне ответственности . В другой зоне – запросы на изменение . </li></ul><ul><li>Слабое – есть ответственный за модуль . Все могут менять , но ответственный “ присматривает ” </li></ul><ul><li>Коллективное – всё общее . Отвечают – тоже все . </li></ul>
    15. 15. Тестирование и развёртывание <ul><li>Приёмочные тесты </li></ul><ul><li>Continious integration – тесты каждый час </li></ul><ul><li>Быстрый цикл ручного тестирования </li></ul><ul><li>Predeploy(code-freeze) и Production </li></ul><ul><li>Баги – на Scrumboard – минимализм и наглядность </li></ul><ul><li>Осторожно : </li></ul><ul><li>Не должно быть “ баг-ударов ” в другую итерацию </li></ul>
    16. 16. Ретроспективы <ul><li>Положительная обратная связь </li></ul><ul><li>Вовремя обратить внимание на проблемы </li></ul><ul><li>Утвердить хорошие практики работы </li></ul><ul><li>Выяснить причины невыполнения целей </li></ul><ul><li>Улучшить климат в команде </li></ul><ul><li>Большая ретроспектива – раз в квартал . </li></ul>
    17. 17. Итоги <ul><li>Стабильность разработки (сроки) </li></ul><ul><li>Надёжность продукта </li></ul><ul><li>Низкие затраты на поддержку процесса </li></ul><ul><li>Самоподдерживаемость </li></ul>
    18. 18. <ul><li>Алексей Корсун </li></ul><ul><li>консультант , менеджер проектов </li></ul><ul><li>akorsun.ru </li></ul>

    ×