(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 14:48 (UTC)Я работал в конторе, которая официально работала по XP. Ну что сказать... я пытался их научить работать по XP, без толку %)
SSADM работал. Проект закончили, сдали и продавали. Может, продают до сих пор.
Scope проекта был очень велик, можно сказать, обогнал своё время. И уровень разработчиков, поэтому кое-какие компоненты получились очень корявыми. И возможности отдела продаж, поэтому продавался он мало.
Фактически, это была целая ERM-система.