Как разбить проект программирования на задачи для других разработчиков? [закрыто]

Недавно я присоединился к проекту разработки и неожиданно получил работу ведущего разработчика. Моя главная ответственность состоит в том, чтобы разбить часть проекта на задачи, дать эти задачи другим разработчикам, а затем убедиться, что части работают вместе.

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

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

158 голосов | спросил khm 23 72014vEurope/Moscow11bEurope/MoscowSun, 23 Nov 2014 23:59:03 +0300 2014, 23:59:03

6 ответов


203

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

  1.   

    Основы

         
    • Не ходите в одиночку . Постарайтесь привлечь своих товарищей по команде как можно больше.
    •   
    • Легкий транспорт .
    •   
    • Демократия, но не слишком. Иногда речь идет не о том, что удовлетворяет наибольшее количество людей, но что болит наименьшее количество людей.
    •   
    • Сохраните (необходимо выполнить) и как (это делается) отдельный .
    •   
    • Узнайте о Scrum («что»), XP (экстремальное программирование, «как»), Kanban («сколько») , Lean («что не») и DevOps («с кем»).
    •   
    • Lean также относится к flow : для общей эффективности эффективность потока обычно важнее индивидуальной эффективности.
    •   
    • Узнайте о Software Craftsmanship , Чистый код и Прагматическое программирование .
    •   
    • Хорошая архитектура - это максимизация количества принятых решений .
    •   
    • Scrum /XP /Lean /Agile примерно максимизирует объем выполняемой работы : YAGNI .
    •   
    • Основное значение программного обеспечения заключается в том, что вы можете легко изменить его. То, что он делает то, что он должен делать, важно, но это только его Вторичная ценность.
    •   
    • Предпочитайте итеративный и инкрементный подход, используйте временные рамки для почти всего, особенно для встреч, сделайте < em> Закон Паркинсона ваш друг, потому что действует закон Хофстадтера .
    •   
    • Структура балансовой команды с пониманием Закона Конуэя и Этапы развития команды Tuckman .
    •   
    • Программирование - это кватернион, это science , engineering , art и craft в одно и то же время , и они должны быть в равновесии.
    •   
    • Просто потому, что Scrum / XP /XYZ хорош для кого-то (включая меня), не обязательно означает, что это хорошо для вас /подходит для вашей среды. Не слепо следуйте шумихе, сначала поймите.
    •   
    • Осмотреть и адаптировать! (Scrum Mantra)
    •   
    • Избегайте дублирования - Один раз и только один раз! (XP Mantra) aka DRY - не повторяйте себя aka SPOT - одиночная точка Истина
    •   
  2.   

    «Процесс разбивки по миру»

         
    • Соберите требования как Истории пользователей / Истории вакансий в отставание продукта .
    •   
    • Пользователь (из пользовательской истории), аналогичный Актеру (в UML), похожим на Persona похожа на Роль .
    •   
    • Уточнить Истории пользователей , пока они не соответствуют вашей команды INVEST (независимая, Negotiable, Value, Estimable, Small, Testable). (Scrum Meeting: Reflogment )
    •   
    • Сортировка отставания продукта по Бизнес-значение .
    •   
    • Не начинайте работу над историей, пока не будет Ready Ready (готово в соответствии с определением готовности).
    •   
    • Используйте Планирование покера для оценки усилий Историй в Story Points . Используйте Сравнение триангуляции , чтобы обеспечить согласованность оценок.
    •   
    • Вчерашняя погода - лучшая оценка, надеюсь, что худшее.
    •   
    • Разделить истории , если они слишком большие.
    •   
    • Улучшить культуру доставки с помощью Определение сделанного .
    •   
    • Не принимайте реализацию пользовательской истории до того, как она Готово (сделано в соответствии с определением Done).
    •   
    • Несколько команд на одной и той же базе кода должны согласовать и совместно использовать те же Определение Done (особенно стандарты кодирования ).
    •   
    • Проверьте свой прогресс с помощью Схемы Burndown .
    •   
    • Регулярно проверяйте со своими заинтересованными сторонами, действительно ли то, что команда предоставляет, действительно необходимо. (Scrum Meeting: Sprint Review )
    •   
  3.   

    Разрушение истории

         
    • Список и описание Пользователи / Персонажи / Актеры / Роли (владелец продукта)
    •   
    • Epic -> Истории (история пользователей или история работы) (владелец продукта)
    •   
    • История -> Критерии приема (владелец продукта)
    •   
    • История -> Подзадачи (Dev Team)
    •   
    • Критерии приема -> Приемочные испытания (Spec: Product Owner, Impl: Dev Team)
    •   
    • Начните с Walking Skeleton , который является минималистичным End-to- (Half-End) .
    •   
    • Создайте MVP - минимальный жизнеспособный продукт .
    •   
    • Разверните MVP с помощью SMURFS - специализированные, полезные, выпущенные функциональные наборы .
    •   
  4.   

    <сильный> "Какмир "

         
    • Используйте OOA /D , UML и CRC-карты , но избегайте большого дизайна upfront . . li>   
    • Внедрите объектно-ориентированные , структурированные и функциональные в одно и то же время, насколько это возможно, независимо от языка программирования.
    •   
    • Используйте Контроль версий (желательно распределенный ).
    •   
    • Начните с Приемочных тестов .
    •   
    • Примените TDD , позволяя Три закона TDD провести вас через Red-Green-Refactor-Cycle , с Single -Assert-Rule , 4 A , GWT (задано когда тогда) из BDD .
    •   
    • " Тесты устройств - это тесты , которые быстро выполняются ." Майкл Перс
    •   
    • Примените принципы SOLID и , чтобы управлять связью и связью .   Пример: S в SOLID - это SRP = Single Responsibility Principle, значительно уменьшает количество изменений. слияния-конфликты в командах.
    •   
    • Знай Закон Деметры / Скажите, не спрашивайте .
    •   
    • Используйте Непрерывная интеграция , если применимо, даже Непрерывная доставка (DevOps).
    •   
    • Используйте Собственность коллективного кода на основе согласованного стандартного стандарта кодирования (который должен быть частью Определение сделанного ).
    •   
    • Применить Непрерывное улучшение дизайна (fka Continuous Refactoring).
    •   
    • Исходный код - это дизайн . Все еще предварительное мышление незаменимо, и никто не будет возражать против нескольких хороших разъясняющих диаграмм UML.
    •   
    • XP не означает, что день не является днем ​​архитектуры, это означает, что каждый день является днем ​​архитектуры. Это сосредоточено на архитектуре, а не на расфокусировке, и основное внимание уделяется кодексу.
    •   
    • Сохраняйте свой Технический долг низким, избегайте четырех ароматов дизайна Fragility , Жесткость , Immobility и Вязкость .
    •   
    • Архитектура относится к бизнес-логике, а не к механизмам сохранения и доставки.
    •   
    • Архитектура - это командный вид спорта ( в архитектуре нет).
    •   
    • Шаблоны проектирования , Рефакторинг и Приоритет трансформации .
    •   
    • Код проекта - это ATP-Trinity с приоритетами: 1. Код автоматизации , 2. Тестовый код , 3. Производство Код .
    •   
    • Регулярно проверяйте со своими коллегами, как можно улучшить команду. (Scrum Meeting: Retrospective Sprint )
    •   
    • Тесты должны быть FIRST - быстрые, независимые, повторяющиеся, самонастраивающиеся и своевременные.
    •   

Вышеуказанный список, безусловно, неполный, и некоторые части могут даже быть спорными!

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

См. также

Дальнейшее чтение (онлайн)

Дальнейшее чтение (книги)

  • Чистый код Robert C. Martin
  • Agile Software Development: принципы, шаблоны и практика Роберта К. Мартина.
  • Прагматический программист - от Journeyman до Master by Andrew Hunt и David Thomas.
  • Эффективная работа с устаревшим кодом Майкла Перса
  • Рефакторинг - улучшение дизайна существующего кода Мартина Фаулера
  • Рефакторинг для шаблонов Джошуа Кериевского
  • Десять дней MBA Стивена Сильбигера (sic!)
  • Проект, управляемый доменом Эриком Эвансом
  • Истории пользователей, применяемые Майком Кон
  • Объектно-ориентированный анализ и дизайн с помощью приложений Gray Booch и др.
  • Шаблоны проектирования банды четырех
  • Испытательная разработка Кент Бек
  • Экстремальное программирование Кента Бек
  • [если Java] Эффективная Java от Джошуа Блоха
ответил Christian Hujer 24 12014vEurope/Moscow11bEurope/MoscowMon, 24 Nov 2014 01:08:21 +0300 2014, 01:08:21
35

Получить Agile

Я бы предложил следующее:

Редактирование тех же файлов

Сначала используйте Git (или аналогичную параллельную систему управления версиями). Пока вы редактируете разные части тех же файлов, вы не получите конфликтов. Если вы столкнулись с конфликтами, они будут четко обозначены как таковые.

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

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

Список всех функций

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

Это должны быть видимые пользователем функции, позже вы можете поговорить о стратегии реализации.

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

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

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

Планирование покера

Пойдите в планирование покера. Все вместе со всеми дайте всем картам разработчиков, которые говорят «1 балл», «2 балла» и т. Д., До «4 балла». Также «больше». Точка примерно эквивалентна часу.

Пройдите список функций по одному. Когда вы читаете какую-либо функцию, каждый должен сыграть карту. Если один человек играет 1, а другой человек играет 4, там проблема общения. Один человек понимает, что эта функция означает нечто отличное от другого. Обсудите и обсудите то, что на самом деле означало, и обратите внимание на карту.

Если вы согласны с тем, что функция «больше», эта функция слишком велика. Вы должны сломать эту функцию. Сделайте это так же, как и раньше.

Как только у вас есть соглашение, напишите цифры на карточках в другой цветной ручке.

Точки лучше часов

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

Теперь составьте спринт

Спринт - это быстрый всплеск к цели. Определите длину спринта, возможно, 5 или 10 дней. Умножьте количество дней на количество разработчиков на количество очков в день.

Предположим, что на начальном этапе изначально выбирают 6 пунктов в день. Это достижимое число. Если у вас 5 человек, это 5 * 5 * 6 = 150 баллов. В сочетании со всеми разработчиками и руководством выберите функции из списка, до 150 пунктов. Это ваш спринт.

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

Здесь вам нужно учитывать зависимости. Например, настройка среды, очевидно, должна быть включена в первый спринт. На самом деле это относительно легко сделать, когда все присутствуют. У вас есть 6 мозгов в комнате, все говорят «это зависит от этого» и т. Д. Затем вы можете перетасовать карты вокруг, чтобы продемонстрировать зависимости.

Как только у вас будет спринт, к нему ничего не добавится, он заблокирован на 5 дней. Особенность ползучести будет подчеркивать команду, нанести урон морали и замедлить всех. В конце концов, ползучесть остановит проект. Как лидер команды вы должны защитить свою команду от ползучести функции. Если появляется новый запрос функции, он должен быть добавлен к следующему спринту. ЕСЛИ следующий спринт уже заполнен, что-то еще нужно снять.

Никогда не соблазняйтесь, чтобы втиснуться вовнутрь. Over-promising дает вам радостный клиент в течение 1 дня, а затем 4 дня стресса команды и, в конечном итоге, скорее всего, несколько несчастных клиентов, когда команда не может доставить вовремя.

Теперь перейдите к нему.

Выложите карты, спросите, кто хочет что-то делать. У вас есть полная видимость того, что делается, и вы можете подсчитать количество точек до нуля. У стойки в начале каждого дня, чтобы все знали, кто работает над тем, что и что сделано.

5 или 6 достойных мотивированных разработчиков, работающих вместе как единое целое по четко определенным управляемым целям, могут достичь довольно короткого количества вещей в 5-дневном спринте.

Поддержание видимости

Убедитесь, что каждый может видеть, каков статус проекта. Bluetack все карты к стене. Слева - карты, которые еще не обработаны. Справа сделаны карты.

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

Существуют технологические альтернативы для карточек с индексом, но ничто не сравнится с массивным бумажным отображением статуса проекта на стене.

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

Burndown

Вы можете нарисовать свои точки, направленные к нулю, на диаграмме сжигания. Если ваша линия наилучшего соответствия пересекает ноль, прежде чем вы нажмете свой лимит времени, вы, скорее всего, пойдете в путь. Если нет, вам может понадобиться сообщить об этом вашему клиенту, прежде чем вы приблизитесь к предельному сроку.

Если вы собираетесь потерпеть неудачу, провалитесь раньше.

Вы можете сделать сжигание с помощью программного обеспечения, но я предпочитаю только большой лист бумаги на стене. Нарисуйте и напишите все это.

Автоматическое тестирование

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

Модульное тестирование - это процесс написания тестов для каждой отдельной части вашей кодовой базы (в идеале каждый метод). Тестирование устройства должно выполняться часто, при каждом сохранении, если это возможно. Есть много инструментов, которые могут помочь с этим, например, Karma или Rspec.

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

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

Избегайте технического долга и сделайте это сделано

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

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

Это одна из причин, по которой мы изначально указываем только 6 баллов за разработчика, в день. Выполненный результат требует дополнительной работы, но чувствует себя прекрасно и дает команде толчок.

ответил superluminary 24 12014vEurope/Moscow11bEurope/MoscowMon, 24 Nov 2014 20:51:46 +0300 2014, 20:51:46
10

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

В основном я бы сделал, разделите проект на «функции», которые являются отдельными. Возможно, что-то связано с обработкой сетевых протоколов, а другое с конфигурационным файлом, а другое - с обработкой БД. Особенности - большие вещи.

Затем вы хотите разделить эти функции на задачи (рассказы). Это должны быть простые вещи, например «когда пользователь нажимает кнопку, программа загрузит файл», «когда программа запустится, она загрузит файл конфигурации» и т. Д.

Некоторые задачи должны быть завершены последовательно («программа будет анализировать все поля в файле конфигурации» должна появиться после того, как «программа загрузит файл конфигурации»). Другие не будут (вы можете одновременно работать с БД и сетью).

Но, скорее всего, вы сделаете это неправильно, и в этом случае возникает опыт. Вы потерпите неудачу только немного (или много), получите оценки времени неправильно, и ваш проект займет немного больше времени, чем должен был. В следующий раз вам будет лучше.

Я бы также предложил прочитать «Экстремальное программирование» Кента Бек. Отличная книга, которая помогла мне, когда я собирался стать менеджером проекта.

ответил Erez Eshkol 24 12014vEurope/Moscow11bEurope/MoscowMon, 24 Nov 2014 00:42:31 +0300 2014, 00:42:31
9

В чем дело, вам нужно разбить приложение на функциональные модули, а затем ввести контракты (интерфейсы и контракты данных) между различными модулями. Затем каждый модуль может быть передан другому разработчику. Когда вы ставите все вместе, контракты будут обеспечивать правильное взаимодействие этих модулей друг с другом.

Убедитесь, что вы применяете TDD к разработчикам, чтобы гарантировать, что все модули работают индивидуально.

Чтобы дать вам пример того, что я имею в виду:

Предположим, вы хотите, чтобы один из ваших разработчиков создал SQL-журнал.

Вы определяете интерфейс и задаете один из ваших разработчиков ( или создаете историю, если используете Agile ), что вы хотели бы использовать SQL-регистратор в соответствии со следующей спецификацией:

  интерфейс ILogger
{
    void Log (строковое сообщение, int level);
}
 

То, что я ожидаю от разработчика, следующее:

  1. Реализация SQL для журнала

      класс SqlLogger: ILogger
    {
        private readonly SqlLogRepository _logRepository;
    
        public SqlLogger (SqlLogRepository _logRepository)
        {
            this._logRepository = _logRepository;
        }
    
        public void Log (строковое сообщение, int level)
        {
            _logRepository.CreateLog (сообщение, уровень);
        }
    }
     
  2. Любой зависимый код, такой как реализация для SqlLogRepository

  3. Единичные или макетные тесты в зависимости от того, что было предложено. Фальшивый тест в вышеприведенном случае (где у нас есть другие внешние зависимости), или если это, например, простая функция утилиты, такая как String.ReverseCharacters (строковый ввод) , тогда я просто хотел бы увидеть модульные тесты, которые тестируют несколько разных сценариев.

Это означает, что:

Теперь вы и ваша команда можете продолжить разработку с использованием этого интерфейса. например

  class SomeModuleThatUsesLogging
{
    приватный readonly регистратор ILogger;

    public SomeModuleThatUsesLogging (регистратор ILogger)
    {
        this.logger = logger;
    }

    public void DeleteFiles ()
    {
        logger.Log («удаленные пользователем файлы», 1);
    }
}
 

, и если вам нужно запустить код перед тем, как SqlLogger находится на месте, вы можете просто создать NullLogger :

  класс NullLogger: ILogger
{
    public void Log (строковое сообщение, int level)
    {
    }
}
 

И вот как вы могли протестировать его тем временем (я предлагаю посмотреть на ICO для инъекций зависимостей)

  void Run ()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging (новый NullLogger ());
    someModuleThatUsesLogging.DeleteFiles ();
}
 

<сильный> Резюме

Я не имею представления о размере вашего проекта, но это может быть довольно сложной задачей, и если вы никогда раньше не делали разработку, я бы предложил, чтобы вы заняли эту задачу очень серьезно и потратили следующие несколько недель на чтение так же, как вы можете на разработку программного обеспечения и архитектор. И быть очень прозрачным о вашей работе ( качество программного обеспечения и т. Д. ), иначе вы быстро окажетесь в глубоком беспорядке, который вы не знаете, как выйти из него.

Я также настоятельно рекомендую вам ознакомиться с дизайном и объектно-ориентированной парадигмой. Вы будете сильно полагаться на ООП для этого проекта.

ответил z0mbi3 24 12014vEurope/Moscow11bEurope/MoscowMon, 24 Nov 2014 00:09:32 +0300 2014, 00:09:32
2

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

Но я должен был помочь определить задачу для лаборатории, где мне пришлось оставить 2-3 человека занятыми в течение 2-4 месяцев (неполный рабочий день и полный рабочий день). Одна вещь, которая действительно помогла мне, заключалась в использовании программного обеспечения для управления проектами, такого как Microsoft Project (я не уверен, есть ли бесплатная версия там, но у вашего работодателя, вероятно, есть что-то вроде этого ... спросите своего руководителя, какое программное обеспечение для управления программой в вашей компании). В частности, я использую диаграммы Ганта довольно немного, что является стандартным представлением в Microsoft Project. Определяя все задачи и как долго вы думаете, что они возьмут, вы можете получить визуализацию, чтобы играть.

Диаграмма Ганта помогает мне в большей степени из-за ее визуализации. Увидеть задачи на бумаге не очень помогает мне, но, видимо, довольно красивые картинки и диаграмма. Microsoft Project также позволяет вам устанавливать предшественники и начинать даты, основная идея - «Найти минимальное количество задач, которые необходимо выполнить для запуска задачи X». По крайней мере, в моих небольших проектах количество «реальных» предшественников довольно невелико. Фактически, в одном проекте у меня была проблема, что почти все можно было сделать одновременно, и пришлось синтезировать два параллельных пути, которые были несколько сплоченными. Например. Я пытался убедиться, что если разработчик A когда-либо касался графического интерфейса, они также работали над задачами, которые были близки к графическому интерфейсу.

Похоже, что вы уже много делаете это, пока ручка и бумага идут, но мне всегда очень полезно видеть графики Ганта. Глядя на задачи, выстроенные последовательно, я действительно заставляю думать: «Подождите, действительно ли нужно выполнить задачу X перед заданием Y? (По моему опыту до сих пор я был удивлен, как часто ответ на самом деле« нет »)

ответил Shaz 24 12014vEurope/Moscow11bEurope/MoscowMon, 24 Nov 2014 20:52:53 +0300 2014, 20:52:53
1

Похоже, вы закончили карьеру разработчика программного обеспечения. Поймите, что управление работой - это не упражнение по дизайну, но два идут рука об руку. Вам нужно управлять выполняемой работой, и это зависит от того, как ваша компания занимается разработкой. Если у вас есть время и ресурсы, то посмотрите на принятие гибкой методологии - в Интернете есть горы письменных материалов. Найдите тот, который работает для вас, но имейте в виду, что, как и все остальное, он не является бесплатным. Принятие любых методов предполагает обучение, обучение и неудачу, прежде чем вы преуспеете. Если у вас нет полосы пропускания, чтобы справиться с принятием более всеобъемлющего метода, то выполнение планирования этапа может быть ответом для вас. Если у вас есть список последовательных задач, возможно, вы не обнаружили последовательности, которые может распараллеливаться. Возможно также, что вы хотите сегментировать свою разработку в более общие задачи, такие как тестирование и внедрение. Это само по себе не решает проблему отчетности, но вы управляете качеством. Ваша прогрессия может быть последовательным списком, но ваши роли параллельны. Просто предложение. Дизайн, который преобразуется в работу, выполняемую людьми, называется структурой разбивки работ.

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

ответил Scott Pavetti 24 12014vEurope/Moscow11bEurope/MoscowMon, 24 Nov 2014 20:49:34 +0300 2014, 20:49:34

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132