Comments 5
Структура основной доски Trello удобна для общего управления проектом, но не подходит для «спринтов». Есть смысл выбранные для очередного «спринта» задачи брать из доски-«бэклога», который можно сравнить с большим мешком с подарками, и переносить эти задачи в новую, отдельную доску, рассчитанную на один «спринт».
Что мешает создать отдельный столбец (несколько столбцов) в начале доски и использовать его для спринта?
Лично я вижу несколько причин.
1) Столбцов и так много, приходится использовать горизонтальный скроллинг, что не очень удобно.
2) Визуальное захламление, огромное количество задач отвлекает и давит.
3) Вероятность всё испортить. Иными словами, когда у тебя целая куча разных задач, и ты перетаскиваешь их между столбцами, то есть шанс закинуть задачу не туда, что-то не так сдвинуть, всё перемешать. Поэтому я бы предпочёл спринтовые задачи иметь на одной доске, а бэклог на другой — так спокойнее.
1) Столбцов и так много, приходится использовать горизонтальный скроллинг, что не очень удобно.
2) Визуальное захламление, огромное количество задач отвлекает и давит.
3) Вероятность всё испортить. Иными словами, когда у тебя целая куча разных задач, и ты перетаскиваешь их между столбцами, то есть шанс закинуть задачу не туда, что-то не так сдвинуть, всё перемешать. Поэтому я бы предпочёл спринтовые задачи иметь на одной доске, а бэклог на другой — так спокойнее.
Шикарная документация, есть чему поучиться.
Мысли пересекаются с моей статьей: habrahabr.ru/post/134128
Как вы проверяли «целостность документации»?
Какими способами искали «неудобные вопросы», которые пропускают?
Мысли пересекаются с моей статьей: habrahabr.ru/post/134128
Как вы проверяли «целостность документации»?
Какими способами искали «неудобные вопросы», которые пропускают?
Спасибо :)
Если я правильно понял про целостность, то я сначала выделил все аспекты игры (код, арт, гейм-дизайн и проч.) и от большого к малому создавал технические задания. Крайне важную роль играют макеты интерфейсов, потому что они напрямую связаны со всеми игровыми фичами. Одного взгляда на экран с GUI достаточно, чтобы увидеть отсылки к десяткам техзаданий.
Что подразумевается под неудобными вопросами? Вообще я просто составил список задач в to-do и методично работал со всеми. Время и труд, как говорится.
Если я правильно понял про целостность, то я сначала выделил все аспекты игры (код, арт, гейм-дизайн и проч.) и от большого к малому создавал технические задания. Крайне важную роль играют макеты интерфейсов, потому что они напрямую связаны со всеми игровыми фичами. Одного взгляда на экран с GUI достаточно, чтобы увидеть отсылки к десяткам техзаданий.
Что подразумевается под неудобными вопросами? Вообще я просто составил список задач в to-do и методично работал со всеми. Время и труд, как говорится.
Проверка на целостность — это как раз поиск «пропущенных» задач: TODO листы + фиксирование уровней детализации каждого из направлениий(AI упомянут в общих чертах, зато история мира проработана до мелочей -> нужно сосредоточится на AI)
Одного взгляда бывает недостаточно, чтобы понять что в этом GUI отсутствует кнопка сохранения или настроек.
Иногда помогают исследования чужих проектов: расписываем документацию по чужому проекту и ссылаемся на нее при разработке собственного.
Неудобные вопросы — это вопросы, на которые мы не знаем ответа, или ответ нам не нравится.
Плохое планирование умело обходит такие вопросы: «разберемся потом».
Одного взгляда бывает недостаточно, чтобы понять что в этом GUI отсутствует кнопка сохранения или настроек.
Иногда помогают исследования чужих проектов: расписываем документацию по чужому проекту и ссылаемся на нее при разработке собственного.
Неудобные вопросы — это вопросы, на которые мы не знаем ответа, или ответ нам не нравится.
Плохое планирование умело обходит такие вопросы: «разберемся потом».
Sign up to leave a comment.
Диздок, или написание проектной документации