Оглавление
Александр Васильевич Бындю. Антихрупкость в IT
Отзывы о книге
Предисловие
Кому нужна эта книга
Об авторе
Благодарности
Структура книги
Раздел I. Управление IT-продуктами
Глава 1. Кнопочное мышление против целостного IT-продукта
Откуда берутся кнопочные идеи
Торопыги
Решалы
Спасители
Я – могучий генератор кнопок
Мимикрирующие User Story и хитрые Product Owner'ы
User Story как фильтр
Хитрые Product Owner'ы
Мимикрирующие User Story
Преждевременные решения
Истории из жизни
Сколько стоят 1000 строк кода?
Истории из жизни
Движение без цели
Истории из жизни
Рефлексия и душевный покой
Глава 2. Impact Mapping на практике
История появления Impact Mapping
Руки без головы
Составляем Impact Map
Why?
Who?
How?
What?
Организация процесса
Пример из практики
Why?
Who?
How?
What?
Результаты создания Impact Mapping
Фильтр входящих задач
Модернизация Kanban-доски
FAQ по Impact Mapping
Глава 3. Углубление в Impact Map
Нюансы Impact Mapping
Типичные ошибки Impact Mapping
Impact Mapping гончара
Почему так сложно сформулировать идею?
Глава 4. Пять самых важных составляющих процесса выпуска успешных продуктов
Общий взгляд на процесс
Более детальный взгляд
Постановка задачи
Точки соприкосновения и взаимосвязи
Глазами пользователей
Первые прототипы
Работа над релизом
К чему готовить заказчика?
Бизнес-кейс
Первая попытка создания продукта
Начинаем с целей
Работаем с CJM и USM
Модель предметной области
Разработка интерфейса
Разработка и релиз
Почему это работает?
Глава 5. Когда надо прекратить писать техническое задание и начать делать продукт?
Затраты на прогноз к эффективности прогноза
Критерии, на которые стоит ориентироваться
1. Высокая цена ошибки
2. Важно не превысить бюджет
3. Важна скорость проверки гипотез
Когда прекратить писать ТЗ?
Глава 6. Пять причин написать ТЗ
1. Снизить риски, уменьшить неопределённость
2. Задача «бездумному» исполнителю
3. ТЗ требуется согласно регламентам
4. Нет доверия с одной из сторон
5. Прокси-менеджер
Как быть, если ни одна причина не подошла?
Глава 7. Двенадцать проблем при работе по техническому заданию
Техническое задание и хрупкость
1. Исполнитель делает выбор в пользу ТЗ
2. Заказчик делает выбор в пользу ТЗ
3. ТЗ создаёт лишь иллюзию предсказуемости и контроля
4. ТЗ – молчаливый источник ответов
5. Авторы ТЗ недоступны во время проекта
6. Описывает только простые задачи
7. Когда пора прекратить писать техническое задание?
8. ТЗ не фиксирует «качество»
9. ТЗ работает по принципу «всё или ничего»
10. Невозможно доказать непротиворечивость
11. Невозможно доказать полноту
12. Не вдохновляет
Не всё так плохо
Глава 8. Как и какое техническое задание писать при работе по Agile
Техническое задание при работе по Agile
Метафора для инструмента планирования
Реализация адаптивного плана работ
Визуальное и «многомерное» техническое задание
Циклы и пересмотры
Объём работ – не фиксированная величина
Ориентация на бизнес-цель
Я бухгалтер, я так вижу
Повышаем качество работы
Глава 9. Определение провала IT-проекта
История провальных проектов
Сцена первая – обнадёживающая
Сцена вторая – разочаровывающая
Сцена третья – провальная
Рисуем красивые фасады
Инженерная гордость
Инструмент для заказчиков
Глава 10. Управление проектом по Fix Time, Fix Budget, Flex Scope (FFF)
Три комбинации
Корень проблемы
А может, вообще не оценивать?
FFF – баланс гибкости и предсказуемости
Внутреннее качество системы
Мотивация заказчика и исполнителя
Выбираем FFF
Раздел II. IT-архитектура для достижения бизнес-целей
Глава 1. От микросервисного монолита к оркестратору
Этап № 1. Монолит
Характеристики
Проблемы
Как перейти на следующий этап
Этап № 2. Микросервисный монолит
Характеристики
Проблемы
Как перейти на следующий этап
Этап № 3. Микросервисы
Характеристики
Проблемы
Как перейти на следующий этап
Этап № 4. Оркестратор бизнес-сервисов
Характеристики
Проблемы
Естественное развитие
Глава 2. Бизнес-гибкость через микросервисы
История появления микросервисов
Почему микросервисы?
Ускоренная поставка бизнес-ценности
Дешёвое масштабирование и эффективный расход ресурсов
Переход на микросервисы
Глава 3. Скрытые расходы при переходе на микросервисы
1. Изменение подхода к работе с мастер-данными
2. Невозможность повторного использования исходного кода монолита
3. Проектирование системы заново
4. Создание нового подхода к управлению инфраструктурой
5. Измерение и проверка SLA каждого микросервиса
6. Микросервисы добавят на порядок больше точек отказа
7. Реорганизация команд
Ремарка о постепенности перехода
8. Обратная совместимость с монолитом
9. Интеграция и обучение служб поддержки
10. Догоняющий поток фич от бизнеса
Чек-лист
Глава 4. Где и как применять low-code платформы
Зачем бизнесу low-code платформы?
Причина провала предыдущих подходов к low-code
РДС (Россия делает сама)
Когда применение low-code оправдано
Есть ли жизнь с low-code?
Глава 5. Работа с унаследованным кодом
Что такое унаследованная система?
Риски и ответственность
Анализ унаследованной системы
Где находится исходный код?
Где развёрнута система?
Какая версия сейчас работает?
Как выпустить новую версию?
Интегрирована ли система с другими системами?
Логирование работы
Настроены ли мониторинг и аналитика?
Модульные и интеграционные тесты
Где можно найти тестовые сценарии?
Какие требования предъявлялись к системе?
Общие рекомендации для начала работы
Стратегия изменения
1. Переписать
2. Оставляем как было
3. Душитель
4. Переработка по модулям
Культура и развитие
Глава 6. Технические долги
Типы долгов
Неумышленные
Умышленные
Кратковременные
Долговременные
«Запах» кода с долгами
Когда начинаем платить?
Динамика нарастания долгов
Почему руководители допускают техдолг
Программисты видят причину
Руководители видят следствия
Стратегии уменьшения долга
Метрики технического долга
Внутреннее качество и антихрупкость
Послесловие
Антихрупность в создании IT-продуктов
Интересы бизнеса
Границы применимости
Дополнительные материалы и сноски
Вопросы и пожелания
Приложение 1. Дополнительные материалы к разделу I
Шпаргалка для предпринимателя по IT-миру
Как перейти от проектного мышления к продуктовому [видео и слайды]
История и принципы Бережливого производства ПО [видео и слайды]
Стендапы в стиле Kanban
Все программисты – оптимисты
Откровенное общение с заказчиком
Техническое задание как база знаний о проекте
Подборка манифестов из мира IT
Распаковка Byndyusoft на Hexlet
Приложение 2. Дополнительные материалы к разделу II
Inner Source и микросервисы: как получить больше плюсов, чем минусов [видео и слайды]
5 критериев выбора языка программирования для проекта от IT-архитектора [видео]
Архитектурные риски при планировании спринтов [видео]
Как выбрать IT-архитектуру: от хаоса до микросервисов [видео]
Бизнес-гибкость через микросервисную архитектуру
Переход от монолитной архитектуры к распределённой
Command and Query Responsibility Segregation (CQRS) на практике
Принципы проектирования классов (S.O.L.I.D.)
Технические долги [подскаст]
