Як повідомити про хід свого проекту (Agile) своєму роботодавцю (який не є програмістом)?

У мене є проблема з повідомленням про прогрес своєму роботодавцю. Я програміст за сумісництвом і займаюся програмним проектом для моєї школи (нетехнічного) відділу.

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

Характер проекту:
Це готове програмне забезпечення, яке було закуплено у сторонньої сторони. Я повинен змінити або додати функцію / функцію до цього програмного забезпечення, щоб задовольнити потреби відділу. Це програмне забезпечення потрібно використовувати протягом семестру. Не всі функції потрібно використовувати на початку.

Отже, ми використовуємо модель Agile: Коли персонал потребує певної функції, вони подають запит, і я вношу зміни. До кінця семестру, я думаю, всі необхідні функції будуть підняті та впроваджені.

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

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

У вас, хлопці, є ідея, як звітувати або відповісти на запитання так просто, як "який стан / хід модифікації програмного забезпечення"?

ОНОВЛЕННЯ Мій начальник не бере участі у розробці завдань безпосередньо, тому вона не має поняття, що я роблю, або як працює програма. Ми не зустрічаємось регулярно, оскільки вона зайнята, і я вважаю, що це буде марною тратою часу, оскільки вона не є головним користувачем, вона не знає деталей програми.

Я регулярно зустрічаюся з персоналом, який використовує та краще знає програмне забезпечення.

Мені важко пояснити прогрес своєму начальнику.

Це поширена проблема, коли ви програміст, який працює самостійно, і ви доповідаєте тому, хто не має технічних питань.

Такі боси в основному хочуть зрозуміти кілька речей:

• Наскільки щасливі користувачі?
• Чи користувачі хочуть зробити це?
• Це те, що ти робиш, коштує тих грошей, які тобі платять?

Agile вигорання або щось подібне було б жахливою ідеєю! Як ви вже сказали, ваш начальник справді зайнятий, тому вони не встигли б дізнатися про це, і, ймовірно, це все одно не цікавить.

Тож якби я був ти, я раз на тиждень надсилав би їм звіт, що містить:

• "Короткий підсумок" на початку: "На цьому тижні завершено 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 ... чи можете ви попросити співробітників швидше підняти більше функцій?"

не впевнений, що я повністю відповів на ваше запитання, тому не соромтесь задавати подальші запитання ...

Три слова ... спалити діаграму.

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

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

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

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

Зауважте, що у справжньому гнучкому процесі у вас дійсно постійно з’являються речі, але ви та ваш менеджер погоджуєтесь, що найважливіше / найнеобхідніше та скільки його вміститься у поточному робочому періоді (чи це тиждень, два тижні, місяць ...), розбивши роботу на більш дрібні шматочки, якщо це потрібно, щоб шматки вписалися в період.

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

В ідеалі у вас є діаграма, у якій є речі, які вам потрібно зробити, порівняно з речами, які ви збираєтеся робити зараз, і ви б перевіряли елементи "робити зараз", як ви йдете разом. Це дозволяє вашому менеджеру просто пройти і побачити, скільки речей відмічено проти речей, які є в списку.

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

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

Я відчуваю, що ваш начальник недостатньо технічний, щоб доглядати або розуміти спритні терміни, такі як швидкість , власник продукту або діаграма прогону . Наведений вище шаблон уникає подібного жаргону, використовує простіші слова, як "відставання" та "черга" у їх здоровому розумінні, і, таким чином, має полегшити спілкування зі своїм начальником.

Я використовував би свою швидкість як основну статистику для нього / неї. Це покаже, скільки завдань / функцій я "погодився" поговорити за певний тиждень (або інший проміжок часу) і скільки я виконав. З цього моменту я зазначив би деякі важливіші функції програм, і чому це змінилося від минулих ітерацій. Ви також можете згадати будь-які перешкоди, з якими ви стикалися та перевершували, і як це впливало на вашу швидкість.

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

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

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

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

Тільки тому, що ваш менеджер не є програмістом, не думайте, що це означає, що вони очікують від вас точної дати завершення. Представте свої номери. Після того, як менеджер бачить кількість отриманих запитів і завершений підйом, менеджер бачить прогрес. Якщо ваші номери запитів виходять з рук, менеджер може вступити і допомогти вам, визначивши пріоритет перед тим, як перевантажуватись. І якщо у вас не вистачає роботи, вони можуть знайти вам невеликий побічний проект. Зрештою, завжди приємно трохи перервати проект, коли, здається, немає кінця в поле зору, а робочі дні проходять швидше і отримують більше користі, коли ти зайнятий.