|
|
| Строка 34: |
Строка 34: |
| | | | |
| | [[Категория:AgileDays-2011 (наша запись)]] | | [[Категория:AgileDays-2011 (наша запись)]] |
| − | {{feedback-appeal|AgileDays}}
| + | |
| | {{replicate-from-custiswiki-to-lib}} | | {{replicate-from-custiswiki-to-lib}} |
Версия 20:45, 24 июня 2011
Аннотация
- Докладчики
Что будет, если практики Agile распространить не только на разработчиков, но и на всю команду — на аналитиков, проектировщиков интерфейсов, документаторов, продвиженцев? Как поменяется работа аналитиков? Сколько времени потратить на начальные исследования пользователей? Когда уже можно начинать программировать? Можно ли проектировать интерфейс по кускам? Как составить ТЗ, чтобы его прочитали разработчики?
В докладе мы ответим на эти и подобные вопросы, основываясь на нашем опыте, полученном в проекте «Электронный бухгалтер Эльба».
Видео
Для этого доклада нужен подкаст (аудиозапись)?
Презентация
Примечания и отзывы
Докладчики из команды компании СКБ «Контур», разрабатывающей любопытный сервис — «Электронный бухгалтер Эльба». Идея — предоставить малому бизнесу сервис упрощенной бухгалтерии в интернет. На сайте есть ролик, наглядно объясняющий суть сервиса. Примечательно, что сервис включает также возможность электронного документооборота с органами отчетности. Впрочем, речь не о продукте, а о команде, процессе, и докладе.
Команда довольно большая — 18 человек, и весьма разношерстная (9 ролей!). Там и разработчики (8 шт), и бухгалтеры-аналитики, «интерфесологи», продвиженцы-маркетологи, дизайнер, юзабилист, и я еще парочку забыл.
Начинали в стиле водопада, но быстро (через пару месяцев) поняли бесперспективность этой затеи и начали двигаться маленькими итерациями, стараясь полностью реализовывать отдельные фичи. Поставили себе задачу «каждый месяц выпускать Real release», то есть такой релиз, где есть что-то существенно новое, а не мелочи и багфиксинг. Это очень правильный принцип, и им, вроде как, удается его выдерживать.
Что удивило:
- Они сидят в одной комнате (18 человек!). Считают это за достижение и говорят, что это им сильно помогает, но я реально не понимаю, как это возможно — или они по большей части молча работают.
- Если задачу оценили в N, а по ходу дела выясняется, что она скорее 3N, то вместо того, чтобы обозначить это, они начинают «списывать пропорционально». Мне кажется, это искажает раннюю информацию об «успеваемости».
Еще из любопытного:
- Они стараются делать такие вещи, как «презентации аналитиков и продвиженцев» — людей, работу которых очень сложно померить и пощупать. Но, стараются, просто чтобы команда была в курсе того, как идут дела.
- Вроде бы у них нет формального PM, хотя наверное, все-таки, кто-то такой есть.
- Позже, на Jam Session девушка по-моему именно из этой команды спрашивала, то делать с нудными и скучными скрам-митингами. Честно говоря, не удивительно при таком разбросе ролей в одной команде!
- Рисуют фичи (user stories) и таски на спринт в виде mind map’а. В любой момент его можно дорисовать, декомпозировав какую-то задачу, и разложив суммарную ожидаемую трудоемкость на части.
- Иногда они проводят «день ретроспективы», выезжая на базу отдыха. Думается, это классная практика, и не слишком накладная, на самом деле.
В общем, мне показалось, что до оптимальности процесса у них еще далеко, и скидывать столько разных ролей в одну команду — это слишком.
Что касается доклада, то он, увы, был довольно занудный. Рассказывали двое, но от обоих хотелось спать.
Доклад о том как внедряли SCRUM для всех ролей для продукта «Электронный бухгалтер Эльба» в компании «CКБ-Контур».
С точки зрения внедрения SCRUM достаточно скучно…
с бизнесовой точки зрения бизнеса, я узнал про этот проект когда он был на уровне бизнес-идеи… интересно, что он превратился в что-то реальное
Добротный доклад с максимумом конкретики, про то как одна небольшая контора делает SaaS для бухгалтерии в малом бизнесе, как все — и маркетологи, и сейлзы, и разработчики — совершают похожие телодвижения с развешиванием бумажек, совместным планированием и итерациями. Как сначала они потратили кучу времени на разработку МегаТЗ, а потом решили постепенно наращивать функционал и очень довольны. Как разработчики сознательно отбирают некоторый процент звонков у службы поддержки, чтобы лучше понимать пользователей (кстати, нам тоже стоит практиковать, это и правда полезно). Очень любопытный жаргон: «клизма» == «бонусная задача». Рисуют багзильное Древо Багов на бумажке. Хоть у них и Agile, а разделение ролей вовсю: разработчик, аналитик, инженерный психолог и дизайнер интерфейсов — это всё разные люди. В общем, ребята оставили хорошее впечатление.
Этот доклад был на первом месте по потенциальным слушателям, но моих надежд не оправдал. Потому что изложение, к сожалению, было очень медленным.
Речь идет о продуктовой разработке и они включили в команду всю цепочку, включая маркетинг. А начали с разработчиков.
Команда 18 человек, все в одной команте: 2 аналитика (грызут нормативку) + 1 инж.психолог + 2 проект.интерфейсов + 1 граф.дизайнер + 8 разр + 2 тестера + 1 менеджер + 1 документатор + 3 продвиженца.
Что интересно, в этой конструкции нет PO — поскольку есть много источников для задач, и как-то это совместно решается.
