Программисты философствуют

[mmoustaf 101]

так аджайл или скрам???

Аджайл это подход к разработке ПО. Скрам - это одна из "методик реализации аджайла", наиболее распространенная. Но есть и другие.

[Justas 9]

а вот если "нужно на вчера и похер как, лишь бы этот говнокод работал" и "что? ТЗ?? не, не слышал! а что это?" - это какая методология?

[mmoustaf 101]

а вот если "нужно на вчера и похер как, лишь бы этот говнокод работал" и "что? ТЗ?? не, не слышал! а что это?" - это какая методология?

Это методолия потерянных высокомолекулярных соединений.

и "что? ТЗ?? не, не слышал!

Кстати по поводу тз. Его в аджайле как бы и нет.

[abel_91 7]

...и понеслись.

Ага, заказчик получает сырой, плоходокументорованный продукт, кое как проверенный тестировщиками после очередной итерации.

[SlavikMIPT 73]

abel_91, полуработающий продукт лучше чем неработающий

[maksims 1]

Можно.

Конечно.

Мы разобъем эпик квейк на фичи и таски, и ты как заказчик отранжируешь их в порядке приоритета.

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

мы будем делать то, что ты скажешь и то с чем ты согласишься.

Я же говорю - в аджайле фиксируется бюджет. срок и производительность.

Объем не фиксируется. Он гибкий. делается то. что заказчик сам пожелает видеть наиболее важным для него.

Ты не поимаешь.

ПМа -нет

Тоесть, заказчик не получит ни квейка ни тетриса? Зато получит необходимость собственной экспертизы сроков, технологий и прочего? Да еще и самому проектом управлять...

Я б не стал заказывать у вас ничего.

[abel_91 7]

abel_91, полуработающий продукт лучше чем неработающий

Лучше вообще без такого продукта.

Авария на Саяно-Шушенской ГЭС

[abel_91 7]

При чем тут документированность? Документацию пишут специально обеченные люди. По условиям задачи нужно уже вчера, а лучше позавчера. При таких исходных условиях не до докуменатции. Почему продукт будет сырой, тоже не понял. В Скрам команду входят не только девелоперы, а все кто имеет отношение к проекту: девелоперы, тестировщики, архитектор, документаторы и т.д.

Ты заголовок темы внимательно читал? Тут вообще-то только про программирование.

Заголовок прочитал внимательно. Там, то же.

Продукт будет сырой по ряду причин. Основными из которых являются. Заказчик/постановщик задачи "хочет фичу" девелопер ее реализует зачастую не анализирую причнно-следственных связей. По принципу:-"Ну не нравится синенькое, замажем красненьким". А "сборка" продукта после скрама, зачастую напоминает фотографию чела, слепленную вручную из фрагментов снятых под электронным мелкоскопом.

Как у Райкина:

[abel_91 7]

Мы о обычной разработке или о разработке по условиям отсюда? http://www.skycentre.net/index.php?showtop...st&p=315426 Если кто-то при скоростной разработке, когда заказ сформулирован как "дайте хоть что-нибудь, лишь бы работало, нужно уже вчера", рассчитывает получить тоже самое, что и при нормальном заказе, пусть нанимает девелоперов уровня Александреску и Руссиновича. За соответствующие деньги. Они ему напишут. Наверное.

Мы об аджайпе как о "гибкой" методологии разработки софта или как о "пожарной команде"?

Сборка продукта и предоставление его заказчику идет не реже чем каждые 2 недели (часто каждую неделю), поэтому заказчи всегда сможет скорректировать не понравившиеся ему места задолго до релиза. Именно поэтому данная методика гораздо лучше обычной, когда ПМ пытает заказчика, потом удаляется на Х месяцев к себе, а после релиза выясняестя, что ПМ накосячил, или заказчик не так думал и т.д.

Тебе дать ссылку на твою ссылку?

[abel_91 7]

Вот я как раз тебя об этом и спрашиваю. Нормальная разработак - это одно, скоростная - совсем другое. И качество на выходе, разумется, будет разным. Почему на выходе нормальной разработки по Аджайлу получается сырой продукт, мне лично непонятно. Т.е. может по каким-то там теоретическим соображениям, он таким будет, но на практике он таким не получается, т.к. заказчик видит его как минимум каждые 2 недели.

Почему, да просто. Берем к примеру ИУС пользователей на 500, хотя бы, по 2-3 десяткам специализаций системы. Как ты себе представляешь "посмотреть релиз через неделю"?

[roma 59]

abel_91,

Почему, да просто. Берем к примеру ИУС пользователей на 500, хотя бы, по 2-3 десяткам специализаций системы. Как ты себе представляешь "посмотреть релиз через неделю"?

через неделю это будет релиз на 10 пользователей и по 5 специализациям :-)

[maksims 1]

Заказчик получит продукт с теми фичами, которые он захотел там увидеть, пока есть бюджет на разработку.

Я хочу тетрис. Или квейк. Я сам не знаю. Но платить буду только за готовый продукт, полностью удовлетворяющий потребностям бизнеса. Не можете ? Нужно помогать/выбирать/управлять вами? Нафиг не нужно.

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

Ужас ужасный. Хотя, теперь я понимаю, как рождаются системы с одной рукой, тремя глазами и без ног.

[mmoustaf 101]

Я хочу тетрис. Или квейк. Я сам не знаю. Но платить буду только за готовый продукт, полностью удовлетворяющий потребностям бизнеса. Не можете ? Нужно помогать/выбирать/управлять вами? Нафиг не нужно.

Какие есть способы у разработчиков выяснить конкретно детально, что именно ты хочешь?

[abel_91 7]

Какие есть способы у разработчиков выяснить конкретно детально, что именно ты хочешь?

У разработчика, как минимум, есть законодательная и нормативная база, техническая документация (если система завязана на привода и датчики), описание/нормативка технологического процесса/документооборота. Есть наконец предпроектное обследование. Если это разработчик, а не ваятель всего и вся кое как по капельке десятилетиями.

[mmoustaf 101]

У разработчика, как минимум, есть законодательная и нормативная база, техническая документация (если система завязана на привода и датчики), описание/нормативка технологического процесса/документооборота. Есть наконец предпроектное обследование. Если это разработчик, а не ваятель всего и вся кое как по капельке десятилетиями.

К тебе пришел Максим. лично к тебе с новой задачей.

Пришел и говорит "Я хочу то ли тетрис то ли квейк"

Какие у тебя есть способы попытаться выяснить что он хочет?

[mmoustaf 101]

Я правильно понимаю, что ты даже примерно не знаешь, что ты хочешь для бизнеса? Что максимум, чего тебе хочется, это сделайте мне то, не знаю что?

Это нормально. У нас именно так. Заказчик хочет то ли ордер менеджмент то ли алготрейдинг. Он не знает как это называется. говорит, я хочу чтобы клиенты торговали определенными бумажками по хорошей цене. Или я хочу интересную игру. Какие есть способы у разработчика выяснить детальнее, что хочет заказчик?

[abel_91 7]

К тебе пришел Максим. лично к тебе с новой задачей.

Пришел и говорит "Я хочу то ли тетрис то ли квейк"

Какие у тебя есть способы попытаться выяснить что он хочет?

Максим пришел к тебе Аджайп, батенька

Мне он напишет ТЗ, после которого будет проведено предпроектное обследование и выдано на гора проектное решение детализация которого останется за Максимом. И если решение его устроит, будет лабаться код.

В примитивном понимании - аджайп, лобание кода сходу, пока у клиента бабки не кончатся. А кончатся они довольно быстро и пойдет он за готовым, годами проверенным, софтом без фич в жырном GUI.

[mmoustaf 101]

Мне он напишет ТЗ, после которого будет проведено предпроектное обследование и выдано на гора проектное решение детализация которого останется за Максимом. И если решение его устроит, будет лабаться код.

Он не знает чего он хочет.

Как он напишет ТЗ?

Ну хорошо, написал.

Если тебе не все понятно - какие есть способы у тебя узнать то, что тебе непонятно.

Максим пришел к тебе Аджайп, батенька

Ко мне они уже 5 лет как ходят.

В примитивном понимании - аджайп, лобание кода сходу, пока у клиента бабки не кончатся. А кончатся они довольно быстро и пойдет он за готовым, годами проверенным, софтом без фич в жырном GUI.

Это миф. Лабания кода с ходу нету. И "пока бабки не кончатся" - это тоже миф.

софтом без фич в жырном GUI.

За командной строкой что ли?

Фича - это не свистоперделка в гуе.

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

[abel_91 7]

Он не знает чего он хочет.

Как он напишет ТЗ?

Либо Квейк либо тетрис

А ты его в течении 5 лет, если бабло не кончится, сподвигнешь на квейкотетрис ну или наоборот и слобаешь?

[mmoustaf 101]

Либо Квейк либо тетрис

Предположим на самом деле ни то ни другое или все вместе. Мы не знаем.

В ТЗ написано "Я хочу либо квейк, либо тетрис"

Как можно узнать детально что именно хочет Максим?

[mmoustaf 101]

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

ИМЕННО!

Игорь, но пусть ребята ответят на вопрос сами. Не включай режим учителя.

То есть надо выяснить у заказчика?

Максим - заказчик. Он не готов помогать и выбирать. Значит ли это что он ничего не ответит на уточняющие вопросы разработчика.

Максим?

[maksims 1]

Какие есть способы у разработчиков выяснить конкретно детально, что именно ты хочешь?

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

Хотя, что я занудствую?

Очевидно, что ответ - работа бизнес и технических аналитиков. И как результат, согласованные функциональные требования и техническое задание. В ТЗ как раз прописано, какую систему делаем (тетрис или квейк) объем работ, условия приемки, и техническое решение (я вссегда настаиваю, чтобы Техничекое решение делалось внутри ТЗ, но это может быть и отдельный документ)

Вообще, судя по тому, что я читаю, стадия анализа и согласования BRD у вас вообще отсутствует.

[mmoustaf 101]

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

Я тебе расскажу но задавая вопросы.

Очевидно, что ответ - работа бизнес и технических аналитиков. И как результат, согласованные функциональные требования и техническое задание. В ТЗ как раз прописано, какую систему делаем (тетрис или квейк) объем работ, условия приемки, и техническое решение (я вссегда настаиваю, чтобы Техничекое решение делалось внутри ТЗ, но это может быть и отдельный документ)

А если у тебя вопросы после появились?

Или заказчик решив тетрис, вдруг сказал - я хочу лайнз?

Вообще, судя по тому, что я читаю, стадия анализа и согласования BRD у вас вообще отсутствует.

Это ты себе придумал.

У нас есть стадия согласования. В ней участвует вся команда и формирует бэклог.

Бэклог гибкий, он не установлен раз и навсегда. И заказчик в ходе разработки может его менять.

[mmoustaf 101]

Коллеги, вы не понимаете одну простую вещь.

Когда заказчик четко знает что именно он хочет, как именно, зачем, почему, и ТОЧНО ЗНАЕТ, ЧТО ОН НИЧЕГО НЕ БУДЕТ МЕНЯТЬ, это одно.

То есть все правильные ответы известны заранее.

Там применим т.н. вотерфолл. Вы фиксируете объем, цену, сроки.

Правда как только выясняется, что заказчик хочет то, что в ТЗ не зафиксированно , то начинаются напряги.

Либо мы расширяем бюджет, либо сдвигаем сроки.

Т.е. все изменения проходят за деньги заказчика.

Заказчик не контролирует свое удовлетворение в процессе разработки.

Вы делаете, тестируете отдаете на UAT.

На UAT выясняется что заказчик либо доволен всем, либо нет.

Если доволен - хорошо

Если не доволен - плохо, мы либо доделываем. либо еще того хуже - переделываем.

Но ПОСЛЕ СДАЧИ И ЗА ДЕНЬГИ ЗАКАЗЧИКА.

Ну или нудные судебные издержки и штрафы нам.

Аджайл применим там, где заказчик не может определиться, или точно в полной мере на все 100% не знает что именно ему нужно.

Ему нужна, например, трейдинговая система. Чо за система, как, хочет ли он фьючерсами торговать или пока не знает. Сказать не может.

При таких установках нет правильных ответов.

Мы фиксируем цену и сроки.

Объем не фиксирован.

Это не значит что его нет.

Мы также выясняем у заказчика что ему нужно, и говорим, что это будет готово тогда-то и за такие-то деньги (исходя из нашей производительности)

Однако мы даем возможность заказчику вносить изменения в проект по спринтам (от одного до 4-х недель - длина спринта)

Но взамен

Заказчик контролирует свое удовлетворение постоянно.

Мы даем заказчику возможность понять, что именно для него важно по мере разработки, а не потом.

И главное изменения бесплатны.

Если в процессе разработки поменялся бизнес (правила трейдинга например, а мы подписывались на другие) мы можем отреагировать сразу.

Практически на следующий день.

В конце разработки заказчик всегда имеет систему со ВСЕМИ НАИБОЛЕЕ ВАЖНЫМИ ФИЧАМИ.

Если скажем фича 38 была в ТЗ, но в процессе разработки заказчик постоянно говорил, что фича 38 не важна и вместо ее реализации предлагал другие более важные для него вещи (фичу 177, 36, 561 и 42) - и в результате фича 38 не вошла в окончательный релиз, то заказчик это прекрасно сам понимает и знает, что ему это не нужно, зато он получил гораздо более важные вещи нужные прямо сейчас.

[mmoustaf 101]

Вообще это все парадокс блаба напоминает.