(no subject)
30/5/06 11:02![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalenСначала был цирковой номер - мой PocketPC с установленным в нём Linux-ом. Девайс замучали, перезагрузили, потыкали во все кнопочки...
Потом опрашивали специально приглашённых Диму Харченко (![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
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 не может справиться с командой более чем на несколько десятков человек.
Потом Сергей рассказал про игру "в проектирование системы".
Лично я не согласен с идеей ограничить команду пятью вопросами к заказчику на сессию.
Обычно при разработке тебя ограничивает не общение с заказчиком, а объём информации о бизнес-процессе: он очень велик. Ну и различные, противоречивые и неполные мнения представилетей заказчика о том, как устроен бизнес-процесс.
Поэтому я предлагаю не ограничивать опрос заказчика по времени, а дать задачу большого объёма.
Потом опрашивали специально приглашённых Диму Харченко (
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 не может справиться с командой более чем на несколько десятков человек.
Потом Сергей рассказал про игру "в проектирование системы".
Лично я не согласен с идеей ограничить команду пятью вопросами к заказчику на сессию.
Обычно при разработке тебя ограничивает не общение с заказчиком, а объём информации о бизнес-процессе: он очень велик. Ну и различные, противоречивые и неполные мнения представилетей заказчика о том, как устроен бизнес-процесс.
Поэтому я предлагаю не ограничивать опрос заказчика по времени, а дать задачу большого объёма.
Tags:
(no subject)
30/5/06 11:18 (UTC)Это один из пунктов, по которым реальность заставила его резко дать задний ход.
"Extreme programming considered harmful" (тут, например) утверждает, что товарищ Бек тот ещё фрухт. Напрочь завалил дорогущий проект, наврал и ещё использовал для раздутия собственного авторитета.