У меня проблемы с описанием процесса разработки моего проекта.
Я прохожу стажировку на предприятии в качестве дизайнера информационных систем и разработчика Java EE для выпуска. Мне нужно рассказать о процессе разработки и организации проекта в своем докладе.
Я спросил своего босса о процессе разработки, который они выполняют на предприятии, и он подтвердил мне, что это Scrum.
Моя тема об Интранете. Мы начали с самого сложного модуля в интранете. Ожидаемый период времени, чтобы закончить его составляет 5 месяцев. После того, как мы закончим этот модуль, мы начнем другой.
Таким образом, в течение этих 5 месяцев мы должны уточнить требования модуля, спроектировать информационную систему, которая удовлетворяет требованиям, спроектировать программную архитектуру, разработать, затем интегрировать, протестировать, затем проверить, а затем перейти к другому модулю. Эти шаги дают мне ощущение, что мы использовали описанный здесь V-Cycle .
Тем не менее, мы применяли практики Scrum, такие как ежедневное взаимодействие Скрам-команды и Скрам-мастера (что вы делали вчера? Есть ли у вас какие-либо трудности? Что вы будете делать сегодня?...) во время встречи. от 5 минут. У нас команда из 3 человек, у нас есть Scrum Master и 2 Product Owner.
Я поговорил со своим боссом, и он сказал, что разделит 5 месяцев на спринты по 2 или 3 недели (спринт проектирования, спринт реализации рабочего прототипа...,..., спринт тестирования).
Однако в колледже я усвоил, что каждый спринт дает нам версию продукта, который мы можем использовать, но который нам нужно улучшить.
Извините за такой длинный текст, но мне нужно было сделать вас в моем контексте, чтобы иметь возможность помочь мне в описании процесса разработки этого проекта. Большое тебе спасибо!
Может это спринты?
К сожалению, вы не используете Scrum. Вы просто применяете определенные практики, но не следуете мышлению. Вы близки, когда говорите, что «...каждый спринт дает нам версию, продукт, который мы можем использовать, но который нам нужно улучшить» . Однако спринты не обязательно производят версии, и в Scrum мы в первую очередь стремимся к обратной связи.
Итак, мы делаем Scrum, чтобы быстрее получать отзывы о нашем продукте. Конечно, вы можете использовать скрам-практики — мы тоже используем парочку из них — но ваши процессы далеки от скрам-процесса.
Когда вы описываете свой процесс, забудьте о Scrum, опишите процесс, а когда вы закончите свой черновик, обновите свое эссе с помощью инструментов Scrum и того, как они помогают вам или вашей организации. Будьте реалистами и не записывайте то, что может выглядеть хорошо, но на самом деле вы этого не делаете.
Вы НЕ можете сделать спринт дизайна, кодирования, тестирования. Каждый спринт должен делать все, чтобы предоставить некоторую работающую функциональность.
Эта ссылка не на изображение V-модели. Однако это популярное заблуждение.
V-модель не имеет стрелы времени. У него есть стрелки зависимостей. Вы не можете сделать это, пока не сделаете это. Scrum не нарушает V-модель. Однако пока V-модель говорит о том, что вы не можете тестировать, пока не напишете код. Agile утверждает, что вы можете и должны писать тесты перед написанием кода. Agile также говорит, что вам не нужно делать все это, прежде чем вы сделаете это. (Не делайте весь дизайн, затем весь код, затем все тесты)
Для Agile (основы):
Видите ли, порядок есть, он такой же, как и V-модель, за исключением того, что оригинальная V-модель не признает, что мы можем писать тесты перед производственным кодом. Он также не признает кодирование дизайном. (код — самая большая часть дизайна)
Нет красивого способа сказать это, это водопад. Единственная хорошая вещь в водопаде заключается в том, что если вы подрядчик, вы можете поддерживать проект в течение очень долгого времени, и клиенты/менеджеры не поймут, что что-то не так.
Тодд А. Джейкобс
пользователь1847726
джморт253
пользователь1847726