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

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

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

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

Есть ли у вас какие-либо идеи:

1. В чем причина этого, это распространено для программистов?
2. Что я могу сделать, чтобы поддержать их в планировании? Существуют ли какие-либо методы или инструменты, которые полезны для программистов в небольших группах?

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

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

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

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

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

В небольшом магазине разработчики часто оказываются удвоенными в качестве системных администраторов, группы поддержки и даже тестеров (хотя из всего, что они могут делать, тестирование - это то, что вам следует избегать любой ценой), поэтому вам необходимо учитывать это. Выясните, сколько времени ваши разработчики фактически тратят на работу над новыми функциями, и учтите это. Если задача оценивается в 2 дня, но ваши разработчики могут работать над новой разработкой только 60% времени, вам понадобится 4 дня для ее завершения. Вы могли бы также помочь с этим, управляя конвейером других задач, которые они должны обрабатывать, так что несрочные задачи администрирования или поддержки могут несколько объединяться вместе, а не обрабатываться на разовой основе. Многие программисты (конечно, в том числе и я в этом) не являются хорошими временными менеджерами, так что все, что вы можете сделать, чтобы помочь в этом отношении, поможет. Однозадачность всегда проще для программистов, чем многозадачность. Блокировка времени в течение дня также может помочь в этом.

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

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

По какой причине [их оценка 2 дня занимает 8 дней], это часто встречается для программистов?

Это если:

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

Чтобы назвать несколько вещей.

Возможно, лучше спросить ваших разработчиков, почему они думают, что их оценки слишком далеки. :-)

Вы не станете первыми, кто попытается найти лучший способ спланировать время разработки. Частично это связано с тем, что трудно измерить количественно то, что вы не видите на самом деле, и частично из-за мифического человеко-месяца , который является прямым контрастом с интуитивной идеей, что если у вас есть 2 программиста, вы должны быть в состоянии развиваться вдвое быстрее, чем если бы у вас был 1 программист.

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

По своему личному опыту программиста я могу сказать, что это помогает разбивать проекты на этапы. Сколько времени нужно, чтобы достичь вехи 1, затем от вехи 1 до вехи 2, затем вехи 2 до вехи 3 и т. Д.? В таком случае ответ обычно гораздо точнее, чем пытаться оценить весь проект целиком. Как ни странно, если вы суммируете оценки всех этих этапов, они обычно будут больше, чем первоначальные оценки для всего проекта (если программист в любом случае честен с самим собой), что заставляет меня думать, что детали - это ключ Вот.

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

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

Надеюсь, это поможет!

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

Теперь у вас есть много возможностей из тех, что я упомяну две:

• Планирование покера
• PERT (метод оценки и анализа программ)

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

Это работает довольно хорошо в небольших гибких командах.

Выдержка из википедии:

• Модератор, который не будет играть, председательствует на собрании.
• Менеджер по продукту предоставляет краткий обзор. Команде предоставляется возможность задать вопросы и обсудить, чтобы уточнить предположения и риски. Резюме обсуждения записывается руководителем проекта.
• Каждый человек кладет карточку лицом вниз, представляя свою оценку. Используемые единицы различаются - это могут быть дни, идеальные дни или исторические моменты. Во время обсуждения цифры не должны упоминаться вообще относительно размера объекта, чтобы избежать привязки.
• Каждый звонит своим карточкам одновременно, переворачивая их.
• Людям с высокими оценками и низкими оценками дают мыльную коробку, чтобы предложить обоснование своей оценки, а затем обсуждение продолжается.
• Повторяйте процесс оценки, пока не будет достигнут консенсус. Разработчик, который, скорее всего, будет владеть конечным продуктом, получит большую часть «консенсуса», хотя модератор может договориться о консенсусе.
• Таймер яйца используется, чтобы гарантировать, что обсуждение структурировано; Модератор или менеджер проекта может в любой момент перевести таймер для яиц, и когда он закончится, все обсуждения должны прекратиться, и начнется еще один раунд покера. Структура в разговоре вновь представлена ​​мыльными коробками.

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

PERT

Часто трудно дать одну точную оценку. Что проще, так это дать вероятность. PERT использует 3 значения для оценки:

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

Взвешивая эти три оценки, вы получаете более надежную оценку.

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

И / или вы можете использовать эти три значения для построения распределения вероятностей, которое может еще больше отражать неопределенность реального мира. Бета-распределение и Треугольное распределение - выдающиеся решения. Используя это, вы теперь можете применять статистику, например, «насколько вероятно, что она закончится на дату x с учетом текущих оценок» или «Если я хочу 95% уверенности, в какой момент времени она будет завершена».

На самом деле, PERT состоит из не только упомянутых здесь аспектов, которые я пропустил для краткости.

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

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

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

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

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

-Pivotal Tracker - отличная программа для отслеживания историй и поощрения разбивочных задач, она быстро подсвечивается при вводе историй и автоматически определяет скорость. https://www.pivotaltracker.com/ .

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

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

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

Надеюсь это поможет