Agile Implementing Tips

Нельзя все сделать реюзабельным

2009-10-13T03:27:00.004+04:00

Парни в команде придумали новый термин - Юрезабельно :)

В честь нашего ведущего архитера (Юра, не обижайся).

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

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

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

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

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

Будьте внимательны, когда начинаете вроде бы динамичный Agile проект, и есть такие признаки как:

ресурсная модель проекта

отсутствие обоснованных бизнес-потребностями заказчика более-менее жестких сроков проекта

желание руководства сделать реюзабельные компоненты

принятие руководством архитектурных решений, особенно противоречащих решениям, принятым ранее архитектором проекта

Команда - основа успеха

2009-08-14T22:02:00.004+04:00

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

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

И уже второй раз ухожу на выходные с чувством выполненного долга :)

Истории пользователей (пожелания) и подзадачи в Jira

2009-08-14T03:58:00.007+04:00

Так получилось, что приходится один из проектов вести в ненавистной Jira.
Пытаюсь для возможности последующего анализа на pre-sale других проектов (а на самом деле в основном для удовлетворения начальства красивым сгенеренным project-планом) получить более менее удобную картину, а именно набор пожеланий, разбитых на задачи с определенным типом.

Т.е. имеем Feature, у которой есть Subtasks: описать требования, разработать UI, разработать серверный компонент, написать тестовый сценарий и протестировать.

Как бы сделать так, чтобы при переходе одной из подзадач в InProgress, исходная фича автоматически переходила в InProgress, а при Resolve или Close последней подзадачи, исходная фича тоже автоматически считалась выполненной? Ну чтобы инструмент помогал в работе, а не создавал новых трудностей.

Может кто знает?

Вот в системе управления проектами DEVPROM, например, при планировании пожелания в итерацию, автоматически предлагается создать набор подзадач (требования, разработка, тестирование), от состояния которых зависит состояние исходного пожелания.

Крайне удобно, и никаких лишних действий не нужно.

Сколько нужно архитекторов на одного разработчика?

2009-08-06T17:52:00.004+04:00

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

Стартовал новый проект с интересной особенностью - на трех (!) разработчиков:

два архитектора

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

ну и до кучи: менеджер, два аналитика и тестировщик

При этом аналитика и архитектура стартанули одновременно с разработкой.

Вот представьте себе состояние разработчиков, которым нужно писать код, когда мало того что ближайшие задачи не проработаны с бизнесом, так еще 4 архитектора даже между собой еще не договорились как будет выглядеть система :)

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

Повышаем эффективность ежедневного скрама

2009-08-06T14:40:00.004+04:00

Все больше убеждаюсь в том, что стандартные на ежедневных скрамах вопросы "Что ты делал вчера (What did you do yesterday)" и "Что будешь делать сегодня (What will you do today)" не самый эффективный способ вести проект к успешному завершению.

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

"я буду делать.. " - это процесс, так можно считать мух на потолке или смотреть на огонь.

"я сделаю.. " - это уже четко намеченная цель, которая должна быть достигнута.

Забота о пользователях или чудеса usability

2009-07-01T16:04:00.008+04:00

На сайте Металинка Оракл (http://metalink.oracle.com) сегодня увидел самую лучшую форму смены пароля из тех, которые требуют от пользователя следования определенным правилам:

Минут 5 сидел проверял как работают подсказки справа :)

TDD books - read it!

2009-06-30T13:15:00.004+04:00

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

Архив Все-в-одном:

Гради Буч - Объектно-ориентированный анализ и проектирование - musthave каждому разработчику прочитать хотя бы раз в жизни.

Кент Бек - Экстремальное программирование

Кент Бек - Экстремальное программирование. Разработка через тестирование

Мартин Фаулер - Рефакторинг. Улучшение существующего кода

Gerard Meszaros - xUnit Test Patterns

Ссылка (подождать минуту для скачивания)

TDD в Москве

2009-06-24T20:01:00.004+04:00

Пару дней назад провел очередной тренинг по Test Driven Development, на этот раз открытый и в Москве.

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

Уже второй раз задают вопрос про Test Driven, да и вообще модульного тестирования пользовательского интерфейса.

Вообще если брать термин "модульный тест" и прикладывать его к UI, то получим тест интеграционный, т.е. который тестирует цепочку вызовов да еще и не изолирован от внешних ресурсов, например базы данных. Различные инструменты для UI тестирования (selenium, watin) используют фреймворки модульного тестирования, вроде xunit, но все же на мой взгляд такими тестами должны (в основном) заниматься тестировщики.

Что касается Test Driven UI, то здесь по опыту приходит на ум только один инструмент - FIT, в котором можно сначала описать простым английским как будет выполняться тест, а уже потом идти создавать саму программу, ее UI и дальше просто связывать интерфейс пользователя с написанными ранее сценариями и запускать. Правда, понадобятся дополнительные фикстуры, но их и самим можно написать.

Следующий тренинг в середине июля в Питере, после занятий сразу на ролики!

TDD в студенческие массы

2009-05-13T14:00:00.002+04:00

Выдалась возможность прочитать настоящую лекцию настоящим студентам в НГТУ в Новосибе - вроде получилось неплохо.

Смутило то, что многие из них работают разработчиками, и при этом 100% аудитории никогда не слышала про continuous integration. Про Agile пара человек, что были на прошлогодней лекции Асхата. Про TDD опять никто. Караул.

Старался положение исправить, через два с половиной часа на моках народ уже начал выключаться :)
Зато вроде как никогда доходчиво изложил суть TDD на примерах, надеюсь хоть кто-нибудь после лекции полистает Кента Бека и попробует TDD.

Что завтрашний день покажет?

Про Новосиб - красивый на подлете, но неприступный внутри. В моем номере гостиницы сидела девушка, расчесывала волосы и курила. Воды горячей нет - капец :) Прошлый раз спал 28 часов назад. Пока шел на лекцию все киоски с колой были закрыты. Когда пришел в парк, перед носом закрылся ларек с мороженым. Когда пришел в кафе поесть и в инет, нашел платный файфай только с третьей попытки..
Хочется на машине по городу поездить посмотреть :)

Измерение скорости разработки по фазам

2009-04-22T01:13:00.008+04:00

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

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

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

(далее рассуждаем, приняв эффективность аналитической деятельности 1 разработчика меньше эффективности такой же деятельности 1 аналитика)

Давайте представим себе, что у нас недельная итерация, в команде помимо разработчиков только один аналитик по 4 часа в день - итого 20 доступных часов. А задач на анализ оказалось на 30 часов (например, недооценили) - и все необходимо сделать, чтобы хорошо начать следующую итерацию.

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

А burndown продолжает показывать, что все в норме!

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

Вот например в DEVPROM такой показатель измеряется и всегда доступен команде рядом с burndown графиком.

Снова в блог и немного новостей

2009-04-06T00:54:00.005+04:00

Давно что-то не получалось писать, хочется наконец это исправить :)

Из прошедшего за последнее время:

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

В феврале читал двухдневный тренинг по Test Driven Development в Одессе для одной небольшой распределенной команды - долго не мог найти подходящие слова, чтобы написать о нем.. так и не написал в итоге :)

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

А вообще, далеко не каждому по силам удаленно собрать такую мощную и слаженную команду.

После тренинга полетел в Сибирь, Шерегеш, где неожиданно оказалось -35-25 и были совершенно пустынные склоны и лес - кататься одно удовольствие, главное пуховик потолще надеть.

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

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

Из грядущего - 9 апреля вечером буду рассказывать и показывать на мастер-классе все прелести управления требованиями в DEVPROM.

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

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

Разминка на гибкость мышления

2009-01-30T18:50:00.003+03:00

За последние дни надавали мне логических задачек на разных интервью, вот, попробуйте немного размять мозги :) Только без гугла!
В конце будет мегазадача, если честно, я не осилил.

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

2. Есть 8 бильярдных шаров, один из них немного тяжелее других. Надо за два взвешивания с использованием рычажных (аптечных) весов, определить какой шар тяжелее.

3. Рассчитать, сколько в Москве двухкомнатных квартир. Еще можно посчитать количество заправок.

4. Сколько и какие точки планеты позволяют пройти 1 км на Север, затем 1 км на Запад и 1 км на Юг и попасть в исходную точку.

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

6. Есть бикфордов шнур, который горит ровно 1 минуту. Но неравномерно.
Как с помощью двух таких шнуров отмерять 45 секунд?

7. Вот самая жесть :)
На языке 'Гуси' одного африканского племени словами записаны следующие числа. Язык - настоящий, реально действующий.

57 emerongo etano na itano na ibere
82 emerongo etano na etato na ibere
230 amagana abere na emerongo etato
308 amagana atato na itano na itato
705 amagana atano na abere na itano

Напишите на этом языке 28 и 837.

P.S. Большинство задач в общем-то известные, но некоторые для меня например были совсем новые. Особенно седьмая.

Организация обратной связи с пользователями

2009-01-26T06:41:00.003+03:00

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

Но обычно, когда говорят об обратной связи, имеется ввиду связь Заказчик-Команда разработки, то есть заказчик все время корректирует наше движение вперед.

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

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

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

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

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

сделать ее максимально доступной пользователю, а не маленькой ссылкой внизу страницы

помещать заведенные пользователями пожелания в журнал (User Backlog?), к которому обязательно давать доступ пользователям

подписывать пользователя по email на все действия с его пожеланием (запланировано на итерацию, реализовано, отложено и т.п.)

иметь возможность комментировать пожелание для общения пользователя и команды, с отправкой уведомлений по email

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

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

Звучит заманчиво?

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

Форма встраивается на сайт несколькими строками html кода, я ее добавил сюда в блог для примера (слева на странице). Цвета, размер и шрифты настраиваются.

Вдобавок ко всему, к форме прилагается и неплохой инструмент для управления проектами DEVPROM.

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

Вы как думаете?

TDD в Омске

2008-11-27T13:07:00.004+03:00

Сегодня и завтра читаю тренинг по Test Driven Development в Омске.

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

Неее, те которые были сегодня - на две головы выше!

Правда, под конец сегодняшнего дня после написания демонстрационной игры, появилось мнение, что TDD провоцирует на написание "быдло-кода" - но завтра каждому клавиатуру в руки и будем с этим ощущением бороться :)

И немного про Омск - мне тут нравится, правда мало еще посмотрел всего. Сейчас пойду искать памятник сантехнику - торчащий из люка бронзовый мужик.
В поисках еды и бесплатного интернета нашел просто нереальную кофейню Berlin Kaffee - красивые официантки, супер-обслуживание, вкусная еда и мгновенный интернет. Если будете тут, рекомендую: Ленина 20, до 16:00 почти бесплатные бизнес-ланчи.

Skype - отличный инструмент

2008-11-17T18:03:00.004+03:00

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

Больше не нужен webex и прочие ужасающе громоздкие инструменты - внутри своей команды вам вполне хватит одного скайпа.
Работает это через Дополнения скайпа, я пробовал Mikodo - free online meetings.

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

Не забываем - 12 ноября встреча AgileRussia!

2008-10-31T23:39:00.003+03:00

12 ноября в 19:00 мы снова встречаемся, на этот раз чтобы обсудить целых четыре(!) темы.

Будут мега-практические доклады, только опыт и ничего кроме опыта:

1. Опыт применения Agile в команде, работающей одновременно над несколькими проектами. Семен Барер, менеджер проектов, Люксофт

2. Agile практики для стартапа с распределенной командой - организация процесса разработки. Дмитрий Быкадоров

3. Опыт Scrum в Web-разработке. Лавлинский Николай, Method Lab

4. Опыт организации самообучающихся команды Study Group. Денис Миллер, Agile евангелист, Agile Consulting

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

12 Ноя	Встреча AgileRussia: 4 доклада 12 ноября! Luxoft Ср, 12 Ноября 2008 в 19:00

До встречи на встрече! :)

SECR 2008 - Проведение оценок в Agile проектах

2008-10-29T19:25:00.001+03:00

Выступал на SECR на прошлой неделе с докладом про проведение оценок в Agile проектах, на основе опыта Люксофт.

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

Видео, к сожалению, нет и не было, поэтому только слайды:

Agile self-assessments

View SlideShare presentation or Upload your own. (tags: secr agile)

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

В итоге от начала до конца присутствовал всего на двух докладах:

- Вадим Савкин из CQG, Автоматизированный контроль процесса разработки ПО - как происходит сбор проектных метрик в компании и демонстрация отчетов. Отчеты были конечно замечательные - много, разноцветные, красивые - вот только зачем их столько и как много труда на них положено :) С этим вопросом выходили из зала многие.

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

А на доклад Асхата про аналитика в Agile, я, к сожалению, приехать не успел. Но судя по отзывам - после доклада Асхата долго не отпускали с вопросами :)

AgileRussia - подкасты встреч

2008-10-20T00:39:00.002+04:00

Открылся новый подкаст блог: AgileRussia - сообщество практиков Agile.

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

Сейчас опубликованы записи докладов (читать про них подробнее тут):

1. ScrumMaster - как НЕ стать команде родной матерью.

2. Внедрение SCRUM в большой компании.

3. Что такое Agile и где граница между Agile и неAgile?

Добавляйте ссылку на подкаст блог в ридеры, а еще лучше приходите на встречи!

Agile не существует. Да здравствует Agile!

2008-10-17T15:24:00.004+04:00

В среду 15 окт состоялась очередная встреча AgileRussia.ru, на которой мы говорили о:

1. ScrumMaster - как НЕ стать команде родной матерью.
Асхат делился опытом как быть хорошим скраммастером и не быть плохим :) Например, как правильно решать конфликты в команде.

2. Внедрение SCRUM в большой компании.
Никита рассказывал, как проходит внеднение SCRUM в рамках не одного проекта, а целой компании. Как это осуществить, как правильно управлять процессом перехода и какие трудности могут поджидать на пути в светлое будущее :)

3. Что такое Agile и где граница между Agile и неAgile?
Здесь немного подробнее.

Идея сделать такое обсуждение пришла из форума AgileRussia, в котором обсуждался вопрос является ли один из приведенных в пример проектов Agile или не Agile.

Также внутри нашей компании мне часто задают вопрос:

- "Дим, а этот проект Agile или не Agile?"
- "А что они сами говорят?" - обычно отвечаю я
- "Они говорят что Agile"
- "Значит Agile :)" - говорю я

Лично мое мнение, что если вам кажется, что вы делаете Agile и то как вы это делаете соответствует принципам гибкой разработки, описанным в AgileManifesto, то значит ваш проект Agile.

Тоесть нифига нет никакой четкой границы между Agile и неAgile.

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

Народу было немного, как-то очень по-домашнему, и вот к чему мы пришли (в общих чертах):

1. Зачем вообще искать эту границу?
2. Agile нет
3. Все вокруг, что соотвествует здравому смыслу - это Agile
4. Agile там, где вы считаете, что это Agile ;) (не забывая про манифест и 12 принципов)

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

Зато мы выяснили, какой проект точно НЕ Agile:

1. Нет регулярного фидбека по реализованному функционалу от заказчика
2. Нет цели - у проекта, релиза и каждой итерации
3. Нет результата - работающий продукт не показывается заказчику каждую итерацию
4. Command&Control
5. Нет сплоченой команды, которая сама принимает решения и отвечает за них
6. Нет ежедневного интенсивного живого общения

Немного фотографий:

2008-10-15 AgileRussia event

P.S. Всем, кто зарегистрировался на эвент и не пришел - двойка в дневник :)

UPD: Аудиозаписи со встречи доступны здесь.

UPD2: Еще одно описание встречи, более подробно раскрыты первые два доклада.

О User story или На тему англицизмов

2008-09-30T17:34:00.006+04:00

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

А вот например, User story, дословный перевод - история пользователя. Длинно и неудобно, чаще всего на русском говорят просто "история". Но тут само значение немного теряется - что за история, к чему история?

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

Тогда и крайне трудно-переводимое слово Product backlog становится простым - Журнал пожеланий. Согласитесь ведь, что это гораздо лучше смотрится в русском тексте, чем product backlog, backlog продукта или баклог подукта или бэклог продукта.

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

Вот кстати думаю и мега-полезная переводимая книга
Scrum and XP from the Trenches смотрелась бы лаконичней с Пожеланиями вместо Историй и Журналом пожеланий вместо product backlog.

Alexsun, как думаешь?

Cкорость разработки команды в GreenHopper

2008-09-18T18:31:00.003+04:00

Про плагин для JIRA под названием GreenHopper я уже как-то упоминал, обращая внимание на то, как открыта их разработка для любого желающего (релизы, состав итераций, текущий статус и т.п.).

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

Но меня долго удивляло, почему в Agile-ориентированном GH нет на видном месте графика Скорости разработки команды. Наконец, удалось нагуглить способ, как заставить GH отображать скорость. Что забавно, на сайте плагина в явном виде мне этот кейс найти не удалось.

А делается это так:
1. Создаем в jira custom field, например Story Points, тип поля number.
2. Идем в плагин, выбираем Configuration -> Planing Board -> Watched fields.
3. Выбираем в списке наше поле и нажимаем Start Watch.
4. Переходим на Configuration -> Cards и добавляем поле в нужное место на карточку (не забыть сделать это для всех нужных типов issue).
4.1. При этом поле будет доступно только в плагине. Чтобы видеть его в самой jira, поле нужно добавить на соотвествующие скрины в настройках jira.
5. Для каждой итерации в свойство Master (правая панель на Planning Board) проставляем релиз, к которому она относится.
6. Идем в Chart Board, выбираем нужный релиз -> Value chart -> For Story Points -> By Children и видим график скорости разработки за релиз.
6.1. Если графика нет, проверьте, указан ли Release date для релиза.

Еще одна метрика для оценки качества кода

2008-08-22T18:10:00.003+04:00

WTFs per minute

Идеальная метрика для оценки качества кода. Просто засеките время, начните рецензирование кода и считайте количество раз, когда воскликните или просто подумаете "Что это???" или "Какой идиот это написал???" (What the F?).

И никакой замороченности на анализ связанности кода и прочие "полезные" измерения.
Все предельно просто и ясно, а главное дает полное представление о качестве кода.

Оригинал здесь.

UPD: Когда писал, думал прикрепить тег Humor. Когда написал, почему-то стал воспринимать метрику серьезней.

Сколько бэклогов нужно распределенному Agile проекту?

2008-08-18T17:03:00.003+04:00

Это на самом деле вопрос к вам, ниже попробую описать свое текущее понимание происходящего.

Классический подход подразумевает всего два (три) бэклога - продукта, итерации и бэклог проблем (impediments backlog - немного частный случай, так как содержит проблемы, а не истории пользователей).

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

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

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

Итого получилось 4 + 1:
User backlog - Product backlog - Release backlog - Iteration backlog (+ Impediments backlog)

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

Персональный burndown chart

2008-07-24T17:04:00.004+04:00

Ребята подкинули идею - а не ввести ли в проекты дополнительный инструмент - персональный burndown chart?

У нас почти все проекты являются распределенными, поэтому в 100% случаев помимо физических артефактов, таких как доска или burndown на листе бумаги на стене, мы используем web-based систему для управления проектами. Это раз.

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

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

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

Планирование в Agile проектах

2008-06-30T14:00:00.006+04:00

С субботней конференции TrainingLabs, о планировании в Agile проектах.

Кстати, если вы ищите инструмент для управления распределенным Agile (и не только) проектом, рекомендую обратить внимание на http://devprom.ru - за невзрачной оболочкой кроется достаточно мощный и гибкий инструмент. Скриншоты на слайдах как раз из него.

Слайды:

| View | Upload your own

И немного фотографий с практической части:

TrainingLabs.AgilePlanning