Комментарии 6
Как мы это решаем?.. гм. А никак не решаем.
Буквально — не прменяем agile в том виде и формах, как это предлагается «идеологами легковесных технологий».
Как работаем?«Вспоминаем классиков» Пытаемся применять принципы масштабирования процесса разработки, заложенные в RUP, причем как это было описано в версиях от Rational (пока методологию еще не испортил IBM своими нововведениями и «принципами бизнес-ориентированной разработки» ).
т.е. вместо того, что бы пытаться адаптировать agile к процессам, которые выходят за границы его применимости, мы сразу берем немного другие принципы/артефакты и «утяжеляем» процесс разработки в зависимости от масштаба / сложности / особенностей проекта. И того, как он развивается.
В начале набор фич, названий usecase, архитектурный прототип (который исполняемая архитектура).
По мере развития проекта и его усложнения или измения границ — утяжеляем / расширяем те или иные стадии или процессы, детализируем артефакты, усложняем процесс работы с ними.
Тут главное не слепо копировать техники «описанные в трудах классиков», а понимать какой артефакт, какой процесс в какой из своих форм тебе сейчас нужен и _достаточен_. Те же usecase могут оставаться в форме кратких описаний до конца проекта, если проект не большой и с заказчиком доверенные отношения. Где то хорошо заходят сквозные сценарии, а где то надо хорошо проработать модель данных и вывернуть процесс разработки от моделирования. 6де то надо у заказчика сидеть, а где то надо строго отрабатывать по этапам.
А за ваш опыт — спасибо. Почитаем про описанные вами техники подробнее, глядишь, где и приложится.
Буквально — не прменяем agile в том виде и формах, как это предлагается «идеологами легковесных технологий».
Как работаем?
т.е. вместо того, что бы пытаться адаптировать agile к процессам, которые выходят за границы его применимости, мы сразу берем немного другие принципы/артефакты и «утяжеляем» процесс разработки в зависимости от масштаба / сложности / особенностей проекта. И того, как он развивается.
В начале набор фич, названий usecase, архитектурный прототип (который исполняемая архитектура).
По мере развития проекта и его усложнения или измения границ — утяжеляем / расширяем те или иные стадии или процессы, детализируем артефакты, усложняем процесс работы с ними.
Тут главное не слепо копировать техники «описанные в трудах классиков», а понимать какой артефакт, какой процесс в какой из своих форм тебе сейчас нужен и _достаточен_. Те же usecase могут оставаться в форме кратких описаний до конца проекта, если проект не большой и с заказчиком доверенные отношения. Где то хорошо заходят сквозные сценарии, а где то надо хорошо проработать модель данных и вывернуть процесс разработки от моделирования. 6де то надо у заказчика сидеть, а где то надо строго отрабатывать по этапам.
А за ваш опыт — спасибо. Почитаем про описанные вами техники подробнее, глядишь, где и приложится.
Сейчас вам расскажут, что вот это-то и есть — настоящий аджайл! :)
да уж )))
и спорить с ними будетбесполезно трудно.
каким должен быть правильный эджайл — нигде толком конкретно, по полочкам, системно не написано. до уровня методики или методологии, сравнимой по степени проработанности с RUP, эти процессы так никем и не проработаны. (ошибаюсь? ткните меня, пожалуйста, в «самое эталонное описание»… ).
у меня такое впечатление, что сегодня «эджайл» — это уже бренд, марка, лейбл, которым клеймят всёчто-ни-попадя, что по мнению авторов должно быть «модно молодежным итеративным». Каждый дудит в свою дуду, у каждого есть своя правда и свой набор успешных проектов…
Каждый _Мастер_ говорит, что «его кунг-фу лучше других кунг-фу»)))
«Мода вокруг эджайл» дошла до того, что в проектном менеджменте уже тоже «используют эджайл»…
вот лет 30 как не эджайл, оказывается; Тернер планирование по вехам не описывал, и итеративную поэтапную работу никто не использовал, о планировании «набегающей волной» тоже никто не слышал («действительно… ведь в PMBoK же нет»… или есть? поправьте если упустил что… вот у Тернера и в НТК от Совнет / IPMA это точно есть ),
И тут бац —
откровение: ЭДЖАЙЛ в проектном менеджменте… ээх.
Конечно, понятно, там совсем-совсем не тот «эджайл» что в статье у автора, и некоторые идеи предлагаемые под этим лейблом там тоже есть — и новые, и жизнеспособные… Но степень «истерии вокруг» и «оторванности вообще» сегодняшнего термина «эджайл» от внятного понимания «что же это такое» — это, имхо, иллюстрирует как нельзя лучше.
PS: и это мы еще про «прогрессивный» «девопс» не говорили )))
и спорить с ними будет
каким должен быть правильный эджайл — нигде толком конкретно, по полочкам, системно не написано. до уровня методики или методологии, сравнимой по степени проработанности с RUP, эти процессы так никем и не проработаны. (ошибаюсь? ткните меня, пожалуйста, в «самое эталонное описание»… ).
у меня такое впечатление, что сегодня «эджайл» — это уже бренд, марка, лейбл, которым клеймят всё
Каждый _Мастер_ говорит, что «его кунг-фу лучше других кунг-фу»)))
«Мода вокруг эджайл» дошла до того, что в проектном менеджменте уже тоже «используют эджайл»…
вот лет 30 как не эджайл, оказывается; Тернер планирование по вехам не описывал, и итеративную поэтапную работу никто не использовал, о планировании «набегающей волной» тоже никто не слышал («действительно… ведь в PMBoK же нет»… или есть? поправьте если упустил что… вот у Тернера и в НТК от Совнет / IPMA это точно есть ),
И тут бац —
откровение: ЭДЖАЙЛ в проектном менеджменте… ээх.
Конечно, понятно, там совсем-совсем не тот «эджайл» что в статье у автора, и некоторые идеи предлагаемые под этим лейблом там тоже есть — и новые, и жизнеспособные… Но степень «истерии вокруг» и «оторванности вообще» сегодняшнего термина «эджайл» от внятного понимания «что же это такое» — это, имхо, иллюстрирует как нельзя лучше.
PS: и это мы еще про «прогрессивный» «девопс» не говорили )))
Разработчики перестраиваются на рельсы agile, и мы здесь не исключение.
Вот прям разработчики? Разработчики-разработчики? :)
Сегодня мы наблюдаем, как во всем мире постепенно отмирает waterfall-модель разработкиВ сбербанке шел 95 год…
Для справки. MSF 94 год, RUP 2003. Waterfall была первая попытка формализовать процесс разработки, стандартом разработки он никогда не был.
Методология agileэто не методология. Agile вообще ничего не привнес, просто написали слово agile, а под ним здравый смысл, который на порядок, чем сам agile. Искренне не понимаю чего все носятся с ним как с писаной торбой.
Все решают проблему по-разному, но обычно все сводится к автоматизации тестирования. далее по текстуВы это сами выдумали или откуда-то взяли, кто эти все? Очень слабое обоснование.
Quality Gatesэто называется ОТК, вообще знание управления производством может много подсказать при разработке взаимосвязанных систем большой группой людей.
Например, избежали значительного дублирования, которое увеличивает сложность кода и вероятность проблем.Может научиться нанимать «правильных пчел», чем постоянно бороться с «непраивльным медом»?
Мы стремимся к тому, чтобы quality gates стали полноценным фреймворком для управления качеством разработки большого количества продуктов в agile.почти бинго))
В будущем мы планируем выкатывать новые наборы обязательных quality gates.Что за вредителей вы нанимаете, которые постоянно все ломают?
Попытка сбера
Итого
Нет никакого обоснования проблемы, техники сбора данных, группировок проблем, подходов и эволюции их решений, аналитики.
Непонятно, неужели люди пишущие критическую систему не способны сами определить критерии качества, чтобы не наносить ущерб другим? Почему менджмент не пытается устранить источник проблемы и на разработку критичных систем ставить адекватных людей с адекватной компенсацией, в том числе и на менеджерские позиции.
И почему Quality Gates нужным всем, что у всех все плохо? Почему не используете принцип: работает — не трогай?
Только сейчас увидил. Вот это да. Мне было бы стыдно некоторые вещи писать и афишировать.
Вишенки на торте вроде "методология agile" или "а у нас waterfall" (в 2018 году).
Ну помимо всего прекрасного (описания своего rup, в котором вообще непонятно, сколько циклов будет для выдачи фичи), в статье прямо запало в душу, что smoke-тесты это панацея, которой по-видимому не было раньше, ведь, как написано, что "Теперь, когда ты ставишь сборку на полигон, то сам тестируешь ее на самые распространенные проблемы". Я смеялся. Похоже кто-тестировал другой за тебя, отдал неработающую хрень и забыл, пока время продакшена не наступит. В принципе в духе Сбера, который до сих пор хочет быть Вовкой в тридевятом царстве, за которого все всё делают. И есть за вас тоже будут :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кто ответит в agile за качество разработки сложных проектов, или методология Quality Gates