Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > УП: Методологии > Один Agile проект

Автор: arilou 5.2.2007, 18:16

Всем привет, Завершаем проект, сделанный в стиле agile. Вот PPT'шка, которую ваш покорный слуга подготовил для разбора полетов. Может пригодится, если в ней все понятно  http://bitfold.net/files/agileproject.zip (~3MB) Спрашивайте

Автор: Bikutoru 8.2.2007, 11:30

Интересная презентация. При ее просмотре у меня возникло несколько вопросов по ее содержанию: Цитата Слайд №9. Итерационное планирование и разработка (3) «Подтягивание хвостов» с предыдущих итераций (баги, CR’ы) –  как они соотносятся по приоритетам с новой функциональностью Что такое CR? Цитата Слайд №13. Нотификации от Subversion (2) Требуйте от программистов комментариев, описывающих смысл коммита, а не содержание Что здесь имеется в виду под смыслом? Допустим у меня есть какой-то баг. Я его исправил и теперь хочу закоммитить код.Что является смыслом этого коммита? Название/код исправленного бага или что-то другое?

Автор: mr.DUDA 8.2.2007, 12:08

Цитата(Bikutoru @  8.2.2007,  10:30 ) Что здесь имеется в виду под смыслом? Допустим у меня есть какой-то баг. Я его исправил и теперь хочу закоммитить код.Что является смыслом этого коммита? Название/код исправленного бага или что-то другое? Ну наверное, имеется ввиду не пояснение типа "Updated bla-bla-bla file and bleh-bleh module", а "Fixed XYZ bug, added ABC feature, resolved GHJ issues".

Автор: arilou 8.2.2007, 13:59

Bikutoru, закономерый вопрос -- я был вынужден убрать скриншоты из-за цензуры. Описание коммита - это описание его смысла. В вашем случае это summary бага и его номер в bug tracking системе. Например Цитата Fixed bug 12121: Incorrect filter behaviour when session is abandoned Цитата(Bikutoru @  8.2.2007,  11:30 ) Что такое CR? CR == Change Request, запрос от клиента на внесение изменений.

Автор: batigoal 21.2.2007, 09:57

arilou, очень хорошо. Вопрос у меня такой - если QA-инженер каждый раз берет для тестинга свежий билд, то это, на мой взгляд, может привести к двум проблемам: 1) Необходимости чуть ли не ежедневной переустановки продукта 2) У вас не будет ни одного полностью протестированного релиза. Как справляетесь с этим? Ну и еще должен сказать. что вам повезло с клиентом. Далеко не все соглашаются на разработку продукта без детального предварительного плана (пускай даже фиктивного) и без спеки. Добавлено @ 10:04  Еще вопрос - что понимается под "динамическим" Proof of Concept? Вы его поддерживаете, что ли?

Автор: arilou 21.2.2007, 15:03

Цитата(batigoal @  21.2.2007,  09:57 ) опрос у меня такой - если QA-инженер каждый раз берет для тестинга свежий билд, то это, на мой взгляд, может привести к двум проблемам: Мы делаем code freeze, и полный functional testing на определенном билде, который разработчики называют "стабильным". Т.е. всегда есть внутренние релизы, и внешние - идущие к клиенту. Внешний практически всегда проходит полноценное тестирование. Цитата(batigoal @  21.2.2007,  09:57 ) динамическим" Proof of Concept Речь идет не о статическом прототипе-наборе всех форма приложения, а небольший программе (в нашем случае это была одна страница), демонстрирующей применение GWT в рамках реализации одной user story очень важного требования. Добавлено @ 15:04  Цитата(batigoal @  21.2.2007,  09:57 ) Ну и еще должен сказать. что вам повезло с клиентом.  Адназначна.

Автор: batigoal 21.2.2007, 15:17

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

Автор: arilou 21.2.2007, 15:28

Цитата(batigoal @  21.2.2007,  15:17 ) Так а в чем "динамичность"?  В отсутствии статичности :-) Статичность - это как HTML прототип в моем случае. Динамичность - это прога на джаве.

Автор: batigoal 22.2.2007, 09:01

Ясно.

Автор: Bose 26.2.2007, 19:10

Цитата(arilou @  5.2.2007,  18:16 ) Спрашивайте    Проект был завршён успешно? ;) Опыт использования упомянутых инструментов уже был у всех участников команды?

Автор: arilou 26.2.2007, 19:15

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

Автор: Bose 26.2.2007, 22:32

Цитата(arilou @  26.2.2007,  19:15 ) Bose, была успешно завершена первая стадия (сейчас в продакшне). Кроме XPlanner'а со всеми остальными тулзами команда уже работала раньше. Отлично  Тихо завидую    А как личные впечатления? Это удобно? Какие-то жалобы от девелоперов, тестировщика, клиента были? Как клиент воспринял такой подход?  Кто был инициатором применения Agile подхода? ;)

Автор: arilou 26.2.2007, 23:04

Цитата(Bose @  26.2.2007,  22:32 ) как личные впечатления? Это удобно? Какие-то жалобы от девелоперов, тестировщика, клиента были? Как клиент воспринял такой подход?  Кто был инициатором применения Agile подхода? ;) Клиент не хотел сначала, но я его убедил. Все остальные были в восторге, но пришлось попотеть.

Автор: Bose 27.2.2007, 00:42

Цитата(arilou @  26.2.2007,  23:04 ) Клиент не хотел сначала, но я его убедил. Нельзя ли тут немного поподробнее? У клиента был какой-то свой взгляд на то как должна вестись разработка? Имел ли он представление о Agile?  Просто мне кажется(именно кажется, ибо реального "контрактного" опыта работы с клиентом у меня нет), что в целесообразности и удобстве Agile можно убедить любого pазумного человека. Если конечно воплощение этот будет одинаково гибким и для девелоперов и для заказчиков.

Автор: batigoal 27.2.2007, 08:55

Цитата(Bose @  27.2.2007,  01:42 ) что в целесообразности и удобстве Agile можно убедить любого pазумного человека. Человека - да, а вот организацию...

Автор: chief39 14.3.2007, 14:21

Цитата(batigoal @  21.2.2007,  09:57 ) Ну и еще должен сказать. что вам повезло с клиентом. Далеко не все соглашаются на разработку продукта без детального предварительного плана (пускай даже фиктивного) и без спеки. Хорошие клиенты знают что такое agile. Как правило, если этот клиент впервые с вами работает - он захочет полные спеки, план, скоп проекта, отчётности и сроки. То есть RUP. В общем, он захочет водопад. Всё медленно, но верно и по уставу.  Agile - это не process oriented, a people oriented подход. Он подразумевает сплочённость команды, её профессионализм, отсутствие жёсткой привязки к документам и перегруженности документов информацией и каждодневной борьбой за актуальность документов и дел в проекте. Большая часть общения - устно и лично. Т.е. главное не то. что всё зафиксировали в документах, а то, что каждый воспринял это и зафиксировал в мозгах. Если возникают некие отклонения в понимании и этому способствует отсутствие детальнейшей доки - agile подход устраняет эту проблему краткостью итераций. То есть, каждая новая итерация - это спрямление пути, с которого, возможно, немного свернули. Кроме того, agile обязательно подразумевает доверие клиента к команде Грубо говоря, RUP подазумевает роту новобранцев, детальный устав и "медленно ли плохо, но постепенно мы это сделаем и клиент всегда видит как идут дела". Agile требует небольшую спаянную команду спецназа, в которой каждый знает каждого, доверяет и оценивает его силы. И, кроме того, мудрое ывсшее командование, которое уверенно в команде и знает что "ребята не подведут". Ессно, в команде должна быть хорошая мотивация, тут не проканает "Эй ты, да, ты. Иди сюда. Вот тебе юзкэйс, вот тебе спецификация, вот тебе срок. Больше тебя ничего не должно волновать. Через месяц проверю". Цитата(Bose @  27.2.2007,  00:42 ) что в целесообразности и удобстве Agile можно убедить любого pазумного человека. Если конечно воплощение этот будет одинаково гибким и для девелоперов и для заказчиков.   См. выше. Опыт и сплочённость команды + доверие(а желательно опыт работы с ним) клиента Цитата(batigoal @  27.2.2007,  08:55 ) еловека - да, а вот организацию...  Зе сейм.

Автор: arilou 14.3.2007, 16:42

Цитата(chief39 @  14.3.2007,  14:21 ) ак правило, если этот клиент впервые с вами работает - он захочет полные спеки, план, скоп проекта, отчётности и сроки. То есть RUP. В общем, он захочет водопад. Всё медленно, но верно и по уставу.  chief39, в нашем случае клиент был новый. Добавлено @ 16:45  Цитата(Bose @  27.2.2007,  00:42 ) У клиента был какой-то свой взгляд на то как должна вестись разработка? Имел ли он представление о Agile?  Он хотел детальный проджект план, и представления об agile у него не было  Но мы его убедили, что для него это будет выгоднее. Но был и другой прецедент -- клиент хотел тотальный подсчет всего и вся до начала проекта, начиная от детальнейшей спеки, заканчивая time line, графиком поставок, и прочее. На agile его не убедили

Автор: chief39 14.3.2007, 17:22

Цитата(arilou @  14.3.2007,  16:42 ) chief39, в нашем случае клиент был новый. Ловко провернули   Респект

Автор: arilou 14.3.2007, 17:30

Цитата(arilou @  14.3.2007,  16:42 ) На agile его не убедили  И из-за этого проект не получили. Но, скорее всего это и к лучшему -- он был уверен, что если все детализировать на начальном этапе, то потом CR'ов не будет   Фантазер

Автор: sandello 14.4.2007, 21:30

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

Автор: chief39 15.4.2007, 15:09

Цитата(sandello @  14.4.2007,  21:30 ) Если я правильно понял, он описывает унифицированный процесс, не RUP. Его процесс - итерационный, так же как и в agile, планируется итерация и т.д. В чем же отличия? В меньшем количестве документов? Т.е. больше отдается на откуп голове? Как сказал наш тренер - Agile ни в одной строчке не противоречит РУПу. Типа, всё по конституции. Но, основной дух эджайла - это именно "голова", доверие, профессионализм, маленькие итерации для быстрой изменчивости по ситуации. Грубо говоря, традиционный РУП - это больая страна с законами, в которых всё расписано, которые надо соблюдать и переписывать с поправками как бы они не мешали порой нормальной жизни. Эджайл - больше для сплочённого сообщества, которые могут работать вместе и без законов, и соблюдения многих бумажек. Потому что каждый "знает" каждого и доверяет. И ситуации "а мне пофик что вам не нравится мой поступок  - в законе это не было запрещено". Если такое начинается - то уж лучше РУП и документы где человеку дословно описано что, как, зачем и что будет "если не..." Тогда меньше шансов спихнуть на незнание, свалить на другого и просто пойти "поперёк" особо и не выпендриваясь. Добавлено через 14 минут и 45 секунд Цитата(sandello @  14.4.2007,  21:30 ) Если я правильно понял, он описывает унифицированный процесс, не RUP. Не заморачивайся  http://en.wikipedia.org/wiki/Rational_Unified_Process придумали  Rational и назвали его а-ля "наш РУП"  На самом деле эта идея лежала на поверхности многие десятилетия, её все использовали и называли по-своему, просто РУП стла стандартом де-факто и они теперь с умными лицами корчат из себя изобретателей  Так же как с принципом:                   ---------> Замысел(сбор требований, определение сути) ------>-                   |                                                                                                     | Анализ(реагирование, оценка)                                        Планирование( расчёт, конкретизация)                   |                                                                                                     |                    ---<----------  Реализация(внедрение, осуществление) <--------- Его юзают уже чёрт знает сколько лет, каждый переиначивает как-то, подгоняет под конкретную потребность, переназывает пункты и провозглашает: Я изобрёл колесо!(его так часто и рисуют  ), оно должно выглядеть так и не иначе! А потом люди морочат себе голову, пытаясь выудить отличия, наёти первооткрывателя и понять принципиальную разницу  Rational-овцы просто взяли, придумали конкретные названия для фаз и накидали конкретики - вот и вышел огуречик со звучным названием РУП  Так же как с POJO  - все "это делали", но появляется такое вот конкретное название - и все бросаются поглядеть - "Ух ты! А как это? в чём отличие от простых классов? Почему тогда отдельное название? Я тоже хочу попробовать POJO!"

Автор: sandello 15.4.2007, 16:00

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

Автор: batigoal 15.4.2007, 22:53

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

Автор: sandello 16.4.2007, 08:24

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

Автор: batigoal 16.4.2007, 08:48

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

Автор: arilou 26.4.2007, 10:52

Цитата(sandello @  16.4.2007,  08:24 ) МХО, утверждение о необходимости коммитить только готовые куски - довольно спорное. Если задача большая и над ней работают несколько человек, то как им обмениваться наработками? Бить задачу на куски в соответствии с будущими коммитами?  Это не задача уже получается, а подсистема. Думаю, имеет смысл делать микро-планирование в ее рамках. Основная сложность тут - увязать планы с другими подсистемами, чтобы не было простоев.

Автор: Kefir 27.6.2007, 23:18

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

Автор: arilou 28.6.2007, 09:21

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

Автор: lvovin 7.7.2007, 10:17

Проект активно разрабатывается. В данный момент работают два программиста, которые до него не имели никакого опыта в agile. Коуч (это я) снялся с проекта уже месяца как четыре. Сегодня пришло письмо от заказчика: Цитата just want to tell you that my new client has very much approved the reliability and quality of [name of the product]. You have to understand that he works together closely with their own IT company and apparently he has had much worse experience with them.   Please tell the team!   Thx a lot for the excellent work!

Автор: arilou 7.7.2007, 10:52

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

Автор: it7ent 9.7.2007, 18:17

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

Автор: lvovin 10.7.2007, 17:43

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

Автор: arilou 10.7.2007, 19:52

Цитата(it7ent @  9.7.2007,  18:17 ) 1. Какова длительность проекта, как вы ее оценивали? Оценивал http://forum.vingrad.ru/index.php?showtopic=162443&view=findpost&p=1190314, плюс вносил повышающие коэффициенты на тестирование и менеджмент. Цитата(lvovin @  10.7.2007,  17:43 ) Впоследствии и оказалось, что фактическая трудоемкость разошлась с оценкой. По деньгам вышло примерно то, что и было в пропоузале. По фичам - меньше. Клиент остался доволен.

Автор: Stampede 25.7.2007, 19:50

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

Автор: arilou 26.7.2007, 15:58

Цитата(Stampede @  25.7.2007,  19:50 ) Я так понимаю, твоя роль в проекте - ведущий разработчик? Неа, PM  Причем опыта с Java у меня Zero. Ведущий отметился в этой теме, как коуч (lvovin). Основная заслуга day-to-day agile mgmt - у него. Цитата(Stampede @  25.7.2007,  19:50 ) Как я понял, проект был выполнен в срок в устроившем заказчика объеме. Можешь ли ты оценить разницу в продуктивности и качестве готового продукта по сравнению с тем, если бы система разрабатывалась традиционно, сверху вниз? По продуктивности: скорее всего, программисты бы быстрее отрапортовали, что "готово". Однако: 1) полная сборка проекта включает в себя сборку GWT и занимает 12 минут (так надо, почему - не знаю  ). если бы программеры не писали тесты в стиле TDD, то представь себе процесс разработки   - через 3 компиляции таким станешь  2) в дни поставок хотелось сказать "все, нафек ваш TDD, фиксите баги! ", но сдерживал себя. 3) если бы разрабатывали сверху вниз, то заказчик своими забубосами со сменой приоритетов и постоянным потоком инфы мне бы плешь проел   Цитата(Stampede @  25.7.2007,  19:50 ) Насколько сильно изменилась программная модель прикладной области на пути от прототипа к готовому продукту? Были ли это изменения чисто экстенсивного характера (добавление новых полей), или более существенные? Скажем, связанные с особенностями персистенции или касающиеся взаимной связи сущностей разного типа. Ну, в прототипе модели-то и не было - только proof of concept одной насыщенной страницы, который выполнялся на клиенте. Насколько я это видел, развитие шло достаточно стабильно, экстенсивно, но один или два раза возникали заморочки с организацией связи между сущностями, т.к. программер реализовал это так, что не получалось по-простому новое требование клиента внести. Все, что касается persistence, закрывал Hibernate и Spring. Очень помогали АОП-шные фишки спринга (логгинг, шифрование, права доступа) Цитата(Stampede @  25.7.2007,  19:50 ) Я не увидел в презентации термина "vertical slice" © Род Джонсон Глянул, что за зверь такой. Сходу ответить не могу, сча попрошу lvovin заглянуть. Цитата(Stampede @  25.7.2007,  19:50 ) Порадовался, что ваш QA-специалист самостоятельно пишет тесты. Сколько я видел, эти ребята максимум могут развернуть продукт и в определенном порядке потыкать в кнопки smile Да, тестер у нас был просто мега! Вообще, все ребята молодцы, без них врядли бы проект удался.

Автор: sandello 14.4.2008, 17:00

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

Автор: Kangaroo 14.4.2008, 17:08

Цитата(sandello @  14.4.2008,  17:00 ) Ээээ можно еще выложить ppt-шку. Для тех, кто не успел. В идеале - сюда залить  Присоединяюсь!

Автор: arilou 14.4.2008, 19:24

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

Автор: gEndelf 2.6.2008, 17:18

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

Автор: mikolas 2.6.2008, 18:33

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

Автор: arilou 2.6.2008, 23:06

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

Автор: cemick 24.3.2010, 10:00

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

Автор: Jey_k 9.9.2010, 21:52

Вброшу свои 5 копеек. Методологии Agile тем и хороши, что очень хорошо настриваемы и масштабируемы. Ну XP не трогаем сейчас. Убеждать дело неблагодарное. Если компания не созрела до Agile, то насильственное внедрение только все усугубит. Должен быть общий курс на то что мы делаем качественные вещи, а не коленочное ###. Сейчас пытаюсь использовать элементы SCRUM. Брать методологию и внедрять полностью нужно не всегда.  Мне например пока нужны только бэклог, игра в планирование и итерации длиной в один рабочий день, потом увеличу

Автор: surlac 21.2.2011, 18:20

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

Автор: Jey_k 13.5.2011, 12:36

Цитата(surlac @  21.2.2011,  18:20 ) руководители должны использовать методы Agile принудительно? Еще раз повторюсь - компания консервативная, поэтому Agile вводится принудительно. Понимаете дело в чем, нельзя гибкие методологии внедрить бюрократическими методами. Ведь agile - это прежде всего философия. Без понимания ее ценностей и почему в ней все именно так толку не будет. Лучше дальше ватерфоллить. Внедрение гибких методологий начинается снизу, с команд, и далее переходит на топ-менеджмент. Сама по себе контора это не сделает, т.к. не знает как. Нужен SCRUM-тренер на несколько месяцев в состав компании. Т.е. человек который будет фасилитировать все дискуссии, направлять, показывать и отыгрывать вместе со всеми.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)