О том, что делать сразу несколько дел – значит не сделать ни одного, мы знаем с детства. Пословица про погоню «за двумя зайцами» считается классическим примером русской народной мудрости. В методике управления проектами по Теории ограничений систем (ТОС) это называют многозадачностью. Выполнение нескольких задач в одном проекте или задач из разных проектов, обычно приводит к срыву запланированных сроков или к ухудшению качества выполненной работы.
В последнее время я часто читаю обсуждения об Agile и отчаиваюсь. Почти каждый вопрос об Agile звучит так: «Какой инструмент лучше всего использовать для {…} в Agile?». Это разочаровывает. Кто-нибудь помнит Манифест Agile? В нем написано: «Люди и взаимодействие важнее процессов и инструментов». Большинство, кажется, забыли этот урок или, возможно, никогда не понимали его.
Каковы границы использования Критической цепи (CCPM)? Другими словами, когда использование CCPM выгодно, а когда необходимо внести определенные изменения?
Не важно, какую бы сферу деятельности современного конкурентного мира вы бы ни рассмотрели, на каждую из них оказывается давление: нужно выполнять больше проектов, быстрее, используя меньше ресурсов.
Запись вебинара Виктора Вальчука «Прорывная ретроспектива» будет интересна тем, кто работает в самоорганизующихся командах (Agile, кanban, холократия), и кому нужны результативные решения ретроспективных совещаний.
Все началось с того, что исполнительному директору компании Pinnacle Strategies Марку Воппэлу позвонили представители компании British Petroleum, с просьбой оказать помощь в борьбе с разливом нефти в Мексиканском заливе. Этот звонок направил представителей компании Pinnacle на выполнение задания международной важности – увеличить выпуск оборудования для устранения нефтяного пятна и, затем, помочь в организации небывалых по масштабам мероприятиям по очистке. В мероприятии приняло участие более 10000 судов.
Концепция MVP – минимального жизнеспособного продукта – вышла из популярной книги Эрика Риса. И это очень полезная и недооцененная концепция.
Установить на этапе планирования длительность всех задач со 100%-й точность практически невозможно. Этому могут помешать уже на этапе исполнения непредвиденные обстоятельства.
Как известно, ретроспектива предлагает ответить нам на три вопроса: 1. Что мы делаем хорошо? 2. Что мы делаем плохо? 3. Что нам нужно сделать, чтобы исправить ситуацию? Достаточно ли этих вопросов? На мой взгляд – нет.
Ретроспектива является одной из священных традиций Agile в разработке программного обеспечения. Но никто не говорит вот о чем: ретроспективы – это не обязательно улучшение.