К основному контенту

Отзыв-конспект "Критическая цепь" Э.Голдратт

По наводке @pimenaus прочитал "Критическая цепь" Э.Голдратта.

Отлично. Читается легко.

Правильный отзыв читайте у pimenaus'а, тут просто конспект с умными мыслями из книги.

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

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

Алгоритм поиска того, на чем надо сфокусироваться:

  1. НАЙТИ компонент-ограничение системы.
  2. Решить, каким образом МАКСИМАЛЬНО ИСПОЛЬЗОВАТЬ компонент-ограничение системы.
  3. ПОДЧИНИТЬ все остальное принятому решению: бессмысленно развивать остальные части системы, если они зависят от того компонента, который является ограничением
  4. РАЗВИТЬ (расширить) ограничение системы: сделать так чтобы оно перестало им быть или уменьшить его влияние

"сфокусированность и процесс непрерывного улучшения — это одно и то же."

Оценка сроков или почему "5 + 5 = 13"
"большинство людей ведут себя в соответствии с тем, как измеряется их деятельность"
"Основное влияние на оценки по времени оказывает то, насколько сотрудник опоздал с завершением задания в прошлый раз"

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

Анализ использования времени, появившегося из-за ошибочных оценок
"Опоздание одного элемента плана полностью передается следующему элементу. Выигрыш по времени, достигнутый одним элементом, как правило, разбазаривается."

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

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

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

Чистую теорию можно почитать здесь. И пару раз перечитайте книжку :)

У @pimenaus'а можно найти еще обзоры книжек про теорию ограничений и про то, в какой последовательности их лучше читать.

Комментарии

  1. Еще хорошо бы знать то, на чем основывается CCPM - это Теория Ограничений (TOC), про это написано много книг, можно тут глянуть обзорчики: http://pimenaus.livejournal.com/tag/toc

    ОтветитьУдалить

Отправить комментарий

Популярные сообщения из этого блога

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu