|
|
|
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
Всем привет,
Завершаем проект, сделанный в стиле agile. Вот PPT'шка, которую ваш покорный слуга подготовил для разбора полетов. Может пригодится, если в ней все понятно Презентация тут (~3MB) Спрашивайте Это сообщение отредактировал(а) arilou - 2.6.2008, 23:05 |
|||
|
||||
Bikutoru |
|
||||
Увлекающийся Профиль Группа: Участник Сообщений: 522 Регистрация: 24.5.2005 Где: Москва Репутация: нет Всего: 22 |
Интересная презентация. При ее просмотре у меня возникло несколько вопросов по ее содержанию:
Что такое CR?
Что здесь имеется в виду под смыслом? Допустим у меня есть какой-то баг. Я его исправил и теперь хочу закоммитить код.Что является смыслом этого коммита? Название/код исправленного бага или что-то другое? -------------------- Человек, словно в зеркале мир — многолик, Он ничтожен — и он же безмерно велик! Омар Хайям |
||||
|
|||||
mr.DUDA |
|
|||
3D-маньяк Профиль Группа: Экс. модератор Сообщений: 8244 Регистрация: 27.7.2003 Где: город-герой Минск Репутация: нет Всего: 232 |
Ну наверное, имеется ввиду не пояснение типа "Updated bla-bla-bla file and bleh-bleh module", а "Fixed XYZ bug, added ABC feature, resolved GHJ issues". -------------------- |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
Bikutoru, закономерый вопрос -- я был вынужден убрать скриншоты из-за цензуры.
Описание коммита - это описание его смысла. В вашем случае это summary бага и его номер в bug tracking системе. Например
CR == Change Request, запрос от клиента на внесение изменений. |
|||
|
||||
batigoal |
|
|||
Нелетучий Мыш Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: нет Всего: 151 |
arilou, очень хорошо.
Вопрос у меня такой - если QA-инженер каждый раз берет для тестинга свежий билд, то это, на мой взгляд, может привести к двум проблемам: 1) Необходимости чуть ли не ежедневной переустановки продукта 2) У вас не будет ни одного полностью протестированного релиза. Как справляетесь с этим? Ну и еще должен сказать. что вам повезло с клиентом. Далеко не все соглашаются на разработку продукта без детального предварительного плана (пускай даже фиктивного) и без спеки. Добавлено @ 10:04 Еще вопрос - что понимается под "динамическим" Proof of Concept? Вы его поддерживаете, что ли? -------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
Мы делаем code freeze, и полный functional testing на определенном билде, который разработчики называют "стабильным". Т.е. всегда есть внутренние релизы, и внешние - идущие к клиенту. Внешний практически всегда проходит полноценное тестирование. Речь идет не о статическом прототипе-наборе всех форма приложения, а небольший программе (в нашем случае это была одна страница), демонстрирующей применение GWT в рамках реализации одной user story очень важного требования. Добавлено @ 15:04 Адназначна. |
|||
|
||||
batigoal |
|
|||
Нелетучий Мыш Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: нет Всего: 151 |
Так а в чем "динамичность"? -------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
В отсутствии статичности :-) Статичность - это как HTML прототип в моем случае. Динамичность - это прога на джаве. |
|||
|
||||
batigoal |
|
|||
Нелетучий Мыш Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: нет Всего: 151 |
Ясно.
-------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
Bose |
|
|||
Эксперт Профиль Группа: Участник Клуба Сообщений: 1458 Регистрация: 5.3.2005 Где: Riga, Latvia Репутация: нет Всего: 51 |
Проект был завршён успешно? ;) Опыт использования упомянутых инструментов уже был у всех участников команды? |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
Bose, была успешно завершена первая стадия (сейчас в продакшне). Кроме XPlanner'а со всеми остальными тулзами команда уже работала раньше.
|
|||
|
||||
Bose |
|
|||
Эксперт Профиль Группа: Участник Клуба Сообщений: 1458 Регистрация: 5.3.2005 Где: Riga, Latvia Репутация: нет Всего: 51 |
Отлично Тихо завидую А как личные впечатления? Это удобно? Какие-то жалобы от девелоперов, тестировщика, клиента были? Как клиент воспринял такой подход? Кто был инициатором применения Agile подхода? ;) |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
Клиент не хотел сначала, но я его убедил. Все остальные были в восторге, но пришлось попотеть. |
|||
|
||||
Bose |
|
|||
Эксперт Профиль Группа: Участник Клуба Сообщений: 1458 Регистрация: 5.3.2005 Где: Riga, Latvia Репутация: нет Всего: 51 |
Нельзя ли тут немного поподробнее? У клиента был какой-то свой взгляд на то как должна вестись разработка? Имел ли он представление о Agile? Просто мне кажется(именно кажется, ибо реального "контрактного" опыта работы с клиентом у меня нет), что в целесообразности и удобстве Agile можно убедить любого pазумного человека. Если конечно воплощение этот будет одинаково гибким и для девелоперов и для заказчиков. |
|||
|
||||
batigoal |
|
|||
Нелетучий Мыш Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: нет Всего: 151 |
Человека - да, а вот организацию... -------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
chief39 |
|
|||
карманная тигра Профиль Группа: Участник Клуба Сообщений: 1631 Регистрация: 20.5.2005 Где: Киев Репутация: нет Всего: 77 |
Хорошие клиенты знают что такое agile. Как правило, если этот клиент впервые с вами работает - он захочет полные спеки, план, скоп проекта, отчётности и сроки. То есть RUP. В общем, он захочет водопад. Всё медленно, но верно и по уставу. Agile - это не process oriented, a people oriented подход. Он подразумевает сплочённость команды, её профессионализм, отсутствие жёсткой привязки к документам и перегруженности документов информацией и каждодневной борьбой за актуальность документов и дел в проекте. Большая часть общения - устно и лично. Т.е. главное не то. что всё зафиксировали в документах, а то, что каждый воспринял это и зафиксировал в мозгах. Если возникают некие отклонения в понимании и этому способствует отсутствие детальнейшей доки - agile подход устраняет эту проблему краткостью итераций. То есть, каждая новая итерация - это спрямление пути, с которого, возможно, немного свернули. Кроме того, agile обязательно подразумевает доверие клиента к команде Грубо говоря, RUP подазумевает роту новобранцев, детальный устав и "медленно ли плохо, но постепенно мы это сделаем и клиент всегда видит как идут дела". Agile требует небольшую спаянную команду спецназа, в которой каждый знает каждого, доверяет и оценивает его силы. И, кроме того, мудрое ывсшее командование, которое уверенно в команде и знает что "ребята не подведут". Ессно, в команде должна быть хорошая мотивация, тут не проканает "Эй ты, да, ты. Иди сюда. Вот тебе юзкэйс, вот тебе спецификация, вот тебе срок. Больше тебя ничего не должно волновать. Через месяц проверю". См. выше. Опыт и сплочённость команды + доверие(а желательно опыт работы с ним) клиента Зе сейм. -------------------- Люди - это свечи. Они либо горят, либо их - в жопу!(с) |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
chief39, в нашем случае клиент был новый. Добавлено @ 16:45
Он хотел детальный проджект план, и представления об agile у него не было Но мы его убедили, что для него это будет выгоднее. Но был и другой прецедент -- клиент хотел тотальный подсчет всего и вся до начала проекта, начиная от детальнейшей спеки, заканчивая time line, графиком поставок, и прочее. На agile его не убедили |
|||
|
||||
chief39 |
|
|||
карманная тигра Профиль Группа: Участник Клуба Сообщений: 1631 Регистрация: 20.5.2005 Где: Киев Репутация: нет Всего: 77 |
-------------------- Люди - это свечи. Они либо горят, либо их - в жопу!(с) |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
И из-за этого проект не получили. Но, скорее всего это и к лучшему -- он был уверен, что если все детализировать на начальном этапе, то потом CR'ов не будет Фантазер |
|||
|
||||
sandello |
|
|||
Опытный Профиль Группа: Участник Сообщений: 295 Регистрация: 18.5.2005 Где: Пермь Репутация: нет Всего: 2 |
Можно вопрос?
Постепенно продираюсь через книгу Крега Лармана «Применение UML и шаблонов проектирования». Если я правильно понял, он описывает унифицированный процесс, не RUP. Его процесс - итерационный, так же как и в agile, планируется итерация и т.д. В чем же отличия? В меньшем количестве документов? Т.е. больше отдается на откуп голове? Еще хотел поинтересоваться, какую политику использовали в subversion: с монопольными блокировками или нет? Это сообщение отредактировал(а) sandello - 14.4.2007, 21:41 -------------------- |
|||
|
||||
chief39 |
|
|||
карманная тигра Профиль Группа: Участник Клуба Сообщений: 1631 Регистрация: 20.5.2005 Где: Киев Репутация: нет Всего: 77 |
Как сказал наш тренер - Agile ни в одной строчке не противоречит РУПу. Типа, всё по конституции. Но, основной дух эджайла - это именно "голова", доверие, профессионализм, маленькие итерации для быстрой изменчивости по ситуации. Грубо говоря, традиционный РУП - это больая страна с законами, в которых всё расписано, которые надо соблюдать и переписывать с поправками как бы они не мешали порой нормальной жизни. Эджайл - больше для сплочённого сообщества, которые могут работать вместе и без законов, и соблюдения многих бумажек. Потому что каждый "знает" каждого и доверяет. И ситуации "а мне пофик что вам не нравится мой поступок - в законе это не было запрещено". Если такое начинается - то уж лучше РУП и документы где человеку дословно описано что, как, зачем и что будет "если не..." Тогда меньше шансов спихнуть на незнание, свалить на другого и просто пойти "поперёк" особо и не выпендриваясь. Добавлено через 14 минут и 45 секунд
Не заморачивайся РУП придумали Rational и назвали его а-ля "наш РУП" На самом деле эта идея лежала на поверхности многие десятилетия, её все использовали и называли по-своему, просто РУП стла стандартом де-факто и они теперь с умными лицами корчат из себя изобретателей Так же как с принципом: ---------> Замысел(сбор требований, определение сути) ------>- | | Анализ(реагирование, оценка) Планирование( расчёт, конкретизация) | | ---<---------- Реализация(внедрение, осуществление) <--------- Его юзают уже чёрт знает сколько лет, каждый переиначивает как-то, подгоняет под конкретную потребность, переназывает пункты и провозглашает: Я изобрёл колесо!(его так часто и рисуют ), оно должно выглядеть так и не иначе! А потом люди морочат себе голову, пытаясь выудить отличия, наёти первооткрывателя и понять принципиальную разницу Rational-овцы просто взяли, придумали конкретные названия для фаз и накидали конкретики - вот и вышел огуречик со звучным названием РУП Так же как с POJO - все "это делали", но появляется такое вот конкретное название - и все бросаются поглядеть - "Ух ты! А как это? в чём отличие от простых классов? Почему тогда отдельное название? Я тоже хочу попробовать POJO!" -------------------- Люди - это свечи. Они либо горят, либо их - в жопу!(с) |
|||
|
||||
sandello |
|
|||
Опытный Профиль Группа: Участник Сообщений: 295 Регистрация: 18.5.2005 Где: Пермь Репутация: нет Всего: 2 |
Еще вопрос. Каким-то средством для сбора/упорядочивания требований пользовались?
-------------------- |
|||
|
||||
batigoal |
|
|||
Нелетучий Мыш Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: нет Всего: 151 |
sandello, как я понимаю, термины "agile" и "итеративный подход" лежат в разных плоскостях, вот и всё.
-------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
sandello |
|
|||
Опытный Профиль Группа: Участник Сообщений: 295 Регистрация: 18.5.2005 Где: Пермь Репутация: нет Всего: 2 |
ИМХО, утверждение о необходимости коммитить только готовые куски - довольно спорное. Если задача большая и над ней работают несколько человек, то как им обмениваться наработками? Бить задачу на куски в соответствии с будущими коммитами?
-------------------- |
|||
|
||||
batigoal |
|
|||
Нелетучий Мыш Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: нет Всего: 151 |
Мы выделяем под такую задачу отдельный интеграционный стрим (у нас ClearCase UCM). А в основной integration он вливается уже по готовности.
-------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
Это не задача уже получается, а подсистема. Думаю, имеет смысл делать микро-планирование в ее рамках. Основная сложность тут - увязать планы с другими подсистемами, чтобы не было простоев. |
|||
|
||||
Kefir |
|
|||
«Hakuna Matata» Профиль Группа: Комодератор Сообщений: 1878 Регистрация: 25.1.2003 Где: Tampere, Suomi Репутация: нет Всего: 87 |
arilou, ссылка на файл не работает... обнови пж-ста.
|
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
Kefir, обновил, см. первый пост.
|
|||
|
||||
lvovin |
|
|||
Новичок Профиль Группа: Участник Сообщений: 2 Регистрация: 7.7.2007 Репутация: нет Всего: нет |
Проект активно разрабатывается.
В данный момент работают два программиста, которые до него не имели никакого опыта в agile. Коуч (это я) снялся с проекта уже месяца как четыре. Сегодня пришло письмо от заказчика:
|
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
lvovin, велкам на Винграде
|
|||
|
||||
it7ent |
|
|||
Новичок Профиль Группа: Участник Сообщений: 9 Регистрация: 24.4.2007 Репутация: нет Всего: нет |
Вопросы:
1. Какова длительность проекта, как вы ее оценивали? 2. На итерации делалась "оценка трудозатрат на каждое требование", никогда не было оценок > 2 недель? 3. Всегда укладывались в 2 недели, а если не укладывались, то что делали? |
|||
|
||||
lvovin |
|
|||
Новичок Профиль Группа: Участник Сообщений: 2 Регистрация: 7.7.2007 Репутация: нет Всего: нет |
1. Был первоначальный пропоузал, который делался пм-ом. Он мог делаться кем угодно, хоть предпродажным аналистом, который никакого отношения к проекту не имеет. Понятно, что его оценка должна быть похоже на правду, чтобы зацепить клиента.
Но после это вступает в действие другой подход. Команда говорит, ок, та оценка это хорошо, она позволяет примерно увидеть когда ты получишь что-то работоспособное, но давай мы будет работать немного не так. Пусть нашей целью будет создание работающего качественного продукта, доступного в любой момент времени с последними фичами. И по ходу дела ты сам будешь видеть прогресс и активно участвовать в постоянном планировании. Впоследствии и оказалось, что фактическая трудоемкость разошлась с оценкой. Но благодаря тому, что мы перешли на agile подход, клиент всю ситуацию видел как она развивалась и скорректировал свои планы так, что мы выпустили первую бету к определенной дате (опять же чуть скорректированной) с меньшим числом фич. После того как демонстрация прошла на ура, разработка вошла в более спокойное русло - были известны фичи намного вперед, и из-за отсутствия их жесткой привязки к каким-то срокам можно было спокойно заниматься краткосрочным планированием и разработкой. 2. Бывают и такие фичи, что не влалят. Тогда они делятся на логические куски, которые сами по себе полезны будучи проимплементированы по очереди. Но бывает что клиенту нужно все или ничего. Тогда разбиение все равно делается, просто результаты промежуточной итерации ему полезны лишь чтобы посмотреть на прогресс, а сам билд никуда не идет кроме тестирования. Или в крайнем случае клиент может сказать давайте что есть, если фича совсем разбухла, а показывать уже надо. 3. Всегда. В следующие две недели старые должки просто перепланируются на новые итерации. Конечно лучше перепланировать задолго до окончания итерации, чтобы не было сюрпризов для всех заинтересованных сторон. Клиент конечно вправе подвигать сроки своих релизов, тогда делается еще одна (микро-)итерация. Но обычная итерация всегда влазит в две недели по определению. |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
Оценивал методом Кларка, плюс вносил повышающие коэффициенты на тестирование и менеджмент.
По деньгам вышло примерно то, что и было в пропоузале. По фичам - меньше. Клиент остался доволен. Это сообщение отредактировал(а) arilou - 10.7.2007, 19:53 |
|||
|
||||
Stampede |
|
|||
Гносеолог Профиль Группа: Участник Клуба Сообщений: 963 Регистрация: 25.4.2005 Где: Calgary, Alberta, Canada Репутация: нет Всего: 144 |
arilou, спасибо - очень интересная презентация и вообще интересный опыт. Плюс без разговоров
Я так понимаю, твоя роль в проекте - ведущий разработчик? Интересно было бы услышать комментарии по некоторым моментам.
Вот. Ну а вообще рад за вас, молодцы! -------------------- "If you want something done right, do it yourself" По секрету: выучить английский - реально! |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
Неа, PM Причем опыта с Java у меня Zero. Ведущий отметился в этой теме, как коуч (lvovin). Основная заслуга day-to-day agile mgmt - у него. По продуктивности: скорее всего, программисты бы быстрее отрапортовали, что "готово". Однако: 1) полная сборка проекта включает в себя сборку GWT и занимает 12 минут (так надо, почему - не знаю ). если бы программеры не писали тесты в стиле TDD, то представь себе процесс разработки - через 3 компиляции таким станешь 2) в дни поставок хотелось сказать "все, нафек ваш TDD, фиксите баги! ", но сдерживал себя. 3) если бы разрабатывали сверху вниз, то заказчик своими забубосами со сменой приоритетов и постоянным потоком инфы мне бы плешь проел Ну, в прототипе модели-то и не было - только proof of concept одной насыщенной страницы, который выполнялся на клиенте. Насколько я это видел, развитие шло достаточно стабильно, экстенсивно, но один или два раза возникали заморочки с организацией связи между сущностями, т.к. программер реализовал это так, что не получалось по-простому новое требование клиента внести. Все, что касается persistence, закрывал Hibernate и Spring. Очень помогали АОП-шные фишки спринга (логгинг, шифрование, права доступа)
Глянул, что за зверь такой. Сходу ответить не могу, сча попрошу lvovin заглянуть. Да, тестер у нас был просто мега! Вообще, все ребята молодцы, без них врядли бы проект удался. |
|||
|
||||
sandello |
|
|||
Опытный Профиль Группа: Участник Сообщений: 295 Регистрация: 18.5.2005 Где: Пермь Репутация: нет Всего: 2 |
Ээээ можно еще выложить ppt-шку. Для тех, кто не успел. В идеале - сюда залить
-------------------- |
|||
|
||||
Kangaroo |
|
|||
AA - Aussie Animal Профиль Группа: Участник Клуба Сообщений: 2042 Регистрация: 7.10.2006 Где: US Репутация: нет Всего: 104 |
Присоединяюсь! -------------------- Lost.... |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
обновил ссылку на первой странице
|
|||
|
||||
gEndelf |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 54 Регистрация: 7.7.2005 Где: the world Репутация: нет Всего: 3 |
прошу залить ещё )
|
|||
|
||||
mikolas |
|
|||
Новичок Профиль Группа: Участник Сообщений: 1 Регистрация: 2.6.2008 Репутация: нет Всего: нет |
Присоединяюсь к просьбе
|
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
gEndelf,
mikolas, сорри. обновил еще раз. |
|||
|
||||
cemick |
|
|||
Опытный Профиль Группа: Участник Сообщений: 416 Регистрация: 6.7.2006 Где: Санкт-Петербург Репутация: нет Всего: 6 |
а есть возможность снова обновить ссылочку?
|
|||
|
||||
Jey_k |
|
|||
WEB-командир Профиль Группа: Комодератор Сообщений: 4149 Регистрация: 16.11.2003 Где: Москва Репутация: нет Всего: 61 |
Вброшу свои 5 копеек. Методологии Agile тем и хороши, что очень хорошо настриваемы и масштабируемы. Ну XP не трогаем сейчас.
Убеждать дело неблагодарное. Если компания не созрела до Agile, то насильственное внедрение только все усугубит. Должен быть общий курс на то что мы делаем качественные вещи, а не коленочное ###. Сейчас пытаюсь использовать элементы SCRUM. Брать методологию и внедрять полностью нужно не всегда. Мне например пока нужны только бэклог, игра в планирование и итерации длиной в один рабочий день, потом увеличу |
|||
|
||||
surlac |
|
|||
Новичок Профиль Группа: Участник Сообщений: 12 Регистрация: 25.1.2011 Репутация: нет Всего: нет |
Есть компания ("созрела до Agile", но все же очень консервативная). На корпоративном уровне вводится Agile. Как регламентировать это новшество, т.е. в каком документе должно быть описано, что руководители должны использовать методы Agile принудительно? Еще раз повторюсь - компания консервативная, поэтому Agile вводится принудительно. |
|||
|
||||
Jey_k |
|
|||
WEB-командир Профиль Группа: Комодератор Сообщений: 4149 Регистрация: 16.11.2003 Где: Москва Репутация: нет Всего: 61 |
Понимаете дело в чем, нельзя гибкие методологии внедрить бюрократическими методами. Ведь agile - это прежде всего философия. Без понимания ее ценностей и почему в ней все именно так толку не будет. Лучше дальше ватерфоллить. Внедрение гибких методологий начинается снизу, с команд, и далее переходит на топ-менеджмент. Сама по себе контора это не сделает, т.к. не знает как. Нужен SCRUM-тренер на несколько месяцев в состав компании. Т.е. человек который будет фасилитировать все дискуссии, направлять, показывать и отыгрывать вместе со всеми. |
|||
|
||||
|
НА ЗЛОБУ ДНЯ: Дорогие посетители, прошу обратить внимание на то, что новые темы, касающиеся новых вопросов, создаются кнопкой "Новая тема", а не "Ответить"! Любые оффтопиковые вопросы, заданные в текущих темах, будут удалены. Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, arilou. |
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | УП: Методологии | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |