Как убедить клиента перейти на Scrum/XP?
Vasiliy Keretsman
Всегда интересовал данный вопрос, так как это оказывается чуть ли не
основной проблемой.
Со стороны разработчиков меньше всего трудностей, если в команде есть
_нужные_ люди.
Думаю главной проблемой является изначально недоверие клиента к
команде.
Вот интересует как этот лед пробить :).
У кого был успешный опыт, поделитесь, пожалуйста, рецептами. :)
Даже если клиент впринципе не настроен, может можно как-то поэтапно
начать двигаться в этом направлении и постепенно убедить клиента на
практике что Scrum работает?
Спасибо
Alexey Krivitsky
Рад тебя здесь слышать.
Ты затронул очень важный вопрос.
Agile базируется на тесном взаимодействии с заказчиками,
так что без их участия в этом процессе, проект нельзя назвать таковым,
который следует agile принципам.
Без заказчиков можно применять практики из XP, проводить stand-up митинги.
Но всё это не agile, если заказчик стоит в стороне.
Разработка софта или построение команды - это не самоцели (хотя и
похвальные вещи).
Основаня цель банальна и проста - разработать софт, который бы решил
поставленную конкретными людьми бизнес-цель
(увеличение продаж, захват рынка, уменьшение врунтренних затрат за
счет автоматизации и проч.)...
Так что убедить и привлечь заказчика это первостепенная задача команды,
которая созрела для движения в сторону agile.
Как это сделать? Есть ли поэтапные подходы? Как заставить заказчика
поверить и попробовать?
Все это не так тяжело, как кажется.
В основе Scrum (как и других agile подходов) лежат простые и здравые цели,
(доходчивое) объяснение которых, должно убедить заказчиков (которые
заботяться о своих проектных вложениях) если не перейти тотально на
agile, то хотя бы попробовать.
Заметь оговорки в вышеописанном тексте, они являются предпосылками.
К примеру, без заботы о проектных вложениях со стороны заказчиков
нечего и говорить о переходе на agile, - в этом просто не будет смысла
с их точки зрения.
Имея предпосылки, можно перейти к объяснению. А оно состоит из такой
логической цепочки:
- разрабатывать софт тяжело, и мы врядли можем предвидеть и
спланировать все наперёд, закрывая глаза на риски и неизвестыне
(доказательством служат тысячи завеленных проектов по всему миру)
- сложность разработки увеличивается нелинейно за счет перемножения
таких факторов как: неизвестность того, как должен выглядеть конечный
продукт (стабильность требований), риски технологий, несыгранность
команды...
- пытаясь искать пути решения, можно перейти к адаптивному ведению
проектов, основанному на циклах проб, наблюдении результатов и
адаптации процесса
- чем короче циклы, тем быстрее можно адаптироваться, следовательно,
чем сложнее ситуация - тем короче должны быть циклы
- чтоб циклы приносили реальные знания о продукте, команде и технологиях,
необходимо чтобы люди, ответственные за то каким должен быть продукт,
вовремя давали свой feedback
- такими людьми есть конечные пользователи (если продукт таковых может иметь),
и их feedback и нужно инкорпорировать в процесс адаптации
- чтобы конечные пользователи могли дать свой feedback, нужно чтоб в
конце каждого
цикла команда могла предоставить им инкремент продукта, на котором
можно "поиграться"
- часто доступа к конечным пользователям у команды нет, либо же он ограничен,
тогда вместо них выступают представители со стороны заказчика.
- .....
На счет поэтапности. Нельзя изменить всё сразу - это очевидно.
Но и без ключевых элементов пытаться что-либо изменить нельзя.
Так что тут должен быть, как и везде, здравый подход.
Леша.
andy
представителя заказчика (допустим раз в неделю) заходить на часик (для
избежания недопонятностей и устранения рисков) и быть подготовленым
показать ему пару демоверсий (лучше по кускам кот его наиболее
интересуют).
Если скажет: "ОК, я именно этого и жду" - сказать спасибо и
поблагодарить (и если так будет каждый раз включая внедрение и
эксплуатацию - может и не нужны эти встречи :)
Намного интереснее если скажет: "совсем не то" - тут уж обоим
очевидно, что эта встреча много времени сэкономила.
А можно и самим с ноутбуком к клиенту "в его же целях".
И начало проложено, при чем совсем не обязательно пугать заказчика и
директора незнакомыми словами, просто трезвая оценка ситуации и
избежание рисков...
Надеюсь адекватно ответил.
On Feb 13, 2:57 pm, "Vasiliy Keretsman" <vasi...@gmail.com> wrote:
> Привет всем!
>
....
> Вот интересует как этот лед пробить :).
>
> У кого был успешный опыт, поделитесь, пожалуйста, рецептами. :)
> Даже если клиент впринципе не настроен, может можно как-то поэтапно
> начать двигаться в этом направлении и постепенно убедить клиента на
> практике что Scrum работает?
...
Max Pendyschtschuk
Шановний Andy, не завжди реально запрошувати клієнта хоча б раз на
тиждень. Я був би задоволений хоча б раз на місяць представника
бачити, але що поробиш якщо всі вони зайняті люди і є громадянами
західної Європи... Все що ми можемо - спілкуватися по скайп/мсн/... І
пропонувати потроху рухатися у напрямок agile, наприклад один з тім
лідерів (ми ще не перейшли на скрам, і чи будемо...) просто обговорив
з клієнтом - а давайте спробуємо так, чи ми будемо робити так... Якщо
йому щось не довподоби - він інформує. На разі цикл у нас досить
короткий (від Evo достався - 1 тиждень), відповідно і легше мабуть з
клієнтом спілкуватися і пропонувати зміни. Не сподобалося, на
наступний тиждень змінимо підхід... Поки що вони намагаються більше
спілкуватися в онлайні замість листів/функціонального опису... Поки що
зі сторони клієнта докорів нема.
Василію, ми якраз намагаємося змінити ситуацію у компанії (власна я,
програміст, та ще одна людина, тім лідер). У нас для початку інша
проблема - умовити боса :) але навіть це ми будемо робити поетапно.
Так само з клієнтами, потрохи пояснювати. Нам самим потрібен невеликий
досвід і розуміння, побачити сильні та слабкі сторони Agile та реакцію
інших програмістів
Успіхів Вам.
Vasiliy Keretsman
Спасибо. Идею уловил.
Действительно, главное не пугать незнакомыми словами и следовать
простым принципам , демонстрируя при этом результат.
> Василію, ми якраз намагаємося змінити ситуацію у компанії (власна я,
> програміст, та ще одна людина, тім лідер). У нас для початку інша
> проблема - умовити боса :) але навіть це ми будемо робити поетапно.
Вибачаюсь за трохи вузьке формулювання "клієнт". Думаю в наших реаліях
варто розглядати клієнта як одне з:
1) Клієнт, для якого ведеться розробка
2) Директор/менеджер в компанії-розробнику, через якого фактично
проходить вся комунікація і який виступає в ролі клієнта для
розробників.
В випадку 2 якщо у директора немає довіри, то навряд чи вдасться
донести це до клієнта.
--
Вася
Alexey Krivitsky
Спасибо, что поделился.
Для старта Скрама необходимы всего такие вещи:
- приоритезированный список фич от заказчика (список должен быть достаточным
для как минимум для 2 итераций, приблизительно)
- эстимейты на эти фичи от команды (приблизительные, в днях или
абстрактных единицах)
- выбранная длительность итерации (лично рекомендую 2 недели)
Дальше начинается планирование итерации.
Команда выбирает из списка фич те, которые может сделать
за одну итерацию, учитывая приоритеты и порядок.
Этот список обговаривается с заказчиком. Процедура может быть
итеративной и привести к изменению приоритетов фич. Повторяется до тех
пор, пока все не согласятся с выбранным списком, и заказчик не
пообещает, что не будет заменять фичи, спланированные на итерацию
(хотя бы постарается)
Hint:
Стоит понимать и объяснить всем, что это безпроигрышная игра для
заказчика в любом случае: так как команда будет работать на наиболее
важными фичами,
даже если не успеет все закончить. За 2 недели вряд ли приоритеты
поменяются кардинально....
Собственно это все, что нужно для старта первого спринта.
.....
В конце спринта в условленое время команда демонстрирует заказчику
то, что работает. Обсуждаются результат. Обновляется список фич...
Все повторяется, пока есть кому и над чем работать ;)
Занавес
Алексей.
On 2/13/07, Max Pendyschtschuk <gotisc...@yahoo.de> wrote:
> Доброго вечора,
>
> Шановний Andy, не завжди реально запрошувати клієнта хоча б раз на
> тиждень. Я був би задоволений хоча б раз на місяць представника
> бачити, але що поробиш якщо всі вони зайняті люди і є громадянами
> західної Європи... Все що ми можемо - спілкуватися по скайп/мсн/... І
> пропонувати потроху рухатися у напрямок agile, наприклад один з тім
> лідерів (ми ще не перейшли на скрам, і чи будемо...) просто обговорив
> з клієнтом - а давайте спробуємо так, чи ми будемо робити так... Якщо
> йому щось не довподоби - він інформує. На разі цикл у нас досить
> короткий (від Evo достався - 1 тиждень), відповідно і легше мабуть з
> клієнтом спілкуватися і пропонувати зміни. Не сподобалося, на
> наступний тиждень змінимо підхід... Поки що вони намагаються більше
> спілкуватися в онлайні замість листів/функціонального опису... Поки що
> зі сторони клієнта докорів нема.
>
> Василію, ми якраз намагаємося змінити ситуацію у компанії (власна я,
> програміст, та ще одна людина, тім лідер). У нас для початку інша
> проблема - умовити боса :) але навіть це ми будемо робити поетапно.
> Так само з клієнтами, потрохи пояснювати. Нам самим потрібен невеликий
> досвід і розуміння, побачити сильні та слабкі сторони Agile та реакцію
> інших програмістів
>
> Успіхів Вам.
>
Alexey Krivitsky
Ну кому-то то он все равно доверяет, так ведь? иначе программил бы сам.
Так вот этот "кто-то" объявляется СкрамМастером, и репортит
"директору" в любое время по прогрессу внутри спринта.
Желающие такаже преглашаются на утренние митинги в роли "chickens".
// Alexey
Max Pendyschtschuk
> Спасибо, что поделился.
Дякую, що створив групу для нашого простору :)
> даже если не успеет все закончить. За 2 недели вряд ли приоритеты
> поменяются кардинально....
Був випадок у практиці, коли від клієнта прийшов лист на наступний
день після нашого планування, в якому він за значив зміну пріоритетів.
Одна ніч змінила все, але добре, що то було на наступний день...
Max Pendyschtschuk
> 2) Директор/менеджер в компанії-розробнику, через якого фактично
> проходить вся комунікація і який виступає в ролі клієнта для
> розробників.
У Scrum директор чи менеджер не може виступати у ролі клієнта
(ProductOwner), це помилка. А в якомусь іншому Agile підході таке
можливо?
І взагалі, припустимо, що вся комунікація відбувається через одну
особу. Наскільки це шкодить розробці? Як на мене то дуже. Часті
випадки з практики - програміст дає запитання менеджеру, той не встані
відповісти (зрозуміла річ) і відсилає їх клієнту. Клієнт присилає
відповіді до менеджера, а останній читає, но запізнюється з
переправкою програмісту, можливо губить взагалі... Діє людський
фактор, спілкування через одну особу може суттєво тормозити розробку.
Це лишень моя думка, можливо у когось є інша.
Alexey Krivitsky
> У Scrum директор чи менеджер не може виступати у ролі клієнта
> (ProductOwner), це помилка. А в якомусь іншому Agile підході таке
> можливо?
Макс, це цілком можливо. на приклад, проект по розробці софта для
автоматизації якогось процесу в компанії.
директор може бути прямим замовником, який хоче знизити розтрати на
робітників за рахунок заміни ручної праці автоматичною.
чи є він ProductOwner? яснаріч є, хто, якщо не він?
але, коли розробка ведеться в оффшорі, ProductOwner, скоріше за все,
повинен бути замовник, що є на стороні клієнта, і котрий відповідає за
розумне використання витрат, що виділені на проект
Vasiliy Keretsman
> > проходить вся комунікація і який виступає в ролі клієнта для
> > розробників.
>
> У Scrum директор чи менеджер не може виступати у ролі клієнта
> (ProductOwner), це помилка. А в якомусь іншому Agile підході таке
> можливо?
Мова йде про те, як переконати директора/клієнта перейти на
Scrum(Agile), коли до цього ніякі agile-методології не
використовувались.
Ситуація, коли "низи" визріли, а "верхи" не хотять або не розуміють :).
--
Вася
Max Pendyschtschuk
соррі.
Для нерозуміючих верхів все потрібно представляти у новому світлі. Це
надто складний процес. В кінці місяця приїздить шеф, будемо
обговорювати це питання. Зараз готуюся, ночами не сплю :)
За "низи" окрема розмова - мені наприклад складно сказати, готові чи
ні. Я тут чи не єдиний програміст, хто у це рветься. Тому перетворення
якщо будуть, то поступові, щоб не перестаратися. Але якщо дитині все
життя батьки бідіть читати книжки і не будуть давати їй самій
спробувати бо вона ще не вміє це правильно робити... дитина ніколи не
навчиться читати. Кращої метафори не придумав (конкурс
вакантний :-) ). Так само і тут - самоорганізація то є складний
процес.
"I don't have to be great to get started, but I have to get started to
be great" - як на мене цитата вдала, нам варто пробувати.
Alexey Krivitsky
есть обычно две ситуации, когда полезно перейти на agile:
1. процесса как такового нету, всё хаотично (можно для красоты назывть
это ad-hoc process...)
2. процесс есть и он водопадного типа (весь проект разбит на фазы:
думаем, пишем, делаем, проверяем, деплоим)
из первого случая перейти к agile довольно просто - упорядоченный
список фич, короткие итерации - это даст положительные результаты
сразу (даже до старта первой итерации)
вторая ситуация - сложнее. обычно люди привыкли к водопаду (пол-года
отдыхаем, месяц запарки), и тут-то как раз может быть тяжело
переубедить народ рабоать в режиме "полу-запарки" все время.
Alexey Krivitsky
опиши в кратце ваш текущий процесс, пожалуйста.
On 2/14/07, Max Pendyschtschuk <gotisc...@yahoo.de> wrote:
Max Pendyschtschuk
деякі зміни, тому підходи трохи різні, але рух у сторону Agile після
старого EVO. Як ми працюватимемо стане відомо скоріше на початку
березня... А дуже коротко
ітерація - 1 тиждень
щоденні мітинги відсутні
наявність Проджект Менеджера у прямому розумінні слова (не
СкрамМайстра), який і задає завдання на ітерацію
- це те що зараз спільне, але воно по трохи змінюється, у пятницю у
нас бів мітинг з цього приводу. Зміни однозначно будуть, але коли і як
ще не утрясли, є додаткові фактори які на це впливають.
Вибач, нічого конкретнішого зараз не можу сказати...
Alexey Krivitsky
Vasiliy Keretsman
> Вибач Олексію, але не знаю навіть, що описувати. У нас вже почалися
> деякі зміни, тому підходи трохи різні, але рух у сторону Agile після
> старого EVO. Як ми працюватимемо стане відомо скоріше на початку
> березня... А дуже коротко
>
> ітерація - 1 тиждень
> щоденні мітинги відсутні
> наявність Проджект Менеджера у прямому розумінні слова (не
> СкрамМайстра), який і задає завдання на ітерацію
Як мінімум, daily meetings уже можна проводити. По часу займає не
багато - у нас десь максимум 10 хв (10 чоловік)
а завдання на ітерацію вибирає команда в залежності від приорітетів
які виставив Product Owner, якщо я правильно зрозумів.
--
Вася
Alexey Krivitsky
> багато - у нас десь максимум 10 хв (10 чоловік)
>
> а завдання на ітерацію вибирає команда в залежності від приорітетів
> які виставив Product Owner, якщо я правильно зрозумів.
absolutely
за это с него берется слово принимать эстимейты, которые дает команда
Tim Yevgrashyn
Хотел вставить свои "пять копеек" в вопрос формирования "доверия".
На мой взгляд, тут еще важно "технически" обеспечить возможность
реально _показать_ результат.
Максим пишет:
> Шановний Andy, не завжди реально запрошувати клієнта хоча б раз на
> тиждень. Я був би задоволений хоча б раз на місяць представника
> бачити, але що поробиш якщо всі вони зайняті люди і є громадянами
> західної Європи... Все що ми можемо - спілкуватися по скайп/мсн/...
Если у заказчика есть простая возможность зайти на тестовый сайт или
скачать тестовый билд и собственоручно поклацать все новые фичи -
тогда он уже будет больше доверять, потому что будет видеть и
"ощущать" результат каждогой спринта (итерации). Это сыграет как
минимум психологическую роль успокоения, а как максимум - это тот
самый "быстрый feedback" от того, кто принимает работу.
Т.е., в обоих случаях описанных Василием:
> Вибачаюсь за трохи вузьке формулювання "клієнт". Думаю в наших реаліях варто розглядати клієнта як одне з:
> 1) Клієнт, для якого ведеться розробка
> 2) Директор/менеджер в компанії-розробнику, через якого фактично проходить вся комунікація і який виступає в ролі клієнта для розробників.
"Клиент", должен иметь возможность получить "готовый инкремент"
продукта и поиграться с ним, прежде чем внедрять в production.
И еще важно "узаконить роль ProductOwner", как единого контакта со
стороны Клиента, который имеет право расставлять приоритеты для
разработчиков. Т.е. у них там могут быть десятки пользователей или
сейлзов или еще кого. Но, если все они кинутся "флудить"
разработчиков, то дела не будет.
А так "Клиент" получил билд, поклацал, подумал как жить дальше,
посовещались у себя внутри и пришли к разработчикам с новым Product
Backlog.
"Политику" оставим заказчикам, а "религию программирования" -
разрабочикам :-)
Alexey Krivitsky
но это необходимо. если их больше одного, то и продуктов видимо больше
одного фактически
Tim Yevgrashyn
После некоторых размышлений и чтения других топиков, понял что
проблема многосторонняя и может быть вызвана множеством причин :-)
Давайте вкратце подумаем о возможных причинах и тогда пути решения
каждой уже будут отдельными вопросами (топиками?).
Я попробую сформулировать несколько возможных причин на основе того,
что я уже читал/встречал.
1. Непонимание смысла (термина) Agile заказчиком. Фактически для него
Agile = Chaos.
Тут нужно сказать, что в первую очердь SCRUM и другие - это _процесс_,
который основан на систематизированном подходе, проверенном практикой
и опытом многих людей.
Более того, например SCRUM, имеет очень четкие подходы к планированию
работ (3 уровня! см. еще для иллюстрации
http://www.implementingscrum.com/cartoons/cartoons_files/implementingscrum-20070212.html).
Плюс подходы к трэканью прогресса - все это при должном исполнении
дает почти абсолютный контроль и прозрачность.
Т.е. убедите заказчика, что уровень контроля проекта только повысится.
2. Недоверие к команде (см. даже отдельный топик на эту тему).
Тут, на мой взгляд, следуюет разделять причины недоверия.
Одна из них - это может быть боязнь хаотичности в работе команды и их
неконтролируемое движение в разработке. Тут смотри предыдущую причину
и дави на _процесс_, планирование и контролирование, которые
предлагает та или иная методология.
Вторая возможная причина - недоверие к техническому уровню команды, ее
знанию системы и т.п.
Думаю это все-таки временные трудности и их можно и нужно решить.
Например, для начала предоставить заказчику план обучения. Или вовлечь
в команду разработчиков со стороны заказчика, которые считаются
"экспертами". Или же хотя бы просто изолировав тестовый environment от
Production. Т.е. перед тем как отослать все пользоватлям, будет время
убедиться, что это 100% рабочее решение.
Но скорее всего этот вопрос - тема отдельного обсуждения :-)
3. Боязнь прозрачности процесса - это одна из частовстречающихся, но
"негласных" причин.
Ели команда разработчиков начнет работать эффективно, то очень быстро
станет понятно, что плохо работают другие отделы. Может выясниться,
что тот же Product Owner или другие аналитики, stake-holder'ы и т.п.
просто не справляются со своей работой вовремя и с надлежащим
качеством. Раньше все валили на разработчиков, а теперь валить будет
не на кого :-)
Т.е. после перехода на эффективный Agile-процесс, может оказаться, что
нужны кадровые перестановки и внутри команды и снаружи. Это не всегда
"комфортно" для начальства. С другой стороны, если есть реальная
возможность получать Прибыль от продукта сделанного быстро (в срок) и
с должным качеством, то тут уже начальство должно решать что им
важнее, деньги или люди, к которым они "привыкли" ;-)
У меня пока все. Думаю кто-то еще сможет добавить причин "боязни
перехода на Scrum/XP".
Думаю, если мы составим такой список "Top 10 прчин" с возможными
путями решения каждой из них, то в итоге получится очень хорошая
помощь любому, кто захочет убедить начальство перейти на новый
процесс.
Alexey Krivitsky
1
на счет agile equal chaos
тут достаточно рассказать теоририю адаптивных процессов
и дать линк на controlchaos.com.
остальное придет с практикой.
2
на счет недовения - согласен, но он присутствует всегда и вполне
естессвенно. мы доверяем тому, кого проверили на практике, к остальным
относимся с опаской. но как только человек или команда показывают свою
компетентность - доверие начинает рости и растет довольно
стремительно.
как вырастить доверие - показывать работающий программный продукт по
чаще, который удовлетворяет требованиям...
3
на счет боязни - это скорее всего правда. я такого пока не встречал,
но Швабер об этом частенько поговаривает.
в этом случае наверное нужно не боятся эскалировать проблемы на нужный
уровень - чем выше уровень управления в компании,
тем небезразличнее отношение к Return Of Investments
если ты уверен в своей правоте, уверен, что твой процесс принесет
помощь компании - я уверен, ты найдешь людей, котрые в итоге
тебя поддержат.