(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

[dph.livejournal.com]

Гм, странно. Очень многие ответы совсем не соответствуют XP.

[singalen]

Я, увы, по XP не работаю и тренинга не проходил. Поэтому пересказал то, что запомнил.
Товарищ Бек писал, что если вам что-то надо поменять - то меняйте на здоровье.
Это, правда, относится и к любой другой технологии разработки ПО.

[beldmit.livejournal.com]

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

[singalen]

Ага. Он ещё писал в "XP explained", что в XP документация не нужна в принципе.
Это один из пунктов, по которым реальность заставила его резко дать задний ход.

"Extreme programming considered harmful" (тут, например) утверждает, что товарищ Бек тот ещё фрухт. Напрочь завалил дорогущий проект, наврал и ещё использовал для раздутия собственного авторитета.

[dph.livejournal.com]

Гм. Формально в XP как раз требуется соблюдение всех техник ;)
В отличии от какого-нибудь SCRUM.

[beldmit.livejournal.com]

И я про то же.
Что есть SCRUM? Ты его в последней беседе активно упоминал.

[singalen]

Гм. Формально в XP как раз требуется соблюдение всех техник ;)

Э, на заборе тоже написано. А он из досок.
Вы читали, как статья смешивает Бека с какашками?

5 The C3 Project Revisited

The “Chrysler Comprehensive Compensation System”, C3 in short, may well be the most often cited
and referenced software development project in history and it was the “proof by example” of the
Extreme Programming inventors. Of the 20 participants named in [Beck98C3], five subsequently
published a current total of three books ([Beck00XP], [Jeffries00Installed], [Beck01PlanningXP]) about
extreme programming and a myriad of articles ([Jeffries99ET], [BeckIEEE99Embrace],
[Williams00Strengthening], [Hendrickson01Customer], [Haungs01Pair]). Numerous other articles and
books reference the project, for example [Cockburn00Select] or [Williams00Strengthening].
Despite the heaps of information given, I have ceased the search for a clear picture about what really
happened in C3. The exaggerations are obvious. In [Haungs01Pair] it is stated that the project “was to
scale up to pay hundreds of thousands of people every week” or in [Cockburn00Select] there is talk
about “The recently completed Chrysler Comprehensive Compensation System (C3) experience.”
I found the most credible information in [Beck98C3], [BeckIEEE99Embrace] (the framed report by
Chet Hendrickson) and [Hendrickson01Customer]:
• January 1995: C3 was launched under a fixed price contract with a joint Chrysler and
contractor team.
• Since March 1996: C3 was conducted in Extreme Programming style after Kent Beck arrived,
according to Ron Jeffries. At that time the fix price contractor had failed to deliver a working
product and the project was in a mess, particularly it is reported that there was no sound
testing in place.
• August 1998: C3 was paying a pilot group of around 10 000 people.
• February 2000: C3 was cancelled after being nearly four years in Extreme Programming
mode.

Other facts that are credibly reported:
• C3 experienced a high productivity in the first 30 weeks after Kent Beck arrived and the staff
was significantly scaled down, following his advice.
• C3 was supposed to serve as a payroll application for a total of 87 000 employees and get
operational by mid 1999 [Beck98C3].
• C3 was at no point in time used to pay more than around 10 000 employees, but has proven
to be capable to pay another 20 000.
• It is reported in [Hendrickson01Customer] that the first person to play the customer role of
Extreme Programming left the project due to burn out after a few months and could not be
adequately replaced.
• Extreme Programming was retired as a development method after this project at the then
DaimlerChrysler Company.
Considering the fact that for a long time all of the major Extreme Programming experts were involved
and they used Smalltalk, which is considered to be most suitable for Extreme Programming due to its
dynamic typing, the project outcomes are not particularly convincing.

[singalen]

Все читают "XP Explained", но это умозрительно написанная книжка.
SCRUM (в Википедии) же создавали с уже набитыми шишками.

[dph.livejournal.com]

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