XP does not recommend or encourage architecture-driven design or practices. However, our Studio Team (SQUARE Root) used architecture-driven practices in conjunction with XP practices during the implementation phase. This paper reflects on three lessons we learned from that experience.
The idea of this paper is to consolidate key principles that will help software professionals think architecturally. The ideas provided here are expressed in terms of common questions that normally challenge many professionals in industry. Knowing how to tackle these questions is fundamental to understand the critical role architects plays in software industry. This paper will be helpful to start developing architect’s intuition.
This paper explores the use of the scientific method as means for constraining process data collection and focusing process improvement effort in agile processes. Current agile retrospective techniques are not adequate because they require that team members be experienced, observant, interested, and process savvy. The scientific method helps teams overcome these issues through experimentation, the results of which will help the team objectively understand how the process is working for them and give clear guidance on how to tailor. This assertion is supported by the author’s experience with an industry project that used Extreme Programming during the construction phase of development. In this case, the team framed an experiment to determine whether pair programming would allow them to complete the project on time with the expected level of quality. This paper will discuss the how the team framed the experiment, how the team was able to use the experiment results, and lessons learned from the experience.
The software industry has been witness to project failures of epic proportions - many of which are a direct consequence of process mismanagement. The questions that come to mind when dealing with this topic are - What exactly is process management? What makes it so difficult? And of course, the most important question of all, what can be done to alleviate the problem? Process engineering is a discipline that attempts to tackle this esoteric problem that is often experienced but rarely comprehended in its entirety by a substantial number of organizations. Although there exists many areas of process engineering on which one can delve upon, this paper is directed to concerns related to process selection, improvement and maintenance. The first reason is that, although there is considerable literature on various processes, there is limited availability on materials that analyze the criterion for factoring out infeasible processes based on the context of the project. Furthermore, after spending a year in the software engineering program at CMU, I have become aware that many software practitioners view software processes as an ‘overhead’ to a project. While I do view processes as a means to an end - the end goal being the final deliverable of the product (where even the word ‘final’ is relative), in my opinion, the term ‘overhead’ seems to be a misnomer due to its implicit negative connotation. Through this paper, I hope to convince the reader of the criticality of process selection, when to invest in its improvement, its relation to project management, and how, in the overall scheme of things, it can ultimately determine the success or demise of a project.