Метод критической цепи для проектов по разработке ПО

chain-metal-iron-links-of-the-chain-connection-cover.jpg

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

Читать дальше

Анонс. Открытый тренинг "Применение Agile для построения эффективной команды"

Коллеги, Санкт-Петербурге 19-21 мая пройдет наш первый открытый, 3-х дневный, тренинг "Применение Agile для построения эффективной команды". Тренинг раскрывает особенности применения Agile подходов Scrum, eXtreme Programming, Теории Ограничений (ТОС) и психологии  для разработки ИТ систем. Если вы ищете "серебряную пулю", чтобы сдавать ИТ проекты вовремя и улучшить доставку ценности вашим клиентам, этот тренинг для вас.

Читать дальше

Перевод статьи Эли Шрагенхайма. Часть 5. Управление характеристиками продукта в проекте

watch-gears-technic-technical-header.jpg

При планировании проекта, устоявшейся нормой является наличие детального плана всех характеристик продуктов уже на начале проекта. Методология планирования проектов ТОС, которая называется CCPM (Управление Проектами по Методу Критической Цепи), исходит из предпосылки, что уже в самом начале проекта существует хорошее понимание требуемого результата проекта и все задачи, которые необходимо выполнить для достижения этого результата, также известны вначале проекта.

Является ли эта предпосылка соответствующей реальности в множестве проектов? Хорошо ли иметь детальное определение результата проекта до начала проекта? Это хороший способ выполнения проектов? Какой уровень детальности необходим для принятия решения о начале проекта и оценки его рационального бюджета? Что на самом деле нужно, чтобы оценить время выполнения проекта?

Читать дальше

Перевод статьи Эли Шрагенхайма. Часть 1. Проблемные области принятия решения в управлении проектами

calendar-date-time-month-week-planning-paper-1-800-header.jpg

Применение общих подходов Теории ограничений, методологии составления графиков проектов и контроля за реализацией единичных проектов получила название Управление Проектами Методом Критической Цепи (CCPM). Позднее эта методология была также расширена на управление в условиях мульти-проектного окружения. Тем не менее, Теория ограничений до сих пор не внесла значительного вклада в другие критически важные области принятия решения в управлении проектами.

Читать дальше

Перевод статьи Эли Шрагенхайма «Проекты по развитию продуктов: рекомендации по оценке потенциала новых продуктов и планированию различных характеристик продукта в проекте»

examination-of-eyes-header.jpg

Существует три проблемных области принятия решения в проектном управлении, где ТОС [i] должна оказать значительное влияние:

  1. Как выбрать проект?
  2. Как выбрать конкретные характеристики продукта [ii] для данного проекта?
  3. Как управлять графиком проекта и его реализацией?

 

Читать дальше

Что делать если не успеваешь сделать работу в срок

Как успеть сделать в срок?

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

  • Внешние обстоятельства которые помешали,
  • Привычка откладывать все на последний момент,
  • Оптимистичные оценки относительно трудоемкости,
  • Сработал Закон Паркинсона: работа заняла все отведенное на неё время
  • Исходные данные пришли поздно.

И когда вы уже понимаете что явно не успеете, начинаются метания: "А что делать?"

Читать дальше

Надежный SCRUM

График расхода буфера критической цепи Что такого плохого в гибком (Agile) подходе к управлению проектом по разработке программного обеспечения? Особо ничего, если не считать того что завершение проекта в срок не стоит целью этой методологии.

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

Читать дальше