Some of us prefer the Red Hat flavor of Linux to the Debian and Ubuntu distros. Although CentOS is a very stable system, you do run into issues like any other operating system. Here is an issue that I encountered on my CentOS 8.1 web server, while trying to fix something else.
Modular Dependency Problems with Perl
Running a dnf check would result in the following messages.
Modular dependency problems:
Problem 1: conflicting requests
- nothing provides module(perl:5.26) needed by module perl-DBD-MySQL:4.046:8010020191114030811:073fa5fe-0.x86_64
Problem 2: conflicting requests
- nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8010020191113222731:16b3ab4d-0.x86_64
The fix was to run the following command:
#yum module enable perl:5.26
After this, I reran the dnf check and the dependency problems were gone.
In software development, planning is a necessary component regardless of whether one takes a traditional waterfall methodology or adopts a more agile mindset, such as SCRUM. As a project manager or scrum master, you often have to estimate how long a software release or product will take to develop. Given a set increment, such as a two-week sprint or calendar month, and the number of development units you have, it is possible to plan out a software project and estimate how much work can be completed. This estimation work is one of the many things that Microsoft Project excels at, however not everyone has Microsoft Project. Instead, you can use Microsoft Excel to do this type of work and achieve similar results.
Calculating Development Capacity:
To start with we have Development Units. This is a measurement of dedicated development hours which is what most project managers deal with in Microsoft Project, or you can substitute hours for Agile Story Points. For my example, I will utilize story points, but either hours or points will work.
Next we need to know the number of development resources that we will have available to us by Sprint or by Month. For this example, I am going to use 12 months (January through December).
The next value that we will need is how many units a single developer can complete in a given month.
Inputting these values into a table, will give us an estimated capacity for the project.
What we need next is the set of stories and their corresponding unit values. For this, we start with 49 sample stories, each with a different unit value, in this case story points. Our stories will be completed sequentially in Excel, and their story points will be totaled as we progress. This summary is used to calculate what month the work will take place in. If we are over the sum capacity of the 12 months, then we would have exceeded our percentage capacity and note this as “Over Capacity”.
We either can remove stories or increase the number of developers for a given month.
To do this in Excel, I created a Calendar worksheet with a table that listed out by month, the number of developers, the estimated velocity, and incremented story points. The calendar table does simple addition and subtraction. You can change the number of Developers and outside of the table, there is a value of Story Points per Developer that can also be changed.
In cell A4, we have 32 story points which we have already completed at the beginning of March. For the month of March we have an estimated capacity of 16 story points. Note, I have set the Story Points Per Developer value to 4 for this example. With the Calendar worksheet completed, we have a good overview of what our capacity for the next 12 months will be. We can now move on to story planning.
Next I added a Story Planner worksheet with another table that lists out the planned stories and estimated points. The Story Summary incrementally sums up the story points.
For the Estimated Month, a VLOOKUP formula evaluates the story points to the values in the calendar table. The IFERROR is used to display Jan instead of #NA values.
The Capacity column calculates a percentage and if over 100%, displays a warning message, to let me know we are over our story points.
The formula uses the IF function to display the percentage if it is less than 1, or display Over Capacity message. You can also apply percentage formatting to the column to make it appear like in the example above.
=IF((D2/Calendar!$A$14)<1, (D2/Calendar!$A$14),"Over Capacity")
Microsoft Excel is a very versatile tool and this tutorial illustrates some simple planning techniques that can be done using a couple of tables and some basic formulas. I have made a version of the Excel file, to use as a starter template:
Over the last year I have utilized Atlassian’s JIRA issue-tracking system for monitoring the progress of various scrum development teams. JIRA is a very versatile tool for Agile software development, however, like any other tool, the more you use it the more you find out about its limitations. In regards to scrum, I find the Active Sprint Board view to be rather cumbersome to use, if you are working with a large number of stories and sub-tasks. What we use instead for our larger teams, is a JIRA Dashboard. This allows us to view all the work in one screen and allows project managers to monitor the sprint progress as well.
Display Current Sprint Overview
To start with you will need to create three filters and share them with the project. The first filter is to retrieve all stories and task tickets for the current sprint. The next filter retrieves all sub-task tickets for the current sprint. The last filter is to retrieve any open bug tickets; this may be optional on how you handle defects in your project.
project = PROJ-X AND issuetype in (Story, Task) AND Sprint in openSprints() ORDER BY Rank ASC
project = PROJ-X AND issuetype = Sub-task AND Sprint in openSprints()
project = PROJ-X AND issuetype = Bug AND status != Closed
Now that we have our filters, we will create a new dashboard. I personally prefer the middle layout which gives you a smaller left column and larger right column; however you can choose whichever layout you prefer.
For the right column, add three Filter Results gadgets. Using this gadget, we can display Stories, then Sub-tasks, and then any open Bugs. In the Filter Results configuration, set the following columns to display for Stories:
- Issue Type
- Epic Link
- Story Points
- ∑ Progress
- Linked Issues
For Sub-Tasks and Bugs, you do not have to add as many fields, but you can see what works for you based on the fields listed above.
On the left column of the dashboard, some recommendations would be to add the Sprint Health gadget and Sprint Burndown gadget. I also recommend adding the Issue Statistics gadget to display Status for Stories. Although I am not a fan of the Pie Chart Gadget, you can also add this on the left column to display Sub-tasks and the Assignees.
When complete, this overview dashboard will provide a quick and easy view of the scrum team’s current sprint work. It is great for reviewing before or after standup meetings, or for product owners who need to monitor specific stories.