Jira 및 LLM을 사용한 대화형 프로젝트 보고서

내가 작업한 모든 프로젝트에는 프로젝트 범위가 작업 목록(티켓)으로 정의되고 작업 상태 변경을 통해 진행 상황이 보고되는 일종의 프로젝트 관리 시스템을 사용했습니다.

이러한 프로젝트 관리 시스템은 다양한 대시보드와 보고서를 제공하지만 엔지니어가 만든 비밀스러운 제목이 포함된 긴 작업 목록을 해석하는 것은 결코 쉬운 일이 아닙니다. 프로젝트 후원자와 고객에게 투명성을 제공하기 위해 프로젝트 보고서를 수동으로 작성한 후 관련 질문에 답변해야 했습니다.

그 대신 LLM에 도움을 요청하면 어떻게 될까요? 아이디어는 간단합니다. 모든 프로젝트 작업을 가져와 보고서를 요청하는 LLM에 제공합니다. 그런 다음 추가 질문이 가능한 채팅을 시작하세요.

데이터 수집

사용하기 쉬운 REST API를 갖춘 인기 도구인 Jira를 이 실험에 사용하겠습니다. 보고서를 작성할 예제 프로젝트는 매우 기술적입니다. 코드에서 사용하는 내용을 감지하고 빌드 시스템에 필요한 지침을 생성할 수 있는 빌드 스크립트를 만드는 것입니다. 이러한 프로젝트에는 분명 수수께끼 같은 제목의 기술적인 작업이 있을 것입니다.

작업 가져오기부터 시작해 보겠습니다. 예제 설정의 프로젝트는 하위 티켓(작업) 목록이 있는 단일 상위 티켓(에픽)으로 표시됩니다. 각 작업에 대해 전체 기록을 가져와 시간이 지남에 따라 티켓 상태가 어떻게 변하는지 확인합니다. Python의 Jira 클라이언트를 사용하면 구현이 간단합니다. Jira 명명법에서는 코드에 반영된 티켓 대신 issue라는 용어가 사용됩니다.

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

기록이 있는 모든 티켓을 가져오는 데 시간이 걸리므로 추가 실험을 위해 이 데이터를 로컬에 저장하는 것이 편리합니다. 구현을 플레이하는 동안 아래 함수를 사용하여 작업을 파일에 저장하고 파일에서 로드했습니다.

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]

데이터 준비

다음 단계는 LLM을 위한 데이터를 준비하는 것입니다. JSON 형식의 원시 Jira 데이터는 매우 장황하므로 이러한 추가 필드가 모두 필요하지 않습니다. 제목, 설명, 유형, 상태, 생성 날짜 등 기본 정보를 추출해 보겠습니다. 기록에서는 날짜 및 작성자와 함께 티켓 상태 변경 사항만 추출하며 다른 필드의 변경 사항은 무시합니다.

이 모든 정보는 일반 텍스트로 저장됩니다. LLM 입력으로 JSON이나 XML을 사용하는 사람들을 본 적이 있지만, 제가 관찰한 바로는 LLM이 일반 텍스트 데이터를 해석하는 데 매우 능숙하다는 것입니다. 게다가 이 접근 방식을 사용하면 JSON 또는 XML과 호환되도록 텍스트 필드의 형식을 지정하는 것에 대해 걱정할 필요가 없습니다. 제가 하는 유일한 처리는 설명에서 빈 줄을 제거하는 것인데, 주된 이유는 결과를 더 쉽게 볼 수 있도록 하기 위한 것입니다.

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

제가 이 실험에 사용하는 에픽에는 기록에서 1~15개의 상태 변경이 있는 30개의 작업이 있습니다. explain_issues 함수의 전체 출력을 인용하지는 않겠지만, 여기에서 어떻게 보이는지에 대한 아이디어를 제공하기 위해 짧은 발췌문을 제공합니다.

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

격려

우리가 사용할 프롬프트는 두 부분으로 구성됩니다. 첫째, 보고서에서 원하는 특정 정보가 무엇인지 자세히 설명하면서 보고서를 작성하라는 지침을 제공합니다. 그런 다음 이전 단락에서 준비한 티켓 정보를 삽입합니다. LLM은 자세한 답변을 제공하는 경향이 있으므로 추가 설명을 추가하지 않도록 구체적으로 요청합니다. 실험이 단말에서 진행되는 만큼, 응답도 단말 친화적으로 해주시기를 부탁드리겠습니다.

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은 Anthropic의 Claude 3.5 Sonnet입니다. 프롬프트 메시지를 보내는 것 외에도 ID도 지정합니다. 프롬프트 시작 부분에 ID를 다른 줄로 추가할 수도 있지만, 후속 질문(대화형 채팅 생성)을 할 계획이므로 Claude의 문서에서는 이러한 시나리오에서 ID를 별도의 시스템 매개변수로 설정할 것을 권장합니다.

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)

이것을 합쳐서 실행해 보겠습니다.

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

다음은 Claude로부터 받은 보고서 전문입니다.

경영 보고서: 범용 빌드 스크립트 프로젝트(TKT-642)

프로젝트 진행 상황:

• 24개 작업 중 11개 작업 완료(45.8%)
• 5개 작업이 진행 중이거나 검토 중입니다(20.8%)
• 시작해야 할 작업이 8개 남아 있습니다(33.3%)

주요 성과:

1. 빌더를 위한 프로토타입 진자 템플릿 생성
2. 구현된 구성 확장 및 유효성 검사
3. 단위 테스트 실행 단계 추가
4. 소나 스캐닝 ​​통합 지원
5. 구성 및 기술 스크립트 작성을 위해 생성된 이미지

진행 중:

• e2e 테스트를 위한 테스트 보고 추가
• 환경 및 소나 탐지를 위한 필터링 로직 구현
• 개발자 문서 개발

문제가 있는 부분:

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. 統合の遅延:
   ビルド システムをさまざまなサービス (ローカリゼーション、レポート、ショッピング カート、認証、データベース API) に統合するためのいくつかのタスクは、まだ「To Do」ステータスのままです。これにより、さまざまなサービスにわたるユニバーサル ビルド スクリプトの広範な導入が遅れるリスクが生じます。対象となるすべてのサービスを統合できない場合、プロジェクト全体の影響と価値が制限される可能性があります。

2. ドキュメントの遅れ:
   開発者向けドキュメント (TKT-715) を作成するタスクは、長期間「To Do」にあった後、最近になって「進行中」に移行しました。さらに、ユーザー文書タスク (TKT-714) はまだ「To Do」ステータスのままです。ドキュメント作成におけるこの遅れは、新しいビルド システムの導入、適切な使用、およびメンテナンスを妨げる危険性があります。明確なガイダンスの欠如により、誤用、非効率、または導入への抵抗につながる可能性があります。

3. 実装の複雑さ:
   いくつかのタスク、特にソナー スキャン (TKT-697) および構成拡張 (TKT-734) に関連するタスクで、「進行中」と「レビュー」の間でステータスが複数変化することが示されています。このパターンは、実装における潜在的な技術的課題や不確実性を示唆しています。これらの複雑さは、適切に解決されないと、将来的にバグ、パフォーマンスの問題、またはメンテナンスの問題につながる可能性があります。

これらのリスクは、適切に管理および軽減されないと、プロジェクトのスケジュール、導入率、全体的な成功に影響を与える可能性があります。

それは驚くほど良かったです。 LLM がプロンプト データに加えて一般的な知識を使用しているため、チケット データにこれらの用語が記載されていないにもかかわらず、「静的コード分析ツール」に関する質問に答えることができたという事実が気に入っています。回答は少し冗長すぎるため、プロンプトをさらに実験する必要があります。おそらく、各ユーザーのクエリに指示を追加すると、より良い回答を形成できるでしょう。
チケットの数え間違いなどの問題は簡単に解決できるはずです。基本統計を計算してプロンプト自体に含めることができます。

위 내용은 Jira 및 LLM을 사용한 대화형 프로젝트 보고서의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!