Comments 12
Вики на мой взгляд больше подходит для этого. К примеру возьмем стандартный кейс входа в панель управления неавторизованным пользователем:
1. Неавторизованный пользователь открывает панель управления
2. Пользователю отображается форма входа
3. Пользователь вводит логин и пароль и нажимает «ок»
4. Пользователю показывается панель управления
Смысл такой что это небольшой кейс. И будет лучше если он останется таким, чтобы его можно было оценить сразу. В вики это решается ссылками на страницы, с подробностями каждого шага.
В волне это всё растянется на полэкрана.
1. Неавторизованный пользователь открывает панель управления
2. Пользователю отображается форма входа
3. Пользователь вводит логин и пароль и нажимает «ок»
4. Пользователю показывается панель управления
Смысл такой что это небольшой кейс. И будет лучше если он останется таким, чтобы его можно было оценить сразу. В вики это решается ссылками на страницы, с подробностями каждого шага.
В волне это всё растянется на полэкрана.
Вики — отличный инструмент для инженерных артефактов или тест кейсов.
Для сбора требований на мой взгляд нам нужно что-то другое. Мы должны создать некоторое виртуальное пространство со свойствами чата, онлайн доски для набросок и т.д. Здесь решающим фактором за Волну именно для меня является синхронность общения плюс сокращение времени на формирование вопроса — обозначения к какой части системы идет вопрос, его бекграуда.
С другой стороны я не призываю в волну записывать, скажем, тест кейсы. Здесь лучше Вики. Или какая-то система менеджмента документов с версиями.
Для сбора требований на мой взгляд нам нужно что-то другое. Мы должны создать некоторое виртуальное пространство со свойствами чата, онлайн доски для набросок и т.д. Здесь решающим фактором за Волну именно для меня является синхронность общения плюс сокращение времени на формирование вопроса — обозначения к какой части системы идет вопрос, его бекграуда.
С другой стороны я не призываю в волну записывать, скажем, тест кейсы. Здесь лучше Вики. Или какая-то система менеджмента документов с версиями.
Спасибо за статью )). Комментов я вижу у вас маловато. Наверное большинство просто не догнало о чем речь или обламались читать всю статью ))
Спасибо за статью!
Мы тоже попробовали использовать Волну в небольшом проекте (5-7 человек) для хранения артефактов и быстрых коммуникаций. Наткнулись на все те проблемы, что описаны в статье. И точно так же их решали. :) Лично сидел и «облагораживал» нашу Волну, приводя её в адекватное состояние.
Волна действительно даёт очень много свободы, и поэтому очень важно обговорить все правила заранее.
Мы тоже попробовали использовать Волну в небольшом проекте (5-7 человек) для хранения артефактов и быстрых коммуникаций. Наткнулись на все те проблемы, что описаны в статье. И точно так же их решали. :) Лично сидел и «облагораживал» нашу Волну, приводя её в адекватное состояние.
Волна действительно даёт очень много свободы, и поэтому очень важно обговорить все правила заранее.
Да, Волна только начинает свое движение. Есть много мест которые нужно развивать… Например очень не хватает «фирменного» Drawing гаджета. Также хотелось бы иметь возможность тонких настроек — например не разрешать редактировать определенные сообщения в волне. Очень не хватает конвертеров из Волны (всей я имею ввиду) в pdf, doc и рисунок. Пригодилась бы очень система версионности Волны, нотификаций в еmail, элементов VOIP.
В целом Волна — серезный шаг вперед для коммуникаций. Думаю *ребята* еще не раз нас удивят…
В целом Волна — серезный шаг вперед для коммуникаций. Думаю *ребята* еще не раз нас удивят…
Согласен.
И очень не хватает возможности удалять пользователей из волны. Я как-то случайно добавил человека, который не должен был читать эту волну… так пришлось заново создавать волну и переносить туда весь контент.
Да, там много ещё чего предстоит сделать. Но я верю, Гугл доведёт эту технологию до ума.
И очень не хватает возможности удалять пользователей из волны. Я как-то случайно добавил человека, который не должен был читать эту волну… так пришлось заново создавать волну и переносить туда весь контент.
Да, там много ещё чего предстоит сделать. Но я верю, Гугл доведёт эту технологию до ума.
Имеется несколько вопросов. Возможно, некоторые из них окажутся вне вашей компетенции, но тем не менее:
1) Как видно из примера, драфты страниц сайта рисует project owner. Каким образом в этом процессе задействован дизайнер? Он подключается уже после согласования всех страниц и рисует дизайн по драфтам?
2) Каким образом вам удалось затащить в волну заказчика? :) Что делать, если заказчик отказывается общаться любыми другими способами как по телефону, электронной почте, личных встречах?
3) Окончательный аппрув, что вот эта страница/фича должна выглядеть вот так дает заказчик? Что делать, если заказчик срывает срок согласования страницы/фичи?
1) Как видно из примера, драфты страниц сайта рисует project owner. Каким образом в этом процессе задействован дизайнер? Он подключается уже после согласования всех страниц и рисует дизайн по драфтам?
2) Каким образом вам удалось затащить в волну заказчика? :) Что делать, если заказчик отказывается общаться любыми другими способами как по телефону, электронной почте, личных встречах?
3) Окончательный аппрув, что вот эта страница/фича должна выглядеть вот так дает заказчик? Что делать, если заказчик срывает срок согласования страницы/фичи?
Спасибо за вопросы. Прокомментирую по пунктам…
В: 1) Как видно из примера, драфты страниц сайта рисует project owner. Каким образом в этом процессе задействован дизайнер? Он подключается уже после согласования всех страниц и рисует дизайн по драфтам?
О: У нас так сложилось так что дизайнер работает на отдельном потоке. Его задача — нарисовать и согласовать с заказчиком главную страницу сервиса и несколько второстепенных — чтобы задать look&feel всего проекта. В то-же время в задачу дизайнера не входит рисование всех страниц сервиса. Программисты должны экстраполировать дизайн на их страницы. Разумеется если у них возникают вопросы пор деталям дизайна — они обсуждаются с дизайнером отдельно.
Макеты могут отличаться от дизайна по layout. Программист по макету создает функционал UI, но layout подбирает по дизайну.
Например если в макете главное меню находится в верхней части станицы, а на дизайне оно лежит под большим банером — программист должен его положить под банер (но пункты меню по составу точно соответствуют макету).
По времени дизайнер начинает работу увидев первый макет домашней страницы. Дальше его фантазию никто не сдерживает. Но он должен получить от заказчика добро на один из вариантов.
В: 2) Каким образом вам удалось затащить в волну заказчика? :) Что делать, если заказчик отказывается общаться любыми другими способами как по телефону, электронной почте, личных встречах?
О: Да это сложный момент. Но здесь владелец проекта проводит откровенный разговор с заказчиком, объясняя насколько важно участвовать во всех деталях во время разработки проекта. Приводятся *плохие* примеры которые случились с *плохими* клиентами.
Если же клиент несмотря ни на что явно делегирует принятие решений в команду, его просят подписать *страшную* бумагу о том, что он не будет иметь никаких претензий к финальному продукту если его функционал соответствует Спецификации. То есть по существу проект переключается в Ватерфолл. Архитектурная итерация расширяется и в ней создается спек, состоящий из макетов и тест кейсов. Однако, подчеркну, что этот случай мы рассматриваем как плохой вариант и стараемся клиента склонить к нормальному Agile процессу, возможно с подключением с его стороны ИТ-консультанта.
В: 3) Окончательный аппрув, что вот эта страница/фича должна выглядеть вот так дает заказчик? Что делать, если заказчик срывает срок согласования страницы/фичи?
О: Драфт требований пишется на следующую итерацию. Клиент имеет достаточно времени на его inputs и он в курсе, что, если на момент старта Спринта он не успевает отреагировать на предложения и вопросы, то включается правило делегирования принятия решения в команду.
В: 1) Как видно из примера, драфты страниц сайта рисует project owner. Каким образом в этом процессе задействован дизайнер? Он подключается уже после согласования всех страниц и рисует дизайн по драфтам?
О: У нас так сложилось так что дизайнер работает на отдельном потоке. Его задача — нарисовать и согласовать с заказчиком главную страницу сервиса и несколько второстепенных — чтобы задать look&feel всего проекта. В то-же время в задачу дизайнера не входит рисование всех страниц сервиса. Программисты должны экстраполировать дизайн на их страницы. Разумеется если у них возникают вопросы пор деталям дизайна — они обсуждаются с дизайнером отдельно.
Макеты могут отличаться от дизайна по layout. Программист по макету создает функционал UI, но layout подбирает по дизайну.
Например если в макете главное меню находится в верхней части станицы, а на дизайне оно лежит под большим банером — программист должен его положить под банер (но пункты меню по составу точно соответствуют макету).
По времени дизайнер начинает работу увидев первый макет домашней страницы. Дальше его фантазию никто не сдерживает. Но он должен получить от заказчика добро на один из вариантов.
В: 2) Каким образом вам удалось затащить в волну заказчика? :) Что делать, если заказчик отказывается общаться любыми другими способами как по телефону, электронной почте, личных встречах?
О: Да это сложный момент. Но здесь владелец проекта проводит откровенный разговор с заказчиком, объясняя насколько важно участвовать во всех деталях во время разработки проекта. Приводятся *плохие* примеры которые случились с *плохими* клиентами.
Если же клиент несмотря ни на что явно делегирует принятие решений в команду, его просят подписать *страшную* бумагу о том, что он не будет иметь никаких претензий к финальному продукту если его функционал соответствует Спецификации. То есть по существу проект переключается в Ватерфолл. Архитектурная итерация расширяется и в ней создается спек, состоящий из макетов и тест кейсов. Однако, подчеркну, что этот случай мы рассматриваем как плохой вариант и стараемся клиента склонить к нормальному Agile процессу, возможно с подключением с его стороны ИТ-консультанта.
В: 3) Окончательный аппрув, что вот эта страница/фича должна выглядеть вот так дает заказчик? Что делать, если заказчик срывает срок согласования страницы/фичи?
О: Драфт требований пишется на следующую итерацию. Клиент имеет достаточно времени на его inputs и он в курсе, что, если на момент старта Спринта он не успевает отреагировать на предложения и вопросы, то включается правило делегирования принятия решения в команду.
Спасибо за ответы. У нас пока все проходит не так гладко, как у вас, поэтому очень интересно ваше мнение.
Еще пару вопросов, с вашего позволения:
1) Как вы считаете, какой минимальный срок реализации должен иметь проект (в месяцах от начала до финального релиза), чтобы имело смысл применять в нем Agile? Стоит ли применять Agile на маленьких проектах (1-1.5 мес от начала до конца)?
2) Всегда интересно читать как все работает, но еще интересней узнать, каким образом все это строилось. Расскажите немного о себе и как вы пришли к Agile. С чего начинали, как развивались, какие методологии использовали ранее и т.д.
Еще пару вопросов, с вашего позволения:
1) Как вы считаете, какой минимальный срок реализации должен иметь проект (в месяцах от начала до финального релиза), чтобы имело смысл применять в нем Agile? Стоит ли применять Agile на маленьких проектах (1-1.5 мес от начала до конца)?
2) Всегда интересно читать как все работает, но еще интересней узнать, каким образом все это строилось. Расскажите немного о себе и как вы пришли к Agile. С чего начинали, как развивались, какие методологии использовали ранее и т.д.
Да и у нас не все так гладко :). Разработка софта — это не конвейер. В него вовлечено много умных и хитрых людей. А что делают умные и хитрые люди с правилами ;)? На ровном месте всегда может возникнуть конфликт…
По поводу Agile vs Waterfall (ВФ) можно говорить часами. Мне кажется что самое главное — это то, что в Agile заказчик участвует в проекте (входит в команду если хотите), а в ВФ — нет.
С точки зрения менеджера и команды, вообще, ВФ *ПРОЩЕ* — и его проще организовать и поддерживать. Если мы исключаем клиента из схемы потоков, все радикально упрощается.
Agile на мой взгляд — это более сложный, более дорогой сервис для клиента чем ВФ. Платинум сервис (или как там маркетинговые люди говорят)… Это как пересесть на самолет после автомобиля. Понятно что заказчик должен быть готов к такому сервису и понимать что вокруг него происходит и что хотят все эти люди от него.
Что же получает заказчик в Agile — он видит как его продукт *растет*. Он может сказать что здесь нужно чтото убрать а там — добавить. В ВФ все происходит как в старом фильме про графа Калиостро: молодой барин загадал увидеть Лауру, а как скинули покрывало — там оказалась подружка фокусника :). Но деваться то некуда — все уже подписано.
Извините за пространные рассуждения, просто мне хотелось синхронизировать картинку которую мы видим в этом вопросе. По сути… мне кажется что критерием выбора между Agile и ВФ есть не длина проекта — она может быть любой — а принцип включать или не включать заказчика в процесс.
Что касается нашей истории — то мы конечно работали и иногда работаем в ВФ (по договоренности с заказчиком). Пробовали также Скрам, но не прижилось — слишком много этикета. Поэтому построили свою адаптацию Agile, как впрочем и многие другие команды вроде нашей.
По поводу Agile vs Waterfall (ВФ) можно говорить часами. Мне кажется что самое главное — это то, что в Agile заказчик участвует в проекте (входит в команду если хотите), а в ВФ — нет.
С точки зрения менеджера и команды, вообще, ВФ *ПРОЩЕ* — и его проще организовать и поддерживать. Если мы исключаем клиента из схемы потоков, все радикально упрощается.
Agile на мой взгляд — это более сложный, более дорогой сервис для клиента чем ВФ. Платинум сервис (или как там маркетинговые люди говорят)… Это как пересесть на самолет после автомобиля. Понятно что заказчик должен быть готов к такому сервису и понимать что вокруг него происходит и что хотят все эти люди от него.
Что же получает заказчик в Agile — он видит как его продукт *растет*. Он может сказать что здесь нужно чтото убрать а там — добавить. В ВФ все происходит как в старом фильме про графа Калиостро: молодой барин загадал увидеть Лауру, а как скинули покрывало — там оказалась подружка фокусника :). Но деваться то некуда — все уже подписано.
Извините за пространные рассуждения, просто мне хотелось синхронизировать картинку которую мы видим в этом вопросе. По сути… мне кажется что критерием выбора между Agile и ВФ есть не длина проекта — она может быть любой — а принцип включать или не включать заказчика в процесс.
Что касается нашей истории — то мы конечно работали и иногда работаем в ВФ (по договоренности с заказчиком). Пробовали также Скрам, но не прижилось — слишком много этикета. Поэтому построили свою адаптацию Agile, как впрочем и многие другие команды вроде нашей.
Sign up to leave a comment.
Круговорот артефактов в Agile