Разбивка проекта на небольшие задачи

Question

Интересно, когда придет новый проект, скажем, создайте сайт социальной сети, как мне начать разбивать проект на небольшие задачи. Обычно для каждого проекта обычно 2-4 программиста, и обычно нет тестеров. Должен ли я разбить весь сайт на 4 часа с самого начала. Должны ли мы делать это поэтапно? Как насчет тестирования, нормально ли программистам проверять код?

Спасибо за ваше время.

Answer 1

Мы используем довольно простую систему.

• Сначала мы разбиваем проект на истории пользователей или «вертикали». Например, «Обновить клиент».
• Составьте список всех вертикалей в первом столбце таблицы.
• Затем сверху вы размещаете слои или виды деятельности. Например, Data Layer, UI, Logging.
• Для каждого из элементов в матрице вы можете выделить оценку и решить, кто ее должен разработать.
• Разбить его на 4 часа, это хорошо, потому что тогда каждый разработчик может сказать: «Я собираюсь выполнить эти две задачи сегодня» в схватке.

Обычно мы делаем это для каждого спринта для мероприятий, которые должны быть выполнены в спринте.

При тестировании программисты должны проверить код, написав модульные тесты, но тестеры должны выполнить системный тест.

Answer 2

Вам необходимо подобрать основную книгу об управлении проектами, прочитать ее и практиковать то, что вы узнаете от нее. Проверьте статью Википедии об управлении проектами - хорошая отправная точка: http://en.wikipedia.org/wiki/Project_management

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

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

Что касается программистов тестирования их кода:

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

1. В процессе разработки вы могли бы сделать тест инициативу Развитие-> сделать ваши разработчики пишут тест первым и когда их код сверен в тесте он готов к тому, чтобы использовать любой репозиторий исходного кода.

2. Как только весь ваш код отправлен, и у вас есть ранняя версия вашего программного обеспечения, вы можете выполнить внутреннее тестирование, например, тестирование системы, где у вас есть тестеры или программисты для тестирования приложения.

3. Когда вы довольны тестированием систем, вы можете выполнить тестирование приёма пользователей перед его развертыванием в любом месте. Приемочное тестирование пользователя должно выполняться кем бы то ни было вашим целевым пользователем.

Я желаю вам удачи с вашим проектом :)

Answer 3

Это большой вопрос для форума, поэтому я начну с рекомендовать книгу:

Agile Estimating Planning by Mike Cohn

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

Пока вы не купили и читать книгу, это очень короткая версия может быть полезной:

• ли грубое планирование зерна первым. Что-то вроде: мы планируем развернуть первую версию через два месяца, содержащую самые базовые функции, чтобы сделать ее действительно полезной. После этого у нас будет новая версия о каждом месяце. Удостоверьтесь, что вы не вдаетесь в детали. Так как реальность все равно убьет все подробные планы.Вы можете думать о шагах в этом плане, как фазы, но учтите, что они не матча анализ классической фазы, проектирование, внедрение, тестирование, развертывание

• Для первого плана фазы более подробно, что вы собирается сделать. Используйте вертикальные срезы для планирования, т. Е. Не планируйте: сначала мы создадим GUI, затем модель, затем базу данных, но будем использовать полные функции, часто моделируемые как пользовательские истории. например «Как пользователь, я хочу вводить заказы в систему». Это будет одна история пользователей. Реализация этой истории пользователей подразумевает выполнение всего материала с Userinterface настойчивостью, включая тестирование. («Истории пользователей» Google и «планирование итерации» для получения дополнительной информации об этом.)

Для вашего вопроса тестирования: Разработчики тестирование их код лучше, не теста на всех. Но есть лучшие способы обеспечить высокое качество кода. Я бы порекомендовал следующий подход:

• Проводите тестирование на основе теста, то есть сначала записывайте тесты, а затем выполняйте их. Этот тип сил позволяет вам и вашей команде сделать код хорошо структурированным, он поддерживает быструю смену кода, так как тесты будут информировать вас о том, что материал сломается.

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

• Вам все равно понадобятся ручные тесты всего приложения.

Больше материала для чтения и Google: проворный, хватка, хр, TDD, BDD, Planning Poker,

Answer 4

Еще одна книга, которую вы могли бы найти полезным является

Software Estimation: Demystifying the Black Art

Стив Макконнелл

Другое, чем я могу только повторить то, что говорили другие: это в основном «Разделить и покорить».

Answer 5

Как насчет тестирования, хорошо ли программистам проверить код?

Если вы не имеете QA, программисты должны проверить свой код!

Я рекомендую также программистам делать обзоры кода (пересматривая код друг друга). Как руководитель команды я использовал, чтобы просмотреть все, от новых сотрудников, прежде чем они зарегистрировались:

• контроля качества (убедитесь, что они не проверяя в багах)
• Кроме того, обучение (см ли то, что они не» я знаю и должен знать, что я могу сказать им)

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