Как сообщить о ходе моего проекта (Agile) моему работодателю (который не является программистом)?

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

Контактное лицо:
1. Персонал, который фактически использует программное обеспечение и вызывает запросы на добавление функций,
2. Мой начальник (не программист), и она не является пользователем программного обеспечения.

Характер проекта:
это готовое программное обеспечение, приобретенное у стороннего производителя. Я должен изменить или добавить функцию / функцию к этому программному обеспечению, чтобы удовлетворить потребности отдела. Это программное обеспечение необходимо использовать в течение всего семестра. Не все функции должны быть использованы в начале.

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

Проблема:
Каждый раз, когда мой начальник спрашивал меня, как продвигается, я не могу ответить, потому что я не знаю, как ответить. У меня нет полного списка всех необходимых функций. Несмотря на то, что я выполнил функции, которые были подняты на прошлой неделе, я все еще не могу сказать своему боссу, что я «выполнил», потому что появляются новые функции, и я не знаю, сколько. Я не могу сказать «у нас есть сколько% завершения» или «мы собираемся завершить его к ххх». Иногда из 3 запросов мне удается выполнить 2, я бы сказал своему боссу: «Я выполнил 2, но есть еще одна функция, которая еще не завершена». По прошествии длительного времени я звучу так: «У меня всегда есть что-то не законченное, после стольких лет».

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

Ребята, у вас есть идея, как сообщить или ответить на вопрос так же просто, как "каков статус / ход модификации программного обеспечения"?

ОБНОВЛЕНИЕ Мой начальник не занимается непосредственно разработкой, поэтому она не имеет ни малейшего представления о том, что я делаю, или как работает программа. Мы не встречаемся регулярно, так как она занята, и я чувствую, что это будет пустая трата времени, потому что она не является основным пользователем, она не знает деталей программы.

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

Мне трудно объяснить прогресс моему боссу.

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

Боссы, как это, в основном хотят иметь возможность понять несколько вещей:

• Насколько счастливы пользователи?
• Что хотят сделать пользователи?
• Стоит ли то, что вы делаете, денег, которые вам платят?

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

Так что на вашем месте я бы отправлял им по электронной почте отчет раз в неделю, содержащий:

• «Резюме» в начале: «На этой неделе завершено 3 функции и получено 2 новых запроса на функции. В начале этой недели было 11 незавершенных запросов на функции, а в конце их было 10».
• Список статусов объектов с кратким предложением в трех группах:
  1. Функции, которые вы сделали за неделю
  2. Запросы функций, поступившие в течение недели
  3. Другие функции в «отставании»
• Краткое обсуждение всего, что было сложным или необычным, желательно с использованием нетехнического языка.

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

Похоже, у вас нет возможности узнать, завершены ли вы или как далеко вы дошли до завершения. Это нормально.

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

• Неделя 1 - 2 завершена
• Неделя 2 - 5 завершена (2 недели 1, 3 недели 2)
• Неделя 3 - 8
• Неделя 4 - 12

Если у вас есть 16 недель, вы можете выполнить около 48 функций (не беспокойтесь о том, что некоторые функции будут больше / меньше, чем другие, через 4-5 недель они будут в среднем усреднены). Затем вы можете сообщить всем, что вы можете обрабатывать только X функций. В конце проекта самое главное, что вы предоставили необходимые функции и не убивали себя в течение последних двух недель. Сообщая об этом, вы можете как можно быстрее вывести ключевые требования.

Другая вещь, о которой вы захотите сообщить, - это сколько у вас возможностей. «Я получил только 2 запроса на новые функции, но мог бы обработать 3 ... Можете ли вы попросить сотрудников поднять больше функций раньше?»

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

Три слова ... сжечь таблицу.

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

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

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

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

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

Капитальный ремонт базы данных, занимающий несколько недель, может быть разбит примерно так: создание резервных копий, проверка резервных копий - это хорошо, разработка нового макета базы данных, написание программного обеспечения для преобразования и его тестирование, настройка отката и тестирования, проверка преобразования на постановочная машина, пытаясь выполнить откат на том же месте, а затем, наконец, выполнить преобразование. Каждый из них, вероятно, может быть разбит на 1-недельные (или менее) куски. Если некоторые шаги могут занять 2 или 3 недели, вы сообщите, как далеко вы продвинулись на следующей встрече (нацеливание на 50% на 2 недели, на 33% на 3 недели и т. Д.).

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

Раз в неделю (я предполагаю, что продолжительность итерации / спринта в вашем гибком процессе для примера составляет одну неделю), делайте следующее :

• демонстрация новой работы для персонала, чтобы убедиться, что их запросы были выполнены
• сообщите боссу количество запросов, выполненных вами в течение недели, и определите / опишите эти запросы. Сделайте краткое резюме
• сообщить начальнику о количестве новых запросов, добавленных в вашу очередь / очередь в течение недели, и об общем количестве запросов
• сообщите боссу, над какими (какими запросами) вы планируете работать на следующей неделе; другими словами, текущие приоритеты. У нее есть возможность подтвердить или изменить их, а вам обоим -
• расскажите боссу, каков план на 1-2 недели после этого.

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

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

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

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

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

Total Recieved Feature Requests:
Requests Completed:
Requests since last Update:
Estimated Time to required to complete remaining Requests:

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