One thing that bugs me with development workflow tools is how they never really integrate with the true workflow of developers. Once you have a development workflow with Pull Requests, Code reviews, QA etc, it would be nice to be able to encode it into the
What's the true progress of an issue (ticket, work item...)? Why do I need to remember to set a ticket to "resolved" after a PR completes, and so on.
Every place has a different workflow and they are usually very complex, but these tools (Jira, YouTrack, GitHub issues, Azure DevOps, ...) are complex. They are often configurable, yet they still (as far as I'm aware) fail to integrate the process part of things with the code part of things. At best you have some loose integration between version control and process e.g. "this ticket has these changes" but they don't integrate the two processes so that the state-machine that is a ticket (is it done? why is it not? is it because a PR build failed? Is it because an approval that must be done after merge has failed? is it because the issue has several pull requests associated with it and not all are merged yet?).
I absolutely don't mind complexity in these tools. Having an extremely simple post-it process is good. This is the second best. The process complexity in big enterprises and distributed teams will always be there. If I can configure a tool to make it go away I'm glad. The worst situation is when you have a hyper complicated process and no tools to help. That's the situation many businesses are in. "You didn't mark the two fields and change the state to Y and then send the email to the translation person and notify the regional development person about the change! You have to do that".
Have you heard about Basecamp's solution to this, Hill Charts (https://basecamp.com/features/hill-charts)? It's definitely not an 'enterprise' solution, but I find its simplicity a really good map for the _true_ workflow of developers. That is to say, it's abstract and simple enough to use for devs, while meanigful enough for managers to gauge progress.
Plus, their writeup on imagined vs discovered tasks and how Jira et al give false sense of control when creating tickets upfront is also illuminating: https://basecamp.com/shapeup/3.4-chapter-12
We use JIRA to track our product development with a fairly large team (including 17 engineers) and while JIRA has its pain points, it does have integrations with development workflow.
In our setup, after a PR is merged in Github, the ticket automatically moves to the next “step”, in our case “Ready for QA”.
Beyond that there are automation workflows that accomplish much of what you are asking for here, the issue is that these are complex tools/flows that require a lot of up-front work and continuous maintenance which might not be worthwhile for all teams.
So internally, we're calling it the "task lifecycle". It's going to be a big feature, and the idea is to figure out the true development workflow (that works for 80% of users) and have statuses that update automatically based on Git. We're working on figuring out how to do this well enough, where the user doesn't have to go through complex configuration.
Tickets are for people not machines, they’re used to communicate with the team/PM. All the information in the ticket comes from people (usually developers) anyway. There’s no way for a machine to know if the content of a PR truly represents what the ticket asked for or what the actual status of the ticket is.
I think the only time I’ve ever used kanban in the original form was in college robotics but my understanding is that these tools are supposed to replace sticky notes.
> Why do I need to remember to set a ticket to "resolved" after a PR completes, and so on.
This is my biggest peeve. Every place you have other stuff related to a project, whether it's Trello, Jira, Google Drive, O365, Miro, Confluence, Figma, Travis, CodeClimate, etc etc etc, it's just another ever-increasing set of things to try to keep in sync and up to date.
It makes onboarding new members way more difficult and make everything slower, more frustrating and more error-prone.
We just launched https://treenga.com because of this constant Github mess of product discussions and development details, so we can focus just on product development in one place and just on code in another.
What's the true progress of an issue (ticket, work item...)? Why do I need to remember to set a ticket to "resolved" after a PR completes, and so on.
Every place has a different workflow and they are usually very complex, but these tools (Jira, YouTrack, GitHub issues, Azure DevOps, ...) are complex. They are often configurable, yet they still (as far as I'm aware) fail to integrate the process part of things with the code part of things. At best you have some loose integration between version control and process e.g. "this ticket has these changes" but they don't integrate the two processes so that the state-machine that is a ticket (is it done? why is it not? is it because a PR build failed? Is it because an approval that must be done after merge has failed? is it because the issue has several pull requests associated with it and not all are merged yet?).
I absolutely don't mind complexity in these tools. Having an extremely simple post-it process is good. This is the second best. The process complexity in big enterprises and distributed teams will always be there. If I can configure a tool to make it go away I'm glad. The worst situation is when you have a hyper complicated process and no tools to help. That's the situation many businesses are in. "You didn't mark the two fields and change the state to Y and then send the email to the translation person and notify the regional development person about the change! You have to do that".