The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
В настоящее время Манифест Agile является библией множества команд разработчиков программного обеспечения. Он содержит 12 принципов, которые показывают нам, как должна быть организована разработка программного обеспечения. Эти принципы были изобретены в 2001 году. В целом, я люблю и согласен со всеми ними. Однако на практике большинство команд разработчиков программного обеспечения неправильно их понимают. В результате, вот краткое изложение того, что происходит и мое толкование каждого принципа.
Принцип №1: “Нашим главным приоритетом является удовлетворение клиента через раннюю и непрерывную поставку ценного программного обеспечения.”
Сосредотачиваясь на “удовлетворении клиента”, сторонники Agile полностью забывают о части “через”. Они думают, что счастливый клиент является их настоящей целью, в то время как “непрерывная поставка” является чем-то, что очевидно помогает, хотя и не критически важно. Однако это на самом деле наоборот - клиент будет доволен если программное обеспечение идеально создано и доставлено. Если клиент не доволен, мы ищем другого клиента - это и есть настоящий дух профессиональной команды разработчиков программного обеспечения, которому следует придерживаться. Я считаю, что это то, что означает Манифест. Мы обеспечиваем, что наш процесс является “ранним и непрерывным”, что приведет к удовлетворению клиента. Мы сосредотачиваемся на улучшении нашего процесса, а не на удовлетворении клиента. Удовлетворение - это следствие, а не основная цель.
Принцип №2: “Приветствовать изменения требований, даже в поздних стадиях разработки. Agile-процессы используют изменения в свою пользу клиента.”
Большинство команд Agile понимают слово “приветствовать” здесь как разрешение забыть о любом управлении требованиями вообще. Какой самый простой способ приветствовать изменения? Очевидно, просто избавиться от любых документов с требованиями! В этом случае, любые изменения будут приветствоваться, поскольку они не повлияют на что-либо. Просто не будет ничего, на что они могут повлиять. Но это не то, что означает Манифест! Этот принцип означает, что наш процесс управления требованиями настолько мощный, что он может принять изменения в любой момент. Однако, достичь этого довольно трудно, если требования документированы.
Принцип №3: “Часто доставлять работающее программное обеспечение, от нескольких недель до нескольких месяцев, с предпочтением более короткого временного масштаба.”
Это замечательное правило часто понимается как требование для всей команды. Команда должна часто доставлять, в то время как программисты свободны доставлять почти ничего и когда угодно. Я считаю, что Манифест здесь подчеркивает как индивидуальные, так и групповые обязанности частой поставки. Я также считаю, что частота должна быть намного выше, чем “несколько недель”. Сегодня, с современными технологиями и инструментами, мы можем доставлять намного быстрее - несколько раз в день.
Принцип №4: “Бизнес-люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.”
Работа вместе не означает работу без четко определенных правил и процессов. Однако большинство команд понимают этот принцип как легализацию хаоса. Они думают, что так как мы работаем вместе, нам больше не нужно определять роли, мы не должны документировать требования, нам не нужно заботиться о своих обязанностях. В конечном итоге, мы не знаем, кто что делает и какова структура команды. Но это не то, о чем говорит Манифест! “Работа вместе” означает более быструю обратную связь в коммуникации и более короткий цикл ответа. Она точно не означает отсутствие ролей и обязанностей.
Принцип №5: “Строить проекты вокруг мотивированных людей. Предоставить им среду и поддержку, которые им необходимы, и доверять им выполнить работу.”
Доверие - замечательное слово и концепция, но оно не заменяет другое, не менее замечательное слово - контроль. Большинство команд Agile считают, что доверие означает именно это - полное отсутствие любой проверки, подтверждения, ответственности и контроля. “Мы доверяем нашим программистам писать идеальный код” - я слышал это бесчисленное количество раз, что является просто неправильным. Этот принцип означает кое-что совершенно другое. Это означает, что когда четко определенные задачи назначаются исполнителям, мы полностью делегируем им ответственность. Мы мотивируем их полностью нести ответственность за конечный результат. Однако, мы им не помогаем. Вместо этого, мы доверяем им как самодостаточным людям, способным завершить назначенные задачи самостоятельно.
Принцип №6: “Самый эффективный и эффективный способ передачи информации в команде разработки - это разговоры лицом к лицу.”
Разговоры лицом к лицу не означает нахождение в одном офисе. Манифест ничего не говорит о команде, находящ
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 14:54
