|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
Максим Цепков - AgileDays-2011Материал из CustisWikiСодержание
Общее впечатлениеОбщее впечатление — конференция очень живая. Народу много и он — активный, ищущий. И много разработчиков. в том числе — сильных. Собственно, они хотят продолжать заниматься разработкой, во всяком случае в значительной мере, и agile для них — средство это делать, не становясь в значительной степени менеджерами. При чем у большинства — получается, но они ищут пути улучшения. Соответственно, при таком составе слушателей востребованы не только управленческие доклады о процессе, но и технологические — если ты говоришь что-то новое и интересное. А еще общаясь с участниками можно узнать что-то новое, обсудить детали. И это — полезно. Кстати, среди участников активно появляется in house. Не только Дойч, но и альфа-банк и Сбер, и из ВНИИХТ (вроде) Росатома тоже были. То есть в эту сторону смотрят. А еще — была пара компаний, работающих на запад с продуктовой разработкой, поставляющих решения для нашего сегмента — крупных хедж-фондов и страховых компаний, и общение — достаточно любопытно. Теперь о докладах. В целом уровень докладов достаточно высокий. И я не буду ставить оценки, потому что они становятся малозначащими, линеаризация получается ложной. Потому что если один доклад был со сложными мыслями, который автор не смог донести достаточно прозрачно и с блеском, а в другом — мысли были проще, зато манера изложения — лучше, то оценка ничего не скажет. Понятно, что она будет не высшей, потому что каждый доклад можно улучшить, но ведь улучшить можно почти любой доклад. Три доклада мне понравились очень сильно, что, впрочем, было ожидаемо: доклад Хенрика Книберга и оба доклада Андрея Бибичева, особенно второй, в lighting talk, про пуассоново горение сроков. Доклады можно разделить на две больших категории. Один — доклады достаточно опытных людей, которые имеют большой опыт и в своем докладе осмысливают и обобщают его, взяв определенный аспект — потому что объем ограничен и изложить опыт можно лишь сузив тему. И вторая категория — это доклады людей с гораздо меньшим опытом, которые рассказывают о своих успехах. Это менее интересно для опытных людей, тут нет обобщений, зато есть детали и конкретные случаи, из которых можно делать выводы. Кстати, докладчик может обладать большим опытом в целом, и только предметом доклада заниматься относительно недавно. Заметки по докладам у меня поделены именно так. Вообще для людей с приличным опытом, давно и успешно делающих проекты, ни один доклад конференции не может быть откровением, которое укажет решение каких-то проблем или научит жизни. Однако, детали и мысли — могут послужить толчком к размышлениям, дать новый взгляд. Кроме того, на конференции можно оценить тренды отрасли в целом. И если многие говорят о какой-то практике как о вполне работающей, то у тебя есть повод задуматься. Особенно, если она вроде решает те проблемы, которые имеются. Конечно, она вполне может оказаться не слишком применимой ввиду других особенностей процесса в компании, или сами решаемые проблемы могут не слишком нуждаться в решении, но в этом случае стоит явно все это сформулировать. И еще несколько совершенно общих замечаний
О наших докладахМой доклад в целом прошел нормально. Интересно, что в печатной программе конференции его пропустили, поставив дубль доклада из первого дня с другого трека. Почему — не понятно, я бы возгордясь, утверждал. что это энтропия сопротивляется. Что приятно — в первый день, пока это не поправили в вывешенных программах, меня пара человек спрашивала, будет ли доклад. В целом впечатление было хорошее, и после доклада мы общаслись в коридоре с интересующимися. Доклад Коли Гребнева я слушал, в целом принимали хорошо. Хотя, на мой взгляд, там был слишком большой уклон в показ россыпи вариантов, какая распределенность бывает, а анализа картины несколько недостаточно. На докладе Олега Клинчаева я не был, но вроде он вызвал интерес, во всяком случае после него в коридоре Олег общался со слушателями. Доклады опытныхИтак, доклады опытных — тех, кто обобщил опыт многих проектов и делится им с иллюстрациями. Хенрик Книберг. Everyone likes change, but nobody likes to be changedПрезентация в блоге Хенрика. Доклад был интересен для меня, несмотря на тренинг. Потому что дал обзор верхнего уровня по очень разным областям и подвел итоги. В целом — хороший обзорный доклад профессионала и в предмете и в докладах. Россыпь практик: тезис — объяснение — пример, коротко и просто. С моей точки зрения, можно учиться, как делать доклады и презентации. Дальше — записанные тезисы.
Андрей Бибичев. Архитектура в Agile: переосмысляя идею модульности и компонентностиКак всегда замечательный и содержательный доклад по уменьшению связности объектов. К сожалению, мне пришлось стоять потому что зал был очень полным. Соответственно, я не конспектировал. Если говорить о предмете доклада, то он весьма актуальный — как уменьшать связность фрагментов при реализации систем, чтобы обеспечить их независимость и устойчивость системы в целом при развитии. Какие есть принципы, и как с их точки зрения оцениваются те или иные design pattern. А сам вопрос весьма важный для динамично развивающихся систем, потому что именно хорошая изоляция обеспечивает возможность достаточно безболезненного развития функционала. На мой взгляд, это именно то обобщение опыта и рекомендации, которых не слишком много в книгах — как выбрать те или иные шаблоны, и что они за собой несут. Андрей Бибичев. Пуассоновое горение сроковПри оценках сроков закладываемся в 2-3 раза. Почему это правильно? Мы оцениваем наиболее вероятный срок, но, естественно, можем ошибаться. Интересный вопрос — как распределена вероятность сроков с учетом ошибки. Вовсе не по нормальному закону. Если распределение нормальное, то девиация примерно как оценка. Значит с вероятностью 16 % мы это уже сделали и должны денег. А это не так, сроки обычно оказываются больше. Значит, распределение другое.
Общее — кривая не симметрична. Меньше — почти не бывает. А больше — большая область. И из-за не симметрии вероятность успеть до максимума оценки всего 10-15 %. Так что правильно оценивать — X плюс X или 2X. И еще останется 5 % что не прав. А 5 % — это не так мало, каждый двадцатый. Посчитайте, при недельной итерации — как оно. Антон Кекс. Недостающая часть Scrum: как стать успешным инженером в Agile?Из Эстонии. Основатель и глава фирмы. Хороший обзор, но для новичков.
Стас Фомин: «Максимизировать несделанной работы» — явно что-то не так.
вроде для новичков — ушел потом вернулся — когда игры кончились
Сергей Дмитриев Ретроспективы. Настраиваем наш процесс разработкиЯ был недолго. Изложение не слишком системно, он не успел.
Максим Гапонов. Иду по приборам! Практические советы по визуализации работЯ слушал не сначала. Народ не влезал. Изложение не слишком гладко, зато паузы и шутки. Но где-то на 2/3 доклада народ начал уходить, правда, может потому что начинался другой доклад. Но, в любом случае Максиму не хватило репетиции изложения и это весьма сказалось на докладе. Стас Фомин: Вообще-то, этот доклад Максим уже докладывал на AgileBaseCamp во Львове
Доклад был о проблемах понимания, вернее, неверного понимания с разных сторон, моделях и историях вокруг этого. И, особенно — средствах визуализации. Заметки.
Анна Обухова. Agile Distribution Risk Score — планируйте распределенность осознанноСлушал примерно вторую половину доклада. Как-то скучновато: кейсы команда может быть распределена по-разному — в разных офисах, городах и странах. То есть просто набор кейсов, некоторые детали для каждого, которые, с моей точки зрения, достаточно очевидны. В общем-то еще на середине доклада была разборка, что и как бывает. Впечатление, что в компании умеют организовывать распределенную разработку, причем в разных вариантах, однако вербализация и проявление принципов, которые лежат за этим — не удалась. Заметки.
Сергей Дмитриев. Командный стартВесьма замечательный тренинг. Вещи мне известные и понятные в нашей компании, в частности откуда зарабатываются деньги и прочее, однако далеко не всем они столь известны, так что большинству участников все это было полезно и многим ново. Но я заходил очень фрагментарно, и зашел на финал. В целом — много полезных тезисов, много той убежденности, которая заражает. Идея Сергея — в создании суперпродуктивных команд, которые бы показали экстра-результат, превосходящий средний в десятки. На самом деле, для таких команд надо подбирать сбалансированный состав людей, это экспериментально проверено, и военные, например, этим пользуются. Известные исследования Белбина на эту тему. В том числе, Белбин показал, что моральный дух не коррелирует с результатами команды, а Сергей многое ставит именно на него. Правда, для долговременных команд дух существенно необходим, иначе они просто разбегуться. Заметки.
Константин Гурнов. Enterprise Scale Agile. Lessons learnedРуководит развитием agile в люксофт. В целом понятный доклад обернутого в науку agile — не примеры, а общие слова и хорошие метрики. Заметки Люксофт success story хорошей разработки. Развитие от функциональных команд к кроссфункциональным и далее к бизнес-командах. Рассказ, что применяют крутой agile (Enterprise Scale) — масштаба предприятия. Процесс непрерывного улучшения — главное. Через метрики. Три группы — требования, дизайн+архитектура+техника, инфраструктура. Проблема идентифицируется, гипотеза по исправлению, эксперимент, метрики результата и решение по нему. Пример истории — 100 % автоматизация в одной группе дала кучу плюсов, и не оверхед. Источники — поддержка менеджмента с одной стороны и системное мышление — с другой. Говорит, что все осознали и он прошел пропасть. Только Книберг при этом говорит, что реально не итеративно. Слова — надо решать. И не свои проблемы, а проблемы заказчика. Если заказчик — ит-департамент заказчика, то ему не интересны проблемы с подрядчиком, ему надо решить проблемы бизнес департаментов. Все коммуницируют примерами, аналитик по ним создает user story, по которым команда создает свои а тестеры свои. spec by example настаивает на использовании примеров пользователя. У них — хорошо. Из зала пошли вопросы с завалом — мол, пользователи не знают, что делают. Успешный 5-летний проект с инвестбанком (интересно, с каким, дойч?). Начали Time&Material, потом перешли на Fixprice потому, что заказчик менял у себя процессы в эту сторону. Основная штука успеха — системное мышление. Чтобы оптимизировать, где надо, а не где видны возможности. И работать на результат, а не локальную оптимизацию — я: это как у Голдратта. Второе — уважение к людям. Не только к своим сотрудникам, но и к культуре заказчика. Дамир Тенищев. Предварительная оценка и планирование Agile проектовМенеджер больше старой школы. Знает, как надо. Новые книги читал, с частью согласен, с другими ему не очень комфортно. И доклад достаточно конфронтационный с интерпретацией пионерами и экстремистами новых веяний. Интересны проекты 50-100 человеко-лет. Я общался потом в кулуарах, у них достаточно интересный и высокотехнологичная разработка — продукт для западных страховых компаний с рядом внедрений. При этом они предоставяляют сервисы, сопрягаясь как между собой, так и с системами компаний, в том числе — поддерживающими оригинальные бизнес-процесы. В некотором смысле, антипод нашего позиционирования: мы поддерживаем там, где оригинальные бизнес-процесы, а они — там, где типовые, снимая эту часть и позволяя сосредоточиться на оригинальном. Заметки. Доклад — первый из трех, сейчас часть — проблемы. Фикс price. Регулярные активности всякие — помнить (говорит 12 %, из зала — 30 %). Поддержка старого кода (девелопер на полставке не более 100 тыс.строк). И так далее. Объем кода — нарастает постепенно, но это не видно. Трекинговые системы — но не более 20 задач на человека. Опыт: если больше — зачем-то чистят, меньше — накидывают. Хреново… Но если за первый год много налепили, то буксует — почему — потому что разработчики гибнут под кодом. Важно, чтобы с ростом числа фич объем кода рост не экспотенциально, а логарифмически — новые фичи во многом за счет старого кода. Метрика. Он утверждает, что девелопмент сам по себе — 10 % кода. Не 30, как любят писать. Но это Брукс, а не он. Хотя он говорит о своих вычислениях — интересно посмотреть. Но к заказчику он выходит. Плюс риски неопределенности, например, неточные или неопределенные требования. (По Талебу это не слишком оцениваемо). Я: На самом деле эти риски нельзя снять — неоклассический контракт. Еще — любовь разработчиков закапываться. Полировать детали. Средство борьбы — жесткий deadline. Из зала: но это не agile. Ответ: я попробую, как повернуть, но не уберу со слайда. Баян про документацию против общения. Периоды тишины — например, до 12 — никто не трогает. Оно разумно. Качество на первой линии. Не нравится идея «выделите неделю на ошибки, они поправят». Надо править сразу. «Не живите с раскрытыми окнами». Станислав Калканов. В чем счастье заказчика? Готовые фичи вместо гант чарта!Как-то докладчики от Люксофт однообразны и излагают известные вещи… Заметки. Известные вещи.
Попробовал уйти. Но Бевзюка не было…
Вопросы
Борис Вольфсон. Гибкая теория ограниченийБыл не с начала. Как и анонсирована — теория ограничений Голдратта. Конкретно в применение к разработке. Было весьма интересно послушать, хотя Голдратта я читал и теорию представляю. Заметки.
Роман Юферев. И все-таки программисты — дети!Про то что работа менеджера с программистами очень сопоставима с воспитанием детей и можно применять те же заповеди, подходы. Началось с того, что в детском саду он увидел 10 заповедей родителю и с удивлением понял, что по отношению к програмисту они тоже очень подходят. И дальше доклад строился по этим заповедям. Заметки. Лет пять назад: программисты-аутисты, малоспортивны и прочее. Сейчас — нет. Программисты — самостоятельны спортивны понимают цели продукта и прочее. Что, программисты изменились? Нет, изменилось их восприятие менеджерами. Анна Фрейд. Изучение детской психологии. Основные отличия.
Но эта разница не слишком существенна. Итого — воспринимаем программистов как детей, которых менеджеры воспитывают. 10 заповедей для родителей. На самом деле менеджеру очень применимо. Я не переписываю — но полезно в презентации посмотреть. TED 5 вещей, которые надо разрешить ребенку. Потрясно. Дает водить авто и работать с электоринструментами. Доклады о новом опытеЗдесь собраны доклады, рассказывающие о не слишком большом, но успешном опыте докладчика в какой-либо области. Это обычно некоторый один путь. Дмитрий Лайер. Стратегическое планирование через инновационные игрыНе сначала. В целом докладчик — начинающий, 5 собственных игр. У него получается. От этого фан, осмысления нет, но как рассказ про постороннюю технику. наверное, полезно — для тех, кто в игры не верит. Заметки.
Семен Молотков, Евгений Кобзев. Экстремальный аджайл — танцуют всеЭтот доклад был на первом месте по потенциальным слушателям, но моих надежд не оправдал. Потому что изложение, к сожалению, было очень медленным. Речь идет о продуктовой разработке и они включили в команду всю цепочку, включая маркетинг. А начали с разработчиков. Команда 18 человек, все в одной команте: 2 аналитика (грызут нормативку) + 1 инж.психолог + 2 проект.интерфейсов + 1 граф.дизайнер + 8 разр + 2 тестера + 1 менеджер + 1 документатор + 3 продвиженца. Что интересно, в этой конструкции нет PO — поскольку есть много источников для задач, и как-то это совместно решается. Владимир Бахов. Непрерывная интеграция при разработке баз данныхПионер — относительно нас, мы примерно так со скриптами полного проноса или изменений работали лет 5 назад и ранее. Переход от ручного наката к версионным скриптам и постепенном накате изменений. Но то, что сделано — работает. Народа было много, тема людям интересна. Я все-таки позиционировал этот доклад к докладам о новом опыте, не столько потому, что мы впереди, сколько потому, что рассказывалось без вариаций о том способе, который они сейчас применяют, без связи с окружением мирового опыта. А сами они — работают одним способом. Важно отметить, что доклад был не просто про установку изменений, а именно про непрерывную интеграцию и тестирование. Для тестов они делают тестовую деревню на синтетических данных, а сами тесты делятся на 2 категории: легкие по commit и тяжелые ночью. Заметки.
Стас Фомин:Собственно это я говорил автору еще на этапе ревью. И впечатлил оного — после доклада он подходил ко мне, чтобы я посоветовал ему гуру непрерывной интерграции — я послал его к вам и Игорю Беспальчуку (сам был в полном мыле, общатся не мог), не знаю, дошел ли он до наших.
Кирилл Климов. Kanban vs Scrum — чьё кунг-фу сильнееСлушал с середины. Мое впечатление: докладчики внедрили scrum, он в силу разных особенностей получился урезанным и по этому поводу были комплексы. Поэтому теперь у них Канбан с дополнительными практиками и психологически это комфортнее. Плюс, в таком варианте им легче проявлять и объяснять различную гибкость. В докладе это было менее четко, мысль была «заменим scrum на канбан, потому что scrum жесткий и много лишнего», но меняли, скорее, название чем процесс. Доклад интересен как опыт конкретной и успешной реализации процесса с разными особенностями, тем более, что многие из них для меня, например, узнаваемы. Заметки.
Тимофей Евграшин. Культура лидерства в Agile про лидеровСлушал очень немного. Докладчик не понимает, что команда креативных лидеров загибается — они дерутся. И это экспериментально проверено Белбиным. А еще лидерство и личная отвественность — вещи разные, хотя и пересекаются. Из заметок. Лидер Стив Джобс может сделать во всей компании agile. Лидерство идет из личной ответственности — я с этим сильно не согласен. Александр Лесневский и Никита Филиппов. Наследие капитана ФлинтаОчень странный доклад. Был большой инвестиционный проект, бизнес-план под который предусматривал опеределенную разработку, окупающуюся за десяток внедрений. Четыре года он шел с не очень понятным результатом — с одной стороны, была пара пилотных внедрений, с другой — до фиксации продукта было непонятно сколько, и темпы движения невнятные. Пытались исправить ситуацию через внедрение scrum и отчасти это удалось — внедрили и вроде получили реальный прогноз — еще четыре года. А дальше инвестор, узнав прогноз, предпочел зарыть проект. Но инвестор сохранил деньги, и это бизнес-позитив внедрения scrum. Хотя лично мне получение реалистичного прогноза на 4 года по результатам менее чем полугода работы представляется сомнительным, за этот срок скорость новых команд не могла выйти на плато. Да, я мог напутать, и везде говорилось о 2 годах, а не о 4. Рассказывали все достаточно интересно, с привязкой к типам Адизес — была харизматичная хозяйка (тестеры), поджигатель, фонтанирующий идеями и отказывающийся и провокатор с подколками. Были трудности, но в результате добились стабильной работы. Но харизматичную хозяйку ушли, потому как сопротивлялась. Делили команды, чтобы внутри конфликтов не было. И, все-таки оценив реальные сроки разработки по результатам итераций инвесторы компанию закрыли… Кривая — разработчики нечто сдали тестировщикам. а тестировщики — не признавали этого и не принимали продукт. На старте было 2+7+3 в конце — 1+5+1 с той же производительностью. Я: вполне понятно по Белбину. Юля Нечаева. Как сервисному отделу не стать бутылочным горлышкомСлушал частично. Юля возглавляет не слишком давно созданный отдел тестирования, общий для нескольких команд разработки, которые живут каждая в своем ритме. Судя по всему, до этого были большие проблемы с качеством, которые сейчас их отдел решает. А она делилась опытом организации этого процесса. К сожалению, в докладе было много о проблемах, но не так много о решениях. Кроме того, относительно четкое противопоставление «мы-они» — про разработчиков и тестеров, а не про «мы вместе». И, соответственно, договоренности, как у сторон, которым надо отстроить приемлемые правила взаимодействия в условиях противоречащих требований, а сотрудничество для выпуска продукта — оно где-то за рамками. Наверное, оно есть, но в докладе его видно не было. Из забавного. С точки зрения разработчика, хороший тестер должен заранее знать не только время тестирования, но и количество найденых багов — чтобы разработчики могли заранее запланировать их исправление. И не проверяет повторно — ведь исправили наверняка хорошо. Из позитивных практик — выявлять те тесты, где работа наиболее неустойчива и начинать с них. Например, web тестировать под chrome. Николай Алименков, Алексей Солнцев. Что означает «Готово!»: применение практики Definition of DoneСлушал с середины. В целом показалось, что это борьба с ветряными мельницами бюрократии с одной стороны, и самообманов — с другой — принять почти готовое. Экспрессивно, подряд и несколько сумбурно, без логики изложения. Заметки. Как-то они примитивно про скрам — мол в середине никто не смотрит за процессом… А как же движение по доске? И про канбан — что только одна задача в разработке. В целом по-разному оно. Ну и дальше — no commitment, no understanding, какие-то известные штуки. Надо искать способы договоренности, всякая демократия и прочее… Несогласие двух вариантов: без аргументов и с аргументами. Если с аргументами — обсуждаем. Если без — решаем с менеджером (Хенрик сказал бы — гнать из команды). Всеволод Леонов. Стихийный Agile во внутрикорпоративной средеИз embarcadero. Я квалифицировал, как новый для докладчика опыт — все-таки обобщений тут нет. Довольно сумбурный доклад. Из достаточно большой кучи баек. Попытка уложить в одну канву не слишком получилась, но сами фрагменты достаточно интересны. Но там очень много негатива про внутрикорпоративную разработку: есть и правильные вещи и передергивания. Заметки.
А в конце — реклама delphi и delphiPHP. Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
 |
