Вчера был второй день конференции SoftwarePeople-2012, мне он показался хуже первого. Может быть потому, что на этот день пришлось больше докладов на те темы, которые мне хорошо знакомы. И тут дело не в том, что какие-то авторы повторяют свои доклады из конференции в конференцию. Авторы как раз новые. Просто ситуации в разработке — они повторяются, и слушая чей-то личный опыт или идеи — понимаешь, что это тебе знакомо — из других выступлений. А вот тем, кто не ходит столь активно по конференциям или не работает в отрасли так давно — выступления интересны. И, в любом случае — впечатление именно по сравнению с первым днем, а в целом доклады на хорошем уровне.

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

А сегодня я был на мастер-классе Джеффа Де Люка о Feature Driven Developer (FDD). И с пользой послушал изложение методологии от его автора, который создал ее не теоретически, а обобщая собственный опыт ведения проектов. Опыт от мэтра — это всегда интересно, особенно если он методично изложен. И в целом он окрасил теоретически известную мне методологию практическими аспектами. Часть из которых мы применяем, а другие — точно стоит попробовать использовать и, может быть постепенно возьмем все…

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

Да, мой доклад — http://lib.custis.ru/BabelTower, там презентация и статья.

Доклады второго дня

Начну с конца, потому как последний доклад мне понравился больше всего. Константин Кондратюк, Алексей Янчук. Россия и Европа — взгляд друг на друга в сфере ИТ. Два докладчика, один в зале, другой — по мосту. Сравнивают подходы к IT-разработке в России и Европе. Если резюмировать, в Европе больше порядка, у нас больше хаоса. Зато у нас больше креатива. А в процессе у нас больше ориентируются на суть, там — на форму.

Но интересно не только это. Есть различие в подходах к жизни. В Европе, реально в 30-35 — молодой специалист, а не senior. Потому что кончив институт в 22 они не спешат зарабатывать деньги — они ездят по миру, работают волонтерами. И только к 30 — начинают всерьез думать о работе. Я, правда, не знаю, сколько тут статистики, а сколько — просто личных впечатлений. Но такие люди — точно есть, и их число — заметно.

Да, то, что в 22-25 из России приезжаешь уже как senior работе — не мешает, там оценивают по отношению к работе. А вот пообщаться вне работы — не слишком получается, потому что сильно старше.

Дальше пойдем в том порядке, в котором я доклады слушал.

Марина Кувшинова (IBM). Разработка инновационных продуктов и сервисов. IBM сам работает на своих инструментах, использует Jazz для планирования своих работ и рассказ был об этом. Что интересно — они внедрили у себя, и не просто agile. Или даже SCRUM, слово было сказано. А инструмент — чтобы план был не у руководителя, а у всех. Говорят, начали в 2006 без этого — было хреново. И тогда во-время выходило 46 % релизов, а сейчас — 97 %. И это — не единственный измеримый эффект — есть экономия за счет повышения эффективности общения в распределенных коммуникациях. Сокращение дефектов в production. В общем, много чего. Единственное, что огорчает — автор не из команды разработки, поэтому детали про метрики и процесс — ей неизвестны. А они были бы интересны.

Александр Орлов, Вячеслав Панкратов. Стоп кадр: разбираем сложную управленческую ситуацию. Саша и Слава разбирали конкретные кейсы в интерактиве с аудиторией. И успели это за время стандартного выступления, 45 минут. Кейсов было два:

• Команда из двух половин, в одной руководитель инициативнее, в другой — опытнее. Менеджер уходит на повышение, кого предложить.
• Шеф сказал менеджеру — еще раз провалите самостоятельно оцененный релиз — полкоманды уволишь. Сказать или нет и какими словами.

Получилось хорошо. Просто от авторов — ждешь хороших докладов и потому они не удивляют.

Максим Дорофеев. Кросс-функциональная команда — это хорошо или плохо. Как Макс и обещал, были разобраны аргументы за кросс-функциональность и за специализацию. А аргументы против того и другого. А еще — показана теория ограничений в условиях IT-разработки и с учетом кроссфункциональности персонажей. С модельными примерами и математикой. Правда, на мой взгляд, на несколько поверхностном уровне, особенно потому, что в группе около 5 человек статистика работает плохо из-за всяких квантовых эффектов, а на больших группах становится важна организация процесса, и там другие модели.

Татьяна Свиридова. Использование активной методики как способ повышения мотивации при обучении. Весьма любопытный доклад Украинского отделения Epam об их успехов в обучении. Они пошли дальше схемы с Менторами, о которой рассказывал на нескольких конференциях Дмитрий Петелин и другие сотрудники, заменили ее на BootCamp. Лекции, работа над проектом, экзамен. Две команды, псевдомодельный проект — для ресторана компании, заказ обедов. Что интересно, организовано у них это еще и на общественных началах — и обучающие и учащиеся, добровольно! Платят только бонусы и всякий суппорт типа на пиво. Раньше было сообщество вообще на свои деньги. Вот так.

Роман Шарыгин (Intel). Архитектура тестовой системы для продукта с развитым графическим интерфейсом. Intel разработал свой движок, на котором можно делать автотесты для GUI через скрипты на Python в ходе проекта Intel VTune Amplifier XE. Тут много интересного — и то, что Intel решил разрабатывать, они перед этим смотрели на готовое. И подходы, которые выбрали, компания имеет определенный авторитет, хотя, конечно, разработка софта — не ее конек. Я еще над этим подумаю… И не очень понятно, появится ли это как отдельный продукт…

Алексей Чумаков. Как подружиться с заказчиком: разрабатываем, управляя потребностями. Я попал только на конец — был на тестировании. Надо будет посмотреть — думаю, было интересно. Например «длинные ТЗ — в топку, туда же — длинные планы и отчеты» Вместо этого — быстрое прототипирование по сценариям, ручные краткие отчеты (на одном листе). Лучший отчет — показ результата, рассказ как хорошо разрабатываем — ни о чем. Проверка смысла документа: должно быть понятно Что-Когда-Почем-Кто-Кому-Как-Зачем(-Где), если одно не освящено — не полон. И так далее.

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

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

У них в компании — ориентация на стабильные команды разработки, во главе которых teamlead (7-8 лет). Команды иногда объединяют на большой проект. У этого есть плюсы, минусы и фичи. В том числе незаменимость лидера — если появляется второй сильный, то будет конфликт. Поэтому если лидер уходит — есть свои особенности, обычно у них растят из кого-то внутри команды и он для начала должен взять орг.рутину чтобы не стреляло — тогда его примут.

Считает, что такая структура команд в масштабируется на 200—250 человек (сейчас под ним 50). При этом 10 лидеров — они тоже должны образовывать команду. Это уже ваша работа.

В целом — хорошо и вполне по делу.

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

Владимир Железняк, Дмитрий Снисарь. Управление гневом. Как укротить гнев свой и коллеги/заказчика/подчиненного? Я слушал небольшой фрагмент. Конкретные практики, приемы, ситуации. К сожалению, несколько несистемно, как поток, а не как мозаика. Поэтому я воспринять не успевал. С другой стороны, когда выложат видео — можно будет пересмотреть и спокойно осознать.

Сергей Бережной. Кризис с заказчиком. Рассказ про то, как автору озвучили оценку 4 из 10 от Заказчика и спросили — в чем дело? Потому что 4 — это вообще самое худшее, что было. А оценка, что интересно, была поставлена 2 месяца назад — это у них так обратная связь работала. А дальше — был разбор причин которые вскрылись, и упущений, из-за которых ситуация дошла до кризиса.

Про Жалобы и Конфликты: Жалоба — когда причина и повод совпадает. Конфликт — когда не совпадает. Про работу с ними. Про то, что Заказчик вовсе не всегда раскрывает правду, но усиление давления — сигнал, с которым надо работать.

В докладе было много закладок, маркеров тем, с которыми интересно познакомиться: реактивные реакции, техника работы с жалобами, архетипы системного мышления. Цикл Проблема — Симптомы — Симптоматическое решение — Побочный эффект. Техники выявления проблем — 5 почему, Дерево текущей реальности, SWOT…

В целом тот конфликт был решен — после того как проблему вскрыли. И сейчас с Заказчиком отношения нормальные.

Сергей Зефиров. Сильный разум. Неожиданный доклад о том, что мозг — он усыхает с возрастом. И есть физические упражнения, которые помогают держать его в тонусе.

 Мастер-класс Джеффа Де Люка

Сегодня был на мастер-классе Джеффа Де Люка и Полья Сзего «Как с помощью FDD делать отличный софт (How To Deliver Better Software Using FDD)». Практических занятий, правда, не было, был рассказ мэтра про Feature Driven Developer (FDD).

Сам подход замечателен тем, что получен не теоретически, а обобщением практики успешного руководителя проектов. Началось все с проекта системы кредитов для Сингапурского банка, который был самым большим IT-проектом в то время (1998). При этом был первым проектом клиент-серверной системы для банка, который до этого использовал мэйнфреймы, да еще реализовывался на Java, которая в то время была в весьма слабом состоянии. Так что когда Джефф начал — проект был в глубокой стагнации, а Джефф — успешно его вытащил. В рассказе были примеры именно с того проекта — потому как материалы открытые, банк официально разрешил использовать.

Начался рассказ с проблем водопада, подтвержденных статистикой. Проблемы — известны, а статистика — она реже встречается. А еще — я-таки узнал в чем отличие итеративности в семействе водопадных методов от agile. Да, она там есть. Но при этом исключается deploy and maintain, а часто и (integrate) test системы. Таким образом проблемы выносятся в конец. Поэтому чисто статистически выиграет любой процесс с инкрементальной поставкой — за счет того, что хоть часть проблем с требованиями выяснится раньше. Но все это — кратко. Попутно немного досталось CMMI как чисто теоретическому измышлению, в котором набор принципов, образующих уровни, выделен, по словам Джеффа, достаточно произвольно.

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

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

Краткое описание FDD.

• Процесс делится на две больших части: Начальная и Разработка по фичам.
• Начальная стадия делится на три: Overall model — Feature list — Planing.
• А дальше — Design и Build по фичам, организвоанная весьма сложно — многими мини-командами (4 разработчика), параллельно, инкрементально. При этом каждая фича уходит в Build, в версию.

Процедура Overall model. Общее описание — по 20 минут на тему от главных специалистов. Для начала — по теме в целом, общий обзор на час. Обычно по результатам каждая тема делится на несколько подтем. Обязательно надо согласовать цель и scope проекта. Цель — сразу, а scope — уточняется при описании тем.

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

Надо согласовать названия классов, это иногда долгий процесс.

Почему группа из 3? Потому что когда их больше, один превращается в руководителя и тянет на себя. Почему 3 группы? При 2 часто возникает конкурентная динамика, кто круче. При 3 этого нет. Почему не больше? Потому что дорого. Три группы: 3 бизнеса, 3 аналитика, 3 разработчика. В небольших проектах — может быть 3 пары.

Параллельно с объектной моделью — уточняется структура, классификация предметной области. Два уровня — Subject Area и Business Activity, под которые потом и группируются фичи.

Еще — выбирается технологическая архитектура, хотя можно и немного позже.

Следующий этап — формирование списка фич. Именование фичи — action the result by/for/of/to an object. У фичи должно быть бизнес-value. Быстрая 3-бальная оценка функций по сложности. Быстрая 3-бальная оценка по зависимости. Фичи — небольшие, не более недели, в системе кредитования были тысячи функций.

Следующий этап — Планирование. Каждая функция должна быть оценена (трудоемкость), а у каждой бизнес-активности должен быть поставлен месяц ожидаемого завершения. Именно месяц, и только завершения. Согласование трудоемкости и дат — вопрос менеджера, он не простой. План в таком формате — несколько неожиданный, но заказчику именно это и интересно. А диаграммы Ганта — зло.

Интересная эмпирика — на 1 неделю на моделирования — тратим 3 месяца на реализации. Зная такой коэффициент — можно прогнозировать трудоемкость проекта по скорости моделирования.

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

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

С другой стороны, функции объединяются в некоторые логические пакеты, и для каждого пакета назначается группа разработчиков, состоящая из 1 главного программиста и 3 обычных. При этом в состав группы входят ответственные за те классы, через которые проходит исполнение функции. Разработчик может входить в несколько групп, и быть в одной главным, в других — обычным. Главный программист 50 % времени занимается организацией работ группы, включая коммуникации с другими главными программистами — на больших проектах нельзя общаться «каждый с каждым».

Деление на пакеты и группы с назначением ответственных тоже не делается на весь проект сразу, но должно обеспечивать в целом горизонт работ на 1-2 месяца, а квантование в пакеты — на 2 недели. Группы — не являются постоянными, они меняются в процессе разработки.

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

Понятно, что формирование пакетов, формирование и назначение команд надо проводить с учетом связей функций, и вообще это непросто. Это — требует включения мозга.

Дальше группы реализуют свои пакеты. По функциям, ориентируясь на зависимость между ними, и на сроки, указанные для активностей, в которые входят функции. Для функции выполняется design, обычно — через диаграмму последовательностей, функция проходит через ряд классов. А дальше — build. При этом классы правят те, кто за них отвечает. И тут еще вопрос перегрузки, если человек отвечает за много классов, и тут вдруг пошли пачкой функции, которые в них реализуются.

В целом функция проходит ряд стадий, обычно Domain Walkthrough — Design — Design Inspection — Code — Code Inspection — Promote to build. И при включении в работу Главный программист проставляет ориентировочные сроки. Это является сигналом, что функция пошла в работу. Для стадий известно стандартное распределение по процентам: 1-40-3-45-10-1.

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

Вопрос: а что unittest не является важным? Ответ. Вообще говоря, unittest — обязательный шаг в FDD. Но! он не фиксирует этап, на котором ихнадо писать. Одни пишут раньше, другие — позже, поэтому в этапах его нет.

Это все — про модель предметной области (PD). В больших проектах он обычно выделяет аспекты — UI и Интеграцию (SI), но в FDD такое деление не входит. SI похожа, только фичи интеграционные, а не бизнесовые, и распределение по стадиям другое из-за активного применения типовых решений. А в UI часто и другие стадии, работают разные специалисты, и тут у него нет типового решения. Можно выделять и другие аспекты, например документацию — там, где она важна. И фичи UI лучше называть «UI item», у них другой смысл.

Вопрос? Когда пользователь увидит результат. В принципе можно показать и сейчас, из командной строке. Но лучше — чтобы был интерфейс, и надо это учитывать.

Итак, идет реализация по фичам. Для наблюдения используются отчеты. Состояния отдельных фич агрегируются в состояния бизнес-активностей, которые показываются на интегральной диаграмме «парковка». Там же цветовое различие. И есть детальный отчет по фичам, включая план-факт по стадиям.

Оценка — ответственность. Часто считают, что ответственность за выполнение — на исполнителя. Как будто ошибок в планах — не существует. На самом деле: если вы не уложились — значит плохой был план. Плохо предсказали. Даже если работники некомпетентны — потому что тот, кто планировал должен был учесть.

Процедура — Weekly Release Meeting. Предпочитает в среду до обеда. Жесткий timebox — 15-30 минут (зависит от размера проекта). Проблемы не решаются, это — отчет. Например, задержка релиза — фиксируется и если надо обсудить — назначаем встречу.

Важно — у главного программиста проекта должно быть общее представление — что происходит с проектом.

Полезно иметь отдельного release manager. Он отвечает за оценку дат и смотрит за графиком, фиксирует задержки. И заботится о фронте работ, своевременном планировании пакетов.

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

Дефекты. Если в реализации — исправляют. Состояние фичи при этом не меняется, но на исправление дефектов должно быть заложено время. За их числом — надо следить. Если дефект в требованиях — разбор с бизнесом, и решение как с новой фичей.

Демо для бизнеса — как можно раньше. Это важно. Но эти вехи надо ставить аккуратно — чтобы был готов представимый функционал. И это он тоже планирует.

Процесс — обязательно надо адаптировать. И первый кандидат — система отчетов.

Разработка overall model. ООП — он любит, но не требует. Можно использовать и другие подходы. Важно — по результатам модели надо уметь сделать план. С должной степенью детальности, охвата и точности. Надо уметь отвечать на вопрос «как далеко продвинулись и сколько осталось». Можно работать по-другому. Если отказываются от ООП — надо искать замены для соответствующих методов, в том числе для диаграммы последовательностей — нужно делать дизайн по-другому.

TDD vs FDD

• TDD — не средство дизайна или работы над требованиями!
• А так — unit test и автоматизация тестов — да, можно и нужно.

UseCase — отстой. По многим причинам. UseCase у Якобсона — просто жестко закодированное взаимодействие между пользователем и системой. По сути, противоположно ООП — жесткая реализация вместо гибкого домена.

Нефункциональные требования — контракт. Согласуются сначала. Если вы сделали с нарушением контракта — это баг. Если заказчик в середине меняет — он меняет контракт.

Тестирование. unit — в build. Модульное тестирование входит в ответственность за класс. Интеграционное тестирование — отдельные ответственные, Регресс — тоже, это часть передачи в сборку.

Вроде все. Симпатичная система, ориентированная на большие проекты, в которых важна архитектура. Хорошо сочетается с нашими практиками, в частности DDD.