powerobjects: So You Think You Know Agile?

[Blog bot]

Источник: https://www.powerobjects.com/2017/10...ou-know-agile/
==============


Extending Dynamics 365 is developing software, and there are processes designed for doing just that. “Agile” is a popular way to say, “Lightweight Process” or “Scrum”, but the term means much more than that – Scrum is one piece of a much larger and diverse landscape. In fact, while Scrum is extremely popular, it is focused on project management, and has little to say regarding project planning, designing code or testing strategies.

What is Scrum, and what other things does agile deal with?

In 1987, Hirotaka Takeuchi and Ikujiro Nonaka released an analysis of manufacturing companies who could pivot to rapidly meet new product opportunities. Their article “The New New Product Development Game” championed the term Scrum as a way to keep the front line of business constantly moving toward innovation and new products. Jeff Sutherland, one of the authors of The Agile Manifesto later identified this event as his inspiration for some of the first Agile process refinement. Scrum is intended to be the method for employees to drive the business forward via process and culture. To do this, Scrum is broken into Sprints that can be as short as 1 week, or as long as 4 months. Within each sprint exists a meeting for grooming a feature backlog, planning a sprint, reviewing the sprint for process improvement, and demoing the development for the business.

Why Scrum has become so popular may lie partly in its simplicity. After understanding that features go in a product backlog, and chosen features then join a sprint backlog, it becomes easy to track progress and report upward on the status of each Scrum team. One specific method for scaling upward is named Scrum of Scrums and has a similar structure not for the development team, but for a collection of Scrum Masters. In this scenario, each Scrum team reports upward to a parent Scrum team, which can continue through multiple levels of hierarchy until the top has a summary of the entire business.

Where Scrum offers a strong structure for project management, Scrum offers no recommendations on how code quality can be improved, or on individual practices for developers. This makes Scrum an easy fit with other Agile methods such as Extreme Programming or Kanban.

What do Extreme Programming and Kanban offer?

The complexity latent to software design prompted Microsoft to commission David Anderson in 2006 to study and report on how to improve productivity and increase quality. The result was to bring principles from the Japanese manufacturing methodology Kanban and repurpose them for software. In the Japanese process of Kanban, a hard limit on work-in-progress (i.e. WIP) is set to avoid overloading the manufacturing system. Similarly, a limit is set on which software features are currently being developed. When the maximum cap is met, a feature must either be completed or shelved to allow for another feature to enter the in-progress queue. By focusing on task quantity limits, iteration-less development can be achieved. This is often coupled with Scrum by limiting how many stories can be worked on by a single person at a single time, and enforcing use of a Kanban board to show stories being worked on and completed.

Extreme Programming started a bit earlier in 1996 with a publication by Kent Beck. The goal was to introduce a process that ensured high-quality code with daily releases. Since the initial article, there have been dozens of practices identified as helpful for code quality. Here are some of the more significant practices:

Collective OwnershipBy stressing the idea that code is owned by all developers, sharing code could be encouraged allowing teams to improve general purpose libraries and to facilitate understanding of the entire product for better design decisions.Pair ProgrammingIt’s been shown that pair programming increases the quality of code. While some have argued that the quality isn’t worth the time of two developers, Emerson’s concern with quality makes this practice desirable. Ancillary benefits would include the sharing of project knowledge between two developers, and the ability to train junior developers by pairing them with a senior. Critical system projects could also benefit from two senior developers.40 Hour WeekMistakes are made when programmers are tired and frustrated. By maintaining a 40-hour work week, developers understand they’re valued and respond with increased morale. High reliability and quality can be maintained long term with consistent processes rather than risking burnout from rapid and sometimes unpredictable work schedules.Coding StandardsBy applying the same standards between all developers, the ability to quickly understand another’s code becomes feasible and more likely to happen.On-site CustomerSome developers directly engage clients, and it should be encouraged on all agile teams. This can help emphasize accessibility for feature details, and can greatly reduce defects in requirements. The resulting conversations may also help uncover potential defects and improve code logic.Test Driven DevelopmentA core feature of Extreme Programming is the priority of testing and design before code. By writing code tests first, we ensure that unit tests will be written, and quality will increase commensurately. This practice also encourages consideration of code architecture and logic before beginning to write which increases maintainability and readability.
There are a lot more agile practices out there. A few of dozens would include Feature Drive Design, Crystal, Rapid Application Development! They are all intended to make quality software better and faster, which is a great thing for Dynamics 365.

Subscribe to our blog for more great Dynamics 365 related topics!

Happy Dynamics 365’ing!



Источник: https://www.powerobjects.com/2017/10...ou-know-agile/