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

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

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

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

1. основы

   • Не ходи один . Постарайтесь как можно больше вовлекать своих товарищей по команде.
   • Путешествие легкий .
   • Демократия, но не слишком. Иногда дело не в том, что удовлетворяет наибольшее количество людей, а в том, что вредит наименьшему количеству людей.
   • Держите то, что (должно быть сделано) и как (это сделано) отдельно .
   • Узнайте о Scrum («что»), XP (экстремальное программирование, «как»), Kanban («сколько»), Lean («что не так») и DevOps («с кем»).
   • Бережливость также касается потока : для общей эффективности эффективность потока обычно более важна, чем индивидуальная эффективность.
   • Узнайте о мастерстве программного обеспечения , чистом коде и прагматическом программировании .
   • Хорошая архитектура - это максимальное количество не принятых решений .
   • Scrum / XP / Lean / Agile - это максимальный объем не выполненной работы : YAGNI .
   • Первичная стоимость программного обеспечения является то , что вы можете легко изменить его. Важно то, что он делает то, что должен, но это только его вторичная ценность.
   • Предпочитайте итеративный и инкрементальный подход, используйте временные рамки практически для всего, особенно для собраний, сделайте закон Паркинсона вашим другом, потому что применяется закон Хофштадтера .
   • Сбалансируйте структуру команды с пониманием закона Конвея и этапов развития команды Такмана .
   • Программирование - это квантизм, это наука , техника , искусство и ремесло одновременно, и они должны быть в равновесии.
   • То, что Scrum / XP / XYZ хорош для кого-то (включая меня), не обязательно означает, что он хорош для вас / подходит для вашей среды. Не слепо следуйте за обманом, сначала поймите это.
   • Осмотреть и адаптировать! (Скрам Мантра)
   • Избегайте дублирования - один раз и только один раз! (XP Mantra) aka DRY - не повторяйте себя aka SPOT - единая точка истины

2. "Какой мир" процесс разбивки работы

   • Соберите требования в виде пользовательских историй / рабочих историй в журнал ожидания продукта .
   • Пользователь (из User Story) похож на Actor (в UML) похож на Persona похож на Role .
   • Уточняйте пользовательские истории до тех пор, пока они не соответствуют определению готовности вашей команды на основе ИНВЕСТ (независимый, договорный, ценный, оценочный, малый, проверяемый). (Совещание Scrum: уточнение отставания )
   • Сортировка журнала невыполненных работ по стоимости бизнеса .
   • Не начинайте работу над историей, пока она не будет готова Готово (готово в соответствии с определением готовности).
   • Используйте Planning Poker, чтобы оценить усилия историй в очках истории . Используйте Сравнение триангуляции для обеспечения согласованности оценок.
   • Вчерашняя погода - лучшая оценка, надеюсь худшая.
   • Разделите истории, если они слишком большие.
   • Улучшите культуру доставки с помощью определения «Готово» .
   • Не принимайте реализацию пользовательского Story перед его Готово Готово (сделано в соответствии с определением Done).
   • Несколько команд в одной и той же кодовой базе должны согласовать и использовать одно и то же Определение выполненного (особенно Стандарты кодирования ).
   • Проверьте свой прогресс с Burndown Charts .
   • Регулярно проверяйте с заинтересованными сторонами, действительно ли команда предоставляет то, что действительно нужно. (Scrum Meeting: обзор спринта )

3. Разбивка истории

   • Список и описание пользователей / персонажей / актеров / ролей (владелец продукта)
   • Epic -> Stories (история пользователя или вакансии) (владелец продукта)
   • История -> Критерии приемки (Владелец продукта)
   • История -> Подзадачи (Dev Team)
   • Критерии приемки -> Приемочные испытания (Спецификация: Владелец продукта, Impl: Команда разработчиков)
   • Начните с Ходячего Скелета, который является минималистичным Сквозным (Половина) .
   • Создать MVP - минимально жизнеспособный продукт .
   • Расширьте MVP, используя SMURFS - специально предназначенные для продажи, полезные, выпускаемые наборы функций .

4. "Как мир" реализация

   • Используйте OOA / D , UML и CRC карты , но избегайте большого дизайна заранее .
   • Реализуйте объектно-ориентированный , структурированный и функциональный в максимально возможной степени, независимо от языка программирования.
   • Используйте контроль версий (желательно распределенный ).
   • Начните с приемочных испытаний .
   • Примените TDD , позволяя трем законам TDD провести вас через цикл « красный-зеленый-рефакторинг» , с одним правилом утверждения , 4 A , GWT (задано, когда) из BDD .
   • « Модульные тесты - это тесты, которые работают быстро ». - Майкл Перья
   • Примените SOLID и принципы пакета для управления сцеплением и сцеплением . Пример: S в SOLID - это SRP = принцип единой ответственности, значительно сокращает количество редактируемых операций. конфликты слияния в командах.
   • Знай закон Деметры / Скажи, не спрашивай .
   • Используйте непрерывную интеграцию , если применимо, даже непрерывную доставку (DevOps).
   • Используйте коллективное владение кодом на основе согласованного общего стандарта кодирования (который должен быть частью определения выполненного ).
   • Применить Непрерывное улучшение дизайна (fka Continuous Refactoring).
   • Исходный код - это Дизайн . Тем не менее, предварительное мышление необходимо, и никто не будет возражать против нескольких хороших уточняющих диаграмм UML.
   • XP не означает, что ни один день не является днем ​​архитектуры, это означает, что каждый день является днем ​​архитектуры. Основное внимание уделяется архитектуре, а не расфокусировке, и основное внимание уделяется коду.
   • Сохраняйте свой технический долг на низком уровне, избегайте четырех запаха дизайна Хрупкость , Жесткость , Неподвижность и Вязкость .
   • Архитектура - это бизнес-логика, а не механизмы сохранения и доставки.
   • Архитектура - командный вид спорта ( в архитектуре нет «я» ).
   • Шаблоны проектирования , рефакторинг и приоритетное преобразование .
   • Код проекта - это ATP-Trinity с приоритетами: 1. Код автоматизации , 2. Код тестирования , 3. Код производства .
   • Регулярно проверяйте со своими коллегами по команде, можно ли улучшить то, как команда выполняет поставку. (Встреча Scrum: Ретроспектива Спринта )
   • Тесты должны быть ПЕРВЫМИ - быстрыми, независимыми, повторяемыми, самоутверждающимися и своевременными.

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

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

Смотрите также

• Кто пишет технические «пользовательские истории» в Scrum

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

• Портлендский репозиторий паттернов от Ward Cunningham et al.
• Принципы ООД Роберта "Дядя Боб" К. Мартин
• Прагматичные советы программиста

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

• Чистый код Роберт С. Мартин
• Гибкая разработка программного обеспечения: принципы, шаблоны и практики Роберт К. Мартин
• Прагматичный программист - от подмастерья до мастера Эндрю Ханта и Дэвида Томаса
• Эффективная работа с устаревшим кодом от Michael Feathers
• Рефакторинг - Улучшение дизайна существующего кода Мартином Фаулером
• Рефакторинг на Узоры Джошуа Кериевского
• Десять дней MBA Стивен Силбигер (так!)
• Домен-управляемый дизайн Эрик Эванс
• Пользовательские истории, примененные Майком Коном
• Объектно-ориентированный анализ и проектирование с применением Грей Буч и др.
• Шаблоны дизайна от банды четырех
• Разработка через тестирование Кент Бек
• Экстремальное программирование от Кента Бека
• [если Java] Эффективная Java от Джошуа Блоха

Получите Agile

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

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

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

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

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

Перечислите все функции

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

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

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

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

Теперь рассортируйте свои карты по группам, перемешайте их, почувствуйте их. Это ваш проект.

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

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

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

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

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

Очки лучше, чем часы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сгореть

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

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

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

Автоматизированное тестирование

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

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

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

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

Избегать технического долга и добиваться выполнения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

interface ILogger
{
    void Log(string message, int level);
}

То, что я тогда ожидаю от разработчика, таково:

1. Специфичная реализация SQL для логгера

   class SqlLogger : ILogger
   {
       private readonly SqlLogRepository _logRepository;
   
       public SqlLogger(SqlLogRepository _logRepository)
       {
           this._logRepository = _logRepository;
       }
   
       public void Log(string message, int level)
       {
           _logRepository.CreateLog(message,level);
       }
   }
   

2. Любой зависимый код, такой как реализация для SqlLogRepository

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

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

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

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

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

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

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

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

Резюме

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

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

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

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

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

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

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

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