Comments 16
На самом деле не многие задумываются над тем когда agile нужен команде, а когда нет.
Например у вас большой SAAS, который сам по себе много чего умеет и завязан на требования рынка и плюсом к нему поступает задача написать биллинг, но так, чтобы и другие «дружественные» проекты могли его использовать. При этом, допустим, в вашем SAAS проекте итерации одна неделя и agile там полезен.
В такой ситуации я бы сказал, что биллинг делать тоже по agile методологии не стоит, а надо сперва выделить людей из команды на биллинг или взять новых, собрать сведения, подумать, попытать менеджеров и дружественные проекты, подумать еще, составить список сущностей, диаграммы взаимодействий компонентов и сущностей, подумать над расширяемостью и т.д. Только после составить план и двигаться по нему по победного. Возможно только после написания основного куска, который замет у вас 1-3 месяца, уместно будет добавлять к биллингу рюшечки, работая по agile.
Конечно, можно экспериментировать с agile в биллинге с самого начала, но я думаю хорошего ничего не будет — либо итерации у вас будут большие, либо от итерации смысла не будет. В общем биллинг показывает проблему проектов, где польза для заказчика или пользователя наступает только после довольно большого куска проделанной работы. Ну и, конечно, если с разработкой биллинга поторопиться, то вероятно хорошего тоже ничего не будет — это же не личный блог.
Например у вас большой SAAS, который сам по себе много чего умеет и завязан на требования рынка и плюсом к нему поступает задача написать биллинг, но так, чтобы и другие «дружественные» проекты могли его использовать. При этом, допустим, в вашем SAAS проекте итерации одна неделя и agile там полезен.
В такой ситуации я бы сказал, что биллинг делать тоже по agile методологии не стоит, а надо сперва выделить людей из команды на биллинг или взять новых, собрать сведения, подумать, попытать менеджеров и дружественные проекты, подумать еще, составить список сущностей, диаграммы взаимодействий компонентов и сущностей, подумать над расширяемостью и т.д. Только после составить план и двигаться по нему по победного. Возможно только после написания основного куска, который замет у вас 1-3 месяца, уместно будет добавлять к биллингу рюшечки, работая по agile.
Конечно, можно экспериментировать с agile в биллинге с самого начала, но я думаю хорошего ничего не будет — либо итерации у вас будут большие, либо от итерации смысла не будет. В общем биллинг показывает проблему проектов, где польза для заказчика или пользователя наступает только после довольно большого куска проделанной работы. Ну и, конечно, если с разработкой биллинга поторопиться, то вероятно хорошего тоже ничего не будет — это же не личный блог.
Вообще говоря, создание рабочего кода не равно немедленное внедрение.
Мне приходилось работать по Agile (вполне по настоящему Agile, если по критериям статьи) на проекте, который до старта разрабатывался 16 месяцев. Опыт самый позитивный в конце каждой итерации была демонстрация заказчику.
И кстати, даже после того, как проект вышел в Production, завершение итерации не равно выдаче новой версии на боевые сервера. Итерации были двухнедельные, а версии планировались отдельно, около месяца.
Мне приходилось работать по Agile (вполне по настоящему Agile, если по критериям статьи) на проекте, который до старта разрабатывался 16 месяцев. Опыт самый позитивный в конце каждой итерации была демонстрация заказчику.
И кстати, даже после того, как проект вышел в Production, завершение итерации не равно выдаче новой версии на боевые сервера. Итерации были двухнедельные, а версии планировались отдельно, около месяца.
Тут не смогу поспорить можно это назвать agile или нет.
Я правильно понял, что бизнес по сути не получал профита от разработки все эти 16 месяцев и смог зарабатывать деньги только в конце срока? По мне agile с точки зрения деплоя — это именно методология, которая позволяет получить профит для бизнеса в денежном эквиваленте после каждой итерации.
Можно у вас спросить почему для вашей команды не подошла водопадная модель?
Я правильно понял, что бизнес по сути не получал профита от разработки все эти 16 месяцев и смог зарабатывать деньги только в конце срока? По мне agile с точки зрения деплоя — это именно методология, которая позволяет получить профит для бизнеса в денежном эквиваленте после каждой итерации.
Можно у вас спросить почему для вашей команды не подошла водопадная модель?
Основной смысл гибких методологий не в профите для бизнеса после каждой итерации, а в совмещении проектирования и производства (разработки). Есть потребность в совмещении — есть agile. Нет такой потребности или наоборот, есть потребность сначала все хорошенько запроектировать — будет классика.
Профит для бизнеса- побочный эффект, который может быть, а может и не быть. Более того, Agile методологии без деплоя на клиентов тоже вполне работают, т.к. это способ проектирования и производства, а не способ доставки продукта.
Профит для бизнеса- побочный эффект, который может быть, а может и не быть. Более того, Agile методологии без деплоя на клиентов тоже вполне работают, т.к. это способ проектирования и производства, а не способ доставки продукта.
Да, правильно. Только после 16 месяцеа
Agile стремится к наиболее быстрой поставки ПО, но это не всегда возможно мгновенно. Поставку нужно делать в тот момент, когда польза от использования продукта будет больше, чем накладные расходы на это. В нашем случае, у заказчика уже была сложная IT-инфраструктура и бизнес-процессы с ее использование. Ранняя поставка, особенно после каждой итерации, потребовала бы менять их каждые две недели.
Что касается водопадной модели, я, честно говоря, не представляю, как бы мы сумели использовать ее и уложится в те же сроки/ресурсы/качество.
Если бы мы заранее делали полное исследование всех реализованных БП, это заняло бы несколько месяцев, и к тому моменту, когда начали бы программировать, то многие мелкие детали уже бы забылись. Я
Если бы мы проектировали всю систему до начала программирования… Оглядываясь назад, вспоминая всю ее эволюцию — не спроектировали бы. Мы очень многому научились в процессе. Самая общая архитектура систмемы была определена заранее (трехзвенка, собственный тонкий клиент, учетный контур в БД и т.п.), но детально понятно как сделать конкретные вещи хорошо стало только после экспериментов и ошибок.
Про тестирование — опять же, я не представляю, как тестировать системы такого объема одним куском. А так после каждой итерации у нас был продемонстрированный заказчику, протестированный вручную и, самое главное, покрытй автотестами код.
И я не говорю про неизбежные ошибки на каждом этапе. Благодаря демонстрациям, постоянной связи с заказчиком, мы могли их устранять на достаточно ранних этапах, когда их следствия еще не распространились по всей системе.
Agile стремится к наиболее быстрой поставки ПО, но это не всегда возможно мгновенно. Поставку нужно делать в тот момент, когда польза от использования продукта будет больше, чем накладные расходы на это. В нашем случае, у заказчика уже была сложная IT-инфраструктура и бизнес-процессы с ее использование. Ранняя поставка, особенно после каждой итерации, потребовала бы менять их каждые две недели.
Что касается водопадной модели, я, честно говоря, не представляю, как бы мы сумели использовать ее и уложится в те же сроки/ресурсы/качество.
Если бы мы заранее делали полное исследование всех реализованных БП, это заняло бы несколько месяцев, и к тому моменту, когда начали бы программировать, то многие мелкие детали уже бы забылись. Я
Если бы мы проектировали всю систему до начала программирования… Оглядываясь назад, вспоминая всю ее эволюцию — не спроектировали бы. Мы очень многому научились в процессе. Самая общая архитектура систмемы была определена заранее (трехзвенка, собственный тонкий клиент, учетный контур в БД и т.п.), но детально понятно как сделать конкретные вещи хорошо стало только после экспериментов и ошибок.
Про тестирование — опять же, я не представляю, как тестировать системы такого объема одним куском. А так после каждой итерации у нас был продемонстрированный заказчику, протестированный вручную и, самое главное, покрытй автотестами код.
И я не говорю про неизбежные ошибки на каждом этапе. Благодаря демонстрациям, постоянной связи с заказчиком, мы могли их устранять на достаточно ранних этапах, когда их следствия еще не распространились по всей системе.
Отделите, пожалуйста, disclaimer визуально. Изменение рода, от которого ведется повествование сбивает.
И спасибо за неплохой перевод.
И спасибо за неплохой перевод.
Мне кажется аджайл будет уместен там, где в команде преемущественно выскококвалифицированные специалисты, которые могут грамотно расчитывать сроки, тем самым сообщая клиенту, более реалистичный план по проекту. То есть группа людей, которые действительно способны расчитать время и работать с относительно постоянной производительностью. Помимо этого, конечно неплохо было бы иметь небольшую избыточность ресурсов в команде для того чтобы снизить риск человесеского фактора.
И опять же: рефакторинг. Мы сталкиваемся постоянно с тем, что без практически ежедневного системного рефакторинга тот «долг», о котором идет речь в статье, стреляет достаточно быстро и часто очень больно.
И опять же: рефакторинг. Мы сталкиваемся постоянно с тем, что без практически ежедневного системного рефакторинга тот «долг», о котором идет речь в статье, стреляет достаточно быстро и часто очень больно.
Agile не дает фиксированных сроков разработки. Заранее сказать заказчику сколько займет разработка «полного» проекта и гарантированно уложиться в этот срок там нельзя. Там либо фиксируют срок разработки (сделаем максимум возможного за N месяцев), либо объем работ (сделаем эти N задач, но гарантировать время не можем).
Скорость разработки в agile — это не скорость с которой проект движется по плану, а скорость с которой выполняется реальная задача. Если план хорошо соответствует реально проделываемой работе (чего достичь часто сложно) то это будет одна и та же сущность, если нет — то увы движение по плану будет неравномерным и как правило с отставанием.
Одна из ключевых идей Agile — в том что надо стремиться не к тому чтобы за месяц был выполнен план, а к тому чтобы за месяц было сделано максимум полезного при заданных ресурсах и нормальном режиме работы. Попытка загнать всех «в план» как раз приводит к описанному выше антипаттерну — проект отстает от плана, людей начинают подгонять чтобы этот план реализовать, реальная скорость работы над проектом временно растет а затем надолго падает.
Так что тут не специалисты нужны в команде, а адекватный менеджмент, который понимает что невозможно достичь одновременно качества продекта, фиксированного срока разработки и фиксированного функционала, добавление людей в команду не обязательно повышает скорость разработки и т.д. и способен эти идеи так или иначе донести до заказчика.
Скорость разработки в agile — это не скорость с которой проект движется по плану, а скорость с которой выполняется реальная задача. Если план хорошо соответствует реально проделываемой работе (чего достичь часто сложно) то это будет одна и та же сущность, если нет — то увы движение по плану будет неравномерным и как правило с отставанием.
Одна из ключевых идей Agile — в том что надо стремиться не к тому чтобы за месяц был выполнен план, а к тому чтобы за месяц было сделано максимум полезного при заданных ресурсах и нормальном режиме работы. Попытка загнать всех «в план» как раз приводит к описанному выше антипаттерну — проект отстает от плана, людей начинают подгонять чтобы этот план реализовать, реальная скорость работы над проектом временно растет а затем надолго падает.
Так что тут не специалисты нужны в команде, а адекватный менеджмент, который понимает что невозможно достичь одновременно качества продекта, фиксированного срока разработки и фиксированного функционала, добавление людей в команду не обязательно повышает скорость разработки и т.д. и способен эти идеи так или иначе донести до заказчика.
Дайте пожалуйста ссылку на оригинал, хочу коллегам показать.
Мне кажется выдавать бесконечный код невозможно, по той простой причине что количество связей растет увеличивая сложность, причем нелинейно.
Бесконечно можно выдавать если только добавлять столько сколько выкинул.
Бесконечно можно выдавать если только добавлять столько сколько выкинул.
Конечно, ничего не живет бесконечно. Так что буквально понимать не следует в любом случае.
А если говорить «на протяжении достаточно долгого времени», то помогает
1) Выкидывать ненужный код (как Вы верно заметили)
2) Реструктурировать старый (рефакторинг). Часто к моменту реструктурирования есть новый уровень понимания, который позволит упростить систему в целом, инкапсулируя сложность внутри частей.
Оговорюсь, что мой опыт ограничивается системам сроком жизни до 10 лет, и написанным не так давно (т.е уже после 2000 года).
А если говорить «на протяжении достаточно долгого времени», то помогает
1) Выкидывать ненужный код (как Вы верно заметили)
2) Реструктурировать старый (рефакторинг). Часто к моменту реструктурирования есть новый уровень понимания, который позволит упростить систему в целом, инкапсулируя сложность внутри частей.
Оговорюсь, что мой опыт ограничивается системам сроком жизни до 10 лет, и написанным не так давно (т.е уже после 2000 года).
Эта бесконечность не строгая математическая. Имеется в виду, что команда «вышла на режим» и будет так работать, пока условия не изменятся, проект не закончится или ещё что серьезное не случится.
Sign up to leave a comment.
Нелицеприятный тест вашего Agile