Теория разработки проектов

[whirlwind]

Не, к тому, что заказчик сам не знает что он хочет нужно быть готовым сразу. Это типичная ситуация. Выход тут один: додумывать за него, предлагать свои варианты. И тут маленькие шаги очень облегчают задачу: за большой период можно напридумывать такого, что очень сильно разойдется с видением проекта заказчиком. И переделывать нужно будет много и быстро, а бюджет ограничен. В случае мелких шагов, процесс не выходит из под контроля.

>и если в проекте работы на человеко-год, то за месяц ты его не выкатишь

Фичекат - это feature cut. Убираем функционал, который менее важен именно сейчас. Понятно, что за месяц мегапроект не сделать. Но лучше начинать получать деньги с 5% от функционала проекта через неделю-другую после старта, чем не факт что получить через полгода. Приход денег оченно радуют заказчика. Потому что для него прибыль первична, а не сам проект.

 

[MiksIr]

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

 

[whirlwind]

MiksIr при таком подходе проектирование не может быть до-процессом. Ведь оно получается проектирование относительно текущего состояния проекта. Здесь есть хороший плюс - заказчика не надо заставлять платить за проектирование. Это входит в стоимость итерации.

 

[grigori]

в моих проектах "основной десяток" / feature cut требует месяцы работы, проекты непростые

 

[MiksIr]

MiksIr при таком подходе проектирование не может быть до-процессом. Ведь оно получается проектирование относительно текущего состояния проекта. Здесь есть хороший плюс - заказчика не надо заставлять платить за проектирование. Это входит в стоимость итерации.

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

 

[MiksIr]

в моих проектах "основной десяток" / feature cut требует месяцы работы, проекты непростые

Возьми не десяток, а пару фич

 

[craz]

Т.е. все-равно нужно оценить количество итераций, когда он будет готов.

Поскольку это все теория, я как понимаю кол-во итераций конечно в проекте любой сложности?

 

[whirlwind]

Так никто не спорит. Но работа то все равно идет каждый день, а не разом. Все равно нужно планировать. Это как TDD заставляет соблюдать дисциплину кода, итерации заставляют соблюдать дисциплину архитектуры. Существуют ведь и промежуточные этапы. Например забивать базу контентом. Чем раньше пользователи подключаются к работе, тем быстрее получаем четкое видение. Давайте рассматривать любой проект, могу продемонстрировать.

Вот наш объем по тестам если смотреть

Time: 09:36, Memory: 70.75Mb

OK (2398 tests, 39894 assertions)

это много или мало?

Насчет сроков примерно хоть при каком подходе можно прикинуть. И хоть при каком подходе можно ошибиться. Если срок = бюджет, то в интересах заказчика получить максимум за минимальное количество итераций. Это то, о чем я говорил - заинтересованность всех сторон.

>Поскольку это все теория, я как понимаю кол-во итераций конечно в проекте любой сложности?

нет предела совершенству

 

[MiksIr]

Поскольку это все теория, я как понимаю кол-во итераций конечно в проекте любой сложности?

Стопудово конечно. Заказчик тоже не бессмертный.

 

[craz]

нет предела совершенству

Это понятно и в тоже время как я понимаю раз кол-во итераций известно, то впринципе известны и они сами. То есть каким бы не был проект есть некое множество I итераций беря из I iую итерацию для данного проекта мы знаем о сотояние проекта? так?

То есть составив карту итераций можно составить блоксхему разработки?

 

[igortik]

1. Начинать надо с конца, точнее - понимать конечную цель, видеть конечный результат.
2. Потом разбирать как достигается этот результат, какие процессы (этапы) приводят к выполнению.
3. Далее понять какие инструменты (базовые классы, ф-ции) для этих процессов нужны, которые будут повторяться с определенной частотой (работа с базой, проверка файлов, проверка данных и т.п.)
4. Построить иерархию файлов и каталогов системы, пример:
- Понятие приложения /applications/site [adm,crm,etc...]
- Понятие модуля (группы файлов), под модулем я понимаю функционал, который помогает решать конкретную задачу (либо ряд связанных задач)
- Контроллер и модель работы с данными (/modules/module/controllers/ ... , /modules/module/models/ ...)
- Глобальная библиотека (классов и функций), возможно, будут уместны библиотеки в конкретном модуле, но я бы вывел это все в модель, т.к. это тавтология кода
- Вывод (функционал, который помогает вывести результат, т.е. связка классов и функций, решающие задачи визуализации)
- Роутер, обрабатывающий запрос (возможно, просто парсинг урла)

Собрав картину воедино мы видим:
- запрос правоцирует систему выполнить конкретную операцию
- обращение идет к конкретному модулю к конкретному контроллеру к конкретному действию (учесть логику "по-умолчанию")
- действие, как один из результатов обработки данных контроллером, при успешной валидации данных дергает модель, которая работает с базой и прочими данными, отдав результат контроллеру
- контроллер, не долго думая, передает результат "в вывод" (view) или просто завершает свою работу (зависит от конкретной задачи)
- вывод готовит шаблоны, один словом - html
- статика (макеты дизайна, форм, возможно макет для конкретного экшена (экшн рассматривается как один из результатов выполнения задачи конкретного контроллера), css, js)
- во время всей этой магии, более чем вероятно будут происходить:
-- понадобятся какие-либо классы из глобальной библиотеки системы (класс проверки данных, класс для работы с бд, класс шаблонизатора и т.д.)
-- будет востребована статика модуля (сборка общего css, js из всех модулей)
-- создание полного или частичного кеша результата выполнения

5. Набросать краткий (минимум) план. Детали пониженной важности учитывать не стоит, они, либо сами всплывут во время писанины кода, либо будут забыты и не востребованы.
6. И главное - постараться мыслить объектами. (так можно в голове построить цепочку связей одного компонента с другим).

 

[whirlwind]

craz в ретроспективе можно.

 

[craz]

craz в ретроспективе можно.

вы к примеру имеете данную ретроспективу? как выполненные проекты с их тасками по итерациям?

 

[MiksIr]

Это понятно и в тоже время как я понимаю раз кол-во итераций известно, то впринципе известны и они сами.

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

 

[craz]

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

Да вы правы, мне как раз попадались заказчики которые ничего не знают о конечном результате и не представляют конечного продукта, но Вы немного или много меня не поняли, что я имел ввиду

Есть N кол-во проектов в каждом проекте есть In - итераций, тогда при большом N будем иметь матрицу I - итераций содержащую все возможные итерации для любого проекта любой сложности, ну или с погрещностью стремещейся к 0. Так?

 

[igortik]

Да вы правы, но Вы немного или много меня не поняли, что я имел ввиду

Есть N кол-во проектов в каждом проекте есть In - итераций, тогда при большом N будем иметь матрицу I - итераций содержащую все возможные итерации для любого проекта любой сложности, ну или с погрещностью стремещейся к 0. Так?

Можно теперь земным языком? )))))

 

[whirlwind]

> вы к примеру имеете данную ретроспективу? как выполненные проекты с их тасками по итерациям?

У нас скорее в коммитах. В коммитах номера тасков. Как то так. Но вообще на большие периоды мы не смотрим ни вперед, ни назад. Нет необходимости, а заказчик по деньгам смотрит.

 

[craz]

Можно теперь земным языком? )))))

это вроде земной)

 

[craz]

> вы к примеру имеете данную ретроспективу? как выполненные проекты с их тасками по итерациям?

У нас скорее в коммитах. В коммитах номера тасков. Как то так. Но вообще на большие периоды мы не смотрим ни вперед, ни назад. Нет необходимости, а заказчик по деньгам смотрит.

да ну нет я имею ввиду из 10 проектов из 100 проектов вы же можете уже составить полную карту не типового проекта только по таскам другого проекта, к примеру в одном проекте надо было СОАП какой нить создать, а в другом базу ноумайсиквел. Значит для проекта где будет и соап и база NoSql вам уже известны итерации и время их выполнения.

Я понимаю что аджайл и XP которые вы я так понимаю пропаведуете в работе, не поддерживает обобщения, но чисто теоритически возможно же такое?

 

[whirlwind]

craz Если последующая итерация базируется на результатах всех предыдущих, ну тут математика сам прикинь. Есть этапы, которые можно выделить. Но проект там же бизнес процессы, а не утилитарные функции типа вреймворка. Можно просчитать итерации на типовые операции, но каждый бизнес-процесс не типовой. Похожие есть, но любая самая маленькая отличительная черта на предыдущей итерации меняет всю последовательность (см. первое предложение). Это как md5.