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