Agile манифест разработки программного обеспечения
Agile философия это определенный образ мышления с системой ценностей. Сторонники аджайла верят, что создать идеальный продукт или запустить проект могут самостоятельные команды из профессионалов.
Введение
- этот манифест и принципы были описаны опытными разработчиками, которые обожглись об ошибки в управлении, которые приводили к огромным затратам и проблемам с качеством
- самые опытные разработчики и руководители собрались и описали ключевые идеи и принципы, которые позволяли делать качественные продукты максимально эффективно
- соблюдение этих принципов позволяет делать качественный продукт, с минимальными затратами
- нарушение или не понимание — приводит к тому что продукт в итоге окажется очень дорогим, с кучей проблем и низким качеством для конечных Клиентов
Далее приводим перевод оригинального манифеста дословно…
Сам Манифест
Мы постоянно открываем для себя более совершенные методы разработки
программного обеспечения, занимаясь разработкой непосредственно и помогая
в этом другим.
Благодаря проделанной работе мы смогли осознать, что:
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
12 основополагающих принципов Agile-манифеста
Мы следуем таким принципам:
- Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения. - Изменение требований приветствуется, даже на поздних стадиях разработки.
Agile-процессы позволяют использовать изменения для обеспечения заказчику
конкурентного преимущества. - Работающий продукт следует выпускать как можно чаще, с периодичностью
от пары недель до пары месяцев. - На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе. - Над проектом должны работать мотивированные профессионалы. Чтобы
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им. - Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды. - Работающий продукт — основной показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки. - Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта. - Простота — искусство минимизации лишней работы — крайне необходима.
- Самые лучшие требования, архитектурные и технические решения рождаются
у самоорганизующихся команд. - Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать
стиль своей работы.
Материалы по теме Agile
Tехника «5 почему» или как разобраться в любой проблеме?
Пять почему — техника, используемая для изучения причинно-следственных связей, лежащих в основе той или иной проблемы. Идея исследования причинно-следственных связей была выдвинута ещё Сократом. Но сам метод, получивший название «5 почему», был разработан основателем Toyota…
Эффективность неэффективности — Дорофеев Максим
Про то что компании и команды всегда продают свое узкое горлышко. Загружать людей становится не эффективно. эту статью хорошо дополняет другая:
Ценообразование в ИТ-разработке: Fixed Price или T&M?
Ценовые модели работы с ИТ-аутсорсерами: T&M, Fixed Price. Когда речь касается разработки и поддержки информационных систем, многие компании предпочитают сотрудничать с внешними партнерами. Это позволяет сэкономить на содержании собственного штата ИT-специалистов, упрощает контроль…
Сторипоинты и идеальные дни — в чем разница при оценке задач в разработке?
В разработке часто встречается путаница при выборе подхода оценки задач — выбирать сторипоинты или идеальные дни? Вводные Надо сказать что эта тема действительно сложная и спорная. Идея оценивать сторипоинты или баллы кажется интересной.…
Чек-листы в Agile-разработке: DoD, DoR, CoS (AC) & ToDo
В руководстве про Скрам-разработку и просто в статьях о Agile практиках разработки часто встречаются методы чек листов типа DoD, DoR, CoS и ToDo. Давайте разберемся что это такое и как ими пользоваться. DoD…
Барабан-буфер-канат (ББК) — из методов ТОС
Барабан-буфер-канат (ББК) (drum-buffer-rope (DBR)) – метод TOC для планирования и управления производством при наличии внутреннего ресурса-ограничения. О применении в ИТ-разработке. Видео по Канбан, Agile & ББК от Максима Дорофеева Веселое, интересное и полезное видео…
Шаблон сценария (user story) — популярный подход к описанию задач в SCRUM/Agile
Одна из ключевых проблем в разработке продуктов — взаимопониманием стейкхолдеров и команды, а также всех участников внутри команды. Один из классных подходов с решением проблемы — формат user story. В книге «красный скрам»,…
Планирование спринтов в разработке с использованием принципа «Полной банки»
Часто встречается проблема понимания как планировать спринты? Или квартальные планы (например OKR). Кто-то думает что надо забивать весь ресурс команды разработки. Но так ли это? Метод Полной банки в планировании спринтов SCRUM Есть…
Cynefin Framework — выбор подходов и решений задач через модель Киневина
Модель кеневин (или фреймворк кеневин, Cynefin framework) — позволяет лучше понять причину провала сроков в планировании и решения, которые следует предпринять для снижения рисков. Исследования специалистов в области управления показывают, что гибкие подходы в целом и аджайл в…
3 цитаты про Agile:
— «Agile означает, что вы быстрее конкурентов. Сроки в agile измеряются неделями и месяцами, а не годами» (Майкл Хьюго)
— «Важен не сам процесс, а процесс улучшения процесса» (Хенрик Книберг)
— «Agile-команды создают непрерывный поток ценности в устойчивом темпе, адаптируясь к меняющимся потребностям бизнеса» (Элизабет Хендрикссон).
Не знаю почему, но вот очень мне нравятся эти 12 принципов! Хотя понятно почему — потому что работа пошла эффективнее. Можно, конечно, пробовать управлять через реальную доску, но нам легче работать через аспро.agile.