Персональные инструменты
 

В чем счастье заказчика? Готовые фичи вместо гант-чарта! (Станислав Калканов, AgileDays-2011) — различия между версиями

Материал из CustisWiki

Перейти к: навигация, поиск
м (Видео)
м (Видео)
Строка 32: Строка 32:
  
 
[[Категория:AgileDays-2011 (наша запись)]]
 
[[Категория:AgileDays-2011 (наша запись)]]
 +
{{feedback-appeal|AgileDays}}
 
{{replicate-from-custiswiki-to-lib}}
 
{{replicate-from-custiswiki-to-lib}}

Версия 20:55, 22 марта 2011


Аннотация

Докладчик
Станислав Калканов

Agile очень популярен среди разработчиков. Кому не понравится ощущать себя частью самоорганизующейся команды, самостоятельно решать, кто что делает, не тратить время на написание никому не нужных формальных спецификаций, практиковать xDD и вообще — чувствовать себя на гребне волны современной индустрии разработки.

Практика показывает, что в отличии от разработчиков заказчикам намного сложнее понять преимущества Agile и поверить в его эффективность. Действительно, на первый взгляд исчезают все традиционные механизмы контроля проекта: обязательство сделать фиксированный скоуп к определенной дате, план-график и процент его выполнения, формальные спецификации и процедуры приемки, сложные метрики и подробные статусные отчеты. С другой стороны… С другой стороны заказчик получает возможность видеть реально работающие фичи, моментально давать по ним обратную связь и получать реализованные изменения, а не стопку запросов на изменение планов и спецификаций. Появляется возможность быстро изменить скоуп и добавить в релиз новые фичи, о которых месяц назад еще никто и не знал, и быть уверенным, что они будут сделаны. А главное — появляется уверенность, что за неделю-другую до выхода релиза заметно погрустневший менеджер проекта не скажет, что пока ничего не получается и нужно отодвигать дату сдачи системы и делать перепланирование проекта.

Эта реальная история о переводе продуктового проекта с традиционного планового подхода на Agile будет полезна как тем заказчикам, менеджерам продуктов и проектов, которые еще только задумываются о переходе на Agile, так и тем, кто уже работает по Agile. Что изменится в жизни заказчика? К чему нужно быть готовым? Как будет устроена работа со скоупом и как контроллировать прогресс проекта? Какие дополнительные преимущества даст Agile, а от чего придется отказаться? Как изменится подход к планированию и выпуску продукта?

На чужих ошибках трудно научиться, но чужой положительный опыт даст дополнительную уверенность в необходимости изменений, поможет поверить в их успешность и, наконец, поможет захотеть to be changed.

Видео


Примечания


Призыв к зрителям!

Мы призываем всех зрителей видеозаписей докладов давать хоть какой-нибудь, желательно конструктивный feedback.

Где? — неважно. В блогах, в форумах, в комментах — пофиг, лишь бы можно было найти, например, поиском по блогам, по ключевому слову «AgileDays» (ну и/или по названию доклада).

Что-то побольше твиттер-вскрика, хотя бы пару абзацев. Да, иногда краткая характеристика бывает достаточной («маркетинговый булшит», «унылый самопиар» — обычно в адрес «спонсорских докладов»), но это очень, очень редко, а так хочется прочитать что-то большее, чем «сижу на XXX, говорят о YYY».

Что писать? Что хорошо, что плохо («плохо» неудачное слово, скажем, «неправильно на ваш взгляд»), как вы поняли то, что рассказано, как это спроецировалось конкретно на вас — все это фантастически важно и полезно:

  • Другим потенциальным зрителям (смотреть/не смотреть, «правильно ли я понял»).
  • И докладчикам:
    • «Правильно ли меня поняли»,
    • «Что я делал правильно, а что улучшить»
    • Даже критический отзыв лучше, чем никакого!
    • Плюс — это мотивация, это награда за немалый труд многие готовятся долго, раскрывают свой опыт, старательно делают слайды, репетируют выступление — и ради чего? двадцать минут театра перед парой десятков зритетелей и все?
  • Организаторам конференций (этой и других) — они внимательно следят за отзывами, и пытаются понять, кого имеет смысл звать («рубит фишку и жжет!»), а к кому отнестись скептически, и если брать, то, например, «прокачать в части выступлений» — мы, например, старались это делать, итеративно рецензировали слайды, рассылали подборку литературы о правильных слайдах и искусстве выступлений.
  • Безотносительно лично докладчиков — важно понять, исчерпала себя тема или для народа еще остаются откровениями то, что для более пресыщенных инфопотоками людей (а организаторы обычно такие) уже выглядит как «аццкий боян». Ну и вообще — что еще интересно, и что было бы интересно услышать-увидеть-пообщаться на тему о…
  • Ну и кстати, мне тоже важно — вообще имел ли смысл весь этот сыр-бор с сьемкой, видеомонтажем и обработкой и публикацией (это, вообще-то дорогая работа, расценки профессионалов в этой области весьма недетские, при том, что до этого уровня монтажа им, как правило очень далеко), или кроме участников конференции эти темы никому не интересны. Может есть какие-то косяки в видео? или предложения как сделать лучше? — связывайтесь со мной, возможно это можно будет исправить (или хотя бы вырезать). Это кстати относится и к докладчикам — если есть какие-то позорные неудачные моменты, или что-то не нравится — это можно убрать.


Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «В чем счастье заказчика? Готовые фичи вместо гант-чарта! (Станислав Калканов, AgileDays-2011)»