(no subject)

[singalen]

Сначала был цирковой номер - мой PocketPC с установленным в нём Linux-ом. Девайс замучали, перезагрузили, потыкали во все кнопочки...

Потом опрашивали специально приглашённых Диму Харченко (cossac) и Эдика Петрищева о том, как работает XP. Их дополнял Андрей Ткаченко.
Как при работе по XP борются с общими проблемами разработки ПО:
1. Как оценивать затраты на user stories - это единица функциональности в XP. При том, что разные user story могут содержать совсем разные риски. Кроме того, не все риски можно показывать заказчику - например, то, что наш программист - дятел.
User stories могут быть выясненными не до конца.
Они могут быть технически проблемными.
Ответ: не запомнил 8(

2. Как XP работает по fixed budget contract. Особенно с удалёнными заказчиками.
Ответ: этот вопрос решается работой с customer expectations. Его надо изначально ориентировать на XP.
В XP же гарантии fixed cost даются на одну итерацию.

3. Связанные и пересекающиеся user stories. Какая-то из них на более поздней итерации может заставить вас переосмыслить и переделать более раннюю функциональность.
Многие большие системы имеют сразу несколько заказчиков.
Ответ: в XP специально оттачивается скил рефакторинга и разрабатывается покрытие автоматическими тестами. Благодаря этому стоимость изменения не растёт экспоненциально с ростом системы, как то происходит при "обычной" разработке. В идеале, она остаётся фиксированной, хотя на самом деле как-то всё же растёт, Брукс всё-таки прав.

4. Как тестируют и исправляют производительность.
Ответ: не помню :) Кажется, либо она есть в user stories и тогда её тестируют automated test-ами, а исправляют unit test-ами. Или не так.

5. Как выбирают платформу для системы и как на этот выбор влияют наличие программистов и рыночная мода.
Ответ: не помню.

6. Как бороться со scope extension.
Ответ: user stories делаются на одну итерацию. В её рамках scope расширяется на соотв. число часов. Биллинг всё равно делается по рабочим часам.
Если scope расширился "вглубь"...
Дима очень живо изображал диалог менеджера с заказчиком. Например, как первый объясняет второму, что если в user story не написано, что 2x2 = 4, то выдавать 5 - это правильное поведение системы на этой итерации.


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

Большой упор делается на покрытие unit test-ами и automated test-ами (различие в том, что последние тестируют приложение целиком).

Для XP нужен специальный XP-шный заказчик, потому что гарантии даются только на одну итерацию :)

У XP есть естественный предел возможностей: размер команды. XP не может справиться с командой более чем на несколько десятков человек.


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

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

Поэтому я предлагаю не ограничивать опрос заказчика по времени, а дать задачу большого объёма.

Comments

[beldmit.livejournal.com]

Каковы границы применимости XP? В исходных книгах они мне не попадались. Очевидно, что команду больше, чем человек в 10-15 так не обустроить. Не менее очевидно, что проект должен быть гомогенным - иначе специалисты влетят в неслабую копеечку. Понятно наличие заказчика под рукой. Что еще?

[singalen]

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

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

On-site customer - как раз необязательный компонент. Потому что через месяц он сходит с ума, как описано в той же статье "Extreme programming considered harmful". Его заменяют на user stories :)

Обязательны: парное программирование - им стимулируют коммуникацию. Planning game — для того же.
Unit tests & automated tests (я знаю, что automated tests не было в оригинале. Надо.) — необходимы для обеспечения качества.
Причём эти тесты ревьюят каждый раз при изменении требований, и на их переделку уходит от 40% до 70% времени. Дима гордится тем, что у него это время ни разу не вышло за 50%.
Рефакторинг — если у всех не будет этого прокачанного скила, то стоимость изменений с ростом проекта будет расти гораздо сильнее.
Итерации и релизы, в ходе которых у заказчика всегда есть такой продукт, какой он хочет (не забывайте о работе с customer expectations).
Постоянная интеграция - я даже и не знаю, как без этого возможна командная работа.

Coding std - используется и полезен безотносительно XP.

On-site team - оказывается, необязательно при наличии постоянного телефона etc. Команда может быть успешно разбита на ДВЕ (не более) достаточно большие части.

[singalen]

Ещё один, как нам рассказывали, обязательный элемент XP: уровень команды должен быть существенно выше среднего.

Да, такая команда в любом случае будет эффективнее средней :) Но! Она даст скорость. В цифре не уверен, кажется, звучало "вдвое быстрее RUP".
А может, это просто накачка мозга участникам XP-шной команды.

[dph.livejournal.com]

Гм, сложно при наличии любой гибкой методологии, сильной и небольшой команды не быть вдвое быстрее RUP ;)

[singalen]

Не знаю, не знаю. Зная RUP только по Ларману, я бы сказал, что он очень похож на XP.
В том числе и гибкостью.
Может, Ларман его идеализирует.

А вот по сравнению с последней (вернее, первой) технологией разработки, которую я знаю — SSADM — действительно сложно не быть быстрее раз в пять.

[dph.livejournal.com]

Может, у меня просто неудачный опыт попытки внедрения RUP в проект на 10 человеко-лет (внедрял не я, но мной).

[singalen]

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

[dph.livejournal.com]

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

[singalen]

Я вообще не видел ни одного запуска RUP-а :) А сколько их было? Были ли при этом специалисты с большим опытом руководства RUP-ом?
Видел запуск SSADM. Была неделя лекций, потом полтора месяца пилотных проектов без тренера. Третий проект после двух тренировочных пошёл хорошо.
Видел запуск XP у нас - у ребят было 2-3 недели тренинга с очень хорошим тренером. Потом одни продолжили работать на внутреннем проекте, остальных забрали на живой.

[dph.livejournal.com]

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

Специалистов с большим опытом работы в RUP - не знаю. А они есть?

А SSADM - он действительно работал? Проект сделан?

[singalen]

И как у знакомых?
Я работал в конторе, которая официально работала по XP. Ну что сказать... я пытался их научить работать по XP, без толку %)

SSADM работал. Проект закончили, сдали и продавали. Может, продают до сих пор.
Scope проекта был очень велик, можно сказать, обогнал своё время. И уровень разработчиков, поэтому кое-какие компоненты получились очень корявыми. И возможности отдела продаж, поэтому продавался он мало.
Фактически, это была целая ERM-система.

[dph.livejournal.com]

Клетка С3 в таблице Коуберна. По идее может использоваться для C10 и D3, но уже нужно думать о переходе к SCRUM+XP, например.

Команда должна поместиться в одной комнате - т.е. не больше 8 человек
(в Star рекомендуют 7 человек - 4 программиста, 2 тестера, один team-lead.)
Задача - сравнительно короткая, с простой бизнес-логикой, реализуемая без узких тех.спецов (т.е. Oracle в качестве базы использовать не рекомендую).
Требования к производительности и надежности - средние.
Заказчик - должен быть готов к использованию XP, готов взять на себя все функции бизнес-аналитика и project-manager'а.

Т.е. де факто, XP - методология для внутренних проектов или для "аутосорсинга программистов" - и поэтому проблемы стоимости к проектам на XP просто не применимы.