Текущая версия на 21:07, 8 апреля 2011

Конференция SoftwarePeople 2011 7-8.04.2011. Попытка сделать отчет в реальном времени.

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

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

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

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

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

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

Лично я тоже вынес несколько ценных уроков.

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

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

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

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

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

И в заключении — пара слов про анкету. Все-таки, пятибалльная оценка доклада — кошмар. Во-первых, школьные комплексы, не ставить двоек и единиц. Во-вторых — если начинаешь по первым 2-4 докладам. Что-то понравилось — ставишь 5. А потом, в середине — конце — что-то замечательное. А 6 поставить не можешь? А еще, ближе к концу я понял, что категорию «4» я бы разделил на две части — но было уже поздно, править много оценок не хотелось. Так что оставил как есть…

И отдельные мысли по мотивам докладов.

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

Что понравилось — доклады на 5

Нил Мейден (City University London) Requirements Engineering as Creative Problem Solving: New Opportunities to Improve your Practices

Хороший понятный английский, но очень быстрый, переводчик не слишком успевал. Но перевод — хороший!

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

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

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

В целом — хорошо, посмотрим что будет на тренинге.

Юрий Шиляев (EPAM Systems) Программа обучения на 50 000 человеко-часов или как отстроить образовательную программу в ИТ-компании

Доклад о практиках обучения в EPAM. По верхам — ограничение времени, но с конкретикой, и это — хорошо. EPAM организовал обучение потому как берет студентов, других кадров в нужном объеме — нет. В том году — 600 человек новых. В Белоруссии пытаются поставить образование в ВУЗах, дать заказ — ВУЗы говорят нет преподавателей. Поэтому приходится самим.

Формы.

• Open тренинг — придти может кто угодно по регистрации. Например, по SCRUM
• Workshop — когда надо обучить команду, может тому же scrum.
• Менторинг-программы. Об этом было подробнее.

Менторинг. Есть ментор-куратор. Он составляют карту экспертизы, что должны уметь люди про профилю. Группа — ментор и менти — кто учатся. Супервайзер — периодически смотрит за обучением в группах, что оно не превратилось в формальность. Для для менторов и лекторов проводят тренинги, эта отдельная программа подготовки. Самое сложное — вырвать менторов из продуктивити. Они же реально заняты в проектах, они опытные. Но они нашли способом, каким образом ментор и менти остаются в продуктивити. Лучше, когда ментор и менти из одного проекта, бывает не так, но тогда больше риски, особое внимание. Задачи обучения бывают как учебные, так и из проектов менти. Но при этом нужен постоянный прессинг куратора — продолжайте обучение, иначе сваливаются в производство.

Программа — реально длинная, 8-9 месяцев, этим отличается от тренинга на 1-2 дня. Для менти в программе минимум 8 часов, плюс 6 — выполнение заданий. И все в личное время, за это время не платят зарплату! Как университет. Никто в эту программу никого не тянет. Ресурсный менеджер и руководитель проекта — иногда одно лицо, иногда разные. Решение про обучение сотрудника принимает ресурс-менеджер. Обязательно отслеживают обратную связь и от менеджеров сотрудника по результатам обучения.

Как делать.

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

В целом система есть и работает. Принципиально нового я не услышал, но созданное — вызывает уважение.

Ольга Павлова (UsabilityLab) Менеджеры и программисты: как перестать обижаться друг на друга?

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

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

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

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

Из интересных мыслей.

• Обида — это общественное явление: дети до 2 лет не умеют обижаться, а потом учатся.
• Обида — когда есть какое-то общее дело. Выводит из того, что у людей разные представления что хорошо для общего дела. Тут я не согласен, корни обиды в разных оценках поступка, цели чаще разделяются, просто человек не подозревал про полученную интерпретацию.
• Программисты — ошибки предметны. Ошибки менеджеров — они сложно проявляются, как следствие — ненаказуемы. И потому идут обиды — виноваты всегда программисты.
• Гладить по головке — работа менеджера. Не забывайте. Остальное специалисты сделают сами. Но гладить надо искренне. А еще — высказывать уважение сотруднику, тоже искренне.
• Про ответственность. Ее должен брать тот. кого беспокоит ситуация с возможными обидами. Коллективный разум — безответственный, ему свойственно думать, что высказанные идеи таинственным образом осуществятся, и многое другое. А потом возникают обиды.
• Обиды обидами, но паранойю — не лечим.
• Вопрос: менеджер — начальник или лидер. Ответ — это не то и не другое. Без начальников, которых гоняют — можно обойтись. Но лидером быть не обязательно, не все склонны. Главное дать результат.

Александр Горник (ITCD) Когда проектов больше чем людей: процесс разработки в маленькой, но амбициозной компании

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

SCRUM внедрили перед кризисом, делал scrumtrek. Кризис заставил делать все тоже, но быстрее и эффективнее, это стимулировало. А процесс — сильно поплыл, адаптируясь к особенностям. Основное у них — очень короткие проекты. Поэтому итерации — не выжили. А еще компания — маленькая и сплоченная. Поэтому ретро тоже ушло. Зато daily scrum рулит как синхронизация. Планирование осталось в виде оценки для новых заказов. Багтрекер для управления и, главное, прозрачности. Постановки ведут в sharepoint, планируют перейти к вики. В целом — все разумно, понятно и, с моей точки зрения, у нас — пройдено.

А еще компания проводит гуманистические ценности в отношении к разработчиков. И этим очень мне импонирует.

Максим Дорофеев (Лаборатория Касперского) Если бы программы создавали также как автомобили

На этот доклад я попал в самом конце и сильно пожалел, что выбрал не его. Рассказывали о практике организации работ с конкретными примерами.

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

Асхат Уразбаев (ScrumTrek) Agile для внутренней разработки

Доклад про Agile в inhouse. В блестящей манере. С кучей хохмочек. Я слушал не сначала. Доклад для меня поверхностный, с понятными вещами. Но слушать — интересно из-за хорошей манеры изложения. И, думаю, для многих был очень полезным.

Дмитрий Сатин (Usabilitylab) Активные согласования: Как не потерять клиента и не потеряться самому в бесконечных согласованиях?

Не совсем сначала. Хороший доклад от пассионарного докладчика про взаимодействие с заказчиком. Много хороших тезисов вещей про диаграммы, интерактив и презентации, про цели проекта, в которые разработчики часто пишут всякую чушь, обратную связь, и многое другого правильного (и мне — понятного).

Приличные доклады — на 4

Тимофей Басанов (QIWI) Управление своим временем, используя пост-GTD технологии

Докладчик несколько раз пытался использовать GTD, но он развивался, появлялись приоритеты и сроки, в результате все рушилось. Я: Аллен, собственно, настойчиво предостерегает от этого в книге. А потом — прочитал книгу Today Work Control и эта технология — успешно у него прижилась для повседневных дел. С моей точки зрения — это почти чистый GTD в оперативной части. Дела ведет в outlook, 3 приоритета: 1 — сегодня. Внутри приоритета — по дате дела. Два горизонта: сегодня и «близкие дела» — неделя-две. Мелкие задачи по умолчанию ставить дальше близкого горизонта, на понедельник — и раскидывать. Дела потихоньку протухают, естественным образом опускаясь в списке по дате. Поэтому оперативно дел немного, в понедельник полчаса-час разбираешься с тем, что всплыло. Как-то так. Да, в книге 90 % воды, но краткого изложения он не нашел.

Лассе Коскела (Reaktor) Specification By Example

Доклад Коскелы — приличный, хотя пленарный доклад. Но не замечательный. Про то, что такое Specification By Example. На уровне ликбеза, но с некоторой конкретикой, которая позволит попробовать. С достоинствами метода и типичными ошибками. Но без границ применения. И без сравнения с другими методами — многие достоинства и практики присущи не только Specification By Example, они есть и в других методах, но это явно не сказано. Соответственно, для тех, кто знает широкий спектр методов доклад не слишком полезен, а многие примеры выглядят как баяны.

По сути доклада.

Четыре причины дефектов — programmer, design, req, systemic errors. Specification by example — убрать ошибки требований. Пишите для этого пример. Но в его изложении это из серии идеального заказчика и простой задачи. Потому что алгоритм на примерах не задать. Сложную работу формы — тоже не слишком задашь, если цели за рамками. Но как часть тестирования, проверки понимания — да полезно. Но тогда пишет не заказчик, он — проверяет, и именно это дает гарантию понимания — ИТ по общим описаниям от него сделали кейс и сделали верно. Это понятная конструкция. Только писать должна команда, это получается часть разработки. А он предлагает скинуть на заказчика. Это, в целом, только местами работает. На самом деле, вопрос уровня, деления между acceptance scenario and test case. Методика это дело, похоже, смешивает.

Практика — specification workshop внутри итерации. До конца итерации — distill, и на следующей — разработка. Практика общая вообще для постановок командой (мы применяем), а не только в этой.

Сергей Авдошин (ГУ ВШЭ) Формирование современных образовательных стандартов в области программной инженерии: факторы влияния

Доклад был о формировании образовательных стандартов и я пошел потому, что на параллельный доклад по ASP.NET точно не хотел, особенно услышав того же докладчика на HTML5. Докладчик рассказывал про тенденции международной (не российской!) бюрократии в области образовательных стандартов ИТ. Материалом владел. Я слушал для общего представления, делал заметки, параллельно оформлял отчет.

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

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

Что касается ВШЭ, то она движется по пути повышения качества образования, сотрудничества с иностранными университетами, ищет для этого различные формы. В общем, люди работают на международном уровне и делают что могут. Например, есть совместная программа с университетом Eindhoven (там работал Дейкстра) — два магистерских диплома. Для студента бесплатно и даже со стипендией, хотя себестоимость 17т евро. А сам университет — базовый для Phillips. Практически, думаю, таким образом привлекают наши кадры… А для них (ВШЭ) — это способ доступа к исследованиям мирового уровня, в России таких исследований нет.

Роман Юферев. Manageability — кое-что новое в словаре IT-people

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

Владислав Балин (Финам) Современные командные принципы

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

А еще очень забавно, что очень многие современные agile подходы и практики воспроизводят военные принципы управления, разработанные в конце 19 века. Докладчик этого явно не говорил как обобщение, но на примерах — показывал.

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

Александр Орлов (Happy PM) Грабли, стены и проблемы начинающих менеджеров при решении конфликтов

В целом понятный рассказ про решение проблем. Большинство реальных проблем — во взаимодействии. И их надо решать конструктивно, что означает Своевременность, Адресность, Данные и факты и Цель решить проблему, а не человека. А цикл решения — Подготовка -> Проблема -> Решение -> Контроль. Алгоритм — понятный и известный, но практическое повторение полезно. А сам доклад богато иллюстрирован кейсами и хорошо структурирован в общую рамку.

Георгий Баркан (Лаборатория Касперского) Практика и чуть-чуть философии управления требованиями

Доклад был про правильное получение требований. Про тонкую грань между Что и Как, которую надо проводить, чтобы ИТ могло предложить заказчику свои варианты, быть может, более эффективные. Заказчик очень часто склонен формулировать Что и Как вместе. Но есть прорезающий вопрос — «Зачем», с помощью которого как раз можно понять — что именно заказчику нужно, отличить, что именно он сформулировал просто потому, что ему так проще описать потребности, от того, что действительно является существенным требованиям, потому что одно и то же в одних случаях может быть жестким требованием, а может — просто способом описания потребности по аналогии с виденным. В докладе много ценных мыслей, правда, для меня — достаточно известных и из опыта и из литературы. Основные акценты — на коммуникации и не цели.

Сергей Бережной (GlobalLogic) Эффективная работа с командой Заказчика

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

Но в разговоре потом он сказал, что мысль была следующая: восприятие заказчика как бандерлогов — это нынешняя ситуация, а надо перейти к партнерству. К сожалению, так не воспринималось, поскольку были частые переключения между «есть» и «нужно» и контекст терялся. Воспринималось — от заказчика не денешься и хотя они — бандерлоги, надо смириться и налаживать сотрудничество, в целом Маугли это по плечу.

Наталья Желнова (Лаборатория Касперского) Иван Поваляев (Ситроникс Телеком Солюшенс) Внедрение ИТ-систем у зарубежных заказчиков

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

Остальное

Ютта Экстейн (Независимый эксперт) Agile by Planning Continuously

Пленарный доклад, интересный преимущественно новичкам. Это чистый ликбез по agile. Планирование и оценка на daily scrum, 2 недельные итерации поставка каждые 3-6 итераций… Мерить скорость и прочее. Причем — совсем БЕЗ конкретики. Популяризация, и там нет новых мыслей и идей, которые бы были интересны специалистам. Даже если у нее самой за этими словами стоит много конкретики и практики, но в докладе она не проявилась совершенно, даже в виде примеров. Общие слова, вода. Для проблем не только не давали решений (понятно, что многое от условий зависит) — даже не формулировали вопросы, которые правильно задать, чтобы придти к ответу.

Так что с моей точки зрения, у нее вообще шли очевидные вещи — на уровне тех умозрительных программистов, погруженных исключительно в разработку. Хотя, может я ошибаюсь, и они не умозрительны, а распространены?

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

Из любопытного — тезис «Планирование — все, планы — ничто» со ссылками на великих.

Мадс Кристенсен (Microsoft) Writing HTML5 applications using ASP.NET

С этим пленарным докладом получилась проблема. Второй доклад в 2-часовом слоте. Технический или воспринимаемый так, поэтому интересный не всем. Думаю, по HTML5 можно сделать концептуальный общезначимый доклад, и я даже на ADD-2010 видел похожий (HTML5,_CSS3_и_новый_Internet_Explorer_9_(Михаил_Черномордиков_на_ADD-2010)). Но этот доклад — весьма сумбурный, во многом — поток слабосвязанных мыслей. И сам HTML5 для него — зонтик для списка разнородных технологий.

Был живой пример — собственный сайт, куда каждый день выкладывается новая фотография. Но сайт весьма примитивный и не слишком понятно, что именно иллюстрирует. Потому что там блохи, мелочи. Которые, были бы уместны тем, кто на коленке делает собственный сайт, а не профессионалам. Да и на коленке те, кто заморачивается — гораздо более сложные конструкции делают. Хотя некоторые фонты и повороты — которых не было раньше, причем с учетом конкретных броузеров… Частные штуки никуда не уйдут, хотя что-то в стандарт и провалится.

А еще это местами антиреклама — if и структурные операторы внутри html, обрамленные <% %>… Конечно, разработчики и это съедят — а что им делать. Но на мой взгляд, это наглядная иллюстрация того, что у бюрократии разум спит беспробудно и неизбежно рождает чудовищ. Да еще копирайтеры проявились — стандартизаторы не смогли договорить вендоров на использование единого видео-формата, для каждого броузера надо подкладывать видео файл в своем формате!

По впечатлениям от стандарта у меня объединились две идеи. Как известно, сон разума рождает чудовищ. А коллективный разум бюрократии спит беспробудно. Ergo, стандарты — чудовищны.

Станислав Калканов (Luxoft) Прагматичные улучшения: инновационный подход к эффективному внедрению зрелых процессов в крупной компании

Доклад — про организацию изменений в процессы компании. Оказывается, я его слышал на Agile Days и он не слишком меня вдохновил, хотя в целом доклад — по делу. Просто вещи для меня известные, а манера изложения не вдохновляет. Я ушел на Асхата.

Сергей Поволяшко (IT Tuning) Все понятно, а идти-то куда?

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

Константин Кондратюк (ВТБ Факторинг) Владислав Балин (Финам) Взаимоотношения заказчик-исполнитель при разработке ПО

Парный доклад. К сожалению, в форме пересказа булетов. Булеты — правильные. Пересказ — по сути, с содержательными примерами. Но булетов на слайде — 6-8. А каждый рассказывают на пару абзацев. Но по сути это — чтение книги вслух. Да, книга — оригинальная и не написана. Но новых и ярких мысли в этом пересказе мало. А я плохо воспринимаю аудиокниги, увы. Тем более в конце дня конференции.

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

Заметки по докладам

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

Нил Мейден (City University London) Requirements Engineering as Creative Problem Solving: New Opportunities to Improve your Practices

Хороший понятный английский, но очень быстрый, переводчик не слишком успевал. Но перевод — хороший!

Очень хороший доклад. Креативная тема, и в целом с примерами и техниками. По отзывам — доклад многие сочли водой. Я: потому что на таком уровне абстракции не мыслят. Меня наоборот навело на многие мыслим и понравилось.

Традиционный взгляд:

• разделить req and design
• не спускаться до решений на выявлении требований
• при этом к требованиям подходить креативно — они проектируют свойства системы

Заказчик customer отражает реальность, он не представляет будущее, это — задача ИТ Я: спорно, на самом деле, хотя с научно-инженерной точки зрения понятно.

На середине проектор перестал показывать слайды, пошел синий экран… Через некоторое время достал бумаги, решил продолжить интерактивно. Тут оно пошло.

Creativity def Sternberg 1999. psihology etc 42 models of creativity

Osborn 1953 CPS (Req Eng for Creat problem solv) vs soft model

• problem undestand — goal/req
• idea generation — in soft diferent: decomposition and вывод решения, не креатив
• planing action

Я: Пошел полет своей мысли… Я: это потому, что ИТ рассматривают как некреативную область, вернее ограниченно-креативную, средства. Как строительство, когда план дома предписан, придуман, и задача — просто из материалов это сделать, доточить где конструктивно плохо получилось.

Причины — во многом в том, что решение комплексное, бизнесовую часть ИТ не знает, в лучшем случае только понимает, а значит решение — только совместное.

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

Но совместная креативность нужна, примеры вполне рабочие — из авиаперевозок, управление посадками в Хитроу и сегменты в европейском воздушном пространстве. Однако, есть подозрение, что там бизнеса много…

В Хитроу они использовали ЖД опыт — вполне продуктивно, сумев найти отображение.

Интерфейсы… Предложили много (100) идей визуализации, диспетчеры на основе вариантов дальше работали, комбинировали, оценивали… И постепенно привели

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

За 4 дня — 46 страничный отчет…

В сегментах пространства — тоже две аналогии — управление скоростными дорогами и заключение контрактов

Я: Собственно, в этом причина успеха — если участие принимают люди с широким опытом. Они мыслят, знают решения многих областей и могут их применить в новом проекте, дав бизнесам новые идеи, которые за рамками их опыта.

Инструменты — storyboards, визуальная доска, карточки. И это — эффективно, интерактив и много прочего.

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

Эффективный workshop надо хорошо готовить — сценарии, аналогии и прочее. Это — понятно.

Сейчас доски некоторым образом воспроизводятся на web — для распределенного интерактива, когда нужно..

Вопросы…

Команды — 15-20 стейкхолдеров и других экспертов

Ютта Экстейн (Независимый эксперт) Agile by Planning Continuously

Все-таки это чистый ликбез по agile. Планирование и оценка на daily scrum, 2 недельные итерации поставка каждые 3-6 итераций… Мерить скорость и прочее. Причем — совсем БЕЗ конкретики. Даже если у нее самой за этими словами стоит много конкретики и практики, но в докладе она не проявилась совершенно, даже в виде примеров. Общие слова, вода. Для проблем не только не давали решений (понятно, что многое от условий зависит) — даже не формулировали вопросы, которые правильно задать, чтобы придти к ответу. Это для тех умозрительных? программистов, погруженных исключительно в разработку. Или я ошибаюсь, и они не умозрительны, а распространены?

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

Начала с agile is buzzword…

Общие принципы. Идеализм от тоуоты?: если user не используют инструменты или процесс — bad process or tool? not user.

Не делайте слабый (начальный?) функционал сложными средствами. Но потом — добавляете технологию…

Разделение планов и процесса планирования. Процесс — важен, должен быть. Планы — вторично… Ссылки на Эйзенхауэра и Черчиля :) для заказчиков…

Как-то все сильно тривиально и обще… 12:06 может, потом по-другому будет. Работающее ПО — лучший feedback. Я было подумал, что для заказчика, в ответ на его усилия по планированию… Оказалось — для разработчиков, которые по нему могут получить отклик. :) Понятно, что на неработающее они отклика не получат. Но на работающее все тоже не просто.

Классический цикл: plan — do — inspect — adopt

Раз планирование — все давайте сделаем его ежедневным… daily scrum.

Итерации, поставка каждые 3-6 итераций… Но есть парадокс. Для больших команд — надо чаще синхронизироваться, недельные итерации. В принципе понятно, что уйдут в сторону, но накладные расходы? Я: это чисто умозрительное решение…

Классический треугольник сделали квадратом :) time scope resources quality. Надо контролировать 2 переменных, если требования позволяют. Но никогда не больше 3 (то есть все 4 не поддаются?)

Вопросы — тоже общее.

• Как определить счастье заказчика — встречайтесь, не меньше 3 раз, будет доверие — он скажет
• Как транслировать PBL в SBL — общие слова, плывет…

Лассе Коскела (Reaktor) Specification By Example

15' Похоже, ликбезный докладл на основе отвлеченной метафоры… Посмотрим.

20' пошли цитаты и потихоньку переходим к делу

30' у меня пошли собственные мысли по теме — хорошо. Потом я понял ограничения методики в его изложении — для простых областей и кейсов…

40' сказал, что рассмотрели процесс. на самом деле формльно. перешел к ошибкам, и баяны — типа, сотрудничество нужно

TDD.

Началось все с тривиальное примера. Алгебра как простая арифметика 1+2=3 :) Против традиционного формального описания.

Ролик про разружение на уничтожение самолета, которое произошло при нагрузках свыше расчетных — успешные испытания. И вопрос, что из этого следует, про 3 вещи — specification validation verification. Кстати, в приведенном примере validation отсутствовал…

4 причины дефектов — programmer, design, req, systemic errors

Eliminate req errors — Spec by example.

Пишите пример. Я: все-таки это из серии идеального заказчика и простой задачи. Алгоритм на примерах не задать. Сложную работу формы — тоже не слишком задашь, если цели за рамками. Но как часть тестирования, проерки понимания — да полезно. Но пишет не заказчик, он — проверяет, и они дают ему гарантию понимания. Это понятная конструкция. Только писать должна команда, это получается часть разработки. А он предлагает скинуть на заказчика. Это, в целом, только местами работает. На самом деле, вопрос уровня, деления между acceptance scenario and test case. Методика это дело, похоже, смешивает.

Практика — specification workshop внутри итерации. До конца итерации — distill, и на следующей — разработка. Практика общая вообще для постановок командой (мы применяем), а не только в этой.

4 квадратика в другой разбивке. Одна ось — бизнес-технология, вторая — support coding vs critique product. Я: Какие-то странные дихотомии, почему именно такое различие? Он спросил с места, пошли ответы что зависит от контекста. В целом как-то не поняли.

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

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

В общем-то народ в вопросах скорее делился своим опытом. Некоторые даже в вопросы не переходили.

Мадс Кристенсен (Microsoft) Writing HTML5 applications using ASP.NET

С докладом получилась проблема. Второй доклад в 2-часовом слоте. Технический или воспринимаемый так, поэтому интересный не всем.

Наверное, по HTML5 можно сделать концептуальный общезначимый доклад, и я даже на ADD-2010 видел похожий (ссылка). Но этот доклад — весьма сумбурный, во многом — поток слабосвязанных мыслей. Увы!

W3C — в мае 2011 прекращает прием предложений, и до 2014 года стабилизирует!

15' всякая общие вещи. Дальше перешел к конкретным возможностям — как мозаика, без концепций.

Идея — html5 — зонтик для списка разнородных технологий. И именно так представлялось.

Был живой пример — собственный сайт, куда каждый день выкладывается новая фотография. Но сайт весьма примтивный и не слишком понятно, что именно иллюстрирует. Потому что там блохи, мелочи. Которые, скорее. были бы уместны тем, кто на коленке делает собственный сайт, а не профессионалам. Да и на коленке те, кто заморачивается — гораздо более сложные конструкции делают. Хотя некоторые фонты и повороты — которых не было раньше, причем с учетом конкретных броузеров… Частные штуки никуда не уйдут, хотя чсто-то в стандарт и провалится.

А еще это местами антиреклама — if и структурные операторы внутри html, обрамленные <% %>… Конечно, разработчики и это съедят — а что им делать. Но на мой взгляд, это наглядная иллюстрация того. что у бюрократии разум спит беспробудно и неизбежно рождает чудовищ. Да еще копирайтеры проявились — стандартизаторы не смогли договорить вендоров на использование единого видео-формата, для каждого броузера надо подкладывать видео файл в своем формате!

Сергей Авдошин (ГУ ВШЭ) Формирование современных образовательных стандартов в области программной инженерии: факторы влияния

Доклад был о формировании образовательных стандартов и я пошел потому, что на параллельный доклад по ASP.NET точно не хотел, особенно услышав того же докладчика на HTML5. Докладчик рассказывал про тенденции международной (не российской!) бюрократии в области образовательных стандартов ИТ. Материалом владее. Я слушал для общего представления, делал заметки, параллельно оформлял отчет.

Вместе с Тереховым занимаются стандартами образования у нас. Основывают на SVEbok. Нужна международная аккредитация. Програмная инженирия вписывается в общую системную инженерию.

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

Сертификация в международном масштабе цветет и пахнет. В России не слишком, что докладчика огорчает, а меня радует — пока не успели, хотя особых надежд, что оно рухнет — я не испытываю. Флагман у нас по многим вопросам — IBS.

Во ВШЭ они выдают выпускникам сертификаты от IEEE, сертифицирует центр на западе, они готовят. В программу включены семинары, и обделенные специальности — тоже холтят. В принципе, деятельность полезная.

Проф.стандарты АП КИТ — используют. Программиста и Системного архитектора.

Совместная программа с университетом Eindhoven (там работал Дейкстра) — два магистерских диплома. Что важно — для студента бесплатно и даже со стипендией, хотя себестоимость 17т евро. Вообще университет — базовый для Phillips. Практически, думаю, таким образом привлекают наши кадры… А для них (ВШЭ) — это способ доступа к исследованиям мирового уровня, в России этого нет.

Опять про журнал Програмная инженирия, ВАК.

Юрий Шиляев (EPAM Systems) Программа обучения на 50 000 человеко-часов или как отстроить образовательную программу в ИТ-компании

История. Он пару лет назад услышал про обучение в EPAM, он и Петелин там еще не работали. Слушатели не верили про бесплатное обучение без обязанностей. Думали, что будут ломиться на обучение и уходить. По факту — нет, люди не ломятся. Теперь он руководит программой обучения (Петелин — его руководитель).

Нанимают студенты — других кадров нет. 600 за год. Проводят кучу тренингов — чтобы работало. Компания в компании, внутренний заказ на обучение — вместе с Петелиным.

Есть -

• Open тренинг — придти может кто угодно по регистрации. Например, по SCRUM
• Workshop — когда надо обучить команду, может тому же scrum.
• Менторинг-программы.

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

Тренинги для менторов и лекторов — эта отдельная программа подготовки.

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

Программа — реально длинная, 8-9 месяцев. Для менти в программе минимум 8 часов, плюс 6 — выполнение заданий. И все в личное время, за это время не платят зарплату! Как университет. Никто в эту программу никого не тянет.

Цикл Деминга Шухарда 1940-х — о котором все забыли, инкапсулировав в современные практики.

Сетевой график занятости групп и сотрудников. Динамика… Плюсы и минусы. Видно, например, когда куратор ушла в отпуск.

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

Как делать

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

Тренинг — короткая программа, день-два. В отличие от менторинга, который длительный. Хорошо, когда ментор и менти из одного проекта, бывает не так, но тогда больше риски, особое внимание.

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

В Белоруссии пытаются поставить образование в ВУЗах, дать заказ — Вузы отвергают, говорят нет препов.

Ольга Павлова (UsabilityLab) Менеджеры и программисты: как перестать обижаться друг на друга?

Все делятся на обобщенных менеджеров и обобщенных программистов

Обида. Дети до 2 лет не умеют обижаться. Потом учатся — это часть общества.

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

Я: тут она неправа. Корни обиды в разных целях. А дальше — интерпретация поступков в обидном смысле, по-другому… Хотя, мложет. стоит поразмышлять.

Программисты — ошибки предметны. Ошибки менеджеров — они сложно проявляются, как следствие — ненаказуемы. И потому идут обиды — виноваты всегда программисты. Я: программисты они только баги плодят, а на благо проекта не работают.

Результат работы хорошего менеджера — не заметен Я: нерпавильно. Это работа не заметна (и пример был о том же). Результат-продукт отдается команде, но менеджер то с ней :)

Ситуации обиды. Менеджер к программисту объясняет, то ему — «напиши». Обратно — программист написал (много), менеджеру некогда прочесть. «Я к тебе со всей душой…»

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

Гладить по головке — работа менеджера. Не забывайте. Остальное специалисты сделают сами.

Про ответственность. Важно его брать. Коллективный разум — безответственный. Ему свойственно думать, что высказанные идеи таинственным образом осуществяться. И многое другое.

Изменения постановок. Если пришлось менять — ответственны вы (менеджер), а не звезды. Каждый должен принять решение, что делает, а что не делает.

Если держите задачу «исправить ошибку» — делайте по-человечески.

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

Спасибо надо говорить честно, искренне чувствуя. Не провформа. И запоминать.

Защищайте программистов! Не спускать напрямую недовольство топов…

Тот, кто не хочет разбираться, но дает ценные указания — не менеджер.

Менеджер не должен кодлировать в уголке ради установления отношений — все равно не обманешь, если этого внутри нет.

Вопрос: Кто должен брать ответственность? Ответ: Тот кого заботит отсутствие обид.

Пара вопросов — мини выступлений… Типа несогласных или альтернатив. Напрмиер — что вас обиды мучают.

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

Паранойю — не лечим.

Вопрос: менеджер — начальник или лидер. Ответ — это не то и не другое. Без начальников, которых гоняют — можно обойтись. Но лидером быть не обязательно, не все склонны. Главное дать результат.

Роман Юферев. Manageability — кое-что новое в словаре IT-people

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

Разработчик и Владелец. Разработчик создает ПО, Владелец платит деньги.

Но чтобы замкнуть цикл — софт надо продать/развернуть

Но еще есть админы — те, кто сопровождает это ПО и то железо, на которых это стоит. Которые тоже хотят денег. За что? Собственно, за сопровождения. И сложность сопровождения напрямую влияет на стоимость этого процесса.

Managability — это насколько софт приспособлен к сопровождению.

Это включает развертывание, обновление, баги, резервирование и, главное — отказы. И это — серьезная проблема.

Если ПО плохо приспособлено для сопровождения, то админам надо платить дорого. Плюс есть много проблем.

Модель здорового приложения.

• Отказ
• Симптом — определение конкретного отказа
• Рецепт решения.

Метафора — модель здорового человека. И это не простая модель. А еще она различается для разных приложений, хотя есть много общего (скелет у большинства есть и органы дыхания тоже).

Нужны инструментальные средства. Логи, диагностика и прочее. А еще нужны средства мониторинга, для раннего предупреждения, чтобы для отказов не доходило.

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

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

Александр Горник (ITCD) Когда проектов больше чем людей: процесс разработки в маленькой, но амбициозной компании

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

SCRUM внедрили перед кризисом, делал scrumtrek. Кризис заставил делатиь все тоже, но быстрее и эффективнее, это стимулировало. А процесс — сильно поплыл, адаптируясь к особенностям. Основное у них — очень короткие проекты. Поэтому итерации — не выжили. А еще компания — маленькая и сплоченная. Поэтому ретро тоже ушло. Зато daily scrum рулит как синхронизация. Планирование осталось в виде оценки для новых заказов. Багтрекер для управления и, главное, прозрачности. Постановки ведут в sharepoint, планируют перейти к вики. В целом — все разумно, понятно и, с моей точки зрения, у нас — пройдено.

А еще компания проводит гумманистические ценности в отношении к разработчиков. И этим очень мне импонирует.

Заметки.

Маленькая компания, была не ИТ — провайдер услуг. Теперь — web, разные промоакции типа послать смс. Много быстрых мелких проектов.

Все сильно типовое — есть желание сделать продукт. Но без инвестиций, самоокупаемость. Сейчас продукт есть, 2-4к транзакций в сек. 100к кода, 7 разработчиков держат 5 продакшн. Новый продукт — 2 дня, начинали с двух чел на 2 месяца.

2008 внедрен скрам от скрам-трек. На его взгляд — самый разумный процесс. Джоэл…

Потом — кризис. Потребовалось делать тоже самое, но быстрее — процесс эволюционировал.

PO — account manager, под генеральным. В команде — тех.лиды и SM. они под техническим директором. PO — не начальник разработки, это важно.

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

Сначала — растили менеджеров., и единая ответственность. Но практика — менеджер не может быть технически полдкован, преимущественно общается с клиентом и так далее. Поэтому нужен технический лидер внутри. Но PO должен сохранять ответственность за продукт.

Менеджеры внутри компании менее мотивированы бороться за продукт, чем клиент.

Тестеры — это здорово. Но без них тоже получается.

Практики менеджера: все в багтреккер, оценивает только разработчик, документы в общем доступе а не в почте (сейчас SharePoint, будут внедрять wiki — удобнее).

Менеджер основное — разруливать конфликты. Ты не начальник, но конфликт — твоя проблема.

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

Они полностью обелили зарплату. Это давление, но повышает эффективность.

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

Зато есть прозрачность и ответственность, потому что продукт сразу идет в продакшн. Но Демо при этом ушли как не нужные. Опять-таки, может вернуться в длительной команде — для распространения знаний.

Ретроспективы — тоже сошли на нет. Я: это понятно — маленькая компания. Но с ростом могут вернуться.

Daily scrum — очень полезный, расширился — менеджеры тоже встречаются.

Планирование. Итераций нет, но планирование с planing poker — есть, когда планирует новую акцию, новый продукт. А еще в багтрекере ведут и estimate и факт.

Спецификации — клиенту, office + sharepoint. Объем минимизировали usecase. По шаблону Джоэла (joel) — перевели его на русский и используют. Painess…

Планируют перейти в вики, FB + … + Balsamiq — чтобы править сразу, рисовать uml и прототипы интерфейсов.

timeshhets, wirking on, work in progress. Факт в багтрекере нормируется на нормо-часы, можно посчитать стоимость. По новым людям — хотят измерять velocity и персонально.

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

Joel test. Я: Кстати, с joel-тестом у нас все хорошо.

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

17 человек. PO 4 в компании, каждый ведет несколько проектов. Передача работает — отпуска, болезни и прочее.

Действия — прозрачны.

4 года 150 промоакций — обычно успевают. Отстаивают тайминг и прочее. Реально многое происходит в последний момент. Но тогда они двигают scope: диазйн не во-время — к сроку стартует одна страничка и смс-обработчик, остальное позднее, но это обосновано и заказчик тоже понимает. Пока нормально.

Качество в целом устраивает. Тестировщика не берут, потому что очень много требований, не представляет что такого найдут, поэтому менеджеры понемногу…

Владислав Балин (Финам) Cовременные командные принципы

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

А еще очень забавно, что очень многие современные agile подходы и практики воспроизводят военные принципы управления, разработанные в концне 19 века. Докладчик этого явно не говорил как обобщение, но на примерах — показывал.

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

Классический микроменеджмент не работает. Потому что сложность, ограниченность информации и прочее.

Но немцы в армии 100 лет назад уже придумали способ борьбы с этим. Там обстановка меняется, а указания ждать неверно.

• Ставится цель
• Детали описываются только в 2 случаях: когда нужна координация и когда есть внешние ограничения. В остальном — инициатива исполнителя. И надо быть готовым к этому.

Если пошло не так — делят CCIR, что действительно надо доложить срочно, это должно быть выработано.

Исполнитель должен пытаться решить проблему не ожидая указаний. Бездействие недопустьимо.

Но вопрос о доверии…

Приказ в 5 параграфах.

• Ситуация. Цели. Что делают соседи и сверху. В чем проблема (действия противника). Риски, развитие ситуации.
• Execution. Намерение руководителя — Что. Замысел операции — Как. Назначение — кто за что отвечает.

Все повторяется на всех уровнях.

Защита от микроменеджмента — руководителю запрещено навязывать «как»

Разработка ПО похоже на разработку железа. Аналогии.

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

Матричную структуру он знает, но эффективно практическую не видело ни разу.

FDD — по фичам. Работает хорошо, особенно на поддержке и развитии. И под доработки на нескольких структурных единиц делаем временную рабочую группу — эффективно. Я: любопытно, можно подумать.

Chef Programmenr Team — в 70-х в IBM. Брукс рекламирует как бригаду хирурга, забыл сказать про авторство.

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

Матрицы — на самом деле есть области, где они работают. Но большой системе — не слишком.

Планирование: время тоже ресурс, внешнее ограничение в постановке задачи.

Работает по ГОСТу — он не предъявляет требований к процессу, он описывает во взаимодействии с заказчиком.

Александр Орлов (Happy PM) Грабли, стены и проблемы начинающих менеджеров при решении конфликтов

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

Черная книга менеджера. Он закончил белую книгу менеджера, через неделю, думает, появится в свободном доступе.

Биография — Sun, потом Intel. Сейчас собственный проект — для тех, кто хочет стать менеджерами и клуб тренеров.

Было задание — разорбрать пробленый кейс. Проверяя прочел 170 штук. Плюс на конференции подходят. И доклад — обобщение всего этого.

Конструктивное решение проблемы

• Своевременность
• Адресность
• Данные и факты
• Цель: решить проблему, а не человека

Подготовка -> Проблема -> Решение -> Контроль

Проблема и Решение — один этап, обсуждение.

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

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

Еще кейс, когда ПМ тайком пишет альтернативную версию кода… Надо понимать, почему.

Максим Дорофеев (Лаборатория Касперского) Если бы программы создавали также как автомобили

На этот доклад я попал в самом конце и сильно пожалел, что выбрал не его. Рассказывали о практике организации работ с конкретными примерами.

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

Станислав Калканов (Luxoft) Прагматичные улучшения: инновационный подход к эффективному внедрению зрелых процессов в крупной компании

Доклад — про организацию изменений в процессы компании. Оказывается, я его слышал на Agile Days и он не слишком меня вдохновил, хотя в целом доклад — по делу. Просто вещи для меня известные, а манера изложения не вдохновляет. Я ушел на Асхата.

Асхат Уразбаев (ScrumTrek) Agile для внутренней разработки

Доклад про Agile в inhouse. В блестящей манере. С кучей хохмочек. Я слушал не сначала. Доклад для меня поверхностный, с понятными вещами. Но слушать — интересно из-за хорошей манеры изложения. И, думаю. для многих был очень полезным.

Разработчик наносит ответный удар.

• Согласование требований
• Комитет по согласованию изменений
• И прочее…

И люди окапываются. Бюрократизация процесса. В общем-то эффект понятный. Agile дает с этим методы борьбы.

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

Практически — стараются превратить разработку в сервис для бизнеса. Тогда проблемы проявляются. Они выстраивают разработку, и agile — способ. Сервисная разработка возможна только когда с delivery все в порядке. Agile как эксперимент, пробуем отдельные практики. У руководства получаем зеленый свет на изменения, это дает ответ на вопрос «почему меняем» — потому что руководство сказало. Не страшно, если дали только середину цепочки — если ее улучшить, проявятся проблемы краев..

Георгий Баркан (Лаборатория Касперского) Практика и чуть-чуть философии управления требованиями

Доклад был про правильное получение требований. Про тонкую грань между Что и Как, которую надо проводить, чтобы ИТ могло предложить заказчику свои варианты, быть может, более эффективные. Заказчик очень часто склонен формулировать Что и Как вместе. Но есть прорезающий вопрос — «Зачем», с помощью которого как раз можно понять — что именно заказчику нужно, отличить, что именно он сформулировал просто потому, что ему так проще описать потребности, от того, что действительно является существенным требованиям. потому что одно и то же в одних случаях может быть жестким требованием, а может — просто способом описания потребности по аналогии с виденым. В докладе много ценных мыслей, правда, для меня — достаточно известных и из опыта и из литературы.

Где тонкая грань между Что и Как?

Методологи говорят, важно Что, это — требования, а Как — уже дизайн…

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

Вопрос Зачем поэтому очень важен. Особенно потому, что он позволяет понять косвенные, невысказанные требования, которые он часто считает очевидным.

Если заказная разработка — вопрос заказчику. Если собственная — Зачем тиоже актуально, и хороший продукт, есть мнение, получится только если представляешь ответ.

Кейс — заказная разработка, в каждой системе учетные записи пользователей. Долго не могли понять, почему надо строить соответствие, а не просто держать одинаковую запись. После разборов на месте, выяснили, что у заказчика есть 5-6 тетушек, которые вводили записи в разные системы, и если запись общая — отдел уйдет. А заказчик — менеджер этого отдела. Отдел остался «заказчик всегда прав», сделали сложную систему.

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

Коммуникация — важно, письмами не заменишь. Активное слушание. Social Engeneering методика.

Фиксация требований. Единственная цель — добиться однозначного понимания. На нее не надо традить чрезмерно много усилий. И не надо заморачиваться на форматы. Особенно не надо нагибать заказчика на свой формат.

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

Книжка «Сначал скажите нет» Джим Кемп. Стратегии win-win на самом деле нет, компромисс — уступки для обоих. Стоит это понять, переговоры упрощаются.

Триаж требований — по аналогии с триаж, сортировкой, раненых на месте бедствия.

Сортируйтие требовани я. В контексте версий: не «нет», а «в следующей версии».

TED. How great leaders inspire action.

Как заключение. Apple. Хочет сделать мир лучше. И цель — должна быть.

Сергей Поволяшко (IT Tuning) Все понятно, а идти-то куда?

Компания проходила сертификацию CMMI 3 уровня, он этот процесс прошел.

Доклад — про собственные опыт компании. Компания занимается заказной разработкой, аутсорсом. Задача трансляции задачи получения прибыли она операционный уровень. То, о чем рассказывает — на разной стадии внедрения.

Цель рассматривается финансово. Увеличить прибыль в 2 раза (например) в 2010 году. Оговаривается, что цифры — для примера. Тупой способ — увеличить оборот в 2 раза. Но еще можно сократить расходы, сокращение расходов на 5 % дает приличное увеличение прибыли (в примере — 40 % к началу года).

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

Сергей Бережной (GlobalLogic) Эффективная работа с командой Заказчика

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

Принцип Маугли «Мы с тобой одной крови».

Сотрудничать, дополнять и помогать друг другу.

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

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

Поощрять идеи и начинания представителей заказчика.

Хвалить. В том числе за имсполнение обещаний. Особенно в срок. Касаток именно так дрессируют — конфетками, бить их нельзя. Я: обидное сравнение заказчиков с касатками, или бандер-логами.

Не критикуем, а предлагаем. Искать как сделать, искать проблемы — вместо объяснения, почему так сделать нельзя.

В штатах заказчику прислали торт на заказ. 100$, а отношение поменялось принципиально.

Не говорите о себе, говорите о пользователе. Решайте бизнес-кейсы.

Константин Кондратюк (ВТБ Факторинг) Владислав Балин (Финам) Взаимоотношения заказчик-исполнитель при разработке ПО

Парный доклад. К сожалению, в форме пересказа булетов. Булеты — правильные. Пересказ — по сути, с содержательными примерами. Но булетов на слайде — 6-8. А каждый рассказывают на пару абзацев. Но по сути это — чтение книги вслух. Да, книга — оригинальная и не написана. Но новых и ярких мысли в этом пересказе мало. А я плохо воспринимаю аудиокниги, увы. Тем более в конце дня конференции.

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

Паспорт проекта. Цели, зачем проект. Кто заказчик. Альтернативы.

Сарафанное радио рулит…

Наталья Желнова (Лаборатория Касперского) Иван Поваляев (Ситроникс Телеком Солюшенс) Внедрение ИТ-систем у зарубежных заказчиков

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

На входе был жуткий конгломерат требований. Побили систему на области, по каждой пошли работать отдельно.

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

Роль аналитика поделили на бизнесов и системных — бизнеса работали у заказчика, системные — с командой. Следствие удаленности.

Большая текучка персонала заказчика — договариваешься с одним, а сдаешь другому. Описываешь бизнес языком, подписываешь с руководителями департаментов.

Проблемы с ТЗ

• Традиционно забыали про отчеты, сосредотачивались на функциональной части
• Некачественный feedback. Документ не читают. Боролись выдачей порциями и более предметными обсуждениями. Полевые исселдования как есть сейчас.
• Различия налогового законодательства, особенности, например, богатые промоакции.
• Способ решения — мониторинг текущей системы. Например, в Белорусии многие использут телефон в стиле положил 10р — позвонил. И очень большой поток мелких платежей.
• Общий глоссарий

Не игнорировать культурные различия, специфику. Например, у индусов нормально назначить митингш на 9, придти в 9:30. Полезно с заказчиком об этом поговорить — дополнительно он почуствует себя гуру, это улучшит взаимопонимание.

Еще местные праздники, которые не совпадают. И многие вещи типа самолетов.

Человек больше полугода в командировке — 30 % налог :) И зарплата по средней.

Дмитрий Сатин (Usabilitylab) Активные согласования: Как не потерять клиента и не потеряться самому в бесконечных согласованиях?

Не совсем сначала. Хороший доклад от пассионарного докладчика про взаимодействие с заказчиком. Много хороших тезисов вещей про диаграммы, интерактив и презентации, про цели проекта, в которые разработчики часто пишут всякую чушь, обратную связь, и многое другого правильного (и мне — понятного).

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

Ложное мнение «интерфейс — 5 %». Поэтому архитекторы не заморачиваются.

Кейс — посмотрел ТЗ, задал тупой вопрос — почему две формы, а не одна — и обсуждение на 40 минут про архитектуру, а овсе не про интерфейс.

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

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

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

Надо представлять клиенту результаты прроектирования и работы, интерактив, а не переписка. Личные коммуникации. Как только в переписке идут непонятки, надо встречаться лично.

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

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

• Да, разумно
• Не понял обсудите со мной отдельно
• Вы идиоты, я резко против

И собрать это сразу. Чтобы потом они не обсуждали отдельно без них.

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

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

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

Распухание требований — соотносить с целями проекта в целом…

ТЗ не должно ходить по рукам. Его надо самому презентовать заказчику, объяснять.

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

Майстер профессиональные услуги.