Tag Archives: внедрение

Практика внедрения Agile

Статья написана Виктором Прокопеней в апреле 2007 года. Печатается с любезного разрешения автора. (прим. ред.)

Про методологии Agile мы узнали достаточно недавно – около полугода назад, и нашли очень много общего с тем бизнес-процессом, который сформировался у нас по факту. Изучение Agile дало нам прежде всего осознание того, что мы далеко не уникальны в отношении итерационной разработки, а также помогло сформулировать большое количество принципов, которые никак не могли вырваться наружу в какие-то документы. В своей статье я бы хотел рассказать с абсолютно практической точки зрения как теория превращается в практику – как принципы Agile ложаться на реальную жизнь. (more…)

Read full storyComments { 0 }

Проблемы и ошибки при внедрении Scrum

Введение

При первом прочтении какой-нибудь статьи о Scrum складывается впечатление, что внедрить Scrum проще простого. Всего-то daily stand-up, planning meeting и sprint review. На самом деле, формальный Scrum отличается от работающего Scrum’a. Поэтому предлагаю рассмотреть некоторые ошибки, которые часто встречаются при внедрении Scrum’a без помощи опытного Scrum master’a.

Product ownership

Отсутствие product owner’a

Product owner должен предоставлять видение продукта, истории пользователя, определять приоритеты, отвечать на вопросы и давать постоянную обратную связь. Если такой роли нет, то проект будет двигаться непонятно куда, не удастся получить максимальную бизнес-полезность, команда будет периодически простаивать, продукт в итоге может получиться совсем не тот, что ожидался.

Заказчик не всегда готов (или может) выделить отдельного человека на роль product owner’a. В таком случае можно ввести Proxy product owner’a. (more…)

Read full storyComments { 4 }

Такой разный Agile

Agile, как Scrum или XP, уже не просто понятия технические, процессные или идеологические. Это понятия маркетинговые. Заказчики задают вопросы: “А ваша команда работает по Scrum?” А сами уже пишут строгое ТЗ на пол года вперед. Им кто-то когда-то рассказал, что Scrum позволяет делать проекты лучше. И они в это поверили, но что это такое не узнали.
Каждый находит в Agile что-то свое, что ему хорошо и удобно.

Заказчик:
— О! Agile позволяет всегда видеть что делается в разработке. Теперь-то они не отвертятся, что мол релиз будет готов через месяц! Я смогу лучше контролировать их работу. Только не на этой неделе… все дни расписаны, а на следующей неделе конференция 3 дня. Пусть работают, а там через месяц время найдется. (more…)

Read full storyComments { 0 }

Просто ли делать Agile?

Agile, особенно SCRUM – отличный способ организовывать разработку. Agile прост и элегантен, быстр и дешев. Он позволяет делать продукты, максимально близкие к ожиданиям Заказчика. Но это сложно. Да, это сложно! Первая статья в серии про agile – почему это не так просто, как кажется. На очередной выездной сессии обнаружил у коллег страшное заблуждение – многие считают, что agile – это очень просто, гораздо проще чем например RUP. И раз это очень просто, то делать agile в распределенной среде – это тоже очень просто. Караул! Разбираемся по порядку – первая часть заблуждения: agile – это очень просто (про вторую напишу отдельную статью). Давайте будем мыслить инженерно. У всего на свете есть смысл (даже если кажется, что его нет). В чем смысл Менеджера Проекта? Команда проекта делает продукт «софт». Зачем нужен менеджер? Поставить (произвести) процесс. Соответственно «процесс» – это продукт, производимый Менеджером Проекта. Соответственно чем процесс легче, мощнее, быстрее – тем он лучше: тем совершеннее будет «софт». Дальше – отделим процесс как продукт от его «производства». Соответственно производство должно быть простым, легко организуемым, не требующим большого объема знаний (в таком случае говорят, что производство технологично). За «производство» продукта «Процесс» отвечает Менеджер Проекта. (см. Иллюстрацию ниже – команда производит продукт по процессу, менеджер производит процесс для команды (или помогает команде его произвести).

Рис. 1. Команда делает софт, Менеджер делает процесс, по которому делается софт. А теперь внимание. Посмотрите на картинку внизу – что проще?

Рис. 2. Какой из этих двух усилителей проще?

Микросхема – устроена просто, легче, удобнее, быстрее, мощнее. Как продукт она безусловно совершеннее. Ламповый усилитель – устроен сложно, тяжелее, неудобнее, медленнее, слабее. Как продукт он безусловно хуже. Понимаете, о чем я говорю? Результирующий продукт микросхемы – эффективней по всем параметрам, но чтобы произвести его, требуется гораздо большая сумма знаний, технологий и оборудования. Agile – он как эта микросхема. Он отличный, замечательный – но в состоянии ли вы его сделать своими руками? Традиционные итеративные подходы – они почти всегда хуже. Но зато у них есть огромное преимущество – ламповый усилитель вы при желании легко соберете дома. Тот же RUP предоставляет вам кучу шаблонов, заготовок, «хауту», примеров и указаний. Так что получается что agile – да, во многих случаях он лучше. Дешевле и эффективней. При условии, что вы обладает набором необходимых знаний, технологий и оборудования – иначе попытки его использовать – это бесплодные фантазии. То есть для того, чтобы agile заработал, вы должны иметь быть в состоянии его запустить – а значит, обладать большими, нет, БОЛЬШИМИ знаниями во всех областях, связанных с его запуском. В первую очередь это управление ожиданиями заказчика, работа с требованиями, SCM, тестирование. Ну и конечно – плюс требования к знаниям команды, Заказчика и конечно – технологии. Мой совет – пока не научились работать традиционным итеративным подходом и давать устойчивый результат – не трогайте agile. Разберитесь в принципах работы усилителей и соберите простейший – прежде чем пытаться создать ультралегкие новинки. И еще одно – не используйте слово agile для обозначения бардака. Потрудитесь открыть любую книжку по любому agile-методу – там есть довольно большой требований, которые нужно выполнить, чтобы вы могли сказать «мы работаем по XP» или «мы работаем по SCRUM». Это не я говорю, это слова Бека и Швэйбера.

Материал с www.seadmex.ru

Read full storyComments { 2 }

Процесс разработки проекта становится гибче

Некоторое время назад у нас начался большой проект, который потребовал внедрения новых методик работы. Классический “водопад” не может обеспечить быстрое и безболезненное внесение изменений в проект. А это плохо. В условиях не четко поставленной задачи (а она и не может быть четко поставлена) требуется быстро вносить изменения, дополнения, новые требования клиента.

Похоже, что работа над подобными проектами, а также просто работа с разнородными задачами клиентов убеждает меня в том, что я бы не осмеливался сказать еще пару-тройку лет назад:

написать большое и всеобъемлющее ТЗ на крупный проект не реально.

Т.е. я хочу сказать, что это или не реально сложно или вообще не реально. Да я писал большие толстые ТЗ, которые описывали с точностью до запятой, как должен работать сайт, где у него какая информация и на какую кнопку надо нажать и вписать, чтобы он сообщил: “Такой формат e-mail недопустим”. (more…)

Read full storyComments { 0 }