Waterban, PlanTrack, GtkSharp and other funny phrases - a couple of thoughts about why you should make a decision on UE
Good day everyone!
This short camp will go around the issues of project management, having added a prototype of the realization of the idea of combining kanban and a waterfall.
Preamble
I repeatedly came across the picture: they demand from the manager to tell the final date and give him the task tracker. The solution is this - a project plan in MS Project / TeamWork or in some familiar tool for Waterfall, and for tracking customized Jira / Trello or something else. I looked at the torment of managers with the actualization back and forth, and the idea was born of marrying Waterfall and Kanban: methodically and practically (as part of a knee-and-homegrown implementation on Gtk #).
')
Ambula like
Methodically
Kanban is primarily an analysis of changes in the status of tasks. The habitual waterfall is a task sequence analysis. In this regard, at first glance, there is no intersection - scheduled tasks can change status (and even in MS Project or at least where). However, the kanban forecast is based on the time of passing the task to the final status, and the performers change the statuses independently, which creates a fact, while the waterfall gives us planned dates. To combine this into one, it is rather primitive to allow performers to drive waterfall tasks in any direction along kanban paths. The habitual task of the manager after creating the waterfall plan will be reduced to the analysis of deviations from it - while the usual work of the developers and other project executors will be reduced to changing task statuses.
Nothing magic, if not for one thing. There are tasks that change the status of which should reset the status of its followers - for example, if they began to remake the implementation of the feature, then the testing status could go to zero in a good way. Setting such connections without much thought, I called the creation of "strong connections" between tasks.
Thus, kanban and waterfall are completely compatible with each other, and the tracking task can be simplified with strong links.
Practically
For practical implementation, C # and Gtk # were chosen (since I am a linux user, but I wanted to be cross-platform). Implementation (again, without thinking for a long time) I called PlanTrack, and its current state is a prototype.
Link to windows build (read the readme!) .
Postambula
What the post is about may not be about the idea, and certainly not about the implementation (my Gtk exercises # are unlikely to fit anyone).
Fast rather that the creation of their tools can justify themselves. I did not once or twice (as PM'a) different project management solutions, parochial - in the places where I worked. Even at 1C accounted for. And you know what? .. It's worth it. The tool sharpened under itself allows you to hammer in nails right away, rather than pull your work under someone’s thoughts about how it should be.
All these project management approaches, all these project management solutions ... you need to know them - but only to choose what is appropriate in a given situation at a given time. I am a supporter of adapting methods to work, and not adapting work to methods.
In this and the watershed. It is impossible, perhaps, to believe that we will take RUP / XP / Scrum / <The list is long> and now we will live. No, we will not heal, but we will have problems. No, you cannot take MS Project and Jira and say - now we are tracking and planning them, then everything will be fine. No, it won't be good.
It will be good when someone takes, for example, Excel, and on macros VBA does what suits your business. It was the case that I worked for a large company (revolving on the London Stock Exchange) - and no one there ordered an alteration of SAP. Evaluation and tracking of projects were made for themselves, for their projects, for their methods. And in Excel. I also worked in companies 500 times (without exaggeration) less - and there I was justified in creating my own design solutions. Why?
If creating project management solutions for your needs is not the company's competence, then projects are not a priority for the company, and are not an advantage for the business.
Everything is primitive. The future of the project company is ensured by the planning process of this future. If the tool dictates the rules of planning, no matter how good the practices incorporated in it are, the future will not be flexible, it will not match the circumstances of your business. It will correspond to the circumstances of the business that thought for you how to manage your projects.
Good holidays and successful projects!
As a result, the idea is this: your hammer with electrical tape is better than a purchased sledgehammer, and an example of my three-day efforts outlined above may convince someone that this is completely realistic. Thanks to everyone who read it.
This short camp will go around the issues of project management, having added a prototype of the realization of the idea of combining kanban and a waterfall.
Preamble
I repeatedly came across the picture: they demand from the manager to tell the final date and give him the task tracker. The solution is this - a project plan in MS Project / TeamWork or in some familiar tool for Waterfall, and for tracking customized Jira / Trello or something else. I looked at the torment of managers with the actualization back and forth, and the idea was born of marrying Waterfall and Kanban: methodically and practically (as part of a knee-and-homegrown implementation on Gtk #).
')
Ambula like
Methodically
Kanban is primarily an analysis of changes in the status of tasks. The habitual waterfall is a task sequence analysis. In this regard, at first glance, there is no intersection - scheduled tasks can change status (and even in MS Project or at least where). However, the kanban forecast is based on the time of passing the task to the final status, and the performers change the statuses independently, which creates a fact, while the waterfall gives us planned dates. To combine this into one, it is rather primitive to allow performers to drive waterfall tasks in any direction along kanban paths. The habitual task of the manager after creating the waterfall plan will be reduced to the analysis of deviations from it - while the usual work of the developers and other project executors will be reduced to changing task statuses.
Nothing magic, if not for one thing. There are tasks that change the status of which should reset the status of its followers - for example, if they began to remake the implementation of the feature, then the testing status could go to zero in a good way. Setting such connections without much thought, I called the creation of "strong connections" between tasks.
Thus, kanban and waterfall are completely compatible with each other, and the tracking task can be simplified with strong links.
Practically
For practical implementation, C # and Gtk # were chosen (since I am a linux user, but I wanted to be cross-platform). Implementation (again, without thinking for a long time) I called PlanTrack, and its current state is a prototype.
Swearing about the current implementation
As it turned out, Gtk # is not as cross-platform as you would like (under Windows you need to drag a bunch of libraries). Secondly, the choice of the Sqlite database was also quite naive - we need different assemblies for different platforms. Those who want to build a project under linux will have to change three lines in the code (in DBHelper.cs: System.Data.SQLite -> Mono.Data.Sqlite, and in the same file in two places SQLiteConnection -> SqliteConnection) .
Moreover, for sweets. My apologies for the code in a hurry, I have just enough time as usual (I work even on holidays), but even that is not the case. It looks like the entire front-end farm under Linux and under Windows is painfully different.
Moreover, for sweets. My apologies for the code in a hurry, I have just enough time as usual (I work even on holidays), but even that is not the case. It looks like the entire front-end farm under Linux and under Windows is painfully different.
Screenshots
Link to windows build (read the readme!) .
Postambula
What the post is about may not be about the idea, and certainly not about the implementation (my Gtk exercises # are unlikely to fit anyone).
Fast rather that the creation of their tools can justify themselves. I did not once or twice (as PM'a) different project management solutions, parochial - in the places where I worked. Even at 1C accounted for. And you know what? .. It's worth it. The tool sharpened under itself allows you to hammer in nails right away, rather than pull your work under someone’s thoughts about how it should be.
All these project management approaches, all these project management solutions ... you need to know them - but only to choose what is appropriate in a given situation at a given time. I am a supporter of adapting methods to work, and not adapting work to methods.
In this and the watershed. It is impossible, perhaps, to believe that we will take RUP / XP / Scrum / <The list is long> and now we will live. No, we will not heal, but we will have problems. No, you cannot take MS Project and Jira and say - now we are tracking and planning them, then everything will be fine. No, it won't be good.
It will be good when someone takes, for example, Excel, and on macros VBA does what suits your business. It was the case that I worked for a large company (revolving on the London Stock Exchange) - and no one there ordered an alteration of SAP. Evaluation and tracking of projects were made for themselves, for their projects, for their methods. And in Excel. I also worked in companies 500 times (without exaggeration) less - and there I was justified in creating my own design solutions. Why?
If creating project management solutions for your needs is not the company's competence, then projects are not a priority for the company, and are not an advantage for the business.
Everything is primitive. The future of the project company is ensured by the planning process of this future. If the tool dictates the rules of planning, no matter how good the practices incorporated in it are, the future will not be flexible, it will not match the circumstances of your business. It will correspond to the circumstances of the business that thought for you how to manage your projects.
Good holidays and successful projects!
As a result, the idea is this: your hammer with electrical tape is better than a purchased sledgehammer, and an example of my three-day efforts outlined above may convince someone that this is completely realistic. Thanks to everyone who read it.
Source: https://habr.com/ru/post/247381/
All Articles