Agile на клиенте

[Владимир Максимов]

Вот в этой вакансии

Старший Разработчик Axapta (Москва)

Стоит требование

"Приверженность принципам Agile"

Чтобы не захламлять тему с вакансией, решил создать отдельную тему...

А разве на клиенте можно работать НЕ по Agile? По моему, на клиенте - это обычно дело и указывать это как отдельное требование - все-равно, что требовать умение работать в Word/Excel.

Да, конечно, там могут возникнуть "большие" модификации, которые требуют длительного предварительного планирования и согласования, но, обычно, работа как раз и заключается в том, чтобы "там подмазать, тут подклеить" Причем именно "со слов пользователя" без каких-либо письменных документов

Не понимаю. Обычное же дело.. Формализация начинается там, где разработчики начинают "зашиваться" и просто не успевают решать все "хотелки" пользователей. Ну, или у компании проблемы и она пытается их решить формализацией внутренних процессов

Хотя, да, умение сделать красивую обертку (красивое название) - повышает привлекательность Но, как говорил один литературный персонаж: "Оказывается, я всю жизнь говорил прозой" (с)

[cuba]

Не до конца согласен)
У меня проект внедрения на Клиенте выглядит след. образом: по Waterfall напланировали сроки\риски\ресурсы, а дальше все по SCRUM (backlog, sprint, storypoints, etc.) + Kanban.

[Zabr]

Цитата:

Сообщение от cuba

У меня проект внедрения на Клиенте выглядит след. образом: по Waterfall напланировали сроки\риски\ресурсы, а дальше все по SCRUM (backlog, sprint, storypoints, etc.) + Kanban.

Сколько у вас консультантов и сколько разработчиков?

[ax_mct]

Цитата:

По моему, на клиенте - это обычно дело и указывать это как отдельное требование - все-равно, что требовать умение работать в Word/Excel.

Указывать имеет смысл чтобы потом "правильный" программист не обвинял в том что они дикари, на коленке, и вообще не знают методологий. Добрая половина программистов здесь приходит в ужас от того что может не быть подробного задания. А на подавляющем большинстве клиентов (в моем понимании) - вот тебе "тикеты" (которые по сути пожелания из переписки) и скажи пожалуйста когда ты это это сделаешь.
То есть это часто даже не Agile, а полное делегирование мини-проектов. Далеко не всякий программист для этого подходит.

[Stitch_MS]

Цитата:

Сообщение от ax_mct

...вот тебе "тикеты" (которые по сути пожелания из переписки) и скажи пожалуйста когда ты это это сделаешь...

...а потом мы это внесем в Гантт-чарт, где любая задержка будет ставить под угрозу весь запуск, и удачи в попытках пристыковаться к стандарту через расширения. А если из тикета не очень понятно, что конкретно нужно разработать, то милости просим задавать вопросы, но на первоначальную оценку трудозатрат это влиять не должно. Аминь.

[ax_mct]

Цитата:

Сообщение от Stitch_MS

...а потом мы это внесем в Гантт-чарт, где любая задержка будет ставить под угрозу весь запуск, и удачи в попытках пристыковаться к стандарту через расширения. А если из тикета не очень понятно, что конкретно нужно разработать, то милости просим задавать вопросы, но на первоначальную оценку трудозатрат это влиять не должно. Аминь.

Данная вакансия что послужило темой, да и большинство вакансий на клиентах, они после основного запуска. Как я это понимаю, так как программировать клиенту пока партнер не запустил - не разумно.
А вот после запуска партнер уже как бы лишний, нужен мини-партнер в лице программиста под рукой.

И тут уже от программиста зависит все. Умеет он работать в таком стиле или нет. Тикет как задача высокого уровня есть, оценка трудозатрат при этом требуется иначе нет зеленого света. При том что приходящие детали и нюансы могут увеличить трудозатраты в разы.

У меня сейчас ровно такая же ситуация но я к такому уже давно привык. Поэтому вопрос про
"Приверженность принципам Agile" крайне уместен. Действительно понимая что такое Agile и объясняя это другим, все не так и страшно. Оценка шага, управление ожиданиями, прототип, воркшоп. Не в коем случае не фиксированная оценка всего в целом. Любого "эффективного" "PM" можно "победить" именно пониманием принципов.

[trud]

Цитата:

Сообщение от Владимир Максимов

Да, конечно, там могут возникнуть "большие" модификации, которые требуют длительного предварительного планирования и согласования, но, обычно, работа как раз и заключается в том, чтобы "там подмазать, тут подклеить" Причем именно "со слов пользователя" без каких-либо письменных документов

На клиенте не работал, но по моему опыту именно с этого могут начаться проблемы в системе. Хотя конечно зависит от объема таких "доработок"
Ну т.е. даже при продаже машины считается достоинством указывать - "полная сервисная история", а тут целая IT система
У Егора есть хорошее видео по этой теме
https://www.youtube.com/watch?v=OOAMNOso46g

[Владимир Максимов]

Не, народ, вы путаете внедрение и работу на клиенте уже после внедрения

Agile - это, по сути, модификация "на лету". Возникло новое требование - тут же его реализовали в меру своего понимания общей концепции системы. А на клиенте чем разработчик занимается? Да тем же самым! Реализует новые требования, встраиваясь в существующую реализацию Axapta.

Ну, и чем это от Agile отличается? Только тем, что так этот процесс никто не называет...

Есть или нет формализация процесса (ТЗ, выделанные этапы, трудозатраты и т.п.) - это уже частности. Суть-то от этого не меняется. А суть - это как раз модификация "по требованию".

[ax_mct]

Цитата:

Сообщение от Владимир Максимов

Не, народ, вы путаете внедрение и работу на клиенте уже после внедрения

Agile - это, по сути, модификация "на лету". Возникло новое требование - тут же его реализовали в меру своего понимания общей концепции системы. А на клиенте чем разработчик занимается? Да тем же самым! Реализует новые требования, встраиваясь в существующую реализацию Axapta.

Ну, и чем это от Agile отличается? Только тем, что так этот процесс никто не называет...

Есть или нет формализация процесса (ТЗ, выделанные этапы, трудозатраты и т.п.) - это уже частности. Суть-то от этого не меняется. А суть - это как раз модификация "по требованию".

Для меня Agile это работа при отсутствии фиксированных требований. Когда полной картины нет и ее надо делать по шагам, постепенным приближением.

Ad-hoc работа это "на лету".
"по требованию" - это ЗнР, Change Request, FDD etc то есть требование документально как-то описано. Часто не Agile.

То что Agile на клиенте это скорее к активной позиции программиста, а не к документированию.
Документирование и порядок в приложении это сторона не сильно зависит от стиля работы.

А вот ожидание что программист будет вести себя как активный архитектор общаясь, показывая и предлагая - вот это скорее всего тот самый Agile для клиента. Намек - прототип- демонстрация - уточнение - рабочая версия.

То есть это далеко не хотелки на лету без следов. Все же всегда есть backlog/tracker система работающая как минимум на уровне тикетов со всеми статусами и референсами. И при этом может быть и "Waterfall" и "Agile" в разных тикетах/work items. В одной задаче тебе все подумали за тебя, а в другой тебе надо думать за всех. И если честно то чаще всего лучше когда за тебя не думают, потому как тебе куда виднее.

[cuba]

Если брать команду (PM, BA, Dev, Cons, BI и т.д.), то человек 40 только по Dynamics, не считая другого ПО.
Консов человек 10, разрабов около 20, остальные - PM\BA\BI и т.д.

[Zabr]

Цитата:

Сообщение от cuba

Если брать команду (PM, BA, Dev, Cons, BI и т.д.), то человек 40 только по Dynamics, не считая другого ПО.
Консов человек 10, разрабов около 20, остальные - PM\BA\BI и т.д.

В этом обсуждении речь о команде ИТ, работающей на проекте со стороны клиента. Эти 40 человек - это всё сотрудники клиента, работающие на проекте внедрения у себя системы Dynamics? или это внешняя команда? или и те и другие вместе?

[George Nordic]

Я видел и понимаю, как Agile работает на клиенте. Да, есть проблемы с документацией, если принудительно не включать пост-описание модификаций в рамки проекта.

Я не понимаю, как Agile может работать на связке клиент <> партнер, если проект не T&M.

С Уважением,
Георгий

[aws]

Цитата:

Сообщение от George Nordic

Я видел и понимаю, как Agile работает на клиенте. Да, есть проблемы с документацией, если принудительно не включать пост-описание модификаций в рамки проекта.

Я не понимаю, как Agile может работать на связке клиент <> партнер, если проект не T&M.

С Уважением,
Георгий

Согласен...

[Sancho]

Цитата:

Сообщение от George Nordic

Я видел и понимаю, как Agile работает на клиенте. Да, есть проблемы с документацией, если принудительно не включать пост-описание модификаций в рамки проекта.

Я не понимаю, как Agile может работать на связке клиент <> партнер, если проект не T&M.

С Уважением,
Георгий

доверие тут ключевой термин.
если заказчик доволен партнером, если задачи в разумные сроки закрываются и это стоит разумных, заранее оговоренных денег, то можно работать с заказчиком по тайм-шитам в режиме Agile.
именно с пост-описанием.
что куда эффективнее формализации.
как только начались проблемы - пропало доверие - только формализация.

[aws]

Ключевой момент в работе по Agile это наличие Product Owner у клиента или партнера. Если его нет, то это обычная работа по трекингу задач. Просто обсуждения происходят чаще.

[ax_mct]

Цитата:

Сообщение от aws

Ключевой момент в работе по Agile это наличие Product Owner у клиента или партнера. Если его нет, то это обычная работа по трекингу задач. Просто обсуждения происходят чаще.

У меня сейчас трекинг задача создавать продукты и менять все Product атрибуты (включая все связанные с продуктом таблицы в WHS, AWS, TMS, Retail etc) из JSON файла. Обычная работа по списку задач как бы. В полном Agile и со стороны партнера.

При этом Product Owner нет ни на партнере ни на клиенте. Абсолютно соглашусь с тем что это вопрос доверия.

[cuba]

И те и другие)

[Zabr]

Цитата:

Сообщение от cuba

И те и другие)

Тогда Ваш ответ был не по теме.

[cuba]

Внешние появились позже, то есть, изначально была только внут. команда. Надо было в предыдущем ответе это написать)

[Zabr]

Цитата:

Сообщение от cuba

Внешние появились позже, то есть, изначально была только внут. команда. Надо было в предыдущем ответе это написать)

Ну ок. Сколько консультантов и сколько программистов было во внутренней команде до того, как появилась внешняя, и использовала ли эта внутренняя команда тот же порядок работы, про который Вы написали ? ("по Waterfall напланировали сроки\риски\ресурсы, а дальше все по SCRUM (backlog, sprint, storypoints, etc.) + Kanban. ")