Викилоги

В субботу 26.11.2011 участвовал и выступал в Питере на конференции SPM Conf 2011 - Software Project Management Conference. Это - новая конференция от SQA labs, которая, думаю, станет первой в серии конференций по софтверными проектами, дополнив ранее стартовавшие линейки конферениций - SQA Days и Application Development Days. Конференцию снимала на видео наша компания, и скоро запись появится на lib.custis.ru, а пока - мои впечатления.

Если выразить кратко - конференция удалась. Было много хороших и интересных докладов. И, несмотря на относительно узкий предмет, доклады были посвящены различным темам. И это была конференция практиков, которые имея представление о методологиях, основной упор делают именно на практические приемы эффективной работы. И хотят поделиться своим опытом, передать его другим участникам. Наверное, поэтому я не открыл для себя в докладах чего-то принципиально нового - я все-таки работаю в отрасли достаточно давно. Но атмосфера общения с сокультурными людьми - она ценна. Если же говорить о более молодых участниках конференции, то на мой взгляд большинство докладов несло для них ценный опыт и вызывало явный интерес - что хорошо было видно и по вопросам и по активному участию зала. И я видел далеко не все доклады - все-таки, 3 трека подряд, и планируя конференцию я в большинстве слотов отметил себе два доклада, разрываясь между ними. К тому же, на последних трех слотах докладчики конкурировали еще со стендовым докладом Стаса Фомина, который держал стоящую аудиторию 2.5 часа (сидящих мест там было мало). При этом доклад Стаса - не снимался на видео, поэтому при отсутствии - ты терял возможность увидеть. Что повлияло на не только на мой выбор, но и, думаю, на выбор других участников - остальные доклады будут доступны в записи.

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

• Project Manager в SCRUM - как жопа: жопа есть, а слова - нет.
• Аналогия Ежи и Лисы...
• Кнут получился, а пряник - не очень.

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

В целом - все. Надеюсь, эта серия конференций - будет продолжаться.

Сегодня был второй и последний день Бизнес-форума по Управлению знаниями KM Russia-2011. Были мастер-классы, самым впечатляющим из которых безусловно был мастер-класс Рона Янга, больше трех часов. Практически это была расширенная версия его вчерашнего доклада, с конкретными кейсами и подробностями. Замечательный человек. Рон несколько раз задавал работу в группах на 10 минут с ответами на вопросы, а потом - за перерыв подстраивал следующий слот с учетом услышанного. В конце была обратная связь от участников, ему переводили и Рон исписал больше страницы заметок - он тоже учится, проводя такие мероприятия, что очень впечатляет. В апреле, в рамках бизнес-конгресса, обещан его 8-часовой (или 16-часовой?) тренинг.

Тренинг сильно повернул мое представление о знаниях, и их отчуждении. Знания - в головах. При их отчуждении они. на самом деле, превращаются в информацию, в лучшем случае - учебник. Его можно прочесть, но знаний - не получить. Чтобы их реально получить - надо обучиться, это время и усилия. Поэтому управление знаниями - сложный процесс. Безусловно нужна вербализованная часть. Но при этом надо еще обеспечить ее эффективное восприятие другими людьми с тем, чтобы она превращалась именно в знания, а не в прочитанную информацию. Рон рассказывал конкретные паттерны - как это может быть устроено в организации, что для этого нужно. Они - разные, многое зависит от конкретной организации, ее деятельности. Но, тем не менее, как с управлением - это не искусство, есть технологии и методики, и их надо использовать, а не изобретать.

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

А еще, кроме мастер-классов - было живое и активное общение участников. И это - ценная вещь форума, реальный обмен знаниями - потому что участники очень разные. Я, кстати, узнал, что вчера Сергей Гевлич в своем докладе рассказывал про применение ими формы эффективной упаковки знаний в презентациях через рисование и звук, аналогично RSA Animate. И они готовят программу на iPad, которая сделает создание таких презентаций общедоступным. Стас, правда, говорит, что у него такая технология есть...

Сегодня - первый день Бизнес-форума по Управлению знаниями KM Russia-2011, на сайте есть online-трансляция. В прошлом году я на этом форуме был и мне очень понравилось, отчет KM Russia-2010 - конференция по Управлению знаниями. В этом году я в конце сентября посмотрел анонсы, их не обнаружил - и решил, что со вторым бизнес-форумом не сложилось. Но на прошлой неделе меня ожидал сюрприз. Во-первых, форум все-таки состоялся, а, во-вторых организаторы, помня о прошлогоднем отчете меня на него персонально пригласили (и дали скидку) - за что им большое спасибо. Подробный отчет о форуме будет позднее, думаю в середине декабря, а сейчас - первые впечатления.

Мероприятие в этом году более камерное. И более сконцентрированное - на порождении и обмене неявными знаниями. И на crowdsourcing'е. Много интересных и концентрированных докладов. Если резюмировать впечатления, то в целом мир оказался ближе к светлому будущему, чем я об этом думал. И это стоит осмыслить, позиционировать себя в этом мире. Многократно упоминалась история геймеров, спроектировавших за несколько месяцев фермент, который бы боролся с вирусом спида - чего не могли за 4 года сделать профессиональные институты. Между прочим, организация этого процесса шла из Пентагона.

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

Если говорить конкретнее, то в коллективной работе со знаниями четко выделяют три этапа - (1) генерация идей, которой занимаются все; (2) обсуждение, отбор и сортировка, которая идет в сообществах и за счет горизонтальных связей, и реализацию, которой занимается исполнительные структуры наряду с управлением или специализированные проектные группы. При этом такую структуру сейчас умеют строить и эффективно тиражировать не только в небольших компаниях, где многое решается за счет личных коммуникаций, но и в корпорациях и даже государствах, хотя в масштабе большого государства сложностей много. Это эффективно развивается.

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

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

• Ron Young, работавший над управлением знаниями на уровне правительственных программ Великобритании и Еврокомиссии, а последние годы - работающий в межгосударственном агентстве в Азии, объединяющем национальные агентства по производительности труда. Он рассказывал об идеях и рассказывал о развитии отрасли. С его точки зрения, будущее - за Азией. Потому что они сейчас сильно вкладываются в управление знаниями, потому что время одиночек прошло, будущее - за коллективной работой, а это - в их менталитете, и уважение к знаниям - тоже в менталитете. А одиночек, способных порождать идеи - они привлекут.
• Сергей Карелов рассказывал об эволюции краудсорсинга. О новых подходах, которые позволяют преодолеть недостатки классического краудсорсинга - информационный шум и стремление выбирать понятное. О том, что работая по таким технологиям можно делать облачные предприятия.
• Сергей Переслегин дал ретроспективу развития управления знаниями, 12 уровней процессов - от производства до фундаментальных исследований. Основной тезис - на регулярной основе научились делать мега-НИОКРы, примеры - космос или атомный проект. При этом под мегапроект надо делать специальную структуру и, что интересно, она успешно делает лишь первый проект, живет лет семь. Вызов будущего - научиться делать мегаНИРы.
• У Дмитрия Пескова был очень любопытный доклад. О мемах, которые, с одной стороны - современное средство управления массами, а, с другой - способ договариваться о будущем, позиционируясь относительно этих мемов. С метафорой мема как божества, у которого появляются жрецы, которым приносят приношения, и которые распределяют благодать. Например, в виде бюджетных денег. При этом в России - эхо-мемы, первичные мемы сейчас рождают сценаристы Голивуда в своих сериалах. Именно из них широкая публика черпает картину мира. Что, кстати, проявляется и в програмисткой среде, только сериалы тут свои, например, Дильберт.

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

• Василий Буров рассказывал о работе над всенародным обсуждением законов - то, что сейчас происходит с законом об образовании, через что прошел закон о рыбной ловле. Там любопытно. Оказывается в форме соавторства то есть предложения альтернатив, а не комментариев такая форма реально работает. И тот же закон об образовании - ежемесячно выходит новая версия. А приличное количество участников, когда предложили давать именно альтернативы, а не критику - оно испарилось. Все это было в контексте мирового опыта, а не только нашего. Если же говорить о перспективах, то. с его точки зрения, есть два варианта. Может, заработает Демократия 3.0 - сами написали закон. сами исполняем. А если не сложится - то нынешний процесс, пока ограниченный рамками обсуждения проекта - станет процессом постоянного совершенствования и внесения поправок.
• Валентин Матохин рассказывал о системе Текоры. Я год назад слушал его на прошлом бизнес-форуме, и мне было любопытно узнать о прогрессе. А еще на этот раз в докладе процесс был изложено подробнее, чем год назад, с большим количеством деталей.
• Олег Манчулянцев сделал приятный доклад о стартапах как процессе. Я недавно был на SECR, где по стартапам и процессу их инвестиционной поддержки был отдельный трек, и мне было интересно соотнести процессы в IT и на более крупном уровне госкорпораций и государственных образований. Но в обоих случаях были люди, которые делают и поддерживают реальные проекты, работают. И у них нет особых проблем с отсутствием проектов и идей, они сотрудничают с ВУЗами. Все это выгодно отличается от плача, который я слышал в некоторых других местах - что деньги есть, а идей нет, потому как явно перспективные не соглашаются на условия, а для остальных не удается найти экспертную гарантию, и что бизнес "должен поднять ВУЗы".

В целом - очень позитивно, и, надеюсь, завтра будет не мене интересно.

Подготовка выступления к SQA Days и, особенно, обсуждение на форуме http://software-testing.ru моей статьи, помещенной в качестве анонса к докладу, вызвало пару мыслей про Agile, которыми хочу поделиться. Именно про agile - хотя само выступление про совмещение ролей аналитика и тестировщика, в я активно апеллирую к agile-процессу и это вызвало отдельную ветку обсуждений.

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

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

Мысль вторая. Я тут пересмотрел презентацию Джефа Сазерленда на SECR, и вспомнил вещь, на которую обратил внимание еще на конференции. Для Джефа развитие компании идет так: CMMI 1 → CMMI 5 → CMMI 5+SCRUM. Я обсудил это с коллегами, с их точки зрения CMMI5 и SCRUM - вещи слабо совместимые. На самом деле, тут вопрос оценки CMMI. CMMI 4 говорит о том, что в компании должна быть настроена оптимизация процессов на основе показателей. А CMMI 5 - что сам процесс оптимизации тоже должен оптимизироваться. Дальше вопрос - что именно мы вкладываем в понятие "оптимизация". Максималисткий подход - рассматривать оптимизацию как поиск оптимума (логично, правда), который еще должен быть достаточно быстрым - чтобы придти близко к оптимуму за то время, пока окружение можно считать квазистатичным.

А можно рассматривать это иначе, понимая под оптимизацией всего лишь процесс, направленный на улучшение чего либо. То есть некоторые регулярные мероприятия, в рамках которого формулируются шаги по улучшению некоторого процесса, которые потом воплощаются. И достаточно, если шаги будут в среднем правильными. И если оценивать так, то CMMI 4 в SCRUM есть - это ретроспектива. На которой, в числе прочего, следует обсуждать показатели работы команды - burndown (и другие показатели), придумывая меры по их исправлению, которые затем будут воплощены. А чтобы получился CMMI 5 - нужно еще ретро по ретре, и процесс обмена всем этим опытом в рамках компании (процесс обмена и для CMMI 4 нужен).

Естественно, так происходит не в любом SCRUM, нужно как минимум желание и усилия в этом направлении. И я не уверен, что во всех командах у нас в компании действительно есть оптимизация процесса на основе показателей - потому как идеи высказываются, а воплощение они получают не всегда. Хотя стремления - есть. Но, надо сказать, что слушая истории о конкретных командах от Джефа (и от Книберга тоже) - вполне допускаешь, что в конкретных компаниях, в них фигурирующих, SCRUM действительно означает CMMI 5.

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

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

Тем не менее, сейчас такой мировой опыт - есть, и правильно приводить внутренние конструкции к нему, отступая только сознательно в тех местах, где для этого имеются существенные причины. Мы, собственно, уже имеем определенные проблемы с нашей квалификацией "инженера", для которой нет аналогов и потому ее необходимо переводить при каждом разговоре с внешним миром. Думаю, SFIA - не единственная возможная платформа для наведения таких мостов, но российские профессиональные стандарты, к сожалению, оказались кривоватыми и использовать их как базу - не хочется, а SFIA - общедоступна, компактна и мне попалась. Если кто вытащит альтернативы - не вопрос.

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

Еще одна область возможного применения - более четкое деление обязанностей внутри компании. Это процесс, связанный с нашей continuis reorganization. Авторы SFIA подумали и поделили весь спектр IT-деятельности на 90 областей с уровнями внутри, и, в общем, ничего не забыли. Там есть и админы, образование, управление ресурсами, взаимодействие с клиентами и поставщиками, в общем, все то, о чем Володя периодически спрашивал "где это в SCRUM". Эти части - они есть объективно, а дальше надо провести границы - чем занимаются команды, что на профессиональной инфраструктуре, что на различных рабочих группах. И деление тут не только по областям, но и внутри области. Например, 2-3 уровень компетенции 79 PROF Programme and project support office у нас возложены на команду - в виде burndown, доски, планирования и ретры, а далее акцент смещается к менеджерам. Тоже самое можно сказать о 57 SMLO Service level management.

Заметим, что деление на компетенции тут местами непривычно (посмотрите на упомянутые выше компетенции), и есть большой соблазн в него не погружаться, а провести свои границы. Но дело в том, что о своих границах - у каждого собственные представления и их провести - непросто. А дальше еще их надо будет объяснять... Так что использование уже выполненного разделения имеет свои преимущества. Тем более, что компетенции, в которых говорит SFIA - это не должности, и если мы считаем на определенной позиции совмещать несколько смежных умений, то артефакты, которые нужны для коммуникации при их разделении меняют смысл.

Итак, детали.

→ продолжить чтение…

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

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

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

Еще мне понравился доклад Алескандра Калугина (PMarcor, Mercury Development) Навыки менеджера небольшого проекта: окопная правда - сконцентрированно и по делу, с неплохой метафорой обучения водителя мотоцикла (в отличие от фуры, которая - большой проект).

И заключительный доклад Джефа Сазерленда про современный уровень SCRUM. С теми достижениями, которыми он гордится - непрерывный SCRUM российско-американской команды, когда daily scrum проходит вечером по Москве и утром по Америке, с передачей задач. И распределенный германско-индийский скрам на 4 офиса, который организовывался постепенно - сначала совместная работа 4 немцев и 4 индусов в Германии, потом индумсы уехали к себе и начали работать распределенно - мощность сохранилась, потом по одному человеку из каждого офиса поехали в другой офис, во все части команды добавили разработчиков и получилась команда из 4 частей - получили линейный рост мощности по числу разработчиков. В общем, это такие маяки впереди...

Если говорить об уроках SECR для нас, то во-первых, я жалею, что не было никого из Java или Web - в эту сторону были интересные доклады, из которых специалист мог бы извлечь больше. Да и не на всех я был, потому что они пересекались с другими темами. Во-вторых, конкретный урок. Люди активно используют автоматическое тестирование AJAX-приложений, об этом было несколько докладов. Используется Selenium, скрипты пишут тестировщики, а не разработчики. Такие тесты заменяют все остальные, они обеспечивают, что приложение не разваливается. При этом на вопрос о других видах тестов одному из докладчиков был явный ответ, что их писать пробовали, но быстро поняли, что сильно не уложатся в бюджет проекта, а качество достаточно обеспечивается автоматическими тестами. Там есть свои особенности с производительностью - помимо изолированных тестов надо делать один общий, который проигрывает сценарии в одном открытии browser'а - чтобы пускать вручную, потому что полный набор работает долго и на Continius Integration. И еще были конкретные технические рекомендации, это уже отдельно.

Отчет о конференции с резюме докладов в моем стиле - будет. Когда - не знаю.

P.S. На закрытии я сидел в президиуме и говорил от программного комитета. Мелочь, а приятно :)

P.P.S. Предварительные презентации есть не флешке, а окончательные - обещаны на сайте.

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

В целом конференция удалась. Участников много, на пленарных докладах был полный большой зал. Маленькие залы (второй и третий) на докладах сильно заполнены и на некоторых не хватало мест. Довольно много хороших докладов.

Сегодня был пленарный доклад Бертрана Мейера, автора языка Eiffel, который сейчас не только профессор в Цюрихе, но и зав.кафедрой в Петербурге. Доклад бы о подходах к ведению требований. User story и use case для этого недостаточно, требуется абстрагирование, обобщение и построение модели. В качестве средства для которого, естественно, предложен Eiffel. Eiffel Studio обеспечивает графическое представление, и править можно и текст и диаграммы. Доклад мне понравился, он в целом соответствует моему представлению и практике, кроме использования Eiffel, и необходимости в нашей области не только объектных моделей. А еще в нем было живое кодирование модели - что редко встречается в докладах мэтров. И пара прикольных видеосюжетов. Один - с арией Татьяны из Онегина "Никто меня не понимает" - иллюстрировал проблемы аналитика, а второй - катастрофу с ракетой из-за ошибки транслятора Ada при переходе от 64-битных действительных к 16-битным.

Еще мне понравились доклады Артема Воробьева (Deutsche Bank) и Александра Бабкина (Motorola Mobility) о применении agile в корпоративной среде - у них в компаниях. В обоих случаях предпосылки - желание ускорить разработку приложений и желание получить обратную связь в обе стороны, дать заказчику представление о том, что разрабатываться, а программистам - реакцию заказчика на их произведение и возможность что-то скорректировать. В обоих случаях agile получился достаточно витвиеватый, встроенный в корпоративные практики и стандарты, и докладчики говорили об особенностях и деталях, о комбинации практик. В частности, в Моторолле сохранились Project Manager'ы - поскольку весь спектр обязанностей никуда не уходит, плюс корпоративная программа раннего определения PMа никого из подходящих к роли SM просто не оставляет. Но менеджеров учат делать самоорганизующиеся команды, делегировать обязанности и выступать больше арбитром. Оба говорили о необходимости аккуратного подхода к сотрудникам и сложившимся командам, которые ранее работали по другим процессам, о постепенном переходе и внедрении отдельных практик. И о том, что работающие проекты без проблем нет смысла трогать. Доклады дали возможность заглянуть внутрь корпоративных практик больших компаний, и этим интересны.

Понравились сфокусированные технические доклады.

• Автоматизированное тестирование AJAX приложений - Сергей Карпушин (Auriga). Очень сфокусировано, по делу, много практики.
• Опыт создания и развития системы диагностики в виртуализационных продуктах Parallels - Анна Воробьева (Parallels). Заглянуть в кухню отладки крайне высокотехнологичного продукта, почерпнуть идеи.
• От Only-SQL к NoSQL и YeSQL - Мики Алон (GigaSpaces Technologies). Обзор различных моделей NoSQL баз данных на хорошем уровне для не слишком знакомых с деталями людей.
• Особенности разработки облачных приложений - Аскар Рахимбердиев (МойСклад). Неплохая рефлексия создателя по опыту разработки и запуска сервиса МойСклад о том, чем отличается разработка таких сервисов от разработки обычных enterprise приложений. Оказывается - сильно, и опыт разработки enterprise-приложений местами мешал, а не помогал.

Еще были интересные доклады.

• Как спасти котов: нулевая итерация в Agile - Асхат Уразбаев (Scrumtrek, Agile Russia). Асхат, как всегда, великолепен. Он хорошо рассказал про нулевую итерацию - коллективное получение vision проекта и основных его аспектов в крупном, с которого правильно начинать работу.
• Обзор рынка заработных плат сотрудников IT компаний - Денис Каланов (IT-Dominanta). Конкретные цифры зарплат по рынку, и вроде похожие на правду или не сильно заниженные.
• Методы повышения уровня технических знаний и их особенности - Елена Беляева (Motorola Mobility). Неплохой доклад о сравнениях и особенностях работы со знаниями и вообще командной работы в центрах Мотороллы в Москве, Индии и Китае.
• Взаимоотношения сотрудник-фирма в предприятиях масштаба SME - Константин Быченков (Open Code LLC).

А еще я сегодня делал доклад на конференции. Статья с тезисами DDD - эффективный способ работы в условиях системной сложности (Максим Цепков на SECR-2011). Презентация выложена. Доклад приняли хорошо.

Началась конференция SECR-2011. Сегодня - первый день, SECR-банки. В целом соответствует моим ожиданиям. Достаточно официальная, люди в костюмах и/или при галстуках. По ощущениях человек 50-70, в двух залах смотрится пустовато, и вообще есть впечатление камерности мероприятия. Но, может, на основных днях впечатление рассеется.

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

Доклады разноплановые. Очень понравились доклады практиков о внутренних проектах - Юрия Куприянова (проект в НРД), Игоря Суздальцева (Калита-Финанс). Было интересно на докладах ИТшников - Синцова (Digital Security), Фомичева (ЦФТ), Бочкова (Luxoft). Любопытные доклады по бизнесу - Дэвид Литтл (Calypso Technology), Эрик Карпман.

Дальше краткие заметки по докладам, которые я слышал.

• Юрий Куприянов. Доклад про проект описания бизнес-процессов в НРД, возникшем после слияния НДЦ и РД ММВБ. Задача - приведение к единому знаменателю разнородных процессов, которые сложились в двух различных организациях и во многом дублируют друг друга. Они выбрали Business Studio, саратовское решение, опираясь, прежде всего, на уровень восприятия бизнесов. Был кратких обзор альтернативных решений, а также достоинств и недостатков выбранного - что интересно. За год описали примерно половину процессов НДЦ. Проблемы проекта мне примерно понятные. Из рекомендаций докладчика - пауза между пилотом и запуском массового описания на осмысление, у них - не было.
• Сергей Новиков (Новая Афина). Презентовал новый подход, который у них получился пока они писали новую АБС. Оказалось, что получаются независимые компоненты, связанные шиной web-сервисов и как-то конфигурированные компонентой описания бизнес-процессов (Lombardi или BPM Oracle). Сам продукт будет на рынке в лучшем случае в конце следующего года, так что пока все это - некоторая идея, которая у них получилась. А на уровне идеи - она весьма известна и не является чем-то новым, основная сложность тут - в удачном воплощении.
• Вильям Каннингем (Deutsche Bank). Доклад на английском, и много общих слов. Имейте передовые технологии, и клиенты к вам потянутся. И тщательно следите за рисками.
• Игорь Суздальцев (Калита-Финанс). Доклад о системе торгов на многих рынках, предоставляемого не только трейдерам, но и клиентам. В ней можно вести торговлю, ставя простых роботов (если растет нефть - покупать рубль, с деталями). Интересный доклад о внутренней разработке. Не рекламный. С демонстрацией живой системы. С шпильками в адрес ИТшников. Типа, по итогам тестов на пользователях им говорят, что надо написать надпись из 3 слов для объяснения конкретного места пользователям, а они стоят насмерть - это, мол, не юзабельно, так никто не делает. И по вендорам - был вопрос, не набежали ли с готовым решением, зачем своя разработка; ответ - набежали, но из них я бы только двоим дал делать, и с ними не сошлись в цене.
• Эрик Карпман. Рассказывал про автоматический высокоскоросной трейдинг. С трендами и деталями. На уровне общего понимания я это вполне представляю, а глубоко не занимаюсь и мне сложно оценить, было ли в докладе информация интересная для профессионала, или это было на уровне общего понимания.
• Алексей Синцов (Digital Security). Компания занимается проверкой уязвимостях в системах дистанционного банковского обслуживания. К сожалению, дырки есть в 100% решений. Через эти дыры можно добиться падения сервера, можно получить и слить информацию, можно подменить содержимое платежки, подписав ее ЭЦП клиента и показав ему то, что он вводил. И в большинстве - не какие-то сложные, а описанные в учебниках как примеры плохого кода. Которые решаются совершенно стандартными приемами, вплоть до выставления правильных ключей компиляции, предупреждающих, например, переполнение буфера. Живой рассказ, с примерами дыр и решений.
• Дэвид Литтл (Calypso Technology). Рассказ о новых изменениях, вызванных кризисом - требования центрального контрагента, гарантирующего расчеты. А сделки без него считаются рискованными и требуют большего резервирования. Интересен механизм гарантии - открытая позиция банкрота просто распределяется центральным контрагентом на всех участников рынка. Мне было профессионально интересно.
• Андрей Фомичев (ЦФТ). Рассказ о новом подходе ЦФТ, позаимствованном из другого сегмента - AppStore для Apple. Они разделили свои решения на несколько сотен приложений, устанавливаемых независимо в рамках общей платформы и выложили их как магазин, разрешив при этом оплатупосле 3 месяцев промышленного использования. Опубликовали API и позволили партнерам и клиентам тоже выкладывать свои приложения, делясь с ними доходом от продаж. И такая конструкция в целом заработала - за год число приложений выросло от 500 до 1000 и многие написаны партнерами.
• Илья Бочков (Luxoft). Доклад о конкретной разработке, позволяющей на основе технологий просмотра от Adobe Reader вести централизованный каталог документов, которые предоставляются пользователям только авторизованным в системе, в зашифрованном виде с наложением прав, ограничивающих при необходимости снятие копий, печать и даже возможность повторного открытия. Серверная часть тоже скомпонована на известных технологиях. Заказчик предоставляет это решение как сервис. Сделано за 8 месяцев после победы на тендере, в пике команда была 27 человек.
• Круглый стол по интеграции и другим проблемам. Интересны взгляды практиков из Дойчбанка, Ренессанса и других на вопросы интеграции и компонентной архитектуры. Если кратко, то это сказал Эрик Карпман - архитектура должна быть такой, чтобы внезапное решение бизнеса о внедрении того или иного продукта можно было реализовать как можно проще. Такая вот конструкция. А шина - совсем не панацея, хотя применяемая уместно - помогает.

В начале года я обнаружил интересную вещь для описания архитектуры и бизнеса в одном флаконе - Archimate, написал об этом в блоге, начал пропагандировать и пытаться использовать. И в некоторых проектах диаграммки на нем мы делали. А сам язык за это время несколько заматерел, отдельный домен archimate.org стал перенаправлением под крыло родителей - The Open Group, появились ссылки на другое их детище - TOGAF. Что, однако, не отменяет его использования в легком стиле эскизного проектирования, а не моделирования.

А сегодня в блоге Анатолия Левенчука обнаружил, что он тоже заинтересовался Архимейтом (как он его называет), начал применять и, что очень ценно - сделал хороший рассказ метода в целом и творчески перевел основные понятия. Что я всячески рекомендую. Потому как "Архимейт является одним из первых архитектурных языков, который поставил задачу совместного описания по единым принципам и в едином языке как архитектуры деятельности, так и архитектуры IT-решения." ((с) Левенчук), а нам - это очень близко.

Весной на REQ-Labs я услышал в докладе Пауля Тернера о картах компетенций в IT, которые применяются в Англии. Там была ссылка на ассоциацию SFIA (http://www.sfia.org.uk), которая этим занимается. Я тогда еще посмотрел на сайт - оказалось, материалы можно выкачать, если зарегистрироваться. И совершенно свободно использовать в своей организации, нельзя лишь оказывать коммерческие услуги на их основе без соглашения с ассоциацией. А сама ассоциация занимается стандартизацией карты компетенций в IT-отрасли в Великобритании - чтобы была общая терминология в этой области. А сама аббревиатура расшифровывается как Skills Framework for the Information Age.

На днях я зарегистрировался и выкачал материалы. 90 компетенций (skill) в 6 категориях и 20 подкатегориях, определенные по 7 уровням ответственности (впрочем, пара младших и самый старший уровень не слишком заполнены). Для компетенций и категорий есть определения, а сами уровни ответственности определены по 4 параметрам - Autonomy, Influence, Complexity, Business skills. Все это сведено в большой Excel, а также представлено в нескольких pdf-документах.

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

В прошедшую субботу был и выступал на конференции ЛАФ-2011. Было около 100 человек, из Москвы, Питера, Иваново. Самары, Краснодара, Минска и других мест. Три трека - доклады, круглые столы и мастер-классы. Как и в прошлом году, впечатление - крайне позитивное, конференция живая. Люди активно общаются, по этому признаку ее вполне можно сравнить с AgileDays. Доклады были достаточно высокого уровня, вполне сравнимы с другими хорошими конференциями.

Я выступал, снова о DDD, но с другими акцентами. Мой доклад был принят с интересом. А еще - построение учетных моделей с помощью диаграмм учета постепенно овладевает умами. Поезд из Москвы приехал в 6 утра и пока мы ждали открытия конференции, несколько человек спрашивали меня о деталях и подробностях этого подхода. В том числе - спрашивали о схемах управленческого и бухгалтерского учета расчетов с клиентами, которые были недавно опубликованы в журнале Бухгалтер и Компьютер №5 Когда всем понятно.

Из идей, интересных в контексте нашей компании стоит отметить следующее.

• Доклад Ирина Левенец - о поддержании взаимоотношений с заказчиками в условиях длительного сотрудничества. Правда, у них продуктовая разработка. а у нас - заказная. Но все равно, много общего, особенно если рассматривать различные группы пользователей как отдельных заказчиков.
• В докладе Михаил Мочалoв рассказывалось о подготовке аналитиков у них в компании. Из интересного - на входе новичкам сообщают набор блоков (об организации процессов и т.п.), по которым они должны подготовиться и сдать зачет - в форме теста или беседы. Дальше - инициатива на них, хотя есть куратор который поможет. Если не сдал - готовишься и пересдаешь, за это не отсеивают. Я тут подумал, что таким образом самого человека настраивают на активную позицию, снимают барьер, когда он стесняется задавать вопросы. Поэтому, возможно, стоит присмотреться к идее и организовать нечто подобное у нас.

Отчет о конференции ЛАФ-2011

Читая книгу, иногда записываю мысли как пост для блога, а потом - забываю опубликовать. Сегодня вот наткнулся на тезисы по мотивам Черного лебедя Талеба...

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

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

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

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

• Юферев рассказал, что к современным средствам мониторинга можно подключать внешние системы, описывая их на dsl
• Балин достаточно детально рассказывал методику управления подразделениями, сформулированную германским генштабом в 19 веке и нацеленную на достижение общих и согласованных действий в условиях, когда оперативные решения принимает командир низового подразделения по текущей обстановке. С отражением на современное управления программистами, которые рассматриваются именно как инициативные командиры. Там ряд практик, как в таких условиях надо ставить задачи, с моей точки зрения - весьма полезных.

Мой доклад прошел хорошо, вызвал достаточно много вопросов, пожалуй, больше, чем на других конференциях. И потом обсуждали. В целом практики вызывают интерес. Еще в обсуждении был интерес и к нашему ORM cis-uni.net - я свел людей с Игорем Беспальчуком.

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

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

Публикую в оперативном режиме полный отчет. Завтра к нему добавятся впечатления от тренинга Нила Мейдена.

Я попробую не только публиковать впечатления о конференции в реальном времени, но и сделать отчет. Может, он получится write only, как написали о моем отчете по REQ-labs, зато сразу. Тем более, что на 2 недели уезжаю в отпуск.

Итак, SoftwarePeople 2011, день первый.

Общее впечатление — конференция удалась. Она наиболее профессионально организована из всех тех, на которых я был за год. AgileDays-2011 и ADD-2010 мне показались более живые в части общения участников, но профессионализма им не хватает. Правда, они моложе и более дешевые, а профессионализм — он не бесплатен.

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

На конференции попробовали практику пленарных докладов, принятую на зарубежных конференциях. Она очень хороша, когда доклад — достоен. Как у Книберга на Agile Days. Реально достойный пленарный доклад — это очень сложно, потому что он должен быть комбинацией общего смысла, ценного для новых слушателей, но содержать интересные моменты, которые оценят специалисты, свободно владеющие основами. Здесь реально достойный доклад был у Мейдена, но сильно не все на таком уровне абстракции мыслят и восприняли идеи. А вот у Ютты — наоборот, популяризация, ликбез, и там нет новых мыслей и идей, которые бы были интересны специалистам. Более того, с моей точки зрения, у нее вообще не было конкретики, и шли очевидные вещи. Но в перерыве некоторые участники говорили мне, что услышав в докладе в очередной раз известную ранее вещь, они поставили себе пометку — попробовать, сказано было своевременно и подтолкнуло. Доклад Коскелы — посередине между ними. А с докладом Кристенсена по HTML5 получилось совсем неудачно — он воспринимался как технический и, в общем, таким был, и как таковой — был не интересен приличной части участников. А альтернативы не было.

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

После 4 пленарных докладов пошло два трека, и я был на people management, а не technologies. На первом докладе — потому что на техническом треке продолжил Кристенсена, пленарный доклад которого мне сильно не понравился. А потом — были очень креативные докладчики, их было интересно слушать. Возможно, на технической секции доклады тоже были креативные, то область технологий, которых они касались лично мне не слишком интересны, в то время как вопросы организации менеджмента и обучения, о которых говорили на секции менеджмента — интересны.

Отдельные мысли.

• Программисты, ваш собственный feedback на MS или Яндекс — вы просто их меньше ненавидите :) Кто хоть раз написал благодарность за новый функционал? Будьте готовы к тому же от пользователей…
• Как известно, сон разума рождает чудовищ. А коллективный разум бюрократии спит беспробудно. Ergo, стандарты — чудовищны.

Еще из любопытного. С моим докладом в печатной программе опять некоторые проблемы. Не такие, как на Agile Days-2011, где на его место сдублировали информацию по докладу из другого дня и другой секции — здесь всего лишь перепутали фамилию. Ну и бейджика докладчика на регистрации не было. Бейджик оперативно изготовили. Но вообще я бы сказал, что это энтропия бушует, потому как уже второй раз…

Дальше желающие могут посмотреть текущую версию отчета, где есть аннотации по всем сегодняшним докладам, а могут подождать полного отчета.

Причесал и опубликовал свои впечатления о ReqLabs-2011.

В целом конференция мне понравилась, подробности - читайте.

Опубликовал отчет AgileDays-2011.

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

Оценка в SP.

• Почему перешли на оценку в SP (story point)? Это — опыт. При такой оценке команда быстрее приходит к согласию, чем при оценке в идеальных днях/часах. И легче калибровать разные команды, передавать им подходы к оценке. А точность — не уменьшается. Для рефлексии о причинах падения скорости SP обычно хватает, если какая-то одна-две задачи несоразмерно выросли.
• Как первоначально получают оценку в SP? На начальной оценке release PBL берут простую и понятную всем историю, которую оценивают, например, в 3 SP или 5 SP. Получается начальный масштаб, от которого дальше пляшут. Когда переходят к оценке спринта и оценивают task, на которые поделили user story, то оценка user story задает некоторый масштаб, пока команды не привыкнут. Но при этом укладываться и подгонять не обязательно, более того у многих есть практики не показывать на планировании спринта оценки user story, во всяком случае сначала — чтобы они не влияли на оценки отдельных задач. Но в случае расхождений — разбираться, вопрос в подробностях задачи или более систематично что-то поплыло.
• Новичкам для калибровки оценок полезно посмотреть оценки предыдущих спринтов до первого планирования. И, опять-таки, оценить задачу как «похожую на ту» легче, чем прикинуть часы.

О SM

• Если кто не разделяет цели — гнать из команды. Движение должно быть сонаправленным. Размер шага (скорость) — не так важны, это тренируется, если человек разделяет цели. Ответственность за фиксацию таких проблем — на SM.
• Про SM, не смотря на много «управляющих» функций по процессу, явный акцент Книберга на самовыдвижении и отсутствии формальной власти. И SM создает условия для самоорганизации, а не управляет. Основне средство — вопрос «А что вы думаете о …» (а не «Давайте решим такую проблему…»).
• Если есть персональные проблемы, например, кто-то систематически не соблюдает стандарт кодирования и на review это вылезает, то задача SM — это выявить. Хотя на ретро об этом могут не говорить. Поговорить до ретро с членами команды, а дальше по обстановки — можно индивидуально, можно на ретро. То, что это в компетенции SM — «по умолчанию».

Процесс в целом

• Практика, когда задачу заранее готовят к выполнению, например, постановка силами той же команды или согласование с заказчиком — распространенная. И хорошая техника — вместе с DoD сделать Definition of Ready — check list, что должно быть у задачи, чтобы ее можно было запускать в спринт. Пример DoR: есть bug, grade S/M/L, есть acceptante test.
• Еще раз сформулировали — кросс-функциональная команда — не значит, что каждый заменяет каждого. Но значит, что нет критичного для процесса человека, и в целом компетенции сбалансированы с потоком задач с учетом отклонений. Техника: матрица деятельность (DB/Java/Design/Test, например) — сотрудник, на пересечении — оценка: пусто/точка/звездочка. Должно быть минимум две звездочки и несколько точек, если нет, то включаем в цели их прокачку у конкретных участников в ходе спринта за счет выполнения задач (например).
• Project Manager в смысле CMMI поделен в SCRUM примерно так:
  • release plan — PO
  • build team — SM
  • архитектура — команда
  • раздача задач — task board
  • набор персонала — за рамками команды
• Надо ограничивать количество задач, находящихся в работе. На это есть мат.модель (правда тут надо смотреть, насколько плюшевая, я готов рассказать подробности). Кратко так. Если дело проходит через несколько стадий, и на каждой имеет некоторую неопределенную трудоемкость (например, от 1 до 3), то с некоторого числа дел в работе мощность выходит на плато, но чем меньше дел в работе — тем быстрее новое дело, вкинутое на вход, появится на выходе. И это — без узкого горла. Если стадий 5, то в работе оптимально 7 начатых дел. Практически это мощное ограничение, особенно с учетом дорогого переключения контекста, и надо этим пользоваться, и того, что люди не могут одновременно держать много целей.
• Working smart more important than working hard. Не рубите деревья бензопилой, а пилите, и вообще не рубите деревья молотком. Используя SCRUM смотрите, насколько подходит.

Две команды на одном продукте.

• Итерации — рекомендуется синхронно, и общий релиз. Иначе сложно с кодом.
• Задачи на итерации делить можно на общей сессии: все задачи висят на доске, команды у них и высказывают желания, а PO — отдает. Как вариант — в каждой команде свой «локальный PO», который берет задачи от общего, так тоже можно.

Разные техники.

• Если у команды период активной поддержки, то можно резервировать на это некоторую долю времени при планировании спринта, а можно — вставлять в SBL задачи типа «фиксируем 10 самых критичных багов».
• Если возник стресс и запарка — найдите силу воли сделать паузу и проанализировать причины.
• Любопытный пример. Kanban of SCRUM, на 60 человек. Большая доска, слева область для подготовки, потом область выполнения — разбита на 4 части для отдельных scrum-команд — задача уходит на их доску, а после спринта — возвращается на общую. Впечатляет. И, возможно, на проектах с несколькими командами типа ГПБ — может быть полезным.
• Где-то всплыл сайт http://userstories.com - всякие тулы и прочее для поддержки. Может, кому интересно — даю ссылку.

Повсеместная работа с карточками меня впечатлила. Техника ведения трека через карточки, которые сначала есть в PBL, потом помещаются на мини-доску Todo/Doing/Done, а потом — в сделанное в рамках спринта может быть полезна на собраниях с повесткой дня. Я, во всяком случае, буду пробовать — если не забуду. Приоритеты — тоже через них. И bring down на планировании — user story на доске, пишем task и вешаем.

Общение с другими.

• Было много участников, успешно применяющих scrum и приехавших. чтобы улучшить опыт. Сам scrum — разный, в том числе в варианте, когда scrum master близок к менеджеру. У других — упор на PO, есть те, у кого он в команде.
• Была практика, когда один SM ведет две команды, и это — его полная загрузка, а задача его — именно наладить процесс. При этом он знает разряды сотрудников и следит за адекватным вкладу разрядом, говоря о проблемах индивидуально. На ретро или эскалируя.
• Планирование 2-недельной итерации вместе с декомпозицией story на task — полдня, 4 часа.
• SCRUM позволяет делать качественные вещи, вопрос в применяемых практиках. Например, может быть жесткое требование, что по каждой user story — пишем acceptant test (пишет или утверждает PO), который развертывают в test case. И все это делает команда.
• Есть практика тех.лидов, тоже поделенных на 2 команды и занимающихся техническими архитектурными вопросами.
• Понимание терминов — разное. Не все считают, что DoD — это общее для всех задач, некоторые используют его скорее как HowToDemo или Acceptante Test. Это надо иметь ввиду, когда общаетесь.

PO в команде, как это у нас. Не отрицается, что это возможно. И ряд участников рассказывали о положительном опыте, они тоже так делают. Почему сам Генрих не делает, мне понятно — у него основной профиль — работа с проблемными проектами, бизнес-часть там разная, соответственно, он ей не занимается, а обеспечивает процесс за счет SM. Поэтому ничего определенного на мой вопрос не сказал. Что касается моих собственных мыслей об этом (с учетом тренинга и прочего), то, думаю, для нас нынешний вариант неизбежен. Потому что заказчик хочет PO у нас, в том числе согласовывающего позиции разных stakeholder’ов с его стороны. А для этого PO должен разбираться в архитектуре и уметь давать оценки, для чего, в общем-то быть в команде. И естественно им оказывается самый сильный член команды. Теоретически это не мешает появиться еще сильному SM, и команде будет только лучше, но практически в этом случае фирма просто сделает две команды — потому что дефицит руководителей проявляется наиболее отчетливо. Однако все это не мешает работе в SM для их роста, как будущих PO, управляющих процессом, или просто сосредоточенных на тех аспектах, на которые PO не хватает.

От тренинга остались 2 книги, напечатанные и на пружинке.

• SCRUM и XP из окопов с автографом, так что только на почитать.
• SCRUM и Kanban: выжимаем максимум.

И авторский checklist по SCRUMу с градацией bottom line/core/recommended/scaling/positive indicators, он есть на его сайте.

Засим — все.