Enot5467,

Я тоже тщетно пытался разобраться на каком нибудь приведённом примере ЧТО ЖЕ такое - эта Ваша "альтернативная система" Кроме "на ошибках других проектов" учатся - ничего не нашёл. Мне кажется Коллега Вы сами усложнили свои проекты. А логика скарама и еджаил ( SCRUM & AGILE ) сводится как раз к противоположному - УПРОЩЕНИЮ. В Одной итерации - ITERATION{а ею может быть даже один день работы всей команды.
Пример : Заказчик утром "вспомнил" что надо новый рапорт о сдаче НДС в конце дня автоматически посылать всем бизнес оунерам.
В Команде
сели покумекали что делать разбежались --НАЧАЛО

к обеду собрались с идеями --ПРОДОЛЖЕНИЕ

после обеда закодировали, убедились что всё работает --ПРОДОЛЖЕНИЕ

загрузили в сорс контроль - --ПРОДОЛЖЕНИЕ

сделали билд и --ПРОДОЛЖЕНИЕ

отдали тестерам на проверку а сами --ПРОДОЛЖЕНИЕ -->> КОНЕЦ

пишут документацию --КОНЕЦ --> -- Начало НОВОЙ ИТЕРАЦИИ}
- можно увидеть все фазы ведения именно этого кусочка - "забыли про НДС". День работы и назавтра доклад клиенту - ГОТОВО, проверяйте.

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

архитектор,

DBA( даже несколько если система собирает данные из 5 разных ресурсов -
--DB-2,
--SQL Server и
--Oracle
--(XML + Flat Files) и рассылает корпоративной
-->-- IBM Lotus Notes почтой,

рапортовый кодировщик ну например CrystalReports или SSRS.

Другой случай допустим - новую колоночку надо ввести во все ресурсы Например дату изменения значения в записи. - там заправлять будут Проектировщики баз и архитекторы, код будет выдан [всем] DBA для внедрения и так далее...

Enot5467
1. Роли надо планировать за ранее и их всегда гораздо больше 3-х


Может быть и один человек - например писака документации - всё что ему надо - писать писать и писать - на 3-х - 5-ти языках Его то и тестировать труднее всего - ну нет у меня сейчас никого кто понимает японский... И где взять?

Enot5467,

Я правду очень хочу понять Коллега, чесслово. Над ISO9000 - поверьте мне - я работаю более 15 лет, но без специальной ссылки мне там делать нечего. Пурга ... Я очень очень хочу Вас понять - но наверное моя переводческая система чего то упускает. Чесслово - Вот давайте так - я человек с Америки. Русский мой очень лимитированный. Ккак бы Вы объяснили мне при встрече особенности вашего метода?

Nota Bene: Надеюсь мои объяснения итерационного подхода к управлению проектами понятны - если нет - задайте вопросы - попробую ещё раз

Note: I am even dropping the smoking fase for you to make you feel that I really do want to understand.

Enot5467Вот в Вашем списке нет тестера!
........
Убрали тестера, получился проектик хреновый. Кто виноват?

Коллега, Отдел Технического Контроля - это одна из наиважнейших частей нашей работы. Вот в этой ветке я попытался обозначить как работает такая команда. Кстати и вот этот пост нашего топика подчёркивает необходимость QA. Когда упоминается шаг "Отдать Тестерам" - значит не вернуть его в команду а показать "представителю заказчика" которым и является QA на время выполнения проекта.

Enot5467,

Вот теперь мне стало понятно ЧТО имеется ввиду. Коллега iscrafm - Мой Респект и благодарность за ссылочку. То есть вы рассматриваете контроль и управление качеством как отдельный проект. И за основу взяли ISO9001:2000 Мы на сегодняшний день используем TQM систему ISO 8402:1994 которая ещё глубже двигает зависимость PROCESSES, PEOPLE и REQUIREMENTS. Но я ни коим образом не буду Вас отговаривать от избранной схемы. Это уже огромный на мой взгляд скачёк в плане качества.

Только вот он является (обычно) решающим в завершающей стадии итерации проекта. Против TQM - это постоянное отслеживание ошибок и улучшения процессов.

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

В Этом случае - опять же гипотетическом - аналитик может выступать заказчиком. Именно он определил ( сообразил из разговора с заказчиком) что системе надобен какой нить аудит - например время (ну и принадлежность канешна) изменения записи в [системных кодировочных] таблицах. На митинге он выдал мысль. Подключил Проектировщиков - ведь они именно имеют в хозяйстве все модели и условия баз данных. Те сказали чта им надо ещё и архитектора - как будут системы (UNIX, IBM, Windows) себя чувствовать во время таких перемен, посидели - нашли все таблички - а их мога быть штук .н..ста. Отметили в модельках - сгенерили скрипты, Архитект глянул - вроде будет работать, позвал DBA - те подкрутили и одним махом на все 125 баз данных - ГОТОВО. Опять же тестеровщика - на полный цикл Смок Тест, Регрешн Тест, Фанкшн Тест, Деплоймент Тест ну и что там у них ещё - по многу раз - пока не отладят всё - Ведь мы же знаем что баги всё равно будут. Не бывает без багов. То IP в системе не тот (архитектор блин - почему гад не апдейтал) То скрипт завис на таблице в 200000000 рекордов - уппс - не ожидали такого (DBA - крути). То таблицу не узнаёт Было VendorCode а теперь VendorSystemCode - ox уж эти Проектировщики - скока можна напоминать PowerDesigner не для картинок разработан... Ну и так далее... Всё это находят QA - возвращают в доработку и следят чтобы всё было задокументировано.