Как справиться с гибкой разработкой, когда команда не стабильна? [закрытый]
Определенно хороший список. Вот несколько мыслей о нем:
Запись тест сначала, тогда код.
я соглашаюсь на высоком уровне. Но, я был бы более конкретным: "Запишите тест сначала, затем запишите как раз код, чтобы пройти тест и повторение". Иначе я боялся бы, что мои модульные тесты будут больше походить на интеграцию или приемочные испытания.
классы Дизайна с помощью внедрения зависимости.
Согласованный. Когда объект создает свои собственные зависимости, Вы не имеете никакого контроля над ними. Инверсия Управления / Внедрение зависимости дает Вам что контроль, позволяя Вам изолировать объект под тестом с насмешками/тупиками/и т.д. Это - то, как Вы тестируете объекты в изоляции.
Отдельный код UI от его поведения с помощью Образцового Контроллера Представления или Образцового Предъявителя Представления.
Согласованный. Обратите внимание, что даже предъявитель/контроллер может быть протестирован с помощью DI/МОК, путем вручения его блокировал/дразнил представление и модель. Выезд Предъявитель Сначала TDD для больше на этом.
не пишут статические методы или классы.
Не уверенный я соглашаюсь с этим. Это возможно к модульному тесту статический метод / класс, не используя насмешки. Так, возможно, это - один из тех Насмешка Носорога определенные правила, которые Вы упомянули.
Программа от интерфейсов, не классы.
я соглашаюсь, но по немного отличающейся причине. Интерфейсы обеспечивают большую гибкость разработчику программного обеспечения - вне просто поддержки различных платформ фиктивного объекта. Например, не возможно поддерживать DI правильно без интерфейсов.
Изолируют внешние зависимости.
Согласованный. Скройте внешние зависимости позади своего собственного фасада или адаптера (как соответствующие) с интерфейсом. Это позволит Вам изолировать свое программное обеспечение от внешней зависимости, быть им веб-сервис, очередь, база данных или что-то еще. Это особенно важно, когда Ваша команда не управляет зависимостью (иначе внешний).
Mark как виртуальный методы Вы намереваетесь дразнить.
Это - ограничение Насмешек Носорога. В среде, которая предпочитает, рука кодировала тупики по платформе фиктивного объекта, которая не будет необходима.
И, несколько новых вопросов для рассмотрения:
Использование creational шаблоны разработки. Это поможет с DI, но он также позволяет Вам изолировать тот код и тестировать его независимо от другой логики.
Тесты записи с помощью метод Расположения/Закона/Утверждать Следа счета . Эта техника делает его очень ясным, какая конфигурация необходима, что на самом деле тестируется, и что ожидается.
не боятся к насмешкам/тупикам самокрутки. Часто, Вы найдете, что использование платформ фиктивного объекта делает Ваши тесты невероятно трудно для чтения. Путем прокрутки собственного Вы будете иметь полный контроль над своими насмешками/тупиками, и Вы будете в состоянии сохранить свои тесты читаемыми. (Вернитесь к предыдущей точке.)
Избегают искушения осуществить рефакторинг дублирование из Ваших модульных тестов в абстрактные базовые классы или методы установки/разрушения. Выполнение так скрывает код конфигурации/очищать от разработчика, пробующего к grok модульный тест. В этом случае ясность каждого отдельного теста более важна, чем рефакторинг дублирования.
Реализация Непрерывная Интеграция. Регистрация Ваш код каждой "зеленой панели". Создайте свое программное обеспечение и выполните Ваш полный комплект модульных тестов на каждой регистрации. (Несомненно, это не практика кодирования по сути; но это - невероятный инструмент для того, чтобы содержать Ваше программное обеспечение в чистоте и полностью интегрированный.)
7 ответов
Исходя из вопроса, я предполагаю, что у вас есть разработчики (вероятно, 2) 100% привержены проекту, а некоторые (еще 2-3) участвуют только время от времени.
Одна вещь, которую вы можете сделать, - это установить разные процессы для основных разработчиков, которые на 100% привержены, и для всех остальных. Используйте обычный гибкий процесс для основных сотрудников и выпускайте их работу в рамках обычного цикла итераций. Для непрофильных людей мало планируйте и предполагайте, что их (и ваши) оценки время от времени будут ошибочными. В идеале их изменения должны быть изолированы и объединены в стабильную ветвь кода основными участниками, но не все архитектуры проекта и командные роли позволяют это.
Суть в том, чтобы отделить и изолировать источник хаоса и оставить сердце проекта и команды не затронуты.
Используйте обычный гибкий процесс для основных сотрудников и выпускайте их работу в рамках обычного цикла итераций. Для непрофильных людей мало планируйте и предполагайте, что их (и ваши) оценки время от времени будут ошибочными. В идеале их изменения должны быть изолированы и объединены в стабильную ветвь кода основными участниками, но не все архитектуры проекта и командные роли позволяют это.Суть в том, чтобы отделить и изолировать источник хаоса и оставить сердце проекта и команды не затронуты.
Используйте обычный гибкий процесс для основных сотрудников и выпускайте их работу в рамках обычного цикла итераций. Для непрофильных людей мало планируйте и предполагайте, что их (и ваши) оценки время от времени будут ошибочными. В идеале их изменения должны быть изолированы и объединены в стабильную ветвь кода основными участниками, но не все архитектуры проекта и командные роли позволяют это.Суть в том, чтобы отделить и изолировать источник хаоса и оставить сердце проекта и команды не затронуты.
Возможно, вместо гибких подходов вы можете замедлить работу с помощью других итеративных и инкрементных подходов . Вместо того, чтобы измерять итерации неделями, было бы лучше иметь более длинные итерации (возможно, в месяцах), если бы вы продолжали добавлять и исключать людей из команды.
Это не означает, что вы все еще не можете использовать некоторые методы Agile. Я бы по-прежнему поддерживал ваши Backlogs и выжигал графики, понимая, что вместо выпуска каждые 2 недели вы будете выпускать каждые 6 недель (~ 2 месяца). Если у вас есть новые разработчики, присоединяющиеся к более опытным разработчикам, используйте парное программирование, поручайте новым разработчикам исправлять ошибки или поручите новым разработчикам поддерживать модульные тесты, чтобы помочь им изучить кодовую базу.
Скорость - это только оценка.
Наивно, если у вас есть заданная скорость v с командой из 4 разработчиков, то запланируйте вашу итерацию со скоростью (v / 4) * number_of_developers
Вы можете изменить это значение, если участники, которых вы теряете, особенно сильнее или слабее среднего.
В основном это то, что PivotalTracker делает со своей командой показатель прочности.
Пусть отдельный разработчик, который будет работать над историей, оценит усилия, необходимые для завершения истории. Вы можете принять во внимание исторические различия в оценках этого разработчика, но идея состоит в том, что вы можете взять их оценки, а затем выяснить, сколько историй вы сможете закончить в этом спринте.
Не забывайте, что средняя скорость в основном используется для предварительного планирования выпуска; команда отвечает за выбор на каждой итерации , сколько элементов невыполненной работы нужно выполнить (хотя знание исторической скорости может помочь им).
Если размер вашей команды (и, следовательно, скорость) колеблется от итерации к итерации, вы все равно можете выполнять полезное планирование выпуска, используя средние скорости за последние N спринтов, предполагая, что колебания команды будут продолжаться и, следовательно, их долгосрочная средняя скорость будет фактически стабильной.
Ваша основная проблема здесь в том, что команде будет трудно давать предсказуемые оценки и поставки, поскольку команда меняется от спринта к спринту. Это также может повредить приверженности команды и постоянному совершенствованию.
Этот случай может действительно хорошо подходить для подхода Канбан. Ознакомьтесь с введением Хенрика Книбергса в Канбан, чтобы получить краткий обзор.
Удачи!
So, you have a project with a continually changing team size and your boss wants you to give him an accurate estimate of how long it will take? You can do this, as long as you keep in mind the difference between accurate and precise. Your precision will depend largely on the number of items and how granular (decomposed) each item is; the more items you have the more the Law of Large Numbers works for you, averaging out over- and underestimates.
Your accuracy is a function of confidence. Note that estimates aren't single-point values, they're a range with numbers with a percentage of confidence. For instance, a proper estimate wouldn't be "2 weeks" it would be "50% confidence of 2 weeks, 80% confidence of 4 weeks."
If I were the person assigned with the unenviable task of providing an estimate to completion for a project being managed as arbitrarily as in the original post, I'd try to figure out a range based upon the minimum number of folks assigned (e.g., "48 to 66 weeks given 2 developers [50% to 80% confident]"), and a range associated with the average number of folks assigned (e.g., "25 to 45 weeks with 5 developers [50% to 80% confident]"), and use the low figure from the average number along with the high figure from the minimum number (e.g., "25 to 66 weeks given anywhere from 2 to 5 developers [50% to 80% confident]"), and even then I'd put a disclaimer on it ("plus 10% for the lost time due to context switching").
Better yet, I'd explain exactly why this arrangement was, to be polite, sub-optimal, and why multi-tasking is a primary signpost on the road to project Hell.
As someone else suggested, changing the workflow from iteration-based to flow-based (Kanban) might well be a good strategy. With Kanban you handle changing project priorities by changing the priority of items in the backlog; once an item has been grabbed by the team it is generally finished (flows all of the way through the workflow, stakeholders aren't allowed to disrupt the team by screwing around with work-in-progress). I've used Kanban for sustained engineering projects and it worked very well. Re how it would help with estimates, the key to continuous flow is to try to have each work item be roughly the same size (1x, 2x, 3x, not 10x, 20x, 100x). You should track movement of items through the workflow by tracking dates of process state changes, e.g., Queue 1/15, Design 1/22, Dev 1/24, Test 2/4, Integrate 2/7, etc., and then generating a cumulative flow diagram regularly to evaluate the time-in-state durations over time. Working out how long the project should take given that you know the size of each item and the time through the workflow for items is a trivial computational exercise left to the reader. (The more interesting question is how to spot constraints... and then how to remove them. Hint: look for long times in states, because work piles up in front of constraints.)