Персональные инструменты
 

AgileDays-2009 (Technical excelence)

Материал из CustisWiki

Версия от 15:19, 24 декабря 2009; StasFomin (обсуждение | вклад) (MS Team System vs IBM Rational Jazz: лучший инструмент разработчика)

Перейти к: навигация, поиск

Представляем краткий отчет и обзор докладов, прошедших на третьем, техническом треке «Technical excelence» конференции AgileDays.ru.

Note.svg Вообще, мы (Стас Фомин и Андрей Бибичев) осуществляли организационно-техническую поддержку докладов в секции «Technical excelence», в частности, мы сняли и публикуем обработанное видео. Сделали что смогли — цветокоррекция, темпоральная фильтрация шумов, усиление границ (для большей читаемости слайдов), в звуке — нормализация и динамическая компрессия. Некоторую реверберацию (эхо), увы, убрать не удалось (уж очень это трудоемко), сорри.

Видео публикуем и в виде флешвидео (640x512) и отдельно можно скачать видео в оригинальном качестве (720x576). Мы специально оставили изображение слегка вытянутым — и максимум площади из максимально возможного квадрата 640x640 используется, и буквы читаются легче, и люди стройней и симпатичней). Для пары докладов «лекционного» типа, не сильно зависящих от слайдов, мы сделали и аудиоподкасты.


Обзор Agile

Докладчик
Никита Филиппов (ScrumTrek)

Какая конференция Agile без основного доклада по методологиям? Этот доклад будет отправной точкой для тех, кто пришел послушать об Agile, кто планирует внедрять Agile в своем проекте или организации, или для тех, кто хочет сравнить свои способы работы с лучшими практиками индустрии. Главной целью моего доклада является достижение понимания всех участников конференции, что такое Agile.

На этом докладе мы рассмотрим:

  • Плюсы и минусы других процессных подходов: Waterfall, Code & Fix.
  • Принципы Agile: Anti-code & fix, Anti-Waterfall
  • Практики Scrum
  • Чем можно улучшить Scrum?


Обзор Feature-Driven Development и Domain-Driven Design

Докладчик
Андрей Бибичев (CustIS)

Эрик Эванс (Eric Evans) в своей книге о Domain-Driven Design (DDD) пишет: «Software development is all design» (Разработка ПО — это всецело дизайн/проектирование). И правда: ведь сборка ПО целиком автоматизируется и не требует ощутимых усилий со стороны проектной команды.

И что же в Agile есть на тему дизайна/проектирования? Scrum об этом молчит. В eXtreme Programming (XP) есть такие практики, как Test-Driven Development (TDD) и Refactoring, но они работают, скорее, на уровне дизайна отдельных классов и их имплементации («микро-дизайн»). А как же быть с архитектурой и «макро-дизайном»?!

«Лучшие собаководы» (гуру архитектуры и проектирования) рекомендуют сочетать проектирование сверху-вниз и реализацию снизу-вверх, то есть макро- и микро- дизайны. Agile-процесс под названием Feature-Driven Development (FDD) как раз базируется на таком подходе. В докладе дается краткое описание как самого процесса, так и его истории. Проводятся параллели с XP и Scrum, дается анализ сильных и слабых сторон, а также области применимости.

Казалось бы, причем здесь Domain-Driven Design (DDD)? В FDD краеугольным камнем является модель предметной области (Domain Model). В DDD — тоже. Но если FDD — это прежде всего процесс, то DDD является подходом к проектированию и реализации, причем этот подход замечательно сочетается с любым Agile-процессом. Кроме того, в DDD много внимания уделено «сшивке» макро- и микро- дизайнов: описаны общие принципы имплементации модели в программном коде, приводятся готовые образцы (patterns) реализации.

Если вы исповедуете Agile-подход к разработке и не используете хотя бы элементы DDD — вы многое теряете и сильно рискуете. Если же вы только присматриваетесь к Agile и пока полны скепсиса, так как в изученных вами материалах по этой теме полно белых пятен, то данный доклад тоже может быть полезен.



Увидеть лес за деревьями

Докладчик
Стас Фомин (CustIS)

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

Однако на практике возникает проблема — как быстро и эффективно исследовать этот пласт информации?

  • Читать логи переписки и коммиты в VCS? То есть разрабатывать «шахту знаний» киркой и мотыгой? Бродить по лесу и считать деревья?
  • Посчитать метрики? Ненавистные SLOC и иже с ними? В зависимости от глубины детализации можно получить:
    • либо пару унылых метрик («KSLOCs в месяц на сферического разработчика в вакууме», то есть в нашей метафоре максимум — «площадь лесного массива»),
    • либо многостраничные Excel-dashboardы, заполненные мириадами цифр, в которых почти также бессмысленно лезть человеку, если он не профессор Чарли Эппс из сериала Numb3rs с его верными суперкомпьютерами и волшебными алгоритмами DataMining-a.

Что же делать?

Есть альтернативный способ «увидеть лес за деревьями» и при этом выжать краткую информацию по процессу — Визуализация.

Итак,

  • Мы покажем модель визуализации коллективной разработки ПО.
  • Представим portable-фреймворк для такого исследования, адаптированный для максимальной простоты использования — все работает из коробки, просто скормите ему вашу историю.
  • На выходе — музыкальные ролики визуализации! Их можно смотреть как с исследовательскими целями, так и для удовольствия, радуя себя, команду, и, возможно, приманивая новых сотрудников.
  • PROFIT! Фреймворк раздадим всем бесплатно, и никто не уйдет обиженным!


Собственно, все, о чем был доклад, можно пощупать руками — ShowTeamWork.

Внедрение Agile

Докладчик
Павел Афанасенко

Вы узнали про Agile и загорелись – захотели внедрить у себя в команде. Но как это сделать – ваша ситуация не совсем похожа (а иногда и совсем не похожа) на ту, которую описывают в своих статьях и презентациях евангелисты Agile движения. Как преодолеть сомнения? Как начать? Как избежать ошибок на непростом пути внедрения Agile и придти к успешному результату?

Я внедряю Agile вот уже на протяжении 7 лет в командах и организациях разного калибра, находясь при этом на разных ролях: рядового разработчика, тимлида, приглашенного консультанта и менеджера проекта. Независимо от бизнеса компании, разрабатываемого продукта, размера команды, роли адепта Agile в команде и массы других факторов, внедрение Agile происходит по одному общему сценарию, проходит определенные этапы. На пути внедрения возникают типичные ловушки, в которые можно попасть и увязнуть, и уже наработаны методики выявления и преодоления таких ловушек. Этому и посвящен мой доклад.




8-битный Scrum

Докладчик
Алексей Омельянчук (Сигма-ИС)

Можно ли использовать гибкие методологии на предприятиях по производству микроконтроллерных устройств? Оказывается, можно!

Представьте, что разработка включает в себя не только написание ПО, но и создание аппаратной платформы, на которой оно будет исполнятся. Более того, процессоры преимущественно используются 8-разрядные, а языки разработки – ассемблер и "чистый" С. Как использовать в этом случае Scrum?

Автор доклада обобщит свой опыт внедрения Agile в трех различных компаниях:

  • крупное предприятие-интегратор, основная деятельность – строительно-монтажные работы, немного разработки и совсем мало производства.
  • массовый контрактный производитель электроники, очень много производства и совсем чуть-чуть своей разработки.
  • предприятие-разработчик и среднетиражный производитель электроники.

Для всех 3-х предприятий характерна выраженная специализация разработчиков, необходимость синхронизации разработки аппаратной и программной части и "размазанный" по нескольким командам Product Owner.

Автор расскажет о том, что сработало, а что не получилось и о том, как помогло применение отдельных методов Lean Development и максимальный упор на раннюю полномасштабную демонстрацию.



ОО дизайн: SOLID принципы

Докладчик
Дмитрий Кандалов (Deutsche Bank)

В этом докладе я расскажу о SOLID принципах ООП описанных Робертом Мартином (Robert C. Martin) в книге "Быстрая разработка ПО: принципы, паттерны, практики" (Agile Principles, Patterns, and Practices) и что они означают в реальной жизни. Некоторые из этих принципов широко известны в других формах, некоторые очевидны. Но их интерпретация Робертом Мартином одна из лучших и может быть очень полезна для программистов использующих ОО языки.



MS Team System vs IBM Rational Jazz: лучший инструмент разработчика

Докладчики
Евгений Злобин (Microsoft) и Тимур Маркунин (IBM)


TDD + DDD + MVP + GoF + PoEAA= Love!

Докладчик
Антон Бевзюк (Intel)

Наша команда имеет более чем 6-летний опыт использования гибких методологий.

За это время мы разработали десятки бизнес-приложений. Мы используем передовые практики (Scrum, XP, Kanban) и шаблоны (GoF, PoEAA), доказавшие свою эффективность.

Мы расскажем о том, как мы "поженили" все это разнообразие в одном финансовом приложении. Это приложение спроектировано по Domain-Driven Design (DDD), разработка ведется в строгом следовании парному программированию. Test-Driven Development (TDD) обеспечивает 100%ное покрытие тестами бизнес-логики, а применение шаблонов MVP и Model-View-Viewmodel позволяет протестировать презентационную логику unit-тестами без применения внешних инструментов для тестирования интерфейса.

Построенная доменная модель постоянно эволюционирует в соответствии с растущими и постоянно изменяющимися требованиями. Нам удалось добиться того, что изменения в коде проходят сравнительно легко из за гибкой, приспособленной к изменениям архитектуры и дизайна приложения. Это достигается за счет использования множества шаблонов проектирования (GoF, PoEAA, DDD).

Отличительной особенностью нашего кода является то, что он вообще не содержит комментариев без ущерба для понимания. Код самодокументирующийся. Мы активно используем DSL для упрощения написания тестов. К настоящему моменту система содержит 4500+ тестов, которые выполняются не более 1 минуты.

Наш доклад раскрывает ряд best practices в области программной инженерии, например:

  • Автоматизированный деплоймент (на развертывание приложения уходит около 10 минут, делается это одним кликом).
  • Специализированные парные станции
  • Совместное использование всех практик XP (синергетический эффект)
  • Kaizen (постоянный пересмотр как процесса разработки, так и самого кода)
  • Элементы fun'а

В этом году мы успешно выдержали внешний и внутренний аудиты, нацеленные на анализ качества кода и оправданность использованных нами решений. Внешний аудит проводился специалистами Microsoft. По результатам этих проверок наш проект получил высокие оценки процесса и продукта.



Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»