
Ваша оценкаЦитаты
VodkaSeledka8 марта 2023 г.1. Технические долги включают ту работу в проекте, которую мы решаем (хорошо, если осознанно) не делать в данный момент, но которая будет мешать развитию проекта в дальнейшем, если её не выполнить.
2. Технические долги не включают отложенную функциональность, которая была бы хорошим дополнением к проекту, но в данный момент имеет низкий приоритет (например, улучшенный интерфейс пользователя). Кроме этого, техдолги – это не баги.
1103
VodkaSeledka8 марта 2023 г.Перед стартом работы над дроблением монолита на микросервисы рекомендую пройтись по чек-листу и ничего не упустить:
1. Мастер-данные.
- Написание кода по-новому.
- Проектирование IT-продукта заново.
- Создание новой инфраструктуры.
- Измерение и проверка SLA.
- Вклад в fault tolerance на всех уровнях.
- Реорганизация команд.
- Работы по обратной совместимости.
- Интеграция служб поддержки.
- Догоняющий поток фич.
182
VodkaSeledka8 марта 2023 г.Микросервисы позволяют создать такой «рой», в котором каждая боевая единица отлично делает свою работу, умеет понимать общие задачи и работать на общую цель, при этом по своим задачами почти автономна. Если в такой «рой» кинуть палку или попытаться сбить его рукой, то структура немного изменится, потому что он (рой) увернётся от удара, но будет продолжать делать своё дело как единое целое; его целостность и работоспособность не нарушится из-за внешних случайностей.
119
VodkaSeledka8 марта 2023 г.Обычно монолитную архитектуру можно описать так:
1. Единая точка разработки и релиза.
2. Единая база данных.
3. Единый цикл релиза для всех изменений.
4. В одной системе реализовано несколько бизнес-задач.
113
VodkaSeledka8 марта 2023 г.Читать далееFix Time and Budget, Flex Scope (FFF)
1. Зафиксированы три точки проектного треугольника: срок, деньги и внутреннее качество системы.
2. Оплата происходит в конце проекта с возможной предоплатой.
3. В контракте описываются задачи, но достаточно масштабно, чтобы можно было флексить объём работы без переписывания контракта.
4. Объём работы оговаривается в начале проекта, но является предметом дискуссии.
5. Во время разработки нужно следить за сжиганием бюджета, приближающимся сроком релиза и оставшимися задачами, чтобы всё самое важное успеть к сроку. Глубина проработки задач и конечный список этих задач могут меняться во время работы прямо на планированиях или стендапах.
6. Риски делятся поровну: разработчики обязуются поставить ценность в срок и в рамках бюджета, а заказчик старается выбрать/урезать задачи, исходя из приоритетов бизнеса и текущей ситуации.
7. Внутреннее качество системы становится очень важным: объём работ может меняться, но срок и бюджет двигать никто не собирается. Поэтому код, тесты, внутренний дизайн, архитектура и автоматизация должны быть высокого качества, быть гибкими и в конечном итоге помогать быстро подстраиваться под любые изменения.
113
VodkaSeledka8 марта 2023 г.Читать далееTime and Materials (T&M)
1. Зафиксированы деньги и внутреннее качество системы, хотя вторым частенько пренебрегают из-за халатности или неопытности с обеих сторон.
2. Заказчик берёт в аренду ресурсы исполнителя по фиксированной ставке и управляет ими по своему усмотрению.
3. Исполнитель отвечает за максимально качественный продукт за счёт своей компетенции.
4. Оплачивается при этом время, которое сотрудники исполнителя были заняты на проектах заказчика. Это происходит в конце отчётного периода, например, раз в месяц.
5. Основные риски берёт на себя заказчик.
6. Если у заказчика есть чёткое понимание задач и организован контроль работы (в том числе собственных ресурсов, особенно Product Owner'а), то это самый оптимальный и быстрый вариант управления, потому что он наименее бюрократизирован: все заняты только разработкой без лишних отвлечений на ритуалы согласований.
114
VodkaSeledka8 марта 2023 г.Читать далееFixed price
1. Зафиксированы три точки проектного треугольника: срок, деньги и объём работы.
2. Основные риски берёт на себя исполнитель, и, как следствие, эти риски отражаются на оценке. Кроме этого, создаются риски и для заказчика (раздел l, глава 7).
3. Большим плюсом этого подхода является предопределённые до начала работ параметры проекта. Очень часто бизнесу/государству нужно прописать в договоре срок, деньги и объём работы.
4. Внутреннее качество при этом редко фиксируют. Зато почти всегда именно качеством жертвуют, чтобы в нашем изменчивом мире умудриться попасть в срок с фиксированным объёмом работы. Почему так происходит и что является корнем проблемы, обсудим чуть дальше.
5. Оплата происходит в конце проекта с возможной предоплатой в начале.
112
VodkaSeledka8 марта 2023 г.Читать далееПовышаем качество работы
Основные идеи, которые помогут повысить качество работы:- Планирование работ – цикличный и постоянный процесс, мы занимаемся непрерывным прилаживанием новых вводных, поэтому нужно использовать гибкие инструменты.
- Не заменяйте живую коммуникацию на ТЗ. Если ТЗ начинает занимать ведущую роль, то стоит насторожиться и проверить, как устроена коммуникация в проекте между всеми участниками.
- Пишите ТЗ, когда это необходимо. Делайте его как можно более полезным.
- Контроль процесса разработки достигается за счёт визуализации текущего состояния проекта и понимания дальнейших шагов.
111
VodkaSeledka8 марта 2023 г.Читать далееЧтобы уменьшить неопределённость, надо предсказать будущее, построить план и двигаться согласно плану. Как сказал Джокер в фильме «Тёмный рыцарь»: «Люди охотно соглашаются действовать согласно плану, каким бы он ни был, даже если план ужасен».
С этой точки зрения, идеальный уменьшитель неопределённости – техническое задание.- Снизить риски, уменьшить неопределённость
Перед началом проекта и заказчик, и исполнитель будут рады узнать список задач, бюджет и дату релиза. Когда все три составляющие известны и неизменны, тогда проще планировать- Задача «бездумному» исполнителю
Если вы взяли проект на субподряд или отдадите его на субподряд, то всем проще работать со списком задач, который передаётся по цепочке. Чем подробней формализовано задание, тем проще отчитаться о выполнении. Чем подробнее описаны требования, тем меньше возникнет вопросов у всех участников б- ТЗ требуется согласно регламентам
В крупных компаниях и госструктурах часто есть регламент, по которому наличие ТЗ является обязательным пунктом при согласовании бюджета проекта. Независимо от того, оправдано написание ТЗ для конкретного проекта или нет, придётся его написать- Нет доверия с одной из сторон
Если заказчик не доверяет исполнителю или исполнитель не доверяет заказчику, то у них возникает естественное желание защититься друг от друга через подробное описание задачи.117
VodkaSeledka8 марта 2023 г.Почему из всех вариантов решения этой задачи часто выбирают написание подробного плана действий в форме технического задания? Ведь совершенно необязательно иметь стопроцентный контроль над проектом на следующие два года. Более того, иногда Big Design Up Front приносит вред и убытки. Гонщик Mario Andretti говорил об этом так: «Если вы контролируете всё, значит, едете недостаточно быстро».
114