Конспект книги "Постигая Agile"

Скорее даже не конспект, а понравившиеся цитаты

Если за точность выполнения плана в команде отвечает только тот, кто исполняет роль его владельца, то все остальные, столкнувшись с неприятностями, могут отмахнуться от них, сообщив: «Это проблемы того парня»

Люди ошибочно полагают, что, как только задачу записаны в план команда получает непреодолимое стремление ее выполнять.

Обязывают не планы, а наши обещания. План-это просто топ способы фиксации.

Обязательства – это обещание сделать что-либо к определенному сроку

Часто команда голосует за командно-административного менеджера проекта, потому что он берет на себя всю ответственность.

Традиционные руководители проектов воспринимают план как способ мотивировать команду и фиксировать сроки выполнения работ. Они убеждены, что план заставляет команду работать, а без него сотрудники будут бездельничать. Менеджер проекта, требующий от команды чересчур оптимистичных оценок объема работ и «утверждающий» их в начале спринта, будет чувствовать себя комфортно, используя этот план для дальнейшего третирования команды. Вот почему такое отношение к «плану работ, рабочему плану» может привести к разладу между руководителем проекта и командой.

Командно-административное управление проектом начинается с предположения, что задачи по развитию проекта должны быть выполнены определенным членом команды. Причина, как правило, в наличии специальных знаний (например, администратор баз данных с навыками оптимизации БД). Это выглядит как аргумент в пользу предварительного планирования: создает узкое место в потоке работ, и команда, имеющая фиксированный крайний срок выполнения работы, должна учитывать это при планировании. Как ни странно, это самый распространенный источник проблем в области управления проектами

• Во время этой встречи каждый член команды несет ответственность перед коллегами и должен объяснить, почему обязательство, взятое на предыдущей встрече, не выполнено.
• Ежедневные митинги нужны для выявления проблем, а не для их решения. Если не удалось решить проблему в течение пары минут во время дискуссии, запланируйте следующую встречу с теми, кто должен участвовать в решении.
  
• В проекте нет единственного «хранителя плана» или одного наиболее значимого человека. Очевидно, что некоторые разработчики опытнее других.
  
• Не воспринимайте это как ритуал
  
• Каждый принимает участие. Каждый – это значит и тестировщики, и бизнес-аналитики, и остальные члены команды, и владелец продукта.
  
• Не относитесь к этому как к статус-митингу. Типичный статус-митинг – это отличный пример «ритуала», который мы должны совершать каждую неделю. Все мы знакомы с ритуалами и совершаем их, не задавая лишних вопросов. Предполагалось, что совещание служит двум целям: информировать команду и администрацию. Но для большинства команд это действительно всего лишь односторонняя связь, связка двух человек – члена команды и руководителя проекта.
  
• Когда вы ищете препятствия, анализируйте не только текущую работу. Просчитывайте ситуацию на несколько ходов вперед, исследуя каждый элемент в колонке «сделать», чтобы выяснить, повлекут ли они последствия.
  
• Бэклог и доска задач должны отражать реальный проект. Если проблема обнаружена, то вся команда должна работать вместе, чтобы исправить ситуацию
  
• Если люди негативно отреагируют на изменения, о которых узнали сегодня, то изменения, обнаруженные позже, они воспримут гораздо хуже. --- Разбивка проекта на этапы называется инкрементальной разработкой
  

Итеративный процесс позволяет достигать прогресса за счет последовательных уточнений. Команда разработчиков берет первый отрезок системы, зная, что он неполный или слабый в некоторых (а возможно, во многих) областях. Затем она многократно совершенствует эти области до тех пор, пока продукт не станет удовлетворительным. С каждой итерацией программное обеспечение улучшается путем добавления дополнительных деталей.

В инкрементальном процессе программное обеспечение создается и поставляется частями. Каждая часть, или инкремент, представляет собой полный ряд функций. Инкременты могут быть маленькими или большими, возможно, это будет только логин системы на экране или очень гибкий набор управления данными экрана. Каждый инкремент полностью закодирован и протестирован, и считается, что работу, проделанную в этой итерации, уже не нужно будет пересматривать.

• выявить главные потребности компании и транслировать их команде разработчиков;
• понять, какие именно функции программного обеспечения команда потенциально может поставить;
  
• выяснить, какие функции наиболее ценны для компании, а какие второстепенны
  
• работать с командой, чтобы понять, какие функции создавать легче, а какие сложнее
  
• использовать понятия ценности, сложности, неопределенности, комплексности и прочие, чтобы помочь команде выбрать нужные функции для создания продукта в каждом спринте
  
• делиться этими знаниями с остальными работниками компании, чтобы они могли сделать все необходимое для подготовки следующей версии программного обеспечения.
  

Бэклог задач считается «выполненным», когда его принимает владелец продукта и весь результат можно поставлять клиентам. Если нет однозначного определения понятия «выполнено» по каждому пункту, то неизбежны путаница и жаркие споры в конце спринта. Но когда все имеют четкое представление о том, что это означает для каждого пункта, то команда отчетливо видит, как продвигается спринт.

Обзор спринта – это специальное мероприятие, когда вся команда выступает перед пользователями и заинтересованными сторонами, чтобы продемонстрировать результаты своей работы за последние 30 дней. Если обещания не выполнены, то каждый член команды должен напрямую объяснить пользователю, что он делал и почему не справился.

Персональная мотивация не объединяет команду

Начинать с беклога - это значит начинать с пользователей

Scrum одновременно инкрементальный и итеративный. Инкрементальный – потому что работа разбита на последовательные этапы, а итеративный – потому что команда адаптирует каждый новый спринт к изменениям, которые происходят во время проекта.

Работа владельца продукта заключается в том, чтобы сохранить в команде мотивацию создавать ценность, помогая им понимать пользователей, разбираться в том, что они делают и для чего нужно ПО.

Когда командно-административный менеджер проекта выполняет анализ зависимостей для проекта на этапе его планирования, один из его наиболее важных инструментов – экспертное заключение.

Когда самоорганизующаяся команда ежедневно контролирует свой план во время scrum-митингов, она использует ту же экспертную оценку, но имеет гораздо больше информации, потому что участвуют все члены команды.

Самоорганизующаяся команда имеет больше шансов найти критическую зависимость, потому что ищет ее во время проекта. А командно-административная имеет меньший обзор и более скупую информацию, потому что делает анализ за несколько недель или месяцев до начала работы. Улучшенный обзор и высокое качество анализа зависимостей, проведенного в нужное время, – важный источник производительности успешных scrum-команд.

К сожалению, команды разработки нередко выпускают менее полезный для клиента продукт, чем могли бы. Для этого явления придуман специальный термин – золочение. Команды стремятся приукрасить программное обеспечение, то есть добавить никем не востребованные функции, причем делают это с самыми лучшими намерениями. Разработчики хотят помочь клиентам и думают, что создают нечто очень ценное. Вполне естественный порыв для разработчиков, любящих свое дело, но в то же время – одна из главных причин тех самых 64 % неиспользуемого функционала.

Еще один фактор появления большого количества неиспользуемых функций – отсутствие тесного взаимодействия с клиентами. Когда время общения пользователей с командой разработчиков сильно ограничено, они стараются затребовать как можно больше новых функций. В результате стейкхолдеры могут включить в план массу функций, которые не будут применяться на практике.

Планирование – это не предсказание будущего. Многие команды и менеджеры верят в миф об идеальном плане проекта, для которого разработчики могут дать точные оценки, а руководители проектов в состоянии спланировать любой риск и добавить оптимальный резерв на случай чрезвычайных ситуаций. Планы таких команд и менеджеров меняются не реже, чем у всех остальных, а порой даже чаще, потому что они включают в них слишком много мелких деталей, которые очень часто оказываются неточными. Недаром их проекты сталкиваются с проблемами планирования, и поэтому создается впечатление, что программисты бездарны в планировании, а программные проекты непредсказуемы!

• Ликвидируйте потери. Выявите работы, выполняемые вами, но не создающие ценность, и избавьтесь от них. - Усильте обучение Используйте обратную связь, чтобы улучшить свою работу.
• Принимайте решения как можно позже. Принимайте все важные решения по проекту, обладая максимумом информации о нем, – то есть в последний ответственный момент.
  
• Доставляйте ценность как можно раньше. Проанализируйте реальную стоимость задержек и минимизируйте ее при помощи систем вытягивания и очередей.
  
• Раскрепостите вашу команду. Сформируйте целенаправленную и эффективную рабочую среду и объедините энергичных людей.
  
• Добейтесь целостности. Создавайте программное обеспечение, интуитивно понятное для пользователей и работающее сообразно их ожиданиям.
  
• Следите за общей картиной. Постарайтесь досконально разобраться в той работе, которая выполняется у вас в проекте. Примените правильные методы измерения, чтобы убедиться, что вы действительно видите даже мельчайшие детали.
  

Это происходит потому, что, хотя отдельные люди и могут уклоняться от ответственности (особенно под прессингом руководства), команды имеют склонность к ее чрезмерной фиксации. Иногда это связано с желанием погеройствовать – программист обещает больше, чем может сделать. А порой потому, что ответственность вознаграждается: это характерно для тех, кто привык обещать, а потом как ни в чем не бывало извиняться за непредвиденные обстоятельства, помешавшие проекту. («Мы никак не могли это предугадать!») В компаниях, где привыкли обвинять и спасать свою шкуру (CYA), подход «пообещать и извиниться», конечно, не обеспечивает эффективные поставки программного обеспечения, но зато дает возможность получать высокую зарплату и сохранять свою должность

Среди руководителей бытует ошибочное мнение, будто, установив высокую планку, можно мотивировать сотрудников трудиться с утроенной энергией для достижения заданной цели. Если дать каждому члену команды большие цели и сжатые сроки, то все будут стремиться оказаться на высоте. Есть ощущение, что такой «грубо индивидуалистический» подход к построению команд позволит устранить бюрократию. Каждый человек уполномочен решать свои проблемы, и в результате вся команда становится высокоэффективной. Такой индивидуалист-менеджер поощряет практику «геройства». Программист, который работает допоздна, по выходным и создает для команды сложные решения, получает наивысшее признание и попадает в число лучших сотрудников. Такой «герой» поднимается на вершину не благодаря командной работе, не потому, что делает лучший продукт или совершенствует деятельность всей команды, а лишь из-за сидения в офисе допоздна и в выходные. Это непродуктивный, хотя довольно традиционный подход.

Мэри и Том Поппендик решили определить семь потерь разработки программного обеспечения. Как и многое другое, связанное с Lean, эта идея позаимствована у компании Toyota в середине прошлого века. Поппендик обнаружили, что это поможет увидеть потери в вашем проекте:

• Частично проделанная работа. Когда вы осуществляете итерации, вы лишь приближаете работу к состоянию «сделано», потому что если это не полностью работающий продукт, то он не создает ценности для пользователей. Любая деятельность, не предоставляющая ценность, – потери.
• Дополнительные процессы. Пример дополнительного процесса – антипаттерны управления проектом, где команда тратит 20 % времени на отчет о состоянии проекта и оценки, которые используются исключительно для обновления отчета о его состоянии. Все это требует дополнительных усилий в процессе отслеживания проекта и формирования отчетности, но не создает стоимости.
  
• Лишние функции. Когда команда создает никем не заказанную функцию вместо той, которая на самом деле нужна пользователям, – это потери. Иногда причина в том, что кто-то в команде слишком увлекся новой технологией и хочет воспользоваться возможностью изучить ее. Возможно, это ценно для того, кто таким образом улучшает свои навыки, и даже для всей команды (в долгосрочной перспективе). Но это не помогает построению ценного программного обеспечения, так что является потерями.
  
• Переключение между задачами. Некоторые команды работают в многозадачном режиме, и часто он выходит из-под контроля. Люди понимают, что полностью заняты (созданием программного обеспечения) и к тому же имеют дополнительные задачи, относящиеся к частичной занятости (поддержка, обучение и т. д.). И каждый кусочек работы важен и приоритетен. Scrum-ценность «сосредоточенность» демонстрирует нам, что переключение между проектами или не связанными между собой задачами в рамках одного проекта вызывает неожиданные задержки и усилия, потому что создает дополнительную нагрузку на способность к восприятию задач. Теперь мы можем назвать это иначе: потери.
  
• Ожидание. Есть множество вещей, заставляющих профессиональных разработчиков ПО сидеть и ждать: кто-то должен закончить обзор спецификации, утвердить доступ к системе проекта, исправить проблемы с компьютером или получить лицензию… Все это – потери.
  
• Движение. Когда члены команды располагаются в разных помещениях, людям приходится вставать и идти к коллегам, чтобы обсудить проблемы, связанные с проектом. Если сложить время, затраченное на такие прогулки, то потери составят несколько дней или даже недель.
  
• Дефекты. Разработка через тестирование предотвращает множество дефектов. Каждый программист, «зараженный тестированием», хорошо знаком с ситуацией, когда модульный тест обнаруживает ошибку, которую было бы очень сложно исправить позднее, и понимает: требуется гораздо меньше времени на написание всех тестов, чем на отслеживание одной ошибки, особенно если пользователи обнаружат ее после выпуска новой версии. Но если команде приходится задерживаться, чтобы исправлять ошибки, которые можно было предупредить, – это тоже потери.
  

Цель теории массового обслуживания – это необходимость убедиться, что люди не перегружены работой и у них есть время делать вещи правильно. Очередь представляет собой список задач, функций или элементов для группы либо индивидуального разработчика. Очереди имеют порядок. Это, как правило, «первый вошел, первый вышел». Согласно данному правилу, никто не может изменять очередность и элемент, который попал в очередь первым, прежде других вытягивается следующим участником и берется в работу.

Теория массового обслуживания является математическим исследованием очередей, и одно из ее направлений включает в себя предсказание тех последствий, которые вызываются добавлением очередей на входе системы. Lean говорит, что если сделать очередь как поток командной работы публичной и центральным местом в процессе принятия решений, то это поможет командам поставлять результаты работы значительно быстрее.

Когда менеджеры считают, что команды могут сделать невозможное, и игнорируют реальные ограничения проекта, они используют магическое мышление.

Команды при помощи бережливого мышления ведут работу по ликвидации потерь, находя любые виды деятельности, которые напрямую не способствуют построению ценных продуктов, и устраняя их.

Любая деятельность, которая явно не добавляет ценности проекту, считается потерями. Lean-команды стремятся увидеть их и исключить из проектов, насколько это возможно.

Построение целостности – это lean-ценность, включающая в себя воспринимаемую целостность, или то, как хорошо продукт удовлетворяет потребности пользователей, и концептуальную целостность, или то, как слаженно работают функции продукта.

Бережливое мышление помогает командам увидеть ситуацию в целом или объективно понять то, как работает команда, в том числе ее недостатки. Измерение дает возможность сохранить объективное представление о проекте и команде.

Поставлять как можно быстрее значит избавиться от любых ненужных действий, приводящих к задержкам в работе и возникновению узких мест.

Прогресс работ – это измерение, касающееся функционала, несущего ценность заказчику, а не технических задач. Другими словами, он показывает количество функционала или частей продукта, которые находятся в работе, а не конкретные задачи, выполняемые командой, чтобы произвести их.

Теория ограничений утверждает: каждый перегруженный рабочий процесс имеет по крайней мере одно ограничение

Система вытягивания – способ выполнения проекта или процесса, который использует очереди или буферы для устранения ограничений.

Стоимость задержки становится важна: если деталь в дефиците, то задержка ее поставки на конвейер оказывается очень дорогой, а если часть имеется в изобилии, то стоимость задержки низкая.

Минимальная маркетинговая функция (ММФ) – самый маленький «кусок» ценности или функциональности, который команда способна поставить, например пользовательская история или запрос пользователя – то, что может закрыть пункт в бэклоге владельца продукта.

Карта потока ценности – это визуальный инструмент, помогающий lean-команде реально увидеть, как работает проект, показывая весь жизненный цикл ММФ, в том числе время работы и время ожидания на каждом этапе.

Понимание первопричин проблемы поможет вам увидеть ее в целом. Метод пяти «почему» – эффективный способ сделать это.

Полезный инструмент, помогающий команде поставлять как можно быстрее, – WIP-диаграмма, визуальный инструмент, который показывает, как ММФ следуют через поток создания ценности проекта.

Есть три важных вида потерь, которые ограничивают рабочий процесс: муда (потери), мура (неравномерность) и мури (необоснованность и невозможность).