Никакое ИТ решение не может реально помочь, когда нет подкрепления методологией обеспечения коммуникаций в компании или команде проекта и фокусирования целях. Поэтому, BIPULSE будет наиболее эффективен если следовать принципам Agile, Теории Ограничений Систем и Бережливого производства которые мы свели в 7 простых правил.
Так часто бывает, что обещаешь выполнить какую-то работу в срок и не успеваешь. Особенно когда нужно сделать не одну маленькую задачу, а какой-то большой объем работ, на две недели, месяц или два. Причин не успевания может быть много:
И когда вы уже понимаете что явно не успеете, начинаются метания: "А что делать?"
Agile eXtreme Programming Scrum
Сейчас много говорят о гибких подходах к разработке программного обеспечения. И даже пытаются внедрить для выполнения государственных контрактов. С другой стороны, много компаний спотыкаются на этих подходах. И хотя в компаниях делают что нужно, и даже Скрам-мастер в них есть, программный Продукт почему-то перестает развиваться, и появляется много задач на исправление дефектов. Давайте разберемся почему так происходит.
Что такое качество команды? В каких попугаях его мерить?
Качество команды величина субъективная, однако его можно выразить через скорость поставки качественного продукта решающего задачу клиента. Если записать это в терминах ТРИЗ, через идеальный конечный результат, то получим, что качественная команда поставляет качественный Продукт за ноль времени, и потери связанные с переделкой сделанной работы отсутствуют.
Но если мы знаем, что такое качество, и оно нас не удовлетворяет, то как мы можем его улучшить? Как улучшить то, что нельзя пощупать?
Методологии Производительность Управление проектами Шаблон
В любой проектной деятельности самым
базовым элементом планирования работ является "Задача". И это в корне отличает
Проект от деятельности по сопровождению продукта, в которой основной элемент
вокруг которого все вертится, это "Инцидент".
Формулировка Задачи должна отвечать на вопрос "Что мне надо сделать чтобы завершить проект?" , в отличии от инцидента: "Что произошло? И почему пользователь несчастен?"
Agile CCPM eXtreme Programming Методологии
Что такого плохого в гибком (Agile) подходе к управлению проектом по разработке программного обеспечения? Особо ничего, если не считать того что завершение проекта в срок не стоит целью этой методологии.
Эта методология очень хороша для создания Продукта, особенно программного. Вы идете к Заказчику раз в две недели, показываете ему прототип разработанной ИТ системы, уточняете, что еще нужно докрутить, чтобы он был счастлив. Получаете порцию пользовательских историй и....планируете в спринт необходимость переписать половину архитектуры, ибо новые хотелки не стыкуются с уже написанным кодом.
Иногда может сложиться впечатление что ваша команда проекта работает медленнее чем обычно. Это может быть субъективное впечатление, а может быть и на самом деле так. Обычно рекомендуют в таких случаях, для исправления ситуации, руководителю проекта поговорить с каждым участником команды.
