Комментарии 12
О чем статья то? Вы ознакомились с манифестом, чтобы найти ответы на все свои вопросы, а вместо этого нашли даже не заповеди, а положения, задающие нарратив?
Agile отвратителен
Да любому здравомыслящему человеку, зашедшему со стороны, очевидно, что эти принципы - очередной инфоциганский бред для продажи курсов. Сферический конь в вакууме и то больше пользы приносит как концепция, чем эти оторванные от контекста и действительности высказывания. Ония очевидно носят неуничверсальный характер, были созданы в определённом контексте и для узких целей. Чё с этим эджайлом носятся все?
Ну потому как он работает 🤷🏼♂️ собственно, автор концепции гибгого управления проектами прекрасно таки приводит примеры рабочич проектов по scrum методу, поясняет как, почему и зачем. А так же чётко говорит, что это не конечная железная система, а база, которуб можно вполне развивать. Только нужно читать первоисточник ))
Если принципы в манифесте не устраивают это просто непонимание или недостаток опыта в разработке или неверная понимание написанного
Принципы общие, они не учитывают контекст продукта и квалификацию команд
Общие принципы трудно написать
Писать, что мол частые поставки вредны - тут просто надо итерационно простыми шагами поставлять, для части продуктов это жизненно необходимо, насколько я помню авторы писали принципы для традиционных корпоративных приложений, там можно поставлять часто.
Я лично мог каждые 15-30 минут поставлять - но я сидел недалеко от пользователей и общался лично
.
Как вы думаете, пора ли пересмотреть Agile-манифест или его принципы всё ещё актуальны? Насколько они работают в вашей компании?
Нужная своя голова на плечах, опыт и управленческие навыки
Подумайте, как в 41 году прошлого века смогли в условиях войны эвакуировать сотни заводов и в кратчайшие сроки начать производить новую продукцию?
Ведь те, кто это смог осуществить Agile-манифест не читали.
Допиливать уже работающие процессы — спорный момент. Можно бесконечно дорабатывать архитектуру, но пока вы это делаете, заказчику может понадобиться что-то другое. Если вы ориентируетесь на принципы из «Чистого кода», то, возможно, вы регулярно выпускаете технически безупречные, но при этом не адаптивные решения.
Если процессы и архитектуру нужно допиливать, то значит процессов и архитектуры у вас нет. Есть только "автоматизированный бардак". Главный принцип гибкой разработки (а Agile это прежде всего методология разработки, а не управления проектами и релизами, что даже в названии манифеста записано), это:
"Прежде чем вносить изменения в функционал, надо доработать архитектуру, процессы и окружающий код так чтобы эти изменения были максимально просты, очевидны и адаптивны".
То есть "чистый код" это не противоположность адаптивным решениям, это наоборот они самые и есть. Вместо костыльного хака придуманного за минуту - потратить хотя бы 5 минут на встраивание нового функционала в архитектуру, или создание архитектуры там где её нет, чтобы данное изменение не усложняло, а упрощало дальнейшую разработку.
Вкратце: "Лучше день потерять, потом за 5 минут долететь".
Если так разрабатывать постоянно, то будет не перевернутый треугольник, а узкий вертикальный прямоугольник который равномерно наполняется функционалом, не увеличивая сроки и стоимость каждой новой фичи.
А то что нарисовали вы, это не Agile разработка, а Agile профанация "эффективными" менеджерами, когда ежедневное поддержание кода простым, понятным и готовым к любым изменениям, заменяется ежедневными совещаниями весь рабочий день, о том как мы гибко всем управляем, а поддерживать гибкость кода нам в результате некогда, поэтому мы переврём весь манифест, уволим разработчиков которые пытались хоть что отрефакторить и выбраться из бесконечно увеличивающейся сложности, и наймем побольше ATL-ей и проджект менеджеров которые будут ходить и спрашивать "ну чо там", в два раза чаще.
Всё упирается в контекст
Здесь согласен, всё очень сильно зависит от контекста. Мы тоже проводим этот тренинг в нашем учебном центре, и обычно вначале всегда у участников бывает сопротивление — это нормально. Эти принципы не внедряются за раз, это происходит постепенно. Почему и говорят "Agile-трансформация компании", потому что меняются не только процессы, но и культура. Сначала в одной команде на пилотном проекте, потом постепенно-постепенно можно оценивать результат и двигаться дальше. Сразу "стать Agile" на уровне всей компании просто нереально.
Вам очень повезло, что вы смогли послушать столько разных мнений. Это, безусловно, одно из преимуществ работы в командах на тренинге. В обсуждении всегда рождается что-то ценное. Со временем участники, как правило, начинают видеть пользу и запускают процесс изменения в своих компаниях.
Методологий потому и много, что они применимы к разным типам продуктов и этапам их жизни. Agile прекрасно подходит для быстрого создания инновационных продуктов. Для развития существующих - скорее нет.
Есть не просто ощущение, а уверенность что вам ещё надо много чего почитать и поучить, чтобы оспорить свои же выводы. Причём делать вы будете это с удовольствием когда поймёте
12 принципов управления проектами: что не работает в Agile