Хотите, чтобы вас ценил руководитель?
Ценность любого сотрудника уже давно не измеряется одними лишь профессиональными навыками. Какую бы роль в разработке продукта вы не выполняли, важно не только хорошо делать свои собственные задачи, но и уметь правильно строить процесс самой работы, умело взаимодействуя с коллегами. Сегодня, когда компании все больше понимают выгодность хорошо работающих процессов, они стараются выбирать сотрудников, умеющих по ним работать. Это позволяет такому человеку подняться на ступень выше над обычными исполнителями и стать незаменимым для компании. Книга “Гибкие методологии на практике” - поможет вам стать таким человеком.
Для кого эта книга?
Разработчики
Гибкие методологии это то, с чем работают разработчики каждый день, поэтому знать все практики необходимо для ежедневной работы. Руководители команд
Руководителю, как никому другому, необходимо уметь выстраивать правильные процессы в команде. Владельцы продукта
Чтобы получить эффективное развитие своего продукта, просто необходимо знать нюансы построения процессов разработки, уметь правильно работать с приоритетами, описаниями задач и метриками. Менеджеры проектов
Менеджеры проектов - это прямые участники процесса разработки, они должны понимать все тонкости построения процессов. Другие участники
Всем участникам процесса разработки, тестировщикам, дизайнерам, DevOps-инженерам, необходимо знать хотя бы основы построения процессов, чтобы работать по ним. К книге “Гибкие методологии на практике” мы собрали весь свой разносторонний опыт по работе с процессами и изложили его для практического применения. Это не просто очередная книга по Agile, это руководство, по которому вы сможете научиться конкретным практикам и сразу же сможете применять их в своей работе.
Как применение практик, описанных в книге меняет работу
Вот лишь некоторые примеры того, какие результаты вы получите:
- Правильные четкие описания задач, вместо постановок на словах и разработки по дизайну без описаний.
- Только необходимые для работы церемонии, вместо изнурительных бесполезных встреч.
- Четко выстроенные процессы, позволяющие делать нужную работу с первого раза и уходить домой вовремя, вместо переработок, возвращений задач на доработку и задач, сделанных "в стол".
- Прозрачная работа с бизнесом, понимание бизнесом необходимости технического качества проекта, вместо конфликтов и недопонимания.
- Комфортное общение с руководством на его языке, вместо постоянного микроменеджмента.
- Отстроенные процессы рефакторинга, чистый, понятный и расширяемый код, вместо плохого качества проекта.
- Процессы, удобные именно для вашей команды, вместо "так надо по Agile".
!
Почему не получается?
Большинство воспринимает гибкие методологии, как бюрократию, усложняющую жизнь, приносящую много мороки и бесполезные встречи. Причина в неумении применять гибкие методологии на практике, менять их под свою команду, эффективно проводить встречи, общаться с бизнесом на понятном языке. Всему этому учит книга “Гибкие методологии на практике”.
Что вы найдете в книге
Основные темы, которым вы научитесь в книге:
Гибкое мышление, почему без него не работает и как его развить
Понимание преимуществ гибких методологий
Основы гибких методологий с разбором частых ошибок в трактовке, из-за которых удачного применения не получается
Техники планирования и приоритизации
Agile фреймворки, кому они подойдут и как с ними правильно работать
Ведение процесса и практики, необходимые каждому
Внедрение и адаптация под себя и свою команду, что делать, когда из коробки не работает
Авторы книги
Пора перестать страдать от неудобных процессов, перерабатывать и лишаться повышений из-за очередного неудачного релиза. Пора взять построение процессов разработки в свои руки, подняться на ступень выше просто исполнителя и прокачать свою карьеру по максимуму.
Купите книгу “Гибкие методологии на практике” сегодня, а завтра уже наблюдайте за первыми результатами!
Оглавление книги
- Почему Agile
- Плюсы для бизнеса
- Более быстрый time to market
- Быстрая окупаемость инвестиций и экономия на ненужном функционале
- Проактивное управление рисками
- Встроенное качество
- Разработка правильного продукта
- Постоянное выравнивание продукта по видению бизнеса
- Предсказуемость
- Удовлетворенность клиента
- Плюсы для разработки
- Понимание целей продукта
- Прозрачность работы с бизнесом
- Возможность самостоятельной работы
- Возможность итеративного совершенствования
- Встроенное в процесс качество
- Agile-мышление
- Системный подход
- Уважение
- Сотрудничество
- Итерационные циклы обучения
- Возможность развития мастерства и чувство сопричастности
- Фокус на доставку ценности
- Способность к изменениям
- Баланс и здравый смысл
- Основы Agile
- Основные ценности Agile
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
- 12 принципов Agile
- Наивысшим приоритетом признается удовлетворение заказчика за счёт ранней и бесперебойной поставки ценного программного обеспечения
- Изменение требований приветствуется даже в конце разработки (это может повысить конкурентоспособность полученного продукта)
- Частая поставка работающего программного обеспечения (каждые пару недель или пару месяцев с предпочтением меньшего периода)
- Общение представителей бизнеса с разработчиками должно быть ежедневным на протяжении всего проекта
- Проекты следует строить вокруг заинтересованных людей, которых следует обеспечить нужными условиями работы, поддержкой и доверием
- Самый эффективный метод обмена информацией в команде — личная встреча
- Работающее программное обеспечение — лучший измеритель прогресса
- Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок
- Постоянное внимание к техническому совершенству и хорошему проектированию увеличивают гибкость
- Простота, как искусство не делать лишней работы, очень важна
- Лучшие требования, архитектура и проектные решения получаются у самоорганизующихся команд
- Команда регулярно обдумывает способы повышения своей эффективности и соответственно корректирует рабочий процесс
- Планирование и приоритезация
- Бизнес видение и дорожная карта
- Описание задач
- Формат описания задач как пользовательских историй (User Story)
- Критерии приемки задачи
- Определение ответственных за постановку задач
- Определение критериев готовности задачи к разработке (Definition of Ready или DoR)
- Критерии готовности задачи (Definition of Done или DoD)
- Фичи и эпики
- Приоритезация задач
- Управление бэклогом
- Методы приоритезации
- Базовая приоритизация
- Метод MoSCoW
- Метод Dot Voting или голосование точками
- Метод Play Money - техника игровых денег
- Метод RICE
- Метод ICE
- Оценка задач
- Какой должна быть оценка и что такое стори поинты
- Методы оценки задач
- Покер планирования
- Метод размеров рубашек
- Планирование
- Производительность (Velocity) и вместимость (Capacity) команды
- Планирование спринта (или итерации)
- Agile фреймворки
- Скрам (Scrum) фреймворк
- Церемонии Скрама
- Видение проекта
- Ежедневный стендап
- Планирование спринта
- Демо или ревью спринта
- Ретроспектива спринта
- Планирование релиза
- Основные роли в Скрам
- Канбан
- Ведение процесса и практики
- Метрики
- Диаграмма сгорания работ (Burndown chart)
- Диаграмма сгорания работ наоборот (Burnup chart)
- Диаграмма производительности (Velocity chart)
- Диаграмма сравнения запланированной и выполненной работы (Committed vs Delivered)
- Количество дефектов (ошибок), найденных на продакшене и тестировании
- Время жизни дефекта
- Диаграмма сгорания эпика или релиза
- Диаграмма времени жизненного цикла задач
- Сводная диаграмма процесса
- Практики
- Непрерывная интеграция и поставка
- Рефакторинг
- Стандарты кодирования
- Разработка через тесты (TDD)
- Парное программирование
- Внедрение и адаптация Agile под свою команду, решение проблем
- Причины основных проблем при внедрении Agile
- Как менять Agile-фреймворк под нужды команды
- Как работать с неожиданными задачами и дефектами в середине спринта (или итерации)
- Что делать, если бизнес нарушает Agile принципы и практики
- Кто нужен команде, для успешной работы
- Каким командам Agile не подходит
- Заключение