Было время, когда большая часть программного обеспечения создавалась по модели водопада. Вы собрали требования, затем разработали свою систему, затем написали код, отправили код в QA, а затем отправили код клиентам. Хорошая идеальная сборочная линия.
За исключением того, что разработка программного обеспечения — это не конвейер.
Когда вы получаете физический продукт с конвейера, вы не можете просто сказать: «О, было бы идеально, если бы мы сделали это небольшое изменение здесь, в продукте. Не могли бы вы перенастроить всю вашу фабрику?»
Любой, кто сегодня следует методу водопада, застрял бы в том же положении. Каждое небольшое изменение переворачивает весь процесс. Медлительность этого процесса ставит эти продукты в невыгодное положение по сравнению с командами, которые выпускают программное обеспечение каждую неделю. Или каждый день. Или десятки, даже сотни раз в день. Продукты, разработанные с использованием водопада, не могут удовлетворить потребности современных потребителей.
Тем не менее, водопад был тем, «как все делалось» в конце 20-го века. Это привело к тому, что программное обеспечение стало менее способным удовлетворять потребности пользователей, а также стало чрезвычайно изнурительным для разработчиков. Сегодня команды разработчиков программного обеспечения экспериментируют с 4-дневной рабочей неделей. Под водопадом 40-часовая неделя была легкой неделей, особенно когда дата релиза была близка.
Войдите в гибкую разработку программного обеспечения.
По сути, идея состоит в том, чтобы сосредоточиться на самом важном. Вы не работаете над чем-то просто потому, что это указано в документе с требованиями. Вы работаете над чем-то, потому что это приносит пользу пользователям. Вы не пишете документ, потому что он просто «как есть». Вы пишете документы, только если они действительно помогают.
Моя любимая строчка в этом манифесте: «Люди и взаимодействие важнее процессов и инструментов».
Вопреки тому, что некоторые думают о гибкой разработке программного обеспечения, это не означает, что процесса нет. Все разработчики разные, и каждая команда состоит из уникальных разработчиков. Не существует единого процесса, который будет работать для всех команд во всех проектах. У меня когда-то была команда, которая делала волю с сюжетными очками. Поэтому мы использовали стори-пойнты. У меня была другая команда, которая боролась с сюжетными очками. Мы пробовали альтернативы.
Процесс должен адаптироваться к команде, а не наоборот.
Проблема в том, что это тяжело. Вы не можете просто следовать сценарию, разработанному для вас. Вы должны на самом деле размышлять о том, как работает команда, и принимать решения о том, как ее улучшить. Вам постоянно нужно практиковать критическое мышление. И чтобы добиться успеха, нужно много практиковаться. Вы должны признать, что все не будет идеально.
Войдите в agile-консультантов.
Прежде чем я продолжу, я начну с того, что это не обобщение всех agile-консультантов. Я дружу со многими из них. Они делают достойную работу. Некоторое время я работал agile-консультантом. Мне нравится думать, что я проделал достойную работу.
Проблема в том, что делать достойную работу означает помогать людям научиться критически относиться к своему процессу. Дело не в построении процесса для них. Речь идет о том, чтобы дать им возможность повторять свои процессы самостоятельно. Без нас.
Это не лучшая стратегия получения дохода для любой консалтинговой фирмы.
Это также не то, чего на самом деле хотят многие люди. Они могут сказать, что хотят этого, но это не так. Они идут и находят консультанта, который даст им конкретные ответы. Они хотят сборник пьес. Они хотят, чтобы кто-то дал им процесс, которому нужно следовать.
И всегда найдутся люди, готовые удовлетворить этот спрос.
Эти agile-консультанты предоставят процессы, которым вы обязательно должны следовать, чтобы быть гибкими. Они предоставят сертификаты, которые доказывают, что вы знаете, как правильно применять agile. Они обязательно примут ваши деньги в обмен на все это.
Водопадная модель, основной проблемой которой была жесткость процесса, была просто заменена другой серией жестких процессов, называемых «гибкими». По правде говоря, все, что фокусируется на процессе, а не на людях, является полной противоположностью гибкой разработке программного обеспечения.
Сюжетные баллы. Спринты. Скрам-роли. Это все инструменты процесса. Agile-консультанты могут заработать много денег, рассказывая вам, какие именно инструменты использовать и как их «правильно» использовать. На самом деле, эти инструменты похожи на все остальное. Их можно хорошо использовать, чтобы помочь вашей команде создавать программное обеспечение. Их можно использовать не по назначению, чтобы снизить производительность вашей команды. Смысл гибкой разработки программного обеспечения не в том, чтобы слепо использовать инструмент. Это оценка вашей ситуации, пробовать новые вещи, и если они не работают: пробовать что-то еще.
Размышляя о процессе разработки для вашей команды, я призываю вас сэкономить деньги на этих консультантах и сосредоточиться на первой строке манифеста гибкой разработки программного обеспечения: «Люди и взаимодействие важнее процессов и инструментов».
Первоначально опубликовано на https://blog.professorbeekums.com.
