Про точность определений
Apr. 21st, 2013 11:54 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rНа днях прочитал банальную, но постоянно упускаемую из вида вещь.
В классическом смысле проект считается удачным, если первоначально заданные технические требования выполнены полностью, в срок и в рамках бюджета.
Все модели agile создают всё что угодно, но только не результат, соответствующий требованиям, определённым перед началом проекта.
Таким образом, в классических моделях любой проект, использующий agile, является failure просто по определению.
В классическом смысле проект считается удачным, если первоначально заданные технические требования выполнены полностью, в срок и в рамках бюджета.
Все модели agile создают всё что угодно, но только не результат, соответствующий требованиям, определённым перед началом проекта.
Таким образом, в классических моделях любой проект, использующий agile, является failure просто по определению.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-04-22 09:46 am (UTC)В вебразработке основная проблема в том, что заказчик сам не знает что хочет.
И вся эта айджаловская пляска позволяет заставить заказчика определиться с требованиями.
no subject
Date: 2013-04-22 09:53 am (UTC)Это мелочи. Важнейшей функцией является именно переопределение успеха.
В вебразработке основная проблема в том, что заказчик сам не знает что хочет.
Заказчик не знает, что хочет, и в телекоммуникациях, и в машиностроении, и в архитектуре и в космонавтике.
У заказчика есть деньги и есть потребность, а выяснить, что именно это за потребность, какие возможны решения и какое их них оптимально, а потом сделать всё чётко и в срок - это как раз и отличает специалистов от жуликов.
no subject
Date: 2013-04-22 10:00 am (UTC)Я вот работаю на заказчика. От меняет требования 2 раза в день. Обычной процесс:
1. Сделайте мне вот это
2. Сделали
3. Спасибо, я посмотрел на то что вы сделали и понял что нужно по другому.
4. Сделали по другому
5. Спасибо вы молодцы, но подвиньте на пару пикселов вправо
6. Сделано
7. ААААА, уберите в этом месте точку, это критично для всего проекта!!!! Я не могу разрешить пустить в релиз с этой точкой!!!
8. Сделано.
9. Спасибо, молодцы, только теперь уберите эту фичу, я придумал новый вариант.
10. OK :)
Как с таким заказчиком работать в том же RUP-пе?
no subject
Date: 2013-04-22 10:15 am (UTC)1. Сделайте мне вот это
2. Сделали
А что мешает сначала выяснить, что заказчику нужно, а потом уже начинать делать? Две трети таких задач решается на бумаге. Из оставшихся четыре пятых проверяется на скриншотах, собранных в Фотошопе или на прототипах.
Если заказчик хочет просто покомандовать, то тут не производство продукта, а "пусть слоники побегают".
no subject
Date: 2013-04-22 10:21 am (UTC)Но заказчик - перфекционист. Он меняет требования только поработав на реально работающей системе.
Но мы не сильно против, ибо платит хорошо.
no subject
Date: 2013-04-22 10:28 am (UTC)Ну так это и называется "Пусть слоники побегают". Процессы софтопроизводства тут ни при чём.
no subject
Date: 2013-04-22 10:22 am (UTC)а рабочие прототипы - это уже agile ;)
no subject
Date: 2013-04-22 10:29 am (UTC)А agile - это не рабочие прототипы, а прототипы, которые выдаются за работающую программу.
no subject
Date: 2013-04-22 10:54 am (UTC)Паровоз "Ракета" - всё нормально.
а насчёт бумаги - не всё можно быстро нарисовать понятно. А некоторые вещи быстрее сделать и дать покрутить, чем нарисовать.
no subject
Date: 2013-04-22 10:56 am (UTC)no subject
Date: 2013-04-22 10:58 am (UTC)А так - каждый раз себе говорим "ну вот, зато когда будем переделывать - тогда уж мы огого!"
no subject
Date: 2013-04-25 01:23 pm (UTC)То, что заказчик должен остановиться в развитии и не менять бизнес-процессы. Иначе "первоначально заданные технические требования" либо будут слишком слабыми, чтобы быть полезными, либо станут неадекватными к завершению проекта.
no subject
Date: 2013-04-25 01:26 pm (UTC)Если у заказчика всё меняется с такой скоростью, что не успевают задать требования, то после того, как софт поставлен, на следующий день он уже станет устаревшим. Да, собственно, он и сам не понимает, что делает. Если вбивать параметры жёстко в систему, то да, тут можно ваять бесконечно и называть это "новыми релизами".
no subject
Date: 2013-04-25 02:05 pm (UTC)Ну и не надо забывать - конечно, половины этих проблем можно было бы избежать при идеальной работе. Но руководство, программисты и пользователи, к сожалению, не боги и делают ошибки, и рабочих часов у них в сутках всего 12.
no subject
Date: 2013-04-25 02:09 pm (UTC)Тут дело не в том, что "делают ошибки", а в том, что стратегии нет и никто не хочет думать. Особенно насчёт "завтра выясняется, что с ней будет работать четверть компании".
no subject
Date: 2013-04-25 02:34 pm (UTC)no subject
Date: 2013-04-25 04:23 pm (UTC)А данные должны быть доступны в таком виде, чтобы под всякие заскоки писать обычный переходник, а не перелопачивать всю систему.
О стратегии развития должен думать тот, кто отвечает за проект. Обычно это аналитик в фирме производящей софт, так как бухгалтера и финансисты с трудом алгоритмизируют свои знания.
no subject
Date: 2013-04-25 06:11 pm (UTC)P.S.: а к эпизодическим наездам начальника "почему так долго" и его "скисанию" после рассказа о деталях и предложении поделиться соображениями, как оный проект ускорить, мы уже давно привыкли. Притом это не начальник "плохой" - я сам иной раз не выдерживаю и на "смежников" наезжаю. но в глубине души ответ я примерно представляю.
no subject
Date: 2013-04-25 08:18 pm (UTC)Естественно, это надо уметь и получается далеко не у всех, но я не просто "знаю", а ещё и делаю. И такой я не один. (Правда, и проекты, где всё идёт хорошо, встречаются один на десяток или два, но встречаются.)
no subject
Date: 2013-04-29 08:03 am (UTC)Сколько будет стоить переключалка русского/английского языка? PKI ровно 2: чтобы мне за ней не приходилось доделывать и чтобы я её не выключил через неделю с криком "нахрен, лучше буду сам ошибаться и сам за собой исправлять, чем такая автоматизация".
no subject
Date: 2013-04-29 09:40 am (UTC)Работать просто надо с теми клиентами, у которых есть потребность, деньги и желание сотрудничества. Лучше всего, на концерны и государство. Ещё лучше на инженеров и разработчиков софта, они знают, чего хотят.
no subject
Date: 2013-04-22 11:56 am (UTC)no subject
Date: 2013-04-22 09:59 am (UTC)http://programming-motherfucker.com/
Там аджайл жорстко ругайутъ
Да, пора браться за оружие ящитаю.
no subject
Date: 2013-04-22 10:20 am (UTC)Есть три стороны: клиент, программисты и менеджеры. Agile вредит первым и эксплуатирует вторых, но для последних приносит кучу денег при практически нулевых рисках. То есть, польза сильно зависит от того, на чьей ты стороне.
Так что agile вполне работоспособная модель вроде подделки банкнот и грабежа на большой дороге.
no subject
Date: 2013-04-22 10:03 am (UTC)2) agile - это много одно-двух -дневных классических проектов. Они имеют небольшие чёткие требования и завершаются в срок и в бюджете. Ну, иногда и фейлят. Но agile это не останавливает.
Если позволите аналогию : муравейник - это не животное, но весьма похоже, а главное - это живёт :)
no subject
Date: 2013-04-22 10:07 am (UTC)Если бы они писали на знамени "Мы набросаем большую кучу", вопросов бы не было. Они же декларируют строительство дворцов и пирамид.
no subject
Date: 2013-04-22 10:20 am (UTC)на знамени ЕМНИП написано "вы получаете то, что вы просите", и (оглядываясь вокруг) вроде так всё и выходит.
no subject
Date: 2013-04-22 10:26 am (UTC)Тем, что куча, а не здание.
no subject
Date: 2013-04-22 10:47 am (UTC)Чем вам не здание - для муравьев? Ну, оно не так красиво выглядит, как вам кажется, но, как говорится : "Beauty is in the eye of the beholder"
no subject
Date: 2013-04-22 10:54 am (UTC)no subject
Date: 2013-04-22 11:03 am (UTC)