2015 IT Skills and Salary Survey – Now Open

written by: Traci Taylor on October 6th, 2014

How does your salary compare to national averages? What skills are in demand in the competitive job market? Which certifications and training impact salary? Help us discover these answers and more by participating in our 2015 IT Skills and Salary Survey.

ASPE-IT and Global Knowledge are conducting one of the industry’s most extensive and comprehensive studies of IT and business professionals. Last year, more than 16,300 from around the globe completed the survey. By providing insight into your profession, we can make this year’s survey even bigger.

We invite you to be part of this important research to identify IT and business pros’ salary trends, valuable training and certifications, and other fundamental topics. Completing the survey will take approximately 10 to 15 minutes, and you’ll receive a complimentary copy of our IT Skills and Salary Report when it’s published in March.

Complete the survey by October 24th to be entered in a random drawing to win one of eight $250 American Express gift cards.

Get started now!

Share

Mastering Business Analysis is Easy

written by: Traci Taylor on October 21st, 2014

Or not…

Fin278-Mastering-Business-Analysis-Not-Easy

It’s not an easy profession and it’s extremely competitive. In order to set yourself apart from the masses and put a mark of distinction on your resume you need CBAP certification from the IIBA. Recognizing their demonstration of the knowledge and skills necessary for effectiveness and a professional level of competence in business analysis principles and practices, CBAPs are achieving worldwide recognition. We can’t teach you to walk on water, but our CBAP training course will prepare you for certification – guaranteed.

Learn more about guaranteed CBAP training from ASPE-SDLC.

Share

Web Seminar Recap: Expert Q&A – Data Quality: How to Keep it Clean

written by: Tegan Smith on October 17th, 2014

It’s a perennial problem for everybody: Over time, data quality degrades. Human error gradually accumulates, weird duplicates pop up, corruption happens – the list goes on.

How can we do better with our data hygiene and keep our quality standard high when it comes to our information? Data can be our most valuable resource, if it’s a current, well-maintained repository of useful information. Taking small steps now and every day can yield big payoffs in the future if those steps gradually amass a high-fidelity treasure trove of information that can be mined and modeled.

This one-hour open interview with Triangle data guru Damian Herrick was held on October 15th, 2014. Damian is a consulting partner on analytics and enterprise data analysis, and he answered questions about how to maintain high quality standards when working with data.

Missed this seminar? Download the slides and recording here.

Share

An Inside Look at Business Analyst Training with ASPE-SDLC

written by: Traci Taylor on October 13th, 2014

In case you haven’t checked out our YouTube channel lately, we’d like to share with you an inside look into Business Analyst training with ASPE-SDLC.

We sat down with long-time business analyst training instructor, Mary Zarba, to discuss ASPE’s Business Analyst Boot Camp and also got some feedback from our BA students. Mary explains how her business analyst training courses focus on process and organizational change and the elimination of repetitious work. She uses a lot of real-life, practical “what-if” questions to push her students to think outside of the box.

Students were pleasantly surprised that business analyst training with ASPE was more involved and interactive than they had originally anticipated. With an increasing demand for certified BAs rather than experience alone, students were eager to put this type of hands-on training on their resume.

 

 

Share

Unit Testing

written by: Kaete Piccirilli on October 8th, 2014

This content was originally posted on Software Testing Fundamentals.

Unit testing is a common software testing method and is one of the first steps in testing software. Unit testing is a level of the software testing process where individual units of a system are tested. This is to validate that each unit of the system performs as designed.

This is the smallest testable part of the software usually containing one or a few inputs and typically one output. This could be a function, individual program or procedure with the software system.

Unit testing is performed by White Box Testing and is the first level of testing performed prior to Integration testing. This type of testing is performed by the developer or their peers.

Some benefits of Unit Software Testing

  • Increases confidence in maintaining code
  • Development is faster
  • Code can then be more re-usable making it modular to be used in other software
  • Fixing a defect in unit testing is less costly
  • Code is more reliable
  • De-bugging is easier

Find out more about the various common methods in software testing and how you can get your software testing certification.

Share

Putting the “Dev” in DevOps

written by: Chris Knotts on September 30th, 2014

It’s been a good five years since the #DevOps hashtag showed up on Twitter and IT operations teams everywhere started talking about it. But with cloud infrastructure exploding and applications teams growing ever more aware of the capabilities and environments available for deployment and integration, we are definitely hearing more interest in DevOps from our customer base of developers and application teams. The DevOps mentality and the associated skills are becoming important areas of interest for them as well. DevOps isn’t just for ops anymore…and it wasn’t ever supposed to be, was it?

There are a few key factors that are beginning to drive real engagement from the Dev side of the house:

  1. The agile mentality has grown widespread and influential, beginning to reach maturity in the marketplace and the workforce. An agile approach to development is the natural analog to a continuous deployment mentality on the operations side of the house. But perhaps more importantly, agile development teams should understand that they must integrate tools and practices into their project efforts which identify important stakeholders across every area of the IT shop, especially those associated with deploying their applications. This overlap is more than just application people getting interested in DevOps – it is DevOps.
  2. Achieving an end goal as a group is not about technology; it’s about people. It can be tough for both developers and operations people to embrace all the change that’s required to really put this shift in thinking into action. However, it’s a rising sense with everyone you talk to who is involved in IT projects and IT operations. The widespread agile coaching that is going on with application teams everywhere is again a contributing factor here. A foundation of team efficiency and capability, combined with a philosophy which views everything through the lens of successful achievement of a result – it’s not easy to disseminate that mentality across everybody in the IT shop. But thanks to DevOps and Agile (and remember…before there was DevOps there were proto-DNA conversations around Agile Infrastructure), necessitated by the cloud and a wealth of new tools that allow exponential gains in efficiency, we have some real driving force powering DevOps on the application side.
  3. Code, code and more code. Software is eating the world and IT is increasingly a recipe of various abstractions. Whether they serve the purpose of a service oriented piece of software, or an abstracted piece of hardware, there’s an awful lot of programming language being spoken. The rise of the cloud has meant more scripting, more infrastructure as code, and more creative possibilities when it comes to IT frameworks. This seems to be attracting the interest of a growing number of developers. On the flip side, I’ve talked to more than a few system administrators and IT operations folks who seem to allude to a nervous population of operations people who wonder if the professional code writers over in Dev are going to gradually supplant them.

Certainly there is more to the picture than just these three ingredients, but these would be three of the top dynamics. And if we do see a widespread shift from Dev toward adopting a DevOps type way of working, then it could signal the mainstream absorption of DevOps as Standard Operating Procedure that many feel is imminent.

Share

Agile Team Capacity Estimating

written by: Kaete Piccirilli on September 24th, 2014

This content was originally posted on cprime.com.

When working on a project and looking at project management, discussions tend to focus on understanding the requirements and creating the schedule. This is important, but it is also important to understand the work of a project done by the people working on the project.  We need to understand how much work they can do in order to understand the scope that can be delivered in a schedule.

The common approach to scheduling for plan-driven projects is to define tasks and their dependencies (what needs to get done first), estimate the effort per task, assign the individuals to those tasks while performing resource leveling and produce a schedule for the project. However, the Agile approach focuses on the teams and not the individuals. Agile assumes that the Team is a group of people who have the combination of skills required to do the project work. The team then self-organizes to identify tasks, assigns owners to those tasks and they do the work as quickly as possible. Because of the team orientation, resource calculations focus on how much work can be completed by the team rather than the individual. Performing the analysis is much smaller for an Agile project than for a typical plan-driven project.

With Agile Teams, we treat them as equivalent for estimating the team’s total capacity to get work done during a specific time. We know that each person does different types of work and each person has a different skill set, but for estimating purposes, we treat them as equivalent.

In Agile Projects, we typically do the “Task Breakdown” and break down the work of implementing and validating requirements into a set of tasks to be completed with each requirement specification, or what we call the “User Story.” Most Agile projects estimate in person-hours, therefore, we need to determine how many person hours of work a team can perform in a particular Sprint or Release (a determined period of time).  A Person-Hour is the basic unit of effort representing one hour’s work by one person. This unit is not related directly to duration. For example, two people who spend a total of 4 hours each doing some kind of work expend eight person-hours of effort, regardless if they do all of the work in one day or in increments across several days.

To determine effective capacity, we will use a resource model and consider the following factors: number of workdays in the period, number of team members, known meetings or activities which involve the whole team, planned time off for each member during the period. The approach is simply put into a spreadsheet.

Team Member % Available Hrs Off Hours
Kaete

25%

 

10

Christie

75%

 

30

Joseph

75%

 

30

Tegan

75%

20

15

Traci

75%

 

30

Person Days Available

14.375

   
Net Team Resources

2.875

   
Team Hours

115

   

 

  1. Number of Workdays in the Period X 8 hours per day = Total Work Hours in the period
  2. Total Work Hours – total time allotted for team meetings = Net Work Hours and this should be smaller than Total Work Hours
  3. Get availability and time off for each person and do this calculation:
    1. Net Work Hours – Time Off then multiply by the result to get this person’s individual capacity.
  4. Add up the individual capacities to get Team Capacity in person hours and then divide by eight to get the capacity in person-days.
  5. Divide Team Capacity in hours to get Net Team Resources which is the effective number of Full-Time People on the Agile Team.

In my example, I’ve noted that everyone has 20% time spent in meetings and the rest is available for work. Tegan is an Intern working only 20 hours a week therefore she has 20 hours off per week.  One of the interesting things to note is that when you calculate hours this way, you have a more visual picture to see how meetings can reduce the ability to complete work and be efficient. The Team shown here has 4.5 full time equivalents, but only 3.1 effective full time people.

Now some tasks require specialized skills. For example, Joseph is the only Graphic Designer on the team and he has some specific .php skills that only he can do for the team. Some might consider this process of hours planning meaningless because he’s the only one who can do particular types of work. However, most of the time this planning will work because in task planning there are specialized and general tasks and the general tasks can be done by more than one person. Typically, the approach is effective as long as the specialized tasks don’t dominate over the general tasks. There are always exceptions and when that happens, a more complicated analysis may be needed.

The Agile approach to estimating team velocity over a period of time is a team-oriented approach with a team oriented analysis and it is usually effective with an appropriate split of general and specialized tasks.

Want to learn more? Register for our Agile Boot Camp and get an immersive, hands-on training course that teaches you everything you need to know about implementing Agile in your team.

Share