Всем привет,

Завершаем проект, сделанный в стиле agile. Вот PPT'шка, которую ваш покорный слуга подготовил для разбора полетов. Может пригодится, если в ней все понятно 

Презентация тут (~3MB)

Спрашивайте   

Это сообщение отредактировал(а) arilou - 2.6.2008, 23:05

Интересная презентация. При ее просмотре у меня возникло несколько вопросов по ее содержанию:


Что такое CR?


Что здесь имеется в виду под смыслом? Допустим у меня есть какой-то баг. Я его исправил и теперь хочу закоммитить код.Что является смыслом этого коммита? Название/код исправленного бага или что-то другое?

Ну наверное, имеется ввиду не пояснение типа "Updated bla-bla-bla file and bleh-bleh module", а "Fixed XYZ bug, added ABC feature, resolved GHJ issues".

Bikutoru, закономерый вопрос -- я был вынужден убрать скриншоты из-за цензуры.

Описание коммита - это описание его смысла. В вашем случае это summary бага и его номер в bug tracking системе. Например





CR == Change Request, запрос от клиента на внесение изменений.

arilou, очень хорошо.

Вопрос у меня такой - если QA-инженер каждый раз берет для тестинга свежий билд, то это, на мой взгляд, может привести к двум проблемам:
1) Необходимости чуть ли не ежедневной переустановки продукта
2) У вас не будет ни одного полностью протестированного релиза.

Как справляетесь с этим?

Ну и еще должен сказать. что вам повезло с клиентом. Далеко не все соглашаются на разработку продукта без детального предварительного плана (пускай даже фиктивного) и без спеки.

Добавлено @ 10:04 
Еще вопрос - что понимается под "динамическим" Proof of Concept? Вы его поддерживаете, что ли?

Мы делаем code freeze, и полный functional testing на определенном билде, который разработчики называют "стабильным". Т.е. всегда есть внутренние релизы, и внешние - идущие к клиенту. Внешний практически всегда проходит полноценное тестирование.


Речь идет не о статическом прототипе-наборе всех форма приложения, а небольший программе (в нашем случае это была одна страница), демонстрирующей применение GWT в рамках реализации одной user story очень важного требования.

Добавлено @ 15:04 

Адназначна.

Так а в чем "динамичность"?

В отсутствии статичности :-) Статичность - это как HTML прототип в моем случае. Динамичность - это прога на джаве.

Ясно.

Проект был завршён успешно? ;)

Опыт использования упомянутых инструментов уже был у всех участников команды? 

Bose, была успешно завершена первая стадия (сейчас в продакшне). Кроме XPlanner'а со всеми остальными тулзами команда уже работала раньше.

Отлично  Тихо завидую   

А как личные впечатления? Это удобно? Какие-то жалобы от девелоперов, тестировщика, клиента были? Как клиент воспринял такой подход? 
Кто был инициатором применения Agile подхода? ;)

Клиент не хотел сначала, но я его убедил. Все остальные были в восторге, но пришлось попотеть.

Нельзя ли тут немного поподробнее? У клиента был какой-то свой взгляд на то как должна вестись разработка? Имел ли он представление о Agile? 

Просто мне кажется(именно кажется, ибо реального "контрактного" опыта работы с клиентом у меня нет), что в целесообразности и удобстве Agile можно убедить любого pазумного человека. Если конечно воплощение этот будет одинаково гибким и для девелоперов и для заказчиков. 

Человека - да, а вот организацию...

Хорошие клиенты знают что такое 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, велкам на Винграде   

Вопросы: 
1. Какова длительность проекта, как вы ее оценивали?
2. На итерации делалась "оценка трудозатрат на каждое требование", никогда не было оценок > 2 недель? 
3. Всегда укладывались в 2 недели, а если не укладывались, то что делали?

1. Был первоначальный пропоузал, который делался пм-ом. Он мог делаться кем угодно, хоть предпродажным аналистом, который никакого отношения к проекту не имеет. Понятно, что его оценка должна быть похоже на правду, чтобы зацепить клиента.
  Но после это вступает в действие другой подход. Команда говорит, ок, та оценка это хорошо, она позволяет примерно увидеть когда ты получишь что-то работоспособное, но давай мы будет работать немного не так. Пусть нашей целью будет создание работающего качественного продукта, доступного в любой момент времени с последними фичами. И по ходу дела ты сам будешь видеть прогресс и активно участвовать в постоянном планировании.
  Впоследствии и оказалось, что фактическая трудоемкость разошлась с оценкой. Но благодаря тому, что мы перешли на agile подход, клиент всю ситуацию видел как она развивалась и скорректировал свои планы так, что мы выпустили первую бету к определенной дате (опять же чуть скорректированной) с меньшим числом фич. После того как демонстрация прошла на ура, разработка вошла в более спокойное русло - были известны фичи намного вперед, и из-за отсутствия их жесткой привязки к каким-то срокам можно было спокойно заниматься краткосрочным планированием и разработкой.

2. Бывают и такие фичи, что не влалят. Тогда они делятся на логические куски, которые сами по себе полезны будучи проимплементированы по очереди. Но бывает что клиенту нужно все или ничего. Тогда разбиение все равно делается, просто результаты промежуточной итерации ему полезны лишь чтобы посмотреть на прогресс, а сам билд никуда не идет кроме тестирования. Или в крайнем случае клиент может сказать давайте что есть, если фича совсем разбухла, а показывать уже надо.

3. Всегда. В следующие две недели старые должки просто перепланируются на новые итерации.  Конечно лучше перепланировать задолго до окончания итерации, чтобы не было сюрпризов для всех заинтересованных сторон. Клиент конечно вправе подвигать сроки своих релизов, тогда делается еще одна (микро-)итерация. Но обычная итерация всегда влазит в две недели по определению.

Оценивал методом Кларка, плюс вносил повышающие коэффициенты на тестирование и менеджмент.

По деньгам вышло примерно то, что и было в пропоузале. По фичам - меньше. Клиент остался доволен.

Это сообщение отредактировал(а) arilou - 10.7.2007, 19:53

arilou, спасибо - очень интересная презентация и вообще интересный опыт. Плюс без разговоров 

Я так понимаю, твоя роль в проекте - ведущий разработчик?

Интересно было бы услышать комментарии по некоторым моментам.

• Как я понял, проект был выполнен в срок в устроившем заказчика объеме. Можешь ли ты оценить разницу в продуктивности и качестве готового продукта по сравнению с тем, если бы система разрабатывалась традиционно, сверху вниз?
  
• Насколько сильно изменилась программная модель прикладной области на пути от прототипа к готовому продукту? Были ли это изменения чисто экстенсивного характера (добавление новых полей), или более существенные? Скажем, связанные с особенностями персистенции или касающиеся взаимной связи сущностей разного типа.
  
• Я не увидел в презентации термина "vertical slice" © Род Джонсон. Хоть это и не из глоссария agile programming, но вещь полезная, интуитивно понятная, и наверняка использовалась в проекте. Или это понятие подразумевалось включенным в "proof of concept"?
  
• Порадовался, что ваш QA-специалист самостоятельно пишет тесты. Сколько я видел, эти ребята максимум могут развернуть продукт и в определенном порядке потыкать в кнопки 

Вот. Ну а вообще рад за вас, молодцы!

Неа, PM  Причем опыта с Java у меня Zero. Ведущий отметился в этой теме, как коуч (lvovin). Основная заслуга day-to-day agile mgmt - у него.


По продуктивности: скорее всего, программисты бы быстрее отрапортовали, что "готово". Однако:
1) полная сборка проекта включает в себя сборку GWT и занимает 12 минут (так надо, почему - не знаю  ). если бы программеры не писали тесты в стиле TDD, то представь себе процесс разработки   - через 3 компиляции таким станешь 

2) в дни поставок хотелось сказать "все, нафек ваш TDD, фиксите баги! ", но сдерживал себя.

3) если бы разрабатывали сверху вниз, то заказчик своими забубосами со сменой приоритетов и постоянным потоком инфы мне бы плешь проел  


Ну, в прототипе модели-то и не было - только proof of concept одной насыщенной страницы, который выполнялся на клиенте. Насколько я это видел, развитие шло достаточно стабильно, экстенсивно, но один или два раза возникали заморочки с организацией связи между сущностями, т.к. программер реализовал это так, что не получалось по-простому новое требование клиента внести.
Все, что касается persistence, закрывал Hibernate и Spring. Очень помогали АОП-шные фишки спринга (логгинг, шифрование, права доступа)


Глянул, что за зверь такой. Сходу ответить не могу, сча попрошу lvovin заглянуть.


Да, тестер у нас был просто мега! Вообще, все ребята молодцы, без них врядли бы проект удался.

Ээээ можно еще выложить ppt-шку. Для тех, кто не успел. В идеале - сюда залить   

Присоединяюсь!   

обновил ссылку на первой странице

прошу залить ещё )

Присоединяюсь к просьбе 

gEndelf, 
mikolas, 

сорри. обновил еще раз.

а есть возможность снова обновить ссылочку?  

Вброшу свои 5 копеек. Методологии Agile тем и хороши, что очень хорошо настриваемы и масштабируемы. Ну XP не трогаем сейчас.

Убеждать дело неблагодарное. Если компания не созрела до Agile, то насильственное внедрение только все усугубит. Должен быть общий курс на то что мы делаем качественные вещи, а не коленочное ###.

Сейчас пытаюсь использовать элементы SCRUM. Брать методологию и внедрять полностью нужно не всегда. 

Мне например пока нужны только бэклог, игра в планирование и итерации длиной в один рабочий день, потом увеличу

Есть компания ("созрела до Agile", но все же очень консервативная). На корпоративном уровне вводится Agile. Как регламентировать это новшество, т.е. в каком документе должно быть описано, что руководители должны использовать методы Agile принудительно? 
Еще раз повторюсь - компания консервативная, поэтому Agile вводится принудительно.

Понимаете дело в чем, нельзя гибкие методологии внедрить бюрократическими методами. Ведь agile - это прежде всего философия. Без понимания ее ценностей и почему в ней все именно так толку не будет. Лучше дальше ватерфоллить.

Внедрение гибких методологий начинается снизу, с команд, и далее переходит на топ-менеджмент.

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