CustisWiki - Новые страницы [ru]

Максим Цепков - AgileDays-2011/Культура лидерства в Agile

2011-05-11T11:24:06Z

StasFomin: Новая страница: «* Культура лидерства в Agile (Тимофей Евграшин, AgileDays-2011) Слушал очень немного. Докладчик не ...»

Культура лидерства в Agile (Тимофей Евграшин, AgileDays-2011)

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

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

Максим Цепков - AgileDays-2011/Kanban vs Scrum

2011-05-11T11:22:43Z

StasFomin:

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

Заметки.

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

Максим Цепков - AgileDays-2011/Непрерывная интеграция при разработке баз данных

2011-05-11T11:18:52Z

StasFomin: Новая страница: «* Непрерывная интеграция при разработке баз данных (Владимир Бахов, AgileDays-2011) Пионер — о...»

Непрерывная интеграция при разработке баз данных (Владимир Бахов, AgileDays-2011)

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

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

Заметки.

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

Стас Фомин:Собственно это я говорил автору еще на этапе ревью. И впечатлил оного — после доклада он подходил ко мне, чтобы я посоветовал ему гуру непрерывной интерграции — я послал его к вам и Игорю Беспальчуку (сам был в полном мыле, общатся не мог), не знаю, дошел ли он до наших.

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

Максим Цепков - AgileDays-2011/Экстремальный аджайл — танцуют все

2011-05-11T11:16:47Z

StasFomin: Новая страница: «Этот доклад был на первом месте по потенци...»

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

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

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

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

Максим Цепков - AgileDays-2011/Стратегическое планирование через инновационные игры

2011-05-11T11:15:44Z

StasFomin: Новая страница: «* Стратегическое планирование через инновационные игры (Дмитрий Лайер, AgileDays-2011) Не снач...»

Стратегическое планирование через инновационные игры (Дмитрий Лайер, AgileDays-2011)

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

Заметки.

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

Максим Цепков - AgileDays-2011/И все-таки программисты - дети!

2011-05-11T11:13:15Z

StasFomin: Новая страница: «* И все-таки программисты — дети! (Роман Юферев, AgileDays-2011) Про то что работа менеджера с пр...»

И все-таки программисты — дети! (Роман Юферев, AgileDays-2011)

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

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

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

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

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

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

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

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

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

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

Максим Цепков - AgileDays-2011/Гибкая теория ограничений

2011-05-11T11:11:30Z

StasFomin: Новая страница: «* Гибкая теория ограничений (Борис Вольфсон, AgileDays-2011) Был не с начала. Как и анонсирована ...»

Гибкая теория ограничений (Борис Вольфсон, AgileDays-2011)

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

Заметки.

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

Максим Цепков - AgileDays-2011/В чем счастье заказчика

2011-05-11T11:10:25Z

StasFomin: Новая страница: «Как-то докладчики от Люксофт однообразны и излагают [[В чем счастье заказчика? Готовые фич...»

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

Заметки.

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

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

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

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

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

Вопросы

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

Максим Цепков - AgileDays-2011/Предварительная оценка и планирование Agile проектов

2011-05-11T11:09:21Z

StasFomin:

Предварительная оценка и планирование Agile проектов (Дамир Тенищев, AgileDays-2011)

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

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

Заметки.

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

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

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

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

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

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

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

Максим Цепков - AgileDays-2011/Enterprise Scale Agile. Lessons learned

2011-05-11T11:07:06Z

StasFomin: Новая страница: «Руководит развитием agile в люксофт. В целом понятный [[Enterprise Scale Agile. Lessons learned (Константин Гур...»

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

Заметки

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

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

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

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

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

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

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

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

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

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

Максим Цепков - AgileDays-2011/Командный старт

2011-05-11T11:04:47Z

StasFomin: Новая страница: «Весьма замечательный тренинг. Вещи мне извес...»

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

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

Заметки.

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

Максим Цепков - AgileDays-2011/Agile Distribution Risk Score

2011-05-11T11:03:45Z

StasFomin:

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

Заметки.

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

Максим Цепков - AgileDays-2011/Пуассоновое горение сроков

2011-05-11T11:01:01Z

StasFomin:

Пуассоновое горение сроков (Андрей Бибичев, AgileDays-2011)

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

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

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

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

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

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

Максим Цепков - AgileDays-2011/Иду по приборам! Практические советы по визуализации работ

2011-05-11T10:53:02Z

StasFomin: Новая страница: «Я слушал не сначала. Народ не влезал. Изложение не слишком гладко, зато паузы и шутки. Но гд...»

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

Стас Фомин: Вообще-то, этот доклад Максим уже докладывал на AgileBaseCamp во Львове

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

Заметки.

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

Максим Цепков - AgileDays-2011/Ретроспективы. Настраиваем наш процесс разработки

2011-05-11T10:51:20Z

StasFomin: Новая страница: «Я был недолго. [[Ретроспективы. Настраиваем наш процесс разработки (Сергей Дмитриев, AgileDays-2...»

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

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

Максим Цепков - AgileDays-2011/Недостающая часть Scrum

2011-05-11T10:49:54Z

StasFomin: Новая страница: «Из Эстонии. Основатель и глава фирмы. Хороший [[Недостающая часть Scrum — как стать успешным ...»

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

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

Стас Фомин: «Максимизировать несделанной работы» — явно что-то не так.

Большие половины в мире используют agile, 84 % из них — scrum, но только половина — итерации, то есть реально много фуфла. flaccid scrum
Вид программистов-ковбоев. И программистов-бюрократов, что хуже…
Внедрение сверху-вниз. Много плюсов — для менеджеров.
Кен Швабер разочаровался в альянсе, сертифицирующем скрам-мастеров, и начал делать программу обучения и сертификации скрам-разработчиков
Agile требует жесткой дисциплины, иначе ничего не выйдет
YAGNI: simplicity — лишние патерны, проги на будущее — но без оговорки Эванса? — работает из предположения, что добавить потом также просто и что не можешь угадать.
Продать парное программирование девелоперам…

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

История про тесты. Которые просто удаляют, а не исправляют.
Build-мигалка под потолком…
Не меряйте разработчика числом строк — он начнет писать длинно, а не элегантно.
Вертикальная разработка.
- Горизонтальная — прототип формы, который не работает, потом — следующий слой.
- Вертикальная — фича снизу доверху
Против чрезмерной специализации. Если все кроме одного попали под грузовик, один должен мочь продолжать.
Стандарты кода — чтобы ощущали своим.
Архитектура — часть дизайна, которую сложно изменить потому что она вбита. Значит лучше, если нет архитектуры… Пришло из строительства, где дизайн дороже. Он считает, что код и есть дизайн, а вовсе не какой-нибудь UML. С одной стороны, против быдло-кодеров. но с другой…
Software craftmanship
Двойной монитор с дублем экрана и две клавиатуры и мышки. Только пальцем на экране не показывать.
Главное у людей — отношение к работе, а не skills

Максим Цепков - AgileDays-2011/Архитектура в Agile

2011-05-11T10:41:34Z

StasFomin:

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

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

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

Максим Цепков - AgileDays-2011/Everyone likes change, but nobody likes to be changed

2011-05-11T10:23:17Z

StasFomin: Новая страница: «[http://blog.crisp.se/henrikkniberg/2011/03/04/1299219540000.html Презентация] в блоге Хенрика. [[Everyone likes change, but nobody likes to...»

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

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

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

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

Статический анализ C++ кода (Андрей Карпов, ADD-2011)

2011-05-10T19:24:03Z

StasFomin:

Time Management для программиста (Михаил Гедзберг, ADD-2011)

2011-05-10T19:05:06Z

StasFomin:

Разработка корпоративных порталов с использованием Liferay (Алексей Какунин, ADD-2011)

2011-05-10T18:53:22Z

StasFomin:

Когда всем понятно

2011-05-10T17:07:08Z

MaksTsepkov:

Максим Цепков: главный архитектор компании CUSTIS

Опубликовано в журнале Бухгалтер и компьютер, № 5(май), 2011 
Журнал закрылся, архив недоступен

Скрестим вилки (Михаил Шигорин, ADD-2011)

2011-05-10T12:48:10Z

StasFomin: /* Аннотация */

AgileDays-2011:Отчет Никитина В.В./Agile-игры — Business Value Game

2011-05-10T09:09:32Z

StasFomin: Новая страница: «* Agile игры — Business Value Game (Тимофей Евграшин, AgileDays-2011) Имея вечерний опыт хорошего мастер-кл...»

Agile игры — Business Value Game (Тимофей Евграшин, AgileDays-2011)

Имея вечерний опыт хорошего мастер-класса, я понял, что мне сюда. И не прогадал. Была интересная модельная игра. Наша команда выиграла!

Заключается она в том, что есть Заказчики, они дают задачи, за которые мы получаем деньги, если релизим версию. При этом у задачи есть показатель «счастья» клиента: то, насколько повысится счастье (в баллах), если задачка будет отгружена. Изначально у всех заказчиков по 5 баллов счастья. Каждый ход, если заказчику ничего не отгружается, его счастье уменьшается на 1. Если оно становится равным нулю, то команда теряет заказчика, более того, все деньги, которые на нем заработаны до этого, не идут в зачет.

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

В конечном зачете учитывалось и счастье заказчика (об этом было сказано в начале игры), что и вывело нас на первое место.

В целом, хоть игра и модельная, но в ходе нее чувствуешь некоторые моменты.

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

Также Тимофей поделился ссылкой на сайт с играми: http://blog.tastycupcakes.com/all-games/

AgileDays-2011:Отчет Никитина В.В./Командный старт

2011-05-10T09:02:48Z

StasFomin: Новая страница: «* Командный старт (Сергей Дмитриев, AgileDays-2011) Очень понравилось. Знаю, что некоторые наши, ...»

Командный старт (Сергей Дмитриев, AgileDays-2011)

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

e-mail: sergey@agilecoach.ru

Фотографии flipchart’а с мастер-класса: http://www.dropbox.com/gallery/3490871/4/Documentation/Conferences/AgileDays%20Msk%202011/Team%20startup?h=06ae92#/

Всё, что мы написали на тренинге, мы развешивали на стенах в зоне видимости, чтобы можно было в любой момент посмотерть + чтобы был виден объем проделанной нами работы.

Началось все с представления тренера

Затем Сергей озвучил план мероприятия:

Затем мы все вместе написали наши ожидания от мероприятия (мы говорили — он писал)

Командный старт занимает ~1 день. Когда проводится и зачем:

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

Есть исконный agile, как он описан в книжках. Назовем его «Сердце agile» (слева вверху).

Есть Первая команда, которая подкрутила его под себя, добавив командный опыт и ритуалы (справа вверху).

Есть вторая команда, тоже подкрутившая его под себя, но в другом напрвлении (слева внизу).

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

Поэтому при переходе из одной команды в другую, происходит нестыковка в понимании agile, поэтому нужен командный старт.

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

Повторили еще раз про 4 стадии развития команды:

Новая команда формируется, проходя в этом процессе кульминацию (storming) и выходя на нормализацию процесса. После этого идет только совершенствование.

Если же хотя бы один человек добавился в команду — это уже новая команда, и она снова сваливается на стадию Forming.

Что нужно, чтобы командный старт состоялся

Основная структура командного старта: слева указаны соотношения по времени, которое надо отводить на каждый пункт (3:1:1:1:3).

Отдельно пункты разбираются ниже.

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

Для этого используют value stream mapping. Рисуют процесс от старта до отгрузки продукта/версии/релиза и на всех переходах и узлах ставят время, которое он занимает. Потом анализируют. Утверждается, что менеджеры удивляются результатам.

И далее вывод: локально оптимизировать нельзя

И откровение про PO. Он должен все делать с такой позиции: «Что я сегодня могу сделать, чтобы команде было лучше» (сравните с вашим подходом!)

Итак, освежаем процесс:

Знакомимся поближе

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

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

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

Другие игры, помогающие сплочению команды и решению некоторых задач, описаны в книге «Innovation games» by Luke Hohmann

Далее команда обсуждает предстоящую работу:

После этого можно приступать к работе.

Нам же далее был предложен список игр, в которые можно поиграть и из которых нам надо выбрать две:

Наш скрам

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

Мне интересно…

Каждый по кругу спрашивает, начиная фразу словами «Мне интересно, как в скраме …». Ответы, обсуждения. Цель та же: общее понимание общего процесса.

Что такое самоорганизация

Индекс-карточки: как ощущается самоорганизация. Это все, что было сказано.

Играется, если есть несколько наших формулировок чего-то, и нам трудно выбрать одну. Каждый пишет свою на отдельной бумажке. После этого все передвигаются по комнате в произвольных направлениях — перемешиваются, меняются карточками. После сигнала любые двое, находящиеся рядом, образуют пары. Они должны прочитать вдвоем обе карточки и совместно проставить на обратной стороне каждой из карточек баллы так, чтобы в сумме на обеих карточках было 7 баллов. Такая процедура проводится 5 раз. Нетрудно догадаться, что максимум, который может набрать карточка при такой процедуре, 35 баллов (правда, такого еще никогда не было — оно и понятно: если бы была очевидная формулировка-лидер, то и не пришлось бы проводить эту процедуру). Отсюда и название игры. Побеждает формулировка(формулировки), набравшая больше всего баллов. Однако рассматриваются также и отстающие на 1-2 балла. Из них берутся мысли (или не берутся), для дополнения основной формулировки.

Спагетти

Участвует 8 человек. Они берутся за руки и запутываются в «узел». Менеджер должен распутать, но не может. А команда сама легко и быстро распутывается. Играется, чтобы убедить менеджера, что команда и сама способна на многое, а менеджер иногда очень даже мешает.

Рынок навыков

Рисуется стол — витрина. На витрине рисуются навыки и интересы, которые могут пригодиться в проекте — то, что человек предлагает как вклад в команду. Под витриной рисуются навыки и интересы, которые не нужны в проекте, но которыми человек готов поделиться. Пример Сергей нарисовал сам про себя:

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

Жизненное путешествие

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

Угадай-ка

Каждый пишет про себя стикеры двух цветов: на одних то, что 100 % не он — на других то, что 100 % он. Плюс на тот момент уже нарисованы портреты членов команды (это игра, когда каждый дорисовывает в портрет рисуемого члена команды свою деталь: команда ходит по кругу и каждому дается по 3 секунды на дорисовывание). Далее эти бумажки развешивают общими силами/обсуждением на портреты.

Успели поиграть только в 35. Формулировали, зачем нужен командный старт. Вот победившие бумажки.

По окончании написали плюсы, которые дал нам этот мастер класс:

По окончании написали «дельта»-плюсы: что может сделать Сергей, чтобы следующий мастер-класс прошел лучше этого:

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

PO — это король. В его ведении находится вопрос «ЧТО делать», а в ведении команды находится вопрос «КАК делать». Этого самого эксперта, который давлеет над командой, надо выводить на уровень PO, чтобы он не мешал команде. Его место именно там. Пусть PO советуется с ним и спускает уже готовое решение, чтобы у команды не складывалось впечатление, что их мнение игнорируется. Надо отметить, что в этой ситуации страдает не только команда, но сам этот эксперт, поэтому это решение в корне меняет настроения в коллективе.

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

AgileDays-2011:Отчет Никитина В.В./Культура лидерства в Agile

2011-05-10T09:01:23Z

StasFomin: Новая страница: «Сайт http://tim.com.ua Очень толковый [[Культура лидерства в Agile (Тимофей Евграшин, AgileDays-2011)|доклад...»

Сайт http://tim.com.ua

Очень толковый доклад и по содержанию, и по подаче материала. Я внимательно слушал, поэтому мало что записал, поэтому ВСЕМ рекомендую видео к просмотру.

Книга Jurgen Appelo «Managment 3.0»

AgileDays-2011:Отчет Никитина В.В./Agile Distribution Risk Score

2011-05-10T09:00:01Z

StasFomin: Новая страница: «* Agile Distribution Risk Score — планируйте распределенность осознанно (Анна Обухова, AgileDays-2011) Презе...»

Agile Distribution Risk Score — планируйте распределенность осознанно (Анна Обухова, AgileDays-2011)

Презентация на английском - рассказ на русском. ЗАЧЕМ? Предлагала способ оценивания команд по рискам, связанным с распределенными командами. Ничего интересного для нас.

AgileDays-2011:Отчет Никитина В.В./Иду по приборам!

2011-05-10T08:58:51Z

StasFomin: Новая страница: «* Иду по приборам! Практические советы по визуализации работ (Максим Гапонов, AgileDays-2011) Ви...»

Иду по приборам! Практические советы по визуализации работ (Максим Гапонов, AgileDays-2011)

Видел его и на прошлых AgileDays. Материал во многом старый. Такое ощущение, что лишь бы поучаствовать. Сказать нечего.

AgileDays-2011:Отчет Никитина В.В./Ретроспективы. Настраиваем наш процесс разработки

2011-05-10T08:57:30Z

StasFomin:

Очень хороший доклад и в плане содержания, и в плане подачи материала. Очень понравился! Смотреть всем!

Его сайт http://www.agilecoach.ru

Основные мысли:

Ретроспектива — «коллективное рассказывание историй»

Доверяй своим подчиненным

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

Фокус ретроспективы должен быть обращен на то, чтобы что-то произошло — поменялось

Ретро ~ 1 час на неделю работы

Структура:

открытие 5 %
сбор данных 30-50 %
- у всех есть чувства
- по списку красными и зелеными точками отмечают «за» и «против»
приникновение в суть 20-20 %
- анализ данных
решение о дальнейших действиях 10 %
- что реально можем сделать в ближайший спринт
закрытие 10 %

PO — гнать с ретро. Либо пускать хотя бы через раз.

Если команда в отсутвии PO может «вывесить грязное белье», то это уже команда. Иначе — не команда.

И здесь есть игры для ретроспектив — читать книгу Esther Derby, Diana Larsen «Agile retrospectives»

Каждый обязательно должен что-то сказать

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

Рабочий уговор — внутренние правила поведения (например, никто никого не перебивает, никто за другого не говорит и т. п.)

На ретро должен присутствовать модератор. Лучше не из команды.

Анекдот по теме ретро: Мужик пилит дерево, а оно пилится с трудом. К нему подходит другой и говорит: «Ты бы пилу поточил — сразу бы дело быстрее пошло!». «Да, что ты, — отвечает другой — некогда, пилить надо!» Зачастую мы похожи на первого мужика.

AgileDays-2011:Отчет Никитина В.В./Стратегическое планирование через инновационные игры

2011-05-10T08:53:14Z

StasFomin: Новая страница: «Доклад б...»

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

Есть у него книга «Innovation Games: Creating Breakthrough Products Through Collaborative Play». Нашел в инете, где скачать, только усеченный вариант книги: http://agilegames2011.com/images/stories/downloads/innovationgames_3games.pdf

И есть еще сайт http://innovationgames.com/

Вроде бы все это очень помогает в сплочении команд.

AgileDays-2011:Отчет Никитина В.В./Everyone likes change, but nobody likes to be changed

2011-05-10T08:51:32Z

StasFomin: Новая страница: «Доклад был на английском. В целом идея, к...»

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

Не пытайся менять людей -> мотивируй их на то, чтобы они сами хотели меняться

Дай человеку направление, а не укажи решение.

AgileDays-2011: Отчет Кудрявцева В.Б/Гибкая теория ограничений

2011-05-10T08:47:44Z

StasFomin:

Борис Вольфсон

Доклад про теорию ограничений Голдратта. Полезных мыслей по его результатам не возникло.

AgileDays-2011: Отчет Кудрявцева В.Б/Модель принятия инженерных решений

2011-05-10T08:46:15Z

StasFomin:

Евгений Кривошеев, ScrumTrek

Достаточно интересный и познавательный, но малополезный на практике (ИМХО) доклад.

AgileDays-2011: Отчет Кудрявцева В.Б/Модель системы — архитектура для Agile-разработки

2011-05-10T08:43:51Z

StasFomin: Новая страница: « Максим Цепков * [[Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011)]...»

Максим Цепков

Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011)

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

Основные моменты (лучше смотреть видео/презентацию):

Макс упомянул о такое практике XP как «метафора системы», понятие хорошо раскрыто и проиллюстрировано в докладе

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

Стандартные диаграммы (проекции) используемые в ЗИС:
- диаграмма классов (скорее, на мой взгляд, сущностей)
- диаграмма учета
- диаграмма состояний документов

Некоторые правила
- Для простоты и гибкости приходится отказываться от case-средства
- нельзя использовать технические коды на диаграммах
- активно использовать цветовое кодирование
- детализация только там, где необходимо

AgileDays-2011: Отчет Кудрявцева В.Б/Domain Driven Design в условиях разработки распределенных приложений

2011-05-10T08:41:49Z

StasFomin: Новая страница: « Николай Гребнев [[Domain Driven Design в условиях разработки распределенных приложений (Николай Г...»

Николай Гребнев

Обзорный доклад на тему применимости DDD в распределенных приложениях. Добротно, но без откровений. Также было заметно, что аудиторию разочаровало отсутствие хотя бы упоминания новых подходов (типа CQRS).

AgileDays-2011: Отчет Кудрявцева В.Б/Свободное обсуждение разных тем

2011-05-10T08:40:22Z

StasFomin: Новая страница: «* Должен был быть доклад Антона Бевзюка «Архитектура для автоматизированного тестировани...»

Должен был быть доклад Антона Бевзюка «Архитектура для автоматизированного тестирования UI», который обещал быть интересным, но Антон не приехал(

Толку было не очень много. Обсуждали по 5-10 минут следующие темы:

Электронная или реальная доски (выяснили, что лучше и такая и такая)
Длинный скучный Daily Scrum (у девушки команда на 15 человек, делающая разные проекты). Очевидный вывод — делить команду
Agile при работе с гос. заказчиком (ничего особо полезного)
Test-Driven Development (тоже ничего особо полезного)

AgileDays-2011: Отчет Кудрявцева В.Б/Архитектура в Agile

2011-05-10T08:34:48Z

StasFomin: Новая страница: « Андрей Бибичев. ;Презентация: [http://www.slideshare.net/biBIGine/agile-7158754 Документ на slideshare.net (Спасибо Ди...»

 Андрей Бибичев.

Презентация: Документ на slideshare.net (Спасибо Диме Белобородову за ссылку)

Хороший доклад про паттерны и антипаттерны ООП. Интересно, однако, что внедрение многих хороших упомянутых практик в RMS (и в ЗИС вообще) началось по инициативе «снизу», а не пришло из TechEvol.

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

AgileDays-2011: Отчет Кудрявцева В.Б/В погоне за качеством. Code Review

2011-05-10T08:31:39Z

StasFomin: Новая страница: «Николай Алименков, Алексей Солнцев, [http://xpinjection.com XP Injection] Кстати, авторы уже читали [[В пого...»

Николай Алименков, Алексей Солнцев, XP Injection

Кстати, авторы уже читали этот доклад на других конференциях, так что видео можно посмотреть здесь, не дожидаясь публикации докладов с Agile Days. Вы ничего не потеряете, на Agile Days презентация тоже была на английском, хотя доклад читался на русском, с приятным украинским акцентом). Конечно, не обошлось без известной картинки про WTF?/min.

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

Из необычного:

Code Review докладчики предлагают делать «в паре» с автором, на одной машине

Мысли на будущее:

Еще раз подумать про распределенные системы контроля версий.
Посмотреть средства поддержки Code Review, например Code Collaborator

AgileDays-2011: Отчет Беликова Сергея/Agile с фиксированной стоимостью

2011-05-10T08:22:07Z

StasFomin: Новая страница: «[[Agile с фиксированной стоимостью — это реально! (Дмитрий Лобасев, AgileDays-2011)|Интересная тема, ...»

Интересная тема, неплохой докладчик.

Вызвал ооочень много вопросов аудитории. Суть примерно такая. Находим заказчика, фиксируем требования начинаем работать по Fixed price, делаем продукт, проводим демо, собираем обратную связь (важно: все изменения в требованиях фиксируем), все переделки/новые хотелки стоят денег. Тут заказчик радоваться начинает и может быть даже продукт уже вовсю использует/продает, но мы то помним что баблосы ограничены были в начале проекта и мы их выработали ;) Приходим к клиенту и говорим, что дальше надо еще денег. Дальше варианты:

Хороший. Клиент поверил в нас, понял схему работы и вот он T&M.
Не очень хороший. Клиент в шоке, ведь первоначальные требования не все реализованы, а деньги закончились (в порыве радости заказик забыл, что новые хотелки денег стоят). Но деваться клиенту некуда, т.к. продукт надо дописать и мы получаем T&M. Правда потом клиент может не захотеть с нами делать новый продукт.
Плохой. Клиент не просто в шоке, но и начинает откровенно придираться ко всему и вся. Но мы юридически прикрыты и в худшем случае просто потратим время на разборки, ну и продукт не доделаем.

После доклада осталось чувство, что в истории Дмитрия все-таки кто-то кого-то обманул :)

AgileDays-2011: Отчет Беликова Сергея/Enterprise Scale Agile

2011-05-10T08:21:18Z

StasFomin: Новая страница: «Скучный, унылый дядька. Под конец дня уже не воспринимались такие докладчики, я так и не по...»

Скучный, унылый дядька. Под конец дня уже не воспринимались такие докладчики, я так и не понял в чем фишка истории (возможно стоит пересмотреть запись). Глупо получилась концовка выступления.

AgileDays-2011: Отчет Беликова Сергея/Наследие капитана Флинта

2011-05-10T08:18:40Z

StasFomin: Новая страница: «Очень скучный дядька. Когда увидел [[Наследие капитана Флинта — трудности и ошибки внедре...»

Очень скучный дядька. Когда увидел очередной слайд презентации, захотелось выколоть свои глаза. Александр может быть и хороший спец, и интересным опытом хотел поделиться, и даже человек он может быть хороший, но после доклада Дмитрия Лайера я решил не рисковать и пошел кушать бутерброды с чаем.

AgileDays-2011: Отчет Беликова Сергея/Scrum vs Kanban

2011-05-10T08:17:20Z

StasFomin:

Название предвещало многое, а на деле вышел какой-то пшик :) Краткое содержание доклада:

у нас был Scrum;
люди в команде были загружены неравномерно и это сильно напрягало;
мы решили внедрить Kanban;
…
Profit!

Хотелось услышать что-то на подобии доклада А. Уразбаева, а вышел из аудитории с вопросом в голове «Ну и чего?»

AgileDays-2011: Отчет Беликова Сергея/Иду по приборам! Практические советы по визуализации работ

2011-05-10T08:15:26Z

StasFomin: Новая страница: «[[Иду по приборам! Практические советы по визуализации работ (Максим Гапонов, AgileDays-2011)|Сказ...»

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

AgileDays-2011: Отчет Беликова Сергея/Ретроспективы. Настраиваем наш процесс разработки

2011-05-10T08:14:06Z

StasFomin: Новая страница: «[[Ретроспективы. Настраиваем наш процесс разработки (Сергей Дмитриев, AgileDays-2011)|Рассказыва...»

Рассказывал про ретро на примере своей команды. Очень жаль, что у докладчика было только полчаса. Некоторые идеи доклада:

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

Очень понравился прием со спящим животным :)

Рекомендую посмотреть.

AgileDays-2011: Отчет Беликова Сергея/Стратегическое планирование через инновационные игры

2011-05-10T08:12:32Z

StasFomin: Новая страница: «Коротко: никогда не пойду на доклады людей из Softline, особенно если их зовут Дмитрий Лайер. В ...»

Коротко: никогда не пойду на доклады людей из Softline, особенно если их зовут Дмитрий Лайер. В выступлении не было ничего хорошего, разве что название.

AgileDays-2011: Отчет Беликова Сергея/Everyone likes change, but nobody likes to be changed

2011-05-10T08:10:57Z

StasFomin: Новая страница: «Хороший доклад, особенно как открывающи...»

Хороший доклад, особенно как открывающий конференцию. Задал настроение на весь день. Рассказывал про то как менять себя и других, с чего начать, какими способами можно двигаться к цели, какие препятствия встретить на пути и как их преодолевать. Приводил очень понятные и живые примеры про детей и замкнутый круг (разработчики - менеджеры - клиенты). Местами не раз упоминал GTD.

Как докладчик очень понравился живо, четко, ясно, шутил, обращал внимание на аудиторию. С последним чутка переборщил даже :)

Всем рекомендую послушать.

AgileDays-2011:Отчет Цыганкова Д.А./Стратегическое планирование через инновационные игры

2011-05-10T08:06:22Z

StasFomin: Новая страница: «Есть на свете компания, стратегическое планирование в которой проводится [[Стратегическо...»

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

AgileDays-2011:Отчет Цыганкова Д.А./Agile игры — Business Value Game

2011-05-10T08:03:50Z

StasFomin: Новая страница: «Было весело, у всех выиграли, но связь и...»

Было весело, у всех выиграли, но связь игры с практикой весьма опосредованная. Можно предположить, что автор игры (не путать с Тимофеем) работал над небольшими проектами по fix price и никогда не задерживался в одной компании дольше 6 итераций. Что весьма отличается от нашей специфики — гигантские проекты, длящиеся вечно, люди, работающие в компании по 10 лет… В результате, что хотел сказать автор игры — понятно, но это не про нас.

AgileDays-2011:Отчет Цыганкова Д.А./Культура лидерства в Agile

2011-05-10T07:59:03Z

StasFomin: Новая страница: «Впечатление от доклада осталось хор...»

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

AgileDays-2011:Отчет Цыганкова Д.А./Ретроспективы. Настраиваем наш процесс разработки

2011-05-10T07:57:45Z

StasFomin: Новая страница: «[[Ретроспективы. Настраиваем наш процесс разработки (Сергей Дмитриев, AgileDays-2011)|Хорошая, с к...»

Хорошая, с картинками, вдохновляющая речь, заставила задуматься на тему «а как у нас?», и в результате этих размышлений упустил основную нить доклада. Что-то типа «почитать книжку Agile Retrospectives»?

AgileDays-2011:Отчет Цыганкова Д.А./Экстремальный аджайл

2011-05-10T07:56:23Z

StasFomin: Новая страница: «Добротный доклад с максимумом конкретики, ...»

Добротный доклад с максимумом конкретики, про то как одна небольшая контора делает SaaS для бухгалтерии в малом бизнесе, как все — и маркетологи, и сейлзы, и разработчики — совершают похожие телодвижения с развешиванием бумажек, совместным планированием и итерациями. Как сначала они потратили кучу времени на разработку МегаТЗ, а потом решили постепенно наращивать функционал и очень довольны. Как разработчики сознательно отбирают некоторый процент звонков у службы поддержки, чтобы лучше понимать пользователей (кстати, нам тоже стоит практиковать, это и правда полезно). Очень любопытный жаргон: «клизма» == «бонусная задача». Рисуют багзильное Древо Багов на бумажке. Хоть у них и Agile, а разделение ролей вовсю: разработчик, аналитик, инженерный психолог и дизайнер интерфейсов — это всё разные люди. В общем, ребята оставили хорошее впечатление.