Конференция проходила 9 декабря 2009 года в бизнес-центре ГУУ (Выхино)
Общее впечатление хорошее, правда наиболее интересными оказались доклады к Agile относящиеся косвенно.
Agile @ Intel
Евгений Сорокин, Антон Бевзюк (Intel) Два Team Lead'а из Intel рассказывали про свой Agile в Нижнем Новгороде. Они делают большое внутреннее финансовое приложение для маркетинга, распределенная команда: программисты в НН (немножко в Индии), аналитики в Англии, бизнес-пользователи в Штатах.
Как у них
К Нижнем на их проекте работает сейчас 12 разработчиков, изначально было 4, в самые напряженные моменты привлекалось до 20. Утверждают, что тестировщиков нет вообще. Agile они начинали с XP(в 2002 году), в с самом книжном его варианте - используют все практики, за исключением Customer-on-Site, в силу удаленность кастомера). Очень сильно форсируют парное программирование - у программиста есть лично рабочее место, но весь код пишется вдвоем, за специальными станциями, с двумя комплектами мышей, клавиатур и мониторов. Парные сессии продолжаются по 1.5-2 часа, каждые 5-20 минут ведущий в паре меняется. Разбиение происходит на standup, который случается в 9-15 ( не работать нам в Intel:)))
В 2008 году у них появился Scrum. Доска у них - (New, WIP, Completed, Support/Testing)+ бумажки-идеи. Работу делят опять же, классически - на user stories, которые делятся на конкретные tasks (объемом работы не более одного дня). При этом добавляется новая роль - Story Owner, программист отвечающий за данную историю целиком. Также, с внедрением Kanban в 2009 году на доске появились Kanban-лимиты.
Заметные отклонения от книжных описаний ( к которым в Intel явно тяготеют) у них случилось только в области планирования. Во-первых, они не планируют итерацию, оценка происходит по ходу. Во-вторых оцениваются не конкретные задачи, а User Stories целиком, причем оценка эволюционировала от идеальных часов через sp к системе (просто-средне-сложно). Также, при планировании в самом начале разработке, у них получилось более 500 user stories, планирование вылилось в кошмар, что научило оценивать более крупными "функциональными" блоками.
Проблемы
Немножко рассказали про проблемы, с которыми им довелось столкнуться, несмотря на общий радужный тон выступления.
- Долгосрочно планирование. Они это тоже не умеют. В их проекте был фиксированный срок старта (правда, и фиксированный объем работ), рассчитать ресурсы они не сумели, пришлось срочно привлекать помощь из штатов. Правда, измеряя velocity получилось понять это на раннем этапе и не сорвать проект.
- Полный Backlog сразу составить не получилось - пришлось делить на большие блоки и уточнять по ходу. По-моему идея была изначально безнадежная)
- Распределенная команда - разный уровень, разные критерии оценки, плохо передаются знания. Методы борьбы - стандартные: строго общий бэклог, личное общение
- Новички. Команда начиналась с 4 человек, еще 8 набрали по ходу. Кажется студентов) Критерием отбора было знание основ ООП, а не опыт или знание .Net/C#. Говорят, что за 3 месяца новичок превращается в полноценного сотрудника, критерий - можно бывших новичков сажать в пару.
Fun
В Intel есть немало способов скрасить серые будни за написанием тупого кода (почему тупого, см. последний доклад).
- Каска-чекинка (кто в каске, тот и коммитит, во избежания столкновений)
- Сокровища('ништяки' по выражению Юли Вяцковой) и проклятья. На standup каждый случайным образом получает бонус( типа права выбирать любого в пару) и обязанность (типа протереть мониторы или убрать warning'и компилятора)
- Сердечки - на специальной доске каждый член команды получает розовые-розовые сердечки за что-то общеполезное. Курс сокровищ к сердечкам они не сообшили)
- Кондуктор - звучит сирена, и чувак с дыроколом идет пробивать бумажки. Количество дырочек на бумажке - ее lead time. Все бегут и перевешивают свои бумажки
- И общая зарядка)
Увидеть лес за деревьями
Стас Фомин (Заказные ИнформСистемы)
Короткий доклад Стаса, посвященный визуализации хода процесса разработки.
Стас показал две модели. Одну их них, Code Swarm мы уже видели (если не видели - идите смотрите(в конце поста)) - в его основе лежит гравитационная модель, где разработчики притягивают файлы, с которыми работают.
Вторая модель "Пчелы и цветы" еще красивее - проект визуализируется в виде цветка с каталогами-соцветиями и файлами-лепестками(или тычинками), а разработчики летают и опыляют их.
Также Стас анонсировал предварительную версию фреймворка, позволяющего быстро делать такое видео, у меня правда он работать не захотел. Смотреть можно вот здесь.
8-битный Scrum
Алексей Омельянчук (Сигма-ИС)
Интересный доклад, в первую очередь тем, что его читал человек из очень отдаленной от нас области написания логики для контроллеров пожарных датчиков. Мужчина уже в летах, но очень живой, после доклада даже стало приятно - как-то что-то в нашей промышленности шевелится.
Комманда его прошла путь от производственного предприятия работающего на МО с жесктим Rational Unified Process, через крупного частного производителя контроллеров (крупнейший поставщик АвтоВаза, 2 млн. штук в год) до software-предприятия, занимающегося, в основном, программированием, а не железом. На каждом этапе добавлялись новый практики.
Что используются
- спринты, ограниченные во времени
- демо (по признанию докладчика практика оказалась самой полезной)
- планирование. Причем, планируют 120-140% от запаса времени, с разделением на обязательное и бонусы
Длительность спринта составляет 1 месяц, что было связано со сложившимся на предприятии укладом. Также был "мегаспринт" - 3 месяцы. Эта цифра обусловлена
- обновлением реального железа
- высокое руководство имеет возможность приезжать на демо с такой периодичностью.
Еще одна особенность - сборные команды. Каждый проект ведется максимум двумя людьми (большему количеству просто нечего делать на устройстве, куда влезает 500 строк ассемблера), команды объединяют нескоько проектов. Ни о какой кросс-функциональности речь не идет(одна настройка рабочего места занимает день-два), на таким образом все-таки немого смягчаются риски того, что в случае болезни одного человека, его будет некем заменить. Scrum-митинги из-за этой специфики проходят на по 15 минут раз в день, а большее время раз в неделю, чтобы было время въехать в чужую предметную область. На планирование специализация накладывает также глубокий отпечаток - приходится выделять человеческие ресурсы, которые могут решить данную задачу и планировать время каждого отдельно.
SOLID-принципы OO-дизайна
Дмитрий Кандалов (Deutsche Bank)
Java-разработчик из Deutsche Bank рассказывал про очередной набор принципов OO-дизайна. Никаких откровений, но выучить названия и помнить о сути полезно. Рассказ велся по этой статье. Докладчик разумно оговорился, что принципы надо применять по возможности, principles != rules.
Демотиваторы в тему
SOLID - это аббревиатура
- Single Reponsibility Principle - каждый класс должен иметь один смысл, делать что-то одно. Например описание книги не должно вести историю продаж этой книги.
- The Open Closed Principle - создание потомков класса должно расширять поведение базового класс, а не требовать его изменения.
- The Liskov Substitution Principle - обратный к предыдущему. Во всех случаяж должна быть возможность подставить объект подкласс вместо суперкласса.
- The Interface Segregation Principle - принцип разделения интерфейсов. Если у Вас все-таки получился сложный многофункциональный объект, для каждого выделенного случая его использования выделите отдельный интерфейс.
- The Dependency Inversion Principle - Принцип обращения зависимости. Подсистемы верхнего уровня абстракции не должны зависеть от подсистем нижнего уровня, а предоставлять им интерфейс, который они должны реализовывать. Например, программа отправки почты не должна зависеть от сетевого протокола нижнего уровня, а, вызывать его функции через интерфейс, который является частью описания модуля верхнего уровня
MS Team System vs IBM Rational Jazz: лучший инструмент разработчика
Евгений Злобин (Microsoft) и Тимур Маркунин (IBM)
Два сейла не очень убедительно продавали свои продукты. IBM выглядел лучше, но его все равно никто не купит. Рассказ про TeamSystem выглядел особенно бледно - про нужные и полезные нововведения, которые появились в 2010 версии ничего сказано не было. Но зато про них рассказывали месяц назад на Платформе, можно почитать здесь.
DDD+TDD+MVP+DSL+Gof+PoEAA=Love!
Евгений Сорокин, Антон Бевзюк (Intel)
Доклад оставил глубокое впечатление, причем, знаю, не только у меня. Те же докладчики рассказывали о том же приложении, что и на первом докладе, но с акцентом на технические приемы и практики. Размер приложения можно приблизительно оценить по следующим цифрам: 140k строк кода, из них 100k - тесты, 20 экранов, 12 разработчиков, 2 года, 50 человеко-лет.
Тестируемые интерфейсы
Было рассказано о двух паттернах, которые позволяют строить тестируемые интерфейсы, а также о том как их тестируют. Это MVP(Model-View-Presenter), используется для WinForms и веб-интерфейсов приложения и MVVM (Model-Vew-ViewModel)
Рассказ про тестирование поразил - пишутся авто тесты в том числе и на Binding данных к контролам. Выглядит страшновато - делают binding в дизайнере, потом через Reflection пишут код (по сути, тоже самое), который его проверяет
Domain Driven Design и тестируемость всего
Реализация DDD-подхода в данном случае состоит в том, что domain описан в отдельной сборке, которая является полностью независимой. Для обеспечения независимости используется прием Inversion-of-Control и одноименная библиотека.
- Плата за такой чистый дизайн велика - для каждого типа доменный модели нужен еще тип, реализующий для него работу с базой
- Зато 5000 тестов работают одну минут, в отличие от наших. Это именно то, в чем мы их решение пока сильнее нашего
Ребята также показались TDD-экстремистами, не знаю насколько это хорошо или плохо. Их мантры такие
- Подумай->Напиши тест, который падает где ты ожидаешь -> Сделай минимальное исправление
- Assert, по-хорошему, должен быть один, а исправление - минимальным. Если это не так, скорее всего нужен еще один тест.
Остальное
- При написании тестов использует свои embedded DSL. Например, вот такое:
var testDate = 11.12.of2009
public static class DoubleExtensions
{public DateTime of2009(this double date)
{
return new DateTime((int)date.Floor(), (int)(date-date.Floor())*100, 2009)
}
}- Очень любят GoF и Фаулера. Из полезных паттернов упомянули Спецификацию, чему соответствует до некоторой степени Condition в Uni.Net
Сообщения
