Текущая версия на 23:16, 14 апреля 2011

4-5.03.2011 прошла конференция AgileDays 2011. Я на ней присутствовал и выступал с докладом о модели системы как архитектуре в Agile, презентация. Он посвящен весьма интересной теме - какими средствами можно итеративно строить архитектуру системы, обеспечивая при этом ее целостность.

Кроме меня, выступали еще двое сотрудников нашей компании. Доклад Коли Гребнева (презентация) был о том, какие бывают варианты распределенной архитектуры в DDD и как их стоит применять. Доклад Олега Клинчаева (презентация) был о применении некоторых конкретных шаблонов при разработке приложений. Все наши доклады вызвали большой интерес, и после них мы общались со слушателями в коридоре. Что, впрочем, не говорит об их исключительности - на конференции было много хороших докладов, а слушатели - были активны.

А здесь - мои впечатления о конференции.

Конференцию снимали на видео наши сотрудники (компания CUSTIS), так что если Вас заинтересовал какой-то из докладов - через некоторое время можно будет посмотреть видео и презентации.

Общее впечатление

Общее впечатление - конференция очень живая. Народу много и он - активный, ищущий. И много разработчиков. в том числе - сильных. Собственно, они хотят продолжать заниматься разработкой, во всяком случае в значительной мере, и agile для них - средство это делать, не становясь в значительной степени менеджерами. При чем у большинства - получается, но они ищут пути улучшения. Соответственно, при таком составе слушателей востребованы не только управленческие доклады о процессе, но и технологические - если ты говоришь что-то новое и интересное. А еще общаясь с участниками можно узнать что-то новое, обсудить детали. И это - полезно.

Кстати, среди участников активно появляется in house. Не только Дойч, но и альфа-банк и Сбер, и из ВНИИХТ (вроде) Росатома тоже были. То есть в эту сторону смотрят. А еще - была пара компаний, работающих на запад с продуктовой разработкой, поставляющих решения для крупных заказчиков - хедж-фондов и страховых компаний, и общение - достаточно любопытно.

Теперь о докладах. В целом уровень докладов достаточно высокий. И я не буду ставить оценки, потому что они становятся малозначащими, линеаризация получается ложной. Потому что если один доклад был со сложными мыслями, который автор не смог донести достаточно прозрачно и с блеском, а в другом - мысли были проще, зато манера изложения - лучше, то оценка ничего не скажет. Понятно, что она будет не высшей, потому что каждый доклад можно улучшить, но ведь улучшить можно почти любой доклад. Три доклада мне понравились очень сильно, что, впрочем, было ожидаемо: доклад Хенрика Книберга и оба доклада Андрея Бибичева, особенно второй, в lighting talk, про пуассоново горение сроков.

Доклады можно разделить на две больших категории. Один - доклады достаточно опытных людей, которые имеют большой опыт и в своем докладе осмысливают и обобщают его, взяв определенный аспект - потому что объем ограничен и изложить опыт можно лишь сузив тему. И вторая категория - это доклады людей с гораздо меньшим опытом, которые рассказывают о своих успехах. Это менее интересно для опытных людей, тут нет обобщений, зато есть детали и конкретные случаи, из которых можно делать выводы. Кстати, докладчик может обладать большим опытом в целом, и только предметом доклада заниматься относительно недавно. Заметки по докладам у меня поделены именно так.

Вообще для людей с приличным опытом, давно и успешно делающих проекты, ни один доклад конференции не может быть откровением, которое укажет решение каких-то проблем или научит жизни. Однако, детали и мысли - могут послужить толчком к размышлениям, дать новый взгляд. Кроме того, на конференции можно оценить тренды отрасли в целом. И если многие говорят о какой-то практике как о вполне работающей, то у тебя есть повод задуматься. Особенно, если она вроде решает те проблемы, которые имеются. Конечно, она вполне может оказаться не слишком применимой ввиду других особенностей процесса в компании, или сами решаемые проблемы могут не слишком нуждаться в решении, но в этом случае стоит явно все это сформулировать.

И еще несколько совершенно общих замечаний

• На тему отказа от ретро. Общий тезис - отказ от ретро есть самоуспокоенность и самодовольство. Что есть остановка развития, ведущая к гниению.
• Многие не воспринимают agile (и scrum) как метапроцесс, в который заложено постоянное развитие и набор практик. Книберг - воспринимает.
• Когда люди научились делать нечто конкретное хорошо, они склонны воспринимать свой процесс как правильный и соответствующий. А то на чем обожглись и не научились - невозможным. Соответственно, когда им рассказывают нечто другое, они это отвергают, часто совершенно не думая, что компания работает в других условиях. Или научилась обходить или преодолевать определенные трудности.
• Парадоксальная идея: ищите ленивых, которые не хотят чтобы дергали, и потому действуют как умные админы, налаживая все в целом. Ленивый PO не лезет внутрь команды, но сделает так, чтобы это не вредило продукту, а ленивый SM отлаживает процесс, чтобы не решать частных проблем.

Доклады опытных

Итак, доклады опытных - тех, кто обобщил опыт многих проектов и делится им с иллюстрациями.

Хенрик Книберг. Everyone likes change, but nobody likes to be changed

Презентация в блоге Хенрика.

Доклад был интересен для меня, несмотря на тренинг. Потому что дал обзор верхнего уровня по очень разным областям и подвел итоги. В целом - хороший обзорный доклад профессионала и в предмете и в докладах. Россыпь практик: тезис - объяснение - пример, коротко и просто. С моей точки зрения, можно учиться как делать доклады и презентации.

Дальше - записанные тезисы.

• Метафора - уборка комнаты, путь наименьшего сопротивления.
• Внедрение по практикам - быстрее, чем все вместе
• Пилотный проект - столько же, сколько полное внедрение по времени. Но можно обкатать все виды сопротивления.
• Wildfire method - герилья
• Для начала - сделать боль видимой.
• Пример - проект с отставанием (был на тренинге подробнее). Люди должны осознать смертельный марш.
• Пример - проект с ожиданиями, исключить паузы (был на тренинге).
• est vs velocity - таблица со сравнением
• dead sprint detection - horizont burn
• выходить из штопора - переход в канбан, прекратить пытаться сделать чуть-чуть новых фич, вместо этого убрать причины появления багов
• проблемы: no dod, many tech debt
• step1 for solving problem - visualize it
• happiness index - по 5 бальной оценке How does it feel to come to work?
• automate regression test - stable velocity
• strategy - small clear steps
• benefit cost quadrant
• external expert validation
• реклама внутри доклада - книга Working Effectively with Legacy Code (перевод).
• не ждите пока сломается
• попробуйте - вдруг понравится, нет - откажетесь
• придумайте бизнес-смысл case для изменений, business value: if the make relese two month early - what value
• не "парно программируем", а "делаем новую фичу активно обсуждая - сложная..."
• нужны ли все документы - используем ли их.
• кратко шаги внедрения. 1. ask why change? 2. интервью, 3. полдня введение, полдня workshop и хватит...
• tech: visualize effect diagramm. Проблема не плохое качество кода. а провал демо.
• циклы: нет парного программирования, потому что нет в нем опыта... А реально - просто не хотим = lack of trust. (цепочка)
• против компонентных команд
• own scrum taskboard - change himself. start with you и делай те шаги, которые можешь позволить
• не меняй других людей, пусть изменяться сами. покажи причины и возможный путь
• презентакция будет в блоге на google2

Андрей Бибичев. Архитектура в Agile: переосмысляя идею модульности и компонентности

Как всегда замечательный и содержательный доклад по уменьшению связности объектов. К сожалению, мне пришлось стоять потому что зал был очень полным. Соответственно, я не конспектировал.

Если говорить о предмете доклада, то он весьма актуальный - как уменьшать связность фрагментов при реализации систем, чтобы обеспечить их независимость и устойчивость системы в целом при развитии. Какие есть принципы, и как с их точки зрения оцениваются те или иные design pattern. А сам вопрос весьма важный для динамично развивающихся систем, потому что именно хорошая изоляция обеспечивает возможность достаточно безболезненного развития функционала.

На мой взгляд, это именно то обобщение опыта и рекомендации, которых не слишком много в книгах - как выбрать те или иные шаблоны, и что они за собой несут.

Андрей Бибичев. Пуассоновое горение сроков

При оценках сроков закладываемся в 2-3 раза. Почему это правильно? Мы оцениваем наиболее вероятный срок, но, естественно, можем ошибаться. Интересный вопрос - как распределена вероятность сроков с учетом ошибки. Вовсе не по нормальному закону.

Если распределение нормальное, то девиация примерно как оценка. Значит с вероятностью 16% мы это уже сделали и должны денег. А это не так, сроки обычно оказываются больше. Значит, распределение другое.

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

Модель 2 - броуновское движение. Нас бомбардируют отклонения от пути. Дрожание. Общая траектория становится длиннее. логнормальное распределение (логарифм распределен нормлаьно).

Модель 3 - PERT. Бета-распределение. Правда докладчику непонятно почему, но он читал работы. А кривая похожая получается.

Общее - кривая не симметрична. Меньше - почти не бывает. А больше - большая область. И из-за не симметрии вероятность успеть до максимума оценки всего 10-15%. Так что правильно оценивать - X плюс X или 2X. И еще останется 5% что не прав. А 5% - это не так мало, каждый двадцатый. Посчитайте, при недельной итерации - как оно.

Антон Кекс. Недостающая часть Scrum: как стать успешным инженером в Agile?

Из Эстонии. Основатель и глава фирмы. Хороший обзор, но для новичков.

• В первую очередь итеративно и инкрементально, адаптивно
• Нельзя молиться и верить что работает - нужны тесты
• Простота. Максимизировать не сделанной работы.
• большие половины в мире используют agile, 84% из них - scrum, но только половина - итерации, то есть реально много фуфла. flaccid scrum
• вид программистов-ковбоев. И программистов-бюрократов, что хуже...
• внедрение сверху-вниз. много плюсов - для менеджеров.
• кеш швабер разочаровался в альянсе, сертифицируюющем скрам-мастеров, и начал делать программу обучения и сертификации скрам-разработчиков
• agile требует жесткой дисциплины, иначе ничего не выйдет
• yagni? simplisity - лишние патерны, проги на будущее

-- но без оговорки Эванса? - работает из предположения, что добавить потом также просто и что не можешь угадать

• продать парное программирование девелоперам...

вроде для новичков - ушел потом вернулся - когда игры кончились

• история про тесты. которые просто удаляют, а не исправляют
• build-мигалка под потолком...
• не меряйте разработчика числом строк - он начнет писать длинно, а не элегантно.
• вертикальная разработка.
  • горизонтальная - прототип формы, который не работает, потом - следующий слой
  • вертикальная - фича снизу доверху
• против чрезмерной специализации. если все кроме одного попали под грузовик. один должен мочь продолжать
• стандарты кода - чтобы ощущали своим.
• архитектура - часть дизайна, которую сложно изменить потому что она вбита. Значит лучше, если нет архитектуры... Пришло из строительства, где дизайн дороже. Он считает, что код и есть дизайн, а вовсе не какой-нибудь uml. С одной стороны, против быдло-кодеров. но с другой...
• software craftmanship
• двойной монитор с дублем экрана и две клавиатуры и мышки. Только пальцем на экране не показывать
• главное у людей - отношение к работе, а не skills

Сергей Дмитриев. Ретроспективы. Настраиваем наш процесс разработки

Я был недолго. Изложение не слишком системно, он не успел.

• Два вида ретроспектив: внутренние и внешние, большие. Внешние привязаны к релизам, но можно и без привязки, и даже через одну.
• На ретрах часто пропускают фазу анализа, бросаются сразу лечить.
• Выбирают нереалистичные большие шаги
• Модераторы - должны быть и они - вне команды. Но только на ретрах, где есть внешние люди.

Максим Гапонов. Иду по приборам! Практические советы по визуализации работ

Я слушал не сначала. Народ не влезал. Изложение не слишком гладко, зато паузы и шутки. Но где-то на 2/3 доклада народ начал уходить, правда, может потому что начинался другой доклад. Но, в любом случае Максиму не хватило репетиции изложения и это весьма сказалось на докладе.

Доклад был о проблемах понимания, вернее, неверного понимания с разных сторон, моделях и историях вокруг этого. И, особенно - средствах визуализации.

Заметки.

• проблемы понимания. всякие разные.
• например когда в длинных сценариях сознательно говорят все просто
• или говорят о крыше когда не сделан фундамент
• визуализация - вскрывает проблемы, делает видимым. краткость. плюс оба полушария - одно на образы, другое на текст. вскрывает различные представления
• Пирог Гаретта. Вглубь: Поверхность, Компоновка, Структура, Возможности, Стратегии.
• достаточно понятный кейс что для разных пользователей разное важно в одном продукте Я наивновато оно... Хотя, может, для общего уровня нормально. Вариант решения - написать все, собрать всех и обсудить. Правда не всегда реалистично, во-первых, и не все известно заранее во-вторых. Хотя как частная практика, например, на запуске (если волюнтарисnки обрезать список целей) - вполне рабочая.

Анна Обухова. Agile Distribution Risk Score - планируйте распределенность осознанно

Слушал примерно вторую половину доклада. Как-то скучновато: кейсы команда может быть распределена по-разному - в разных офисах, городах и странах. То есть просто набор кейсов, некоторые детали для каждого, которые, с моей точки зрения, достаточно очевидны. В общем-то еще на середине доклада была разборка что и как бывает. Впечатление, что в компании умеют организовывать распределенную разработку, причем в разных вариантах, однако вербализация и проявление принципов, которые лежат за этим - не удалась.

Заметки.

• варианты: isolated scrum/distributed/totaly integrated/flexible (все очень гибко)
• Надо пытаться снижать сложность.
• между 1 и 2 команды разница принципиальная, между 3 и 4 - нет.
• надо упрощать всячески пытаться. Кейсы - если продукт разваливается - разваливайте. И т.п.
• И большое многообразие по разным факторам.
• Но можно определить сложность проекта и риски из коэффициентов.

Сергей Дмитриев. Командный старт

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

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

Заметки.

• Тезис - вписывать хороший дизайн в agile очень сложно
• Говорить о минусах - разбрасывать какашки. Надо говорить о том, как можно было сделать лучше.
• Он нацелен на хорошую командность. Типа вывернуть грязное белье. Я: до конца не согласен. Хотя - попросить помощь и быть готовым - оно правильно - это из зала говорили про такой кейс.
• Он говорит о гиперрезультативных командах. Прирост в разы, от 4 раз и более. (хотя Книберг 2.5 раза дает без этого). правда такие команды год от года и не переформировывать.
• Основное - познакомиться внутри. И познакомиться с целями фирмы, команды и прочее.

Константин Гурнов. Enterprise Scale Agile. Lessons learned

Руководит развитием agile в люксофт. В целом понятный доклад обернутого в науку agile - не примеры, а общие слова и хорошие метрики.

Заметки.

Люксофт success story хорошей разработки. Развитие от функциональных команд к кроссфункциональным и далее к бизнес-командах.

Рассказ что применяют крутой agile (Enterprise Scale) - масштаба предприятия. Процесс непрерывного улучшения - главное. Через метрики. Три группы - требования, дизайн+архитектура+техника, инфраструктура. Проблема идентифицируется, гипотеза по исправлению, эксперимент, метрики результата и решение по нему.

Пример истории - 100% автоматизация в одной группе дала кучу плюсов, и не оверхед.

Источники - поддержка менеджмента с одной стороны и системное мышление - с другой.

Говорит, что все осознали и он прошел пропасть. Только Книберг при этом говорит, что реально не итеративно.

Слова - надо решать. И не свои проблемы, а проблемы заказчика. Если заказчик - ит-департамент заказчика, то ему не интересны проблемы с подрядчиком, ему надо решить проблемы бизнес департаментов.

Все коммуницируют примерами, аналитик по ним создает user story, по которым команда создает свои а тестеры свои. spec by example настаивает на использовании примеров пользователя. У них - хорошо. Из зала пошли вопросы с завалом - мол, пользователи не знают что делают.

Успешный 5-летний проект с инвестбанком (интересно, с каким, дойч?). Начали tm, потом перешли на fixprice потому что заказчик менял у себя процессы в эту сторону.

Основная штука успеха - системное мышление. Чтобы оптимизировать где надо, а не где видны возможности. И работать на результат, а не локальную оптимизацию - я: это как у Голдратта.

Второе - уважение к людям. Не только к своим сотрудникам, но и к культуре заказчика.

Дамир Тенищев. Предварительная оценка и планирование Agile проектов

Менеджер больше старой школы. Знает как надо. Новые книги читал, с частью согласен, с другим ему не очень комфортно. И доклад достаточно конфронтационный с интерпретацией пионерами и экстремистами новых веяний. Интересны проекты 50-100 человеко-лет.

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

Заметки.

Доклад - первый из трех, сейчас часть - проблемы.

Фикс price. Регулярные активности всякие - помнить (говорит 12%, из зала - 30%). Поддержка старого кода (девелопер на полставке не более 100 тыс.строк). И так далее. Объем кода - нарастает постепенно, но это не видно. Трекинговые системы - но не более 20 задач на человека. Опыт: если больше - зачем-то чистят, меньше - накидывают. Хреново... Но если за первый год много налепили, то буксует - почему - потому что разработчики гибнут под кодом. Важно, чтобы с ростом числа фич объем кода рост не экспотенциально, а логарифмически - новые фичи во многом за счет старого кода. Метрика.

Он утверждает, что девелопмент сам по себе - 10% кода. Не 30, как любят писать. Но это Брукс. а не он. Хотя он говорит о своих вычислениях - интересно посмотреть. Но к заказчику он выходит. Плюс риски неопределенности, например, неточные или неопределенные требования. (По Талебу это не слишком оцениваемо). Я: На самом деле эти риски нельзя снять - неоклассический контракт.

Еще - любовь разработчиков закапываться. полировать детали. Средство борьбы - жесткий deadline. Из зала: но это не agile. Ответ: я попробую, как повернуть, но не уберу со слайда.

Баян про документацию против общения.

Периоды тишины - например, до 12 - никто не трогает. Оно разумно.

Качество на первой линии. Не нравится идея "выделите неделю на ошибки, они поправят". Надо править сразу. "Не живите с раскрытыми окнами."

Станислав Калканов. В чем счастье заказчика? Готовые фичи вместо гант чарта!

Как-то докладчики от Люксофт однообразны и излагают известные вещи...

Заметки.

Известные вещи.

• Водопад - плохо, потому что не быстро. И потому что нельзя посмотреть до конца разработки.
• Не реализуйте редко используемые фичи. Вопрос про годовой отчет от Заборова (это - критичная фича системы, хотя раз в год используется) - не поняли.
• Не делайте сложный автоотвертку вместо простой
• Как начинается проект - делаем Гант чарт. А потом его перепланирование в деталях - день на каждое изменение

• Принцип GO SEE. Надо не смотреть на отчеты, а придти на демо...
• Следующий баян - что это (agile) в тенденции.

Попробовал уйти. Но Бевзюка не было...

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

Вопросы

• 3-5 эпик в квартал
• оценка - истории в sp task в часах

Борис Вольфсон. Гибкая теория ограничений

Был не с начала. Как и анонсирована - теория ограничений Голдратта. Конкретно в применение к разработке. Было весьма интересно послушать, хотя Голдратта я читал и теорию представляю.

Заметки.

• Ограничения - узкое звено. Определяет скорость команды. Поэтому на ретро у него в первую очередь
• Как снимать: кроссфункциональность, контроль качества перед ограничением, отсутствие простоя ограничения - буфер задач перед ним, нужность работы ограничения для конкретных задач, детальное распределение обязанностей ограничения.
• Шаги работы: определите ограничения, проанализируйте что делать; настройте работу системы в соответствии с решением; посмотрите работу; если ограничение снято - переходите к шагу 1, не оптимизируйте то что уже не ограничение
• диаграммы теории ограничений. есть 5 штук. Но они используют одну root cost analysis
• инструменты
  • канат - запуск в работу
  • буфера - используюь перед ограничением
  • барабан - синхронизация, идти в ритме с ограничением - но они не придумали как использовать
• Velocity... de Marco etc - теория ограничений и lean.

Роман Юферев. И все-таки программисты - дети!

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

Заметки. Лет пять назад: программисты-аутисты, малоспортивны и прочее.

Сейчас - нет. Программисты - самостоятельны спортивны понимают цели продукта и прочее.

Что, программисты изменились? Нет, изменилось их восприятие менеджерами.

Анна Фрейд. Изучение детской психологии.

Основные отличия.

• Мир вокруг нет. Все служат ребенку.
• Слабость вторичных процессов, например, эмоции и страхи сильнее разума
• Временная ориентация - взрослые на объективные часы, а дети - интенсивность переживания эмоций - в том числе химия
• Отличия в сексуальной области - у детей не развита.

Но эта разница не слишком существенна. Итого - воспринимаем программистов как детей, которых менеджеры воспитывают.

10 заповедей для родителей. На самом деле менеджеру очень применимо. Я не переписываю - но полезно в презентации посмотреть.

TED 5 вещей, которые надо разрешить ребенку. Потрясно. Дает водить авто и работать с электоринструментами.

Доклады о новом опыте

Здесь собраны доклады, рассказывающие о не слишком большом, но успешном опыте докладчика в какой-либо области. Это обычно некоторый один путь.

Дмитрий Лайер. Стратегическое планирование через инновационные игры

Не сначала. В целом докладчик - начинающий, 5 собственных игр. У него получается. От этого фан, осмысления нет, но как рассказ про постороннюю технику. наверное, полезно - для тех, кто в игры не верит.

Заметки.

• Игры, визуализация...
• игра заглянуть в будущее, что будет. например по продукту - только надо с конечными пользователями.
• Я: как-то все про наивно-плохие случаи - когда продукт планируют сами без пользователей и т.п.
• Не запрещайте делать визальный ряд "неправильно"
• Игры - полезны, к их результатам возвращаются. Я: это понятно, мысли - прорастают.

Семен Молотков, Евгений Кобзев. Экстремальный аджайл — танцуют все

Этот доклад был на первом месте по потенциальным слушателям, но моих надежд не оправдал. Потому что изложение, к сожалению, было очень медленным.

Речь идет о продуктовой разработке и они включили в команду всю цепочку, включая маркетинг. А начали с разработчиков.

Команда 18 человек, все в одной команте: 2 аналитика (грызут нормативку) + 1 инж.психолог + 2 проект.интерфейсов + 1 граф.дизайнер + 8 разр + 2 тестера + 1 менеджер + 1 документатор + 3 продвиженца.

Что интересно, в этой конструкции нет PO - поскольку есть много источников для задач, и как-то это совместно решается.

Владимир Бахов. Непрерывная интеграция при разработке баз данных

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

Важно отметить, что доклад был не просто про установку изменений, а именно про непрерывную интеграцию и тестирование. Для тестов они делают тестовую деревню на синтетических данных, а сами тесты делятся на 2 категории: легкие по commit и тяжелые ночью.

Заметки.

• Началось все как-то примитивно, когда был просто ручная сборка скриптов и накат, нет версионности БД, несоответствие тестовой и боевой по производительности и т.п.
• И вообще скриптовый build-инженер ушел в отпуск - жопа
• я еще мяч между dba и разработчиков. да еще когда поставка на площадку, где накатывают другие люди.
• Якобы все решает непрерывная интеграция. Я: На самом деле - совсем не все, то о чем он говорит - это просто наличие тестовых площадках, а непрерывная интеграция - про другое.
• Что есть БД - в ней много данных, надо накатывать изменения, делать миграцию и прочее.
• В общем, с БД сложнее, чем с веб-приложениями.
• Особенно откат на предыдущую версию. Например, drop table.
• Есть проблемы с продуктами, пподдерживающими CI...
• 15 минут внедрения. потом решение - да, это можно.
• Что надо: svn + UTPLsql (сейчас у Oracle в sqldev что-то вышло)
• Задача первая - все менять скриптами.
• Для начала - надо снять текущий слепок кодов проекта prod (по умолчанию исходных кодов нет). Снимают в директории по типам объектов. и именуют с цифрами для правильной сортировке.
• Есть trunc. А дальше - diff между trunc и prod. И накатываем. Продуктив один (хотя там можно по версиям, наверное). Специально добавляют какие-то скрипты и пишут их вручную. По вопросам - надеялись и это автоматом сделать.
• Урезанная продуктивная база для синтетического тестирования.
• Важны функциональные синтетические тесты.
• Поднятие локальной базы - для всех разработчиков. Важно быстро.
• Наивные вопросы из зала - а как бы сделать откат все-таки...
• Техника - diff, ant, gudson/teamcity. Тесты - легкие постоянно, тяжелые ночью. И авторассылка результатов тестов.
• Деревня для автотестов (синтетические данные)

== Кирилл Климов. Kanban vs Scrum – чьё кунг-фу сильнее

Слушал с середины. Мое впечатление: докладчики внедрили scrum, он в силу разных особенностей получился урезанным и по этому поводу были комплексы. Поэтому теперь у них Канбан с дополнительными практиками и психологически это комфортнее. Плюс, в таком варианте им легче проявлять и объяснять различную гибкость. В докладе это было менее четко, мысль была "заменим scrum на канбан, потому что scrum жесткий и много лишнего", но меняли, скорее, название чем процесс. Доклад интересен как опыт конкретной и успешной реализации процесса с разными особенностями, тем более, что многие из них для меня, например, узнаваемы.

Заметки.

• Идея - scrum много привязывает на начало итерации - ретро, оценка.
• зрелый продукт - нет новых фич и нужды в оценке. А что тогда делает команда на разработке. ей же делать нечего.
• Shu-Ha-Ri: понять процесс научиться; адаптировать под себя; выкинуть процесс.
• Итого - упростим, пойдем в канбан.
• Им некомфортно:
  • перекосы со специализацией (и хвосты на следующую, у нас тоже есть)
  • процедуры с релизами, которые не каждую итерацию (проблемы неясны)
  • работа с требованиями где-то за рамками была - запросов больше чем есть.
• Как результат - перестали бороться с моральными угрызениями и перешли на другой процесс.
• При этом канбан обогащен практиками, например, оценки. И ретро, когда-нибудь. И демо... Только к итерациям не привязывать.

Тимофей Евграшин. Культура лидерства в Agile про лидеров

Слушал очень немного. Докладчик не понимает, что команда креативных лидеров загибается - они дерутся. И это экспериментально проверено Белбиным. А еще лидерство и личная отвественность - вещи разные, хотя и пересекаются.

Из заметок. Лидер Стив Джобс может сделать во всей компании agile. Лидерство идет из личной ответственности - я с этим сильно не согласен.

Юля Нечаева. Как сервисному отделу не стать бутылочным горлышком

Слушал частично. Юля возлавляется не слишком давно созданный отдел тестирвоания, общий для нескольких команд разработки, которые живут каждая в своем ритме. Судя по всему, до этого были большие проблемы с качеством, которые сейчас их отдел решает. А она делилась опытом организации этого процесса. К сожалению, в докладе было много о проблемах, но не так много о решениях. Кроме того, относительно четкое противопоставление "мы-они" - про разработчиков и тестеров, а не про "мы вместе". И, соответственно, договоренности как у сторон, которым надо отстроить приемлемые правила взаимодействия в условиях противоречащих требований, а сотрудничество для выпуска продукта - оно где-то за рамками. Наверное, оно есть, но в докладе его видно не было.

Из забавного. С точки зрения разработчика, хороший тестер должен заранее знать не только время тестирования, но и количество найденых багов - чтобы разработчики могли заранее запланировать их исправление. И не проверяет повтороно - ведь исправили наверняка хорошо.

Из позитивных практик - выявлять те тесты, где работа наиболее неустойчива и начинать с них. Например, web тестирвоать под chrome.

Николай Алименков, Алексей Солнцев. Что означает «Готово!»: применение практики Definition of Done

Слушал с середины. В целом показалось, что это борьба с ветряными мельницами бюрократии с одной стороны, и самообманов - с другой - принять почти готовое. Экспрессивно, подряд и несколько сумбурно, без логики изложения.

Заметки. Как-то они примитивно про скрам - мол в середине никто не смотрит за процессом... А как же движение по доске? И про канбан - что только одна задача в разработке. В целом по-разному оно.

Ну и дальше - no commitment, no undestanding какие-то известные штуки. Надо искать способы договоренности, всякая демократия и прочее...

Не согласие двух вариантов: без аргументов и с аргументами. Если с аргументами - обсуждаем. Если без - решаем с менеджером (Хенрик сказл бы - гнать из команды).

Всеволод Леонов. Стихийный Agile во внутрикорпоративной среде

Из embarcadero. Я квалифицировал как новый для докладчика опыт - все-таки обобщений тут нет. Довольно сумбурный доклад. Из достаточно большой кучи баек. Попытка уложить в одну канву не слишком получилась, но сами фрагменты достаточно интересны. Но там очень много негатива про внутрикорпоративную разработку: есть и правильные вещи и передергивания.

Заметки.

• Про то идет или нет agile.
• Agile с серьезными заказчиками... Которые из оборонки по госзаказу.
• Разрешили партизанский agile. Был овертайм. Но зато заказчик овладел так продуктом, что сдавал за них, сдача прошла на ура.
• Почему agile: инвестиции в заказчика; великий продукт; смысл жизни; рывок в startup. Уверенность что делал правильно.
• Panic Driven Development
• Боевое внедрение на продакшене
• Agile как оправдание бардака внутрикорпоративной разработки.

А в конце - реклама delphi и delphiPHP