[PHPCONF09] практика построения среды разработки, определяющей процесс проектирования

Я голосую ...

  • Включить в программу

    Голосов: 14 77,8%
  • Не включать

    Голосов: 4 22,2%
  • Укажу в топике

    Голосов: 0 0,0%

  • Всего проголосовало
    18
  • Опрос закрыт .

whirlwind

TDD infected, paranoid
Совершенно никак не связано. Вы когда нибудь запускали одновременно нагрузочные тесты параллельно разрабатывая программу? А чо, казалось бы, тесты-то выполняются компьютером автоматически и разработчика никак не трогают. А позвольте еще уточнить сколько при таком подходе было перезапусков? Вот так, за счет забытых строчек в конфигах часовые тесты превращаются в четырехчасовые, а профессиональный труд превращается в обезъяний 12-часовой рабочий день. Это мы отбросили время на разработку самих тестов, написание репортов и ФТ, на которое нужна соответствующая квалификация и время соответственно. Или качество какого ПО Вы имели в виду? А то программа программе рознь, так же как и качество.
 

baev

‹°°¬•
Команда форума
Вы приводите узкое определение одного из количественных параметров риска
— нет, это у Вас «узкое определение».
Если вообще правомерно частный случай «могут являться» выдавать за общее определение.

Даже в приведённой Вами цитате ясно сказано, что риск — это возможные случайности и опасности. Если не придираться к словам и не притягивать за уши «измерения» (aka «количественная оценка»), «вероятный неудовлетворительный итог» — ничем не отличается от «возможной опасности».
 

The employer

Новичок
Автор оригинала: baev
— нет, это у Вас «узкое определение».
Если вообще правомерно частный случай «могут являться» выдавать за общее определение.

Даже в приведённой Вами цитате ясно сказано, что риск — это возможные случайности и опасности. Если не придираться к словам и не притягивать за уши «измерения» (aka «количественная оценка»), «вероятный неудовлетворительный итог» — ничем не отличается от «возможной опасности».
Хорошо, я не буду выяснять чье определение более узкое. Достаточно того, что в контексте заданного вопроса имелось в виду определение риска как возможной причины неудачи.

То есть вопрос звучал так: "Какие опасные факторы, какие возможные причины общей неудачи проекта вы относите к сфере разработки?".
 

atv

Новичок
Тема на самом деле очень интересная. Но проблема в том, что, как и с большинством других проблем, пока с ними не столкнёшся, до тех пор будешь как whirlwind отвергать их существование. Но факт отстаётся фактом, большая часть проектов провальные (это по статистике).

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

В общем, тема хорошая, но, наверно, не для конференции. Поработать бы в такой команде годик, другой, да после того как завалил проект, тогда была бы польза :)
 

confguru

ExAdmin
Команда форума
The employer

Нужна краткая версия тезисов для программы.
 

whirlwind

TDD infected, paranoid
Автор оригинала: atv
Тема на самом деле очень интересная. Но проблема в том, что, как и с большинством других проблем, пока с ними не столкнёшся, до тех пор будешь как whirlwind отвергать их существование. Но факт отстаётся фактом, большая часть проектов провальные (это по статистике).
Это какие проблемы я отвергаю? Я вроде наоборот говорю, что при академическом подходе проблема на проблеме и проблемой погоняет. И что за статистика, британские ученые?
 

The employer

Новичок
Автор оригинала: admin
The employer

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

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

Alexandre

PHPПенсионер
Я недавно работал с командой над очень объёмным проектом (макроэкономика, финансы, валюты, рынки и капец ещё сколько), который с успехом провалился.
В этом могут быть несколько причин:
- заказчик не расчитал бюджет (самое распространенное), в результате на этаме 50-60% заканчивается бюджет и проект упроваливается

- требования менялись во время проекта (тоже часто), аппетиты растут во время еды... Рашили выпустить релиз по максимуму, нельзя объять необъятное... в результате пришли к п.1

- плохое взаимодействие Заказчик-исполнитель (менеджмент со стороны проекта) Один думает одно - а другой понимает другое...делаем-делаем - в результате не то, следующая итерация - врезультате приходим к п.1

....

не твой заказчик первый наступал на эти грабли. А вот обидно, что проср@ли хороший проект

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

korchasa

LIMB infected
Автор оригинала: Alexandre
Вывод:
- нужно грамотное взаимодействие с заказчиком
- нужно спланировать релиз (сроки выхода релиза и разных фич, поэтапный ввод проекта )
- нужно планировать разработку
- нужно планировать бюджет
- нужен контроль исполнения
И главное не забывать исправлять планы, по мере изменения и добавления новых фич заказчиком :)
 

AmdY

Пью пиво
Команда форума
korchasa
если это влезет в бюджет, а если не влезает, то уметь отказаться от фичи.
 

Alexandre

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

korchasa

LIMB infected
Автор оригинала: AmdY
korchasa
если это влезет в бюджет, а если не влезает, то уметь отказаться от фичи.
А разве это не дело заказчика, судить о надобности той или иной фичи?

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

atv

Новичок
В этом могут быть несколько причин:
И не назвал ни одной со стороны исполнителей. А их у нас было немало.

Дело в том, что с ростом объёма проекта начинаешь сталкиваться с такими проблемами, о которых на проектах средних объёмов даже не задумываешься.

Например, управление требованиями. Казалось бы, а что тут управлять. А вот, блин, влипли. Со стороны заказчика было несколько специалистов предметной области. Все переговоры велись по аське (хоть какое-то документирование :) ). В результате, один говорит одно, сделали, отдали посмотреть, другой сказал другое, исправили, опять отдали посмотреть (через месяц, так как раньше не соизволили), возникает вопрос, а чего так сделали?, так как сказали, кто сказал?, а хрен его знает, кто-то из вас, пошли шариться по аське (песня за кадром: а время, а время, не убавляет ход, а время, а время идёт).

Далее, отдаём штатным тестировщикам. У тех резонный вопрос, а что должно быть, где требования? Ну, тут должно быть так, а тут должно быть так, и начинаем пересказывать все требования, из тех что помним, которых уже на целый том собралось. Думаете тестировщики всё сразу и запомнили? Фиг вам, потестилии пересели тестить другой проект. А на второй версии нашего опять все те же вопросы (за кадром та же песня).

Сюда же, управление изменениями требований. Казалось бы, а нафиг. Заказчик говорит, сделаете такую фичу?, от чего ж не сделать, сделаем. Сколько времени?, да чё там, в базе поле добавить, фигня. Добавили, в требования изменения не внесли. Тестировщики пишут баг, не соответствует требованиям. А ещё хуже, требование противоречит другому записанному ранее требованию. Чешем репу, откуда это поле в базе, фиг его знает, наверно от старой версии осталось, значит сносим.

Общение с заказчиком. Ну что, как проект, да ни чё, делаем, а, ну хорошо. Через месяц, ну что, скоро закончите, да вот, хотели первую часть показать. Да нафиг надо, меня интересует конечный результат, а не промежуточный. Вы мне всё давайте. Ок, как скажете. Через год с лишним. Ну чё, уже полтора назначенных вами срока прошло, где проект. В жопе. А что ж вы делали? А хрен его знает. Мы ничего не записывали, ни простоев по вине представителей заказчика, ни того, что куча времени ушла на пересказывание требований тестировщикам, ни того, что исправляя баг сидели и вспоминали, а какого хрена здесь сделано вот так, а такого, что это где-то в требованиях проскакивало, что и повлияло на решение, сделать именно так, а не иначе. А сложные решения мы не документировали, не, а зачем?, "при академическом подходе проблема на проблеме и проблемой погоняет."
 

AmdY

Пью пиво
Команда форума
Автор оригинала: korchasa
А разве это не дело заказчика, судить о надобности той или иной фичи?
не всегда, иногда разработчику лучше видно во что обойдётся данная фича, тем более бюджеты и время не безграничны. Вот у нас сейчас ситуация, когда проект должен был быть завершён вчера, подготовлена рекламная акция, но заказчик без устали добавлял новые фичи и перекраивал интерфейс. в итоге кое-как влезли, но весь функционал протестировать не удалось и ещё есть список будущих фич :(. а ведь могли завершить этот проект и взяться за другой, более выгодный или менее гемморойный.
 

korchasa

LIMB infected
Автор оригинала: AmdY
не всегда, иногда разработчику лучше видно во что обойдётся данная фича, тем более бюджеты и время не безграничны.
Ну как бы и заказчику для принятия решения о приоритетах желательно иметь данные о затратах. Но решает то все равно он. Это же его бизнес.
Автор оригинала: AmdY Вот у нас сейчас ситуация, когда проект должен был быть завершён вчера, подготовлена рекламная акция, но заказчик без устали добавлял новые фичи и перекраивал интерфейс.
А что в этом ненормального? Вот ресурсы, вот стоимость фич. Какие будем делать?
Автор оригинала: AmdY в итоге кое-как влезли, но весь функционал протестировать не удалось и ещё есть список будущих фич :(. а ведь могли завершить этот проект и взяться за другой, более выгодный или менее гемморойный.
В этот момент я рад, что мы обычно продаем время работы, а не продукт.
 

The employer

Новичок
Кстати, интересный вопрос насчет "надобности той или иной фичи".

Что движет проектом? Проектом движут цели (обычно описаны в том самом business vision). Не фичи, это важно понимать - именно цели. Фичи же - это просто способ достичь заявленных целей. Типа: "У нас есть цель - получать от пользователей немедленный фидбек. Соответственно, организуем форму обратной связи."

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

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

Сам процесс сбора и анализа требований четко распадается на три вида работ: осознание и структурирование главных целей, поиск и отбор способов достижения по каждой цели, увязывание между собой всех выбранных способов достижения по всем целям.

Именно это содержание стоит за классической формулой анализа требований - "полнота, непротиворечивость, реализуемость".

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

korchasa

LIMB infected
Автор оригинала: The employer
Сбор и анализ требований - сфера компетенции разработчика, это мое глубокое убеждение. Если эту работу делает кто-то другой, разработчик в такой ситуации выступает всего лишь кодером. Никакого риска, никакой ответствености, никаких денег, никакого роста.
Со всем согласен, кроме этого. Сбор и анализ требований подразумевает наличие эксперта в выбранной предметной области, и знание бизнес процессов заказчика. Заказчик по умолчанию уже эксперт и знает бизнес. Какой смысл его дублировать?
 

Alexandre

PHPПенсионер
Вот у нас сейчас ситуация, когда проект должен был быть завершён вчера, подготовлена рекламная акция, но заказчик без устали добавлял новые фичи и перекраивал интерфейс. в итоге кое-как влезли, но весь функционал протестировать не удалось и ещё есть список будущих фич
все очень знакомо... заказчик не знает что хочет и когда уже почти сделано 90% он говорит, а давайте сделаем так...

-~{}~ 04.09.09 14:13:

Заказчик по умолчанию уже эксперт и знает бизнес. Какой смысл его дублировать?
а вот судя по
Да нафиг надо, меня интересует конечный результат, а не промежуточный. Вы мне всё давайте.
Заказчик не участвовал в разработке... Он толком не знал - а че ему надо?
не было налажено четкого взаимодействия... Даже менеджер проекта врядли может быть экспертом в предметной области Заказчика.
 

korchasa

LIMB infected
Автор оригинала: Alexandre
-~{}~ 04.09.09 14:13:

а вот судя по
Заказчик не участвовал в разработке... Он толком не знал - а че ему надо?
Он знает. Он, как выше написал The emploer, знает цели. Он чаще всего не знает метода их достижения.

Даже менеджер проекта врядли может быть экспертом в предметной области Заказчика.
Ага, проектов на самом деле три: тот который в ТЗ, тот который видит заказчик, и то, что получилось у программистов, когда они прочитали ТЗ. Waterfall must die :D
 

atv

Новичок
Сбор и анализ требований подразумевает наличие эксперта в выбранной предметной области, и знание бизнес процессов заказчика.
Какая-то неразбериха получилась. Изучение предметной области и бизнес процессов как раз и происходит во время сбора и анализа требований. Разработчик не сможет разработать структуру данных, не понимая предметной области. Не сможет разработать интерфейс, не понимая бизнес процессов.

Заказчик по умолчанию уже эксперт и знает бизнес. Какой смысл его дублировать?
Заказчик эксперт в предметной области, но не эксперт по автоматизации предметной области. Разработчик в любом случае вынужден разбираться с предметной областью, так как на нём лежит задача "трансляции предметной области проекта в предметную область разработки".
 
Сверху