Laporan projek interaktif bersama Jira dan LLM

Untuk semua projek yang saya kerjakan, saya menggunakan sejenis sistem pengurusan projek di mana skop projek ditakrifkan sebagai senarai tugasan (tiket) dan kemajuan dilaporkan dengan menukar status tugas.

Walaupun sistem pengurusan projek sedemikian menawarkan pelbagai papan pemuka dan laporan, mentafsir senarai panjang tugas dengan tajuk samar yang dicipta oleh jurutera bukanlah perkara remeh. Untuk memberikan ketelusan untuk penaja dan pelanggan projek, saya terpaksa membuat laporan projek secara manual dan kemudian menjawab soalan berkaitan.

Bagaimana jika sebaliknya kami meminta bantuan LLM? Ideanya mudah: ambil semua tugasan projek dan suapkannya kepada LLM yang meminta laporan itu. Kemudian mulakan sembang membenarkan soalan lanjut.

Mengumpul data

Kami akan menggunakan Jira untuk percubaan ini kerana ia adalah alat yang popular dengan API REST yang mudah digunakan. Projek contoh, yang mana kami akan membuat laporan, adalah sangat teknikal - ini mengenai mencipta skrip binaan yang boleh mengesan perkara yang digunakan oleh kod dan menjana arahan yang diperlukan untuk sistem binaan. Projek sedemikian pastinya akan mempunyai tugas teknikal dengan tajuk samar.

Mari kita mulakan dengan mengambil tugasan. Projek dalam persediaan contoh diwakili sebagai tiket ibu bapa tunggal (epik) dengan senarai tiket kanak-kanak (tugas). Untuk setiap tugasan, kami akan mengambil sejarah penuh untuk melihat bagaimana status tiket berubah dari semasa ke semasa. Menggunakan klien Jira Python pelaksanaannya adalah mudah. Perhatikan dalam tatanama Jira istilah isu digunakan dan bukannya tiket yang ditunjukkan dalam kod.

jira = JIRA(server=os.environ["JIRA_SERVER"], basic_auth=(os.environ["JIRA_USER"], os.environ["JIRA_TOKEN"]))

def fetch_issues(epic_key):
    issues = []
    print("Loading epic data...", end="", flush=True)
    issues.append(jira.issue(epic_key))
    print("done")

    print("Loading tasks...", end="", flush=True)
    child_issues = jira.search_issues(f"parent = {epic_key}")
    for issue in child_issues:
        issues.append(jira.issue(issue.key, expand="changelog"))
    print("done")

    return issues

Memandangkan mengambil semua tiket dengan sejarah mengambil sedikit masa, adalah berguna untuk menyimpan data ini secara setempat untuk percubaan selanjutnya. Semasa bermain dengan pelaksanaan, saya menggunakan fungsi di bawah untuk menyimpan tugasan dan memuatkannya daripada fail:

def save_issues(filename, issues):  
    with open(filename, "x") as file:
        file.write("[")
        file.write(",".join(
            json.dumps(issue.raw) for issue in issues))
        file.write("]")

def load_issues(filename):
    with open(filename, "r") as file:
        data = json.load(file)
        return [Issue(jira._options, jira._session, raw=raw_issue)
            for raw_issue in data]

Menyediakan data

Langkah seterusnya ialah menyediakan data untuk LLM. Data Jira mentah dalam format JSON agak bertele-tele, kami tidak memerlukan semua medan tambahan ini. Mari keluarkan maklumat asas: subjek, perihalan, jenis, status dan tarikh penciptaan. Daripada sejarah, kami hanya akan mengekstrak perubahan status tiket bersama-sama dengan tarikh dan pengarangnya, mengabaikan perubahan pada medan lain.

Semua maklumat ini akan disimpan sebagai teks biasa. Saya telah melihat orang menggunakan JSON atau XML sebagai input LLM, tetapi pemerhatian saya ialah LLM sangat baik dalam mentafsir data teks biasa. Selain itu dengan pendekatan ini, saya tidak perlu risau tentang memformat medan teks agar serasi dengan JSON atau XML. Satu-satunya pemprosesan yang saya lakukan ialah menanggalkan baris kosong daripada huraian, dan sebab utama adalah untuk memudahkan saya melihat hasil.

def strip_empty_lines(s):
    return "".join(line for line in (s or "").splitlines() if line.strip())

def issue_to_str(issue):
    return f"""
{issue.fields.issuetype}: {issue.key}
Summary: {issue.fields.summary}
Description: {strip_empty_lines(issue.fields.description)}
Type: {issue.fields.issuetype}
Status: {issue.fields.status}
Created: {issue.fields.created}
Priority: {issue.fields.priority}
"""

def changelog_to_str(changelog, changeitem):
    return f"""
Author: {changelog.author.displayName}
Date: {changelog.created}
Status change from: {changeitem.fromString} to: {changeitem.toString}
"""


def history_to_str(issue):
    if issue.changelog is None or issue.changelog.total == 0:
        return ""
    history_description = ""
    for changelog in issue.changelog.histories:
        try:
            statuschange = next(filter(lambda i: i.field == "status", changelog.items))
            history_description += changelog_to_str(changelog, statuschange)
        except StopIteration:
            pass
    return history_description

#this function assumes the first issue is an epic followed by tasks.
def describe_issues(issues):
    description = "Project details:"
    description += issue_to_str(issues[0])
    description += "\nProject tasks:"
    for issue in issues[1:]:
        description += "\n" + issue_to_str(issue)
        description += f"History of changes for task {issue.key}:"
        description += history_to_str(issue)
    return description

Epik yang saya gunakan untuk percubaan ini mempunyai 30 tugasan yang mempunyai antara 1 dan 15 perubahan status dalam sejarahnya. Saya tidak akan memetik output penuh fungsi describe_issues, tetapi untuk memberi anda gambaran tentang penampilannya di sini ialah petikan ringkas:

Project details:
Epic: TKT-642
Summary: Create universal build script
Description: 
Type: Epic
Status: In Development
Created: 2024-05-24T10:48:33.050+0200
Priority: P4 - Low

Project tasks:

Task: TKT-805
Summary: add test reporting for e2e tests
Description: 
Type: Task
Status: In Progress
Created: 2024-09-06T09:56:33.919+0200
Priority: P4 - Low
History of changes for task TKT-805:
Author: Jane Doe
Date: 2024-09-06T10:04:15.325+0200
Status change from: To Do to: In Progress

Task: TKT-801
Summary: Sonar detection
Description: * add sonar config file detection *
Type: Task
Status: In Progress
Created: 2024-08-30T13:57:44.364+0200
Priority: P4 - Low
History of changes for task TKT-801:
Author: Jane Doe
Date: 2024-08-30T13:57:58.450+0200
Status change from: To Do to: In Progress

Task: TKT-799
Summary: Add check_tests step
Description: 
Type: Task
Status: Review
Created: 2024-08-29T18:33:52.268+0200
Priority: P4 - Low
History of changes for task TKT-799:
Author: Jane Doe
Date: 2024-08-29T18:40:35.305+0200
Status change from: In Progress to: Review
Author: Jane Doe
Date: 2024-08-29T18:33:57.095+0200
Status change from: To Do to: In Progress

Mendorong

Gesaan yang akan kami gunakan terdiri daripada dua bahagian. Pertama, ia memberikan arahan untuk membuat laporan, memperincikan maklumat khusus yang kami mahukan dalam laporan itu. Kemudian kami memasukkan maklumat tiket yang disediakan dalam perenggan sebelumnya. LLM cenderung untuk memberikan respons yang bertele-tele, jadi kami meminta secara khusus untuk tidak menambah sebarang penjelasan tambahan. Memandangkan percubaan dilakukan dalam terminal, kami juga akan meminta untuk membuat terminal respons secara mesra.

def create_prompt(isses_description):
    return f"""
    Using below information from jira generate executive report that focuses on what was done and what is remaining.
    Provide project progress information. Point out problematic tasks and what may be wrong.
    Use status change history to point out tasks that were worked on for too long or have been reopened many times. 
    Check if you can detect other problems from tasks or their history.
    Provide only text content that can be displayed on terminal, without any additional explanation or markdown.
    {isses_description}
    """

LLM yang saya gunakan untuk eksperimen ini ialah Anthropic's Claude 3.5 Sonnet. Selain menghantar mesej gesaan, kami juga akan menentukan identiti. Identiti hanya boleh ditambah sebagai baris lain pada permulaan gesaan, tetapi memandangkan rancangannya adalah untuk membuat susulan dengan soalan (buat sembang interaktif), dokumentasi Claude mengesyorkan menetapkan identiti sebagai parameter sistem yang berasingan dalam senario sedemikian.

def send_messages(messages):
    client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_KEY"])
    identity = "You are a seasoned IT program manager. You have very good communication skills, your answers are concise and focus on key insights."
    message = client.messages.create(
        system=identity,
        max_tokens=2048,
        messages=messages,
        model="claude-3-5-sonnet-20240620"
    )
    return message.content[0].text

def generate_report(prompt):
    messages=[
        {
            "role": "user",
            "content": prompt 
        }]
    return send_messages(messages)

Mari kita satukan ini dan jalankan:

if __name__=="__main__":
    issues = fetch_issues('TKT-642')
    descrption = describe_issues(issues)
    prompt = create_prompt(description)
    report = generate_report(prompt)
    print(report)

Di bawah ialah laporan penuh yang saya terima daripada Claude:

Laporan Eksekutif: Projek Skrip Binaan Universal (TKT-642)

Kemajuan Projek:

• 11 daripada 24 tugasan telah selesai (45.8%)
• 5 tugasan sedang dijalankan atau semakan (20.8%)
• 8 tugasan masih perlu dimulakan (33.3%)

Pencapaian Utama:

1. Mencipta templat jinja prototaip untuk pembina
2. Pelanjutan dan pengesahan konfigurasi yang dilaksanakan
3. Langkah pelaksanaan ujian unit tambahan
4. Sokongan bersepadu untuk pengimbasan sonar
5. Imej yang dicipta untuk membina skrip konfigurasi dan teknologi

Sedang Berlangsung:

• Menambah pelaporan ujian untuk ujian e2e
• Melaksanakan logik penapisan untuk persekitaran dan pengesanan Sonar
• Membangunkan dokumentasi pembangun

Kawasan Bermasalah:

1. Task TKT-734 (Add config extension) went through multiple status changes, indicating potential issues or complexity.
2. Task TKT-697 (Add support for sonar scanning) has been reopened multiple times, suggesting implementation challenges.
3. Task TKT-715 (Create developer documentation) has been in progress for an extended period without completion.

Upcoming Work:

• Integration of the build system into various services (authentication, database-api, shopping-cart, reporting, localization)
• Adding support for monorepos and custom jobs
• Creating user documentation

Recommendations:

1. Review the implementation of config extension and sonar scanning to address recurring issues.
2. Prioritize the completion of developer documentation to support team adoption.
3. Begin planning for the integration of the build system into remaining services.
4. Consider reassessing the priority of tasks that have remained in the "To Do" state for an extended period.

Overall, the project is making steady progress, with nearly half of the tasks completed. However, attention should be given to resolving recurring issues and completing in-progress tasks to maintain momentum.

The result is quite good. It did miscount tickets - in various runs I did it gave me a different number, but never a correct number of 30. Well, LLMs are known for not being able to count r's in the word strawberry. But the summary is correct, recommendations are also reasonable.

Asking questions

Now let's create an interactive session and ask some questions. We'll start with a pre-defined question which is the original prompt we used to generate the report. Then we will read the user's input and attach it to messages. Each response, along with the report is also recorded in the messages chain.

def interactive_session(prompt):
    messages = []
    user_input = prompt
    while user_input != "exit":
        messages.append({
            "role" : "user",
            "content" : user_input
        })
        response = send_messages(messages)
        print(response)
        messages.append({
            "role" : "assistant",
            "content" : response
        })
        user_input = input("QUESTION: ")
    return messages

To run this, just replace generate_report in the main section of the script with interactive_session. Below is a recording of an example session I did. I omitted from the quote the first response which just prints out the report.

QUESTION: how many engineers the team counts?

Based on the information provided in the task histories, I can identify at least three distinct engineers working on this project:

1. John Smith
2. Jane Doe
3. Mike Carpenter

These three names appear frequently in the status change histories for various tasks. However, it's important to note that this may not represent the full team size. There could be other team members who haven't made changes recorded in these specific task histories, or who are involved in the project in other capacities not reflected in this data.

To get an accurate count of the team size, you would need additional information beyond what's provided in these task histories.

QUESTION: is unit test execution task done yet?

Yes, the unit test execution task is completed. Specifically, task TKT-700 with the summary "Add unit tests execution step" is marked as Done. Here's the relevant information:

Task: TKT-700
Summary: Add unit tests execution step
Status: Done

The history of changes for this task shows that it was moved to "Done" status on 2024-08-02, after going through the typical workflow stages (To Do -> In Progress -> Review -> PREPROD VERIFICATION -> READY FOR PRODUCTION -> Done).

QUESTION: does the scope include running some sort of static code analysis tool?

Yes, the project scope includes running static code analysis. Specifically, there's a task for implementing Sonar scanning, which is a popular static code analysis tool. Here are the details:

Task: TKT-697
Summary: Add support for sonar scanning
Status: Done

This task was completed and moved to "Done" status on 2024-09-02. The implementation of Sonar scanning indicates that static code analysis is part of the universal build script project.

Additionally, there's another related task that's currently in progress:

Task: TKT-801
Summary: Sonar detection
Status: In Progress

This task mentions "sonar detection" in its summary, which further confirms that Sonar (a static analysis tool) is being integrated into the build process.

These tasks demonstrate that static code analysis, particularly using Sonar, is included in the project scope and has been largely implemented.

QUESTION: what are the 3 biggest risks of the project?

Based on the provided information, the three biggest risks for this project appear to be:

1. Kelewatan Penyepaduan:
   Beberapa tugas untuk menyepadukan sistem binaan ke dalam pelbagai perkhidmatan (penyetempatan, pelaporan, troli beli-belah, pengesahan, API pangkalan data) masih dalam status "Untuk Dilakukan". Ini menimbulkan risiko kelewatan dalam penggunaan meluas skrip binaan universal merentas perkhidmatan yang berbeza. Kegagalan untuk menyepadukan semua perkhidmatan yang dimaksudkan boleh mengehadkan kesan dan nilai keseluruhan projek.

2. Selang Dokumentasi:
   Tugas untuk membuat dokumentasi pembangun (TKT-715) baru-baru ini telah dialihkan kepada "Sedang Dilaksanakan" selepas berada dalam "Untuk Dilakukan" untuk tempoh yang panjang. Selain itu, tugas dokumentasi pengguna (TKT-714) masih dalam status "Untuk Dilakukan". Kelewatan dalam penciptaan dokumentasi ini berisiko menghalang penggunaan, penggunaan yang betul dan penyelenggaraan sistem binaan baharu. Ia boleh menyebabkan penyalahgunaan, ketidakcekapan atau penentangan terhadap penerimaan kerana kekurangan panduan yang jelas.

3. Kerumitan dalam Pelaksanaan:
   Beberapa tugasan, terutamanya yang berkaitan dengan pengimbasan Sonar (TKT-697) dan sambungan konfigurasi (TKT-734), telah menunjukkan berbilang perubahan status antara "Sedang Berlangsung" dan "Semakan". Corak ini mencadangkan potensi cabaran teknikal atau ketidakpastian dalam pelaksanaan. Terdapat risiko bahawa kerumitan ini boleh membawa kepada pepijat, isu prestasi atau masalah penyelenggaraan pada masa hadapan jika tidak diselesaikan dengan betul.

Risiko ini berpotensi memberi kesan kepada garis masa projek, kadar penerimaan dan kejayaan keseluruhan jika tidak diurus dan dikurangkan dengan betul.

Itu sangat bagus. Saya suka fakta LLM menggunakan pengetahuan generik sebagai tambahan kepada data segera, jadi ia dapat menjawab soalan tentang "alat analisis kod statik" walaupun tiada data tiket menyebut istilah tersebut. Jawapannya agak terlalu bertele-tele, lebih banyak percubaan dengan gesaan diperlukan - mungkin menambahkan arahan pada pertanyaan setiap pengguna akan membantu membentuk jawapan yang lebih baik.
Isu seperti salah mengira tiket sepatutnya mudah diselesaikan, kami boleh mengira statistik asas dan memasukkannya dalam gesaan itu sendiri.

Atas ialah kandungan terperinci Laporan projek interaktif bersama Jira dan LLM. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!