Менеджмент WordPress проектів або як вибрати
потрібний шлях
Пару слов о себе
Как сегодня мы разделим WP проекты?
На коленках за сутки
Пилим-пилим месяцами
А у нас будет что-то
История одного проекта
Кто такой заказчик?
Кто такая команда?
Выбор М перед началом проекта
Как это бывает в методологии “как получится”?
Трекинг времени в activecollab, basecamp… и это Гуд
Знаем о заказчике только по слухам от PM
Разрабатываем на опыте бывалых
чик - чик и в продакшен наш девиз заточенный годами
И мы знаем, что такое адский код
В чем беда такого подхода для нас?
Заказчик постоянно вносит коррективы
Фиксированный бюджет
Сжатые сроки
И от нас хотят какие-то показатели работы
Нам всем хотят “впарить” Scrum:(
Минусы Scrum для нас
Слишком много телодвижений
И затраты времени на них
Нет возможности добавить новую задачу в текущий
спринт
Что мы хотели получить?
Частые поставки продукта заказчику
Показатели команды
Возможность заказчику менять приоритеты тасков по ходу спринта +
добавлять новые
Понимание команды “а что вообще происходит”
Контроль работы заказчика “без обид”
Что-то внедрить
Что из всего этого Agile добра есть у нас?
Выкладка продукта каждую неделю (недельный спринт)
Планирование и оценка задач (и тут может зайти заказчик)
Статус митинги по утрам
Kanban доска + jira agile
Ретро
И тут мы забыли про самое важно - показатели
Главная ошибка
Когда ты будешь думать, что все ОК
Четкий вопрос, а нужен ли QA?
Выделить разработчика “пожарника”
Доверить эту почетную участь PMу
А может отдать на суд заказчику
А будут ли преимущества если выделить ресурс?
Выводы тоже нужны, выводы тоже важны
Спасибо вам!

Менеджмент WordPress проектів або як вибрати потрібний шлях

  • 1.
    Менеджмент WordPress проектівабо як вибрати потрібний шлях
  • 2.
  • 3.
    Как сегодня мыразделим WP проекты? На коленках за сутки Пилим-пилим месяцами А у нас будет что-то
  • 4.
  • 5.
  • 6.
  • 7.
    Выбор М передначалом проекта
  • 8.
    Как это бываетв методологии “как получится”? Трекинг времени в activecollab, basecamp… и это Гуд Знаем о заказчике только по слухам от PM Разрабатываем на опыте бывалых чик - чик и в продакшен наш девиз заточенный годами И мы знаем, что такое адский код
  • 9.
    В чем бедатакого подхода для нас? Заказчик постоянно вносит коррективы Фиксированный бюджет Сжатые сроки И от нас хотят какие-то показатели работы
  • 10.
    Нам всем хотят“впарить” Scrum:(
  • 11.
    Минусы Scrum длянас Слишком много телодвижений И затраты времени на них Нет возможности добавить новую задачу в текущий спринт
  • 12.
    Что мы хотелиполучить? Частые поставки продукта заказчику Показатели команды Возможность заказчику менять приоритеты тасков по ходу спринта + добавлять новые Понимание команды “а что вообще происходит” Контроль работы заказчика “без обид” Что-то внедрить
  • 13.
    Что из всегоэтого Agile добра есть у нас? Выкладка продукта каждую неделю (недельный спринт) Планирование и оценка задач (и тут может зайти заказчик) Статус митинги по утрам Kanban доска + jira agile Ретро
  • 14.
    И тут мызабыли про самое важно - показатели
  • 15.
  • 16.
    Когда ты будешьдумать, что все ОК
  • 17.
    Четкий вопрос, анужен ли QA? Выделить разработчика “пожарника” Доверить эту почетную участь PMу А может отдать на суд заказчику
  • 18.
    А будут липреимущества если выделить ресурс?
  • 19.
    Выводы тоже нужны,выводы тоже важны
  • 20.