Хорошие клиенты знают что такое agile.
Как правило, если этот клиент впервые с вами работает - он захочет полные спеки, план, скоп проекта, отчётности и сроки. То есть RUP. В общем, он захочет водопад. Всё медленно, но верно и по уставу. 

Agile - это не process oriented, a people oriented подход.
Он подразумевает сплочённость команды, её профессионализм, отсутствие жёсткой привязки к документам и перегруженности документов информацией и каждодневной борьбой за актуальность документов и дел в проекте.
Большая часть общения - устно и лично.
Т.е. главное не то. что всё зафиксировали в документах, а то, что каждый воспринял это и зафиксировал в мозгах. Если возникают некие отклонения в понимании и этому способствует отсутствие детальнейшей доки - agile подход устраняет эту проблему краткостью итераций. То есть, каждая новая итерация - это спрямление пути, с которого, возможно, немного свернули.

Кроме того, agile обязательно подразумевает доверие клиента к команде

Грубо говоря, RUP подазумевает роту новобранцев, детальный устав и "медленно ли плохо, но постепенно мы это сделаем и клиент всегда видит как идут дела".
Agile требует небольшую спаянную команду спецназа, в которой каждый знает каждого, доверяет и оценивает его силы. И, кроме того, мудрое ывсшее командование, которое уверенно в команде и знает что "ребята не подведут". Ессно, в команде должна быть хорошая мотивация, тут не проканает "Эй ты, да, ты. Иди сюда. Вот тебе юзкэйс, вот тебе спецификация, вот тебе срок. Больше тебя ничего не должно волновать. Через месяц проверю".



См. выше. Опыт и сплочённость команды + доверие(а желательно опыт работы с ним) клиента


Зе сейм.

chief39, в нашем случае клиент был новый.

Добавлено @ 16:45 

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

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

Ловко провернули   Респект 

И из-за этого проект не получили. Но, скорее всего это и к лучшему -- он был уверен, что если все детализировать на начальном этапе, то потом CR'ов не будет   Фантазер    

Можно вопрос?
Постепенно продираюсь через книгу Крега Лармана «Применение UML и шаблонов проектирования». Если я правильно понял, он описывает унифицированный процесс, не RUP. Его процесс - итерационный, так же как и в agile, планируется итерация и т.д. В чем же отличия? В меньшем количестве документов? Т.е. больше отдается на откуп голове?

Еще хотел поинтересоваться, какую политику использовали в subversion: с монопольными блокировками или нет?

Это сообщение отредактировал(а) sandello - 14.4.2007, 21:41

Как сказал наш тренер - Agile ни в одной строчке не противоречит РУПу. Типа, всё по конституции.
Но, основной дух эджайла - это именно "голова", доверие, профессионализм, маленькие итерации для быстрой изменчивости по ситуации.
Грубо говоря, традиционный РУП - это больая страна с законами, в которых всё расписано, которые надо соблюдать и переписывать с поправками как бы они не мешали порой нормальной жизни.
Эджайл - больше для сплочённого сообщества, которые могут работать вместе и без законов, и соблюдения многих бумажек. Потому что каждый "знает" каждого и доверяет. И ситуации "а мне пофик что вам не нравится мой поступок  - в законе это не было запрещено". Если такое начинается - то уж лучше РУП и документы где человеку дословно описано что, как, зачем и что будет "если не..." Тогда меньше шансов спихнуть на незнание, свалить на другого и просто пойти "поперёк" особо и не выпендриваясь.

Добавлено через 14 минут и 45 секунд

Не заморачивайся 
РУП придумали  Rational и назвали его а-ля "наш РУП" 

На самом деле эта идея лежала на поверхности многие десятилетия, её все использовали и называли по-своему, просто РУП стла стандартом де-факто и они теперь с умными лицами корчат из себя изобретателей 
Так же как с принципом:

                  ---------> Замысел(сбор требований, определение сути) ------>-
                  |                                                                                                     |
Анализ(реагирование, оценка)                                        Планирование( расчёт, конкретизация)
                  |                                                                                                     |
                   ---<----------  Реализация(внедрение, осуществление) <---------


Его юзают уже чёрт знает сколько лет, каждый переиначивает как-то, подгоняет под конкретную потребность, переназывает пункты и провозглашает: Я изобрёл колесо!(его так часто и рисуют  ), оно должно выглядеть так и не иначе! А потом люди морочат себе голову, пытаясь выудить отличия, наёти первооткрывателя и понять принципиальную разницу 
Rational-овцы просто взяли, придумали конкретные названия для фаз и накидали конкретики - вот и вышел огуречик со звучным названием РУП 
Так же как с POJO  - все "это делали", но появляется такое вот конкретное название - и все бросаются поглядеть - "Ух ты! А как это? в чём отличие от простых классов? Почему тогда отдельное название? Я тоже хочу попробовать POJO!"

Еще вопрос. Каким-то средством для сбора/упорядочивания требований пользовались?

sandello, как я понимаю, термины "agile" и "итеративный подход" лежат в разных плоскостях, вот и всё.

ИМХО, утверждение о необходимости коммитить только готовые куски - довольно спорное. Если задача большая и над ней работают несколько человек, то как им обмениваться наработками? Бить задачу на куски в соответствии с будущими коммитами?

Мы выделяем под такую задачу отдельный интеграционный стрим (у нас ClearCase UCM). А в основной integration он вливается уже по готовности.

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

arilou, ссылка на файл не работает... обнови пж-ста.

Kefir, обновил, см. первый пост.

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

lvovin, велкам на Винграде