Sunday, June 26, 2011

How to Branch Strategically ?


Branching is a fundamental part of version control systems. If you're working on any good sized project this is a feature you'll eventually come to depend on to enable simultaneous development of different features.

If you branch strategically, you can maintain the order and consistency of multiple versions of your software. In this article your will learn the best practices for adopting branching in your project regardless of the source control system you rely on.

When you work with a version control system, you must consider how to set up a branch structure. You can create a branch by mirroring the source code file. Then you can change the branch without affecting the source. For example, as the branch structure in the following illustration shows, the MAIN branch contains completed functionality that has passed integration tests, and the DEVELOPMENT branch contains the code that is under construction. When a new functionality in the DEVELOPMENT branch is completed and can pass integration tests, you can promote the code from the DEVELOPMENT branch to the MAIN branch. This process is referred to as reverse integration. Conversely, if you merge the code from the MAIN branch to the DEVELOPMENT branch, the process is referred to as forward integration.
Main Branch


Branching and merging entail the following principles:
  1. Each branch must have a defined policy about how to integrate code into this branch. For example, in the branch structure of the previous illustration, you can assign a team member to own and manage the MAIN branch. This member is responsible for performing the initial branch operation, reverse integrating changes from the DEVELOPMENT branch to the MAIN branch, and forward integrating changes from the MAIN branch to the DEVELOPMENT branch. Forward integration is important when the MAIN branch also integrates changes from other branches.
  2. The MAIN branch must contain code that has passed integration tests so that it is always ready for a release.
  3. The DEVELOPMENT (or work) branch constantly evolves because team members check in changes periodically.
  4. Labels are snapshots of the files in a branch at a specific time.
How often should your team reverse integrate and forward integrate?


As shown in the following illustration, reverse integration and forward integration should occur at least when you complete a user story. Although each team might define completeness differently, completion of a user story generally means that you complete both the functionality and the corresponding unit tests. You can reverse integrate to the MAIN branch only after unit tests have verified the stability of the DEVELOPMENT branch.
Branch across two sprints
If you have more than one work (DEVELOPMENT) branch, forward integration to all work branches should occur as soon as any branch integrates into the MAIN branch. Because the MAIN branch is kept stable, forward integration is safe. Conflicts or failures at the work branches might occur because you cannot guarantee that the work branches are stable.
It is important that you resolve all conflicts as soon as possible. By using a gated check-in for the MAIN branch, you help make the reverse integration much easier because quality gates help avoid conflicts or errors in the MAIN branch.

As the following illustration shows, you can check in changes to a work branch periodically to complete a user story. You can implement multiple user stories in the same branch at the same time. However, you can reverse integrate to the MAIN branch only when you complete all the in-progress work. It is recommended that you group user stories by similar size because you do not want a large user story to block the integration of many small ones. You can split the two sets of user stories into two branches.
Check-in Completes User story

You should create branches in the following situations:
  • When you must release code on a different schedule/cycle than the existing branches.
  • When your code requires a different branch policy. If you create a new branch that has the new policy, you can add strategic value to your project.
  • When functionality is released to a customer and your team plans to make changes that do not affect the planned release cycle.
You should not create a branching for each user story because it creates a high integration cost. The overhead of managing branches can become significant if you have many branches.

Your team should be able to release code at the end of any sprint. By using Team Foundation Server, you can label a branch to take a snapshot of the code at a specific point in time. As the following illustration shows, you can label the MAIN branch for a release. This lets you return the branch to its state at this point.
Label a branch to take a snapshot of the code
Because you must implement updates on releases, creating a branch for a release helps your team continue to work independently on the next sprint without creating conflicts with future releases. The following illustration shows a branch that contains code for an update and that is reverse integrated into the MAIN branch after a release at the end of the second sprint.
Reverse integrate a branch that contains update
When you create a branch for a release, you should create that branch from the MAIN branch, which is the most stable. If you branch for release from a work branch, it can cause integration challenges because the stability of work branches is not guaranteed.

Source: link

Saturday, June 25, 2011

Product Managers Job Role @ Symbyo



In this blog article we will highlight the role Product Managers play in Symbyo Technologies.

Product Managers at Symbyo acts as a managed conduit between the business world and a project team. In the beginning of a project life cycle, they drive gathering requirements, expectations, and constraints and distill them into a solution definition. As a project progresses, Product Managers works with the team to clarify what has been gathered and works with stakeholders to refine expectations. As a solution starts to take form, they reverse the conduit flow to start to prepare stakeholders for the coming solution.

Quality Goals
The quality goals for Product Managers are the following:
  • Satisfy stakeholders
  • Define solution within project constraints

Focus

Product Managers ensures that all stakeholder expectations are understood, managed, and met throughout a project. In addition, Product Managers ensures that a project sponsor is satisfied with the progress and outcome of a project. To be effective, Product Managers needs to understand, communicate, and ensure success from a stakeholder perspective. To do this, they need to gain knowledge about customers' business, success factors, and key performance measures. They own and drive the definition of requirements and feature sets as well as help the team understand user profiles and how users will use a solution. As you can tell, it is a very communications-oriented group.

As discussed previously about partnering with a customer, Product Managers leads this effort. They collaborate with customers to drive a solution vision and adjust both the vision and expectations as a project continues. It cannot be stressed enough how critical it is to manage customer expectations. Stuff happens, no plan is able to cover all project impacts, and as such, sharing that information in a no-fault environment is very important and healthy.

The importance of effectively managing expectations can be illustrated with an example involving the anticipated delivery of five solution features from a team to a customer by a certain date. If a team delivers only three features when a customer expects delivery of all five, a project will be deemed a failure both by the customer and by the team.

If, however, Product Management maintains constant two-way communication with the customer during a feature development and production period, changes are made with regard to customer expectations that ensure success. Product Management might include customers in the trade-off decision-making process and inform them of changing risks and other challenges. Unlike the previous scenario, customers can assess the situation and agree with the team that delivery of all five features within the specified period is unrealistic and that delivery of only three is acceptable. In this scenario, the delivery of three features now matches the customer's adjusted expectations, and both parties will consider the project a success.

Functional Areas

The Product Managers are responsible for several functional areas, including Marketing/Corporate Communications, Business Analyst, and Product Planning.

Marketing/Corporate Communications

This functional area is the process or technique of promoting, selling, and distributing a product, solution, or service. Nearly every solution needs to be introduced and promoted, even if it is a solution being rolled out internally to employees. When solution promotion is internal-facing, it is refered to as Corporate Communications.
Whether it is called a marketing plan or a corporate communications plan, this plan needs to outline how to excite the target audience. After all, not everyone will welcome change; even if it is a new and improved solution. Typical promotional efforts on a project involve launch promotions, sustained promotions, and public relations. Promotional efforts run the gamut from sending out fliers and e-mail to full advertising campaigns.
Key Responsibilities
This functional area and the others to follow have key responsibilities. Key responsibilities for this functional area include the following:
  • Marketing and public relations messages to excite and positively affect the target customer and users
  • Understanding the competitive landscape
  • Distribution channels so target customers easily acquire a solution
  • For packaged solutions, enabling customers to have a positive experience buying and using a solution
Key Activities
Each functional area has a set of key activities to help uphold its responsibilities. Some activities are done throughout a project; some are done each iteration. Key activities for this functional area include the following:

  • Develop a plan to promote a solution
  • Be able to highly differentiate a solution so it stands out from the competition
  • Set up and prepare distribution channels

Business Analyst

A Business Analyst functional area works in conjunction with a sponsor(s) to gather, manage, and refine throughout the life cycle all the market information, all functional and operational requirements, all stakeholder expectations, and anything else that could affect the definition and delivery of a solution.

To start, a Business Analyst team forms an initial vision and conceptual understanding of a solution, given insight of business needs and opportunities as well as the competitive landscape. As a solution vision, solution road map, and constraints are worked into high-level requirements, business analysts work with product planners (discussed next) to segment a solution into projects to deliver capability incrementally.
Key Responsibilities
  • Solution landscape
  • Stakeholder expectations
  • Quantifying a solution's return on investment (ROI)
  • Sponsor relationship
Key Activities
  • Perform objective cost/benefit analyses to help communicate to the team a defined stack ranking of requirements and feature priority
  • Assist sponsor's development of a business case
  • Define and maintain business justification for a projectDefine and measure business value realization and metrics
  • Manage customer expectations and communications
  • Determine business metrics and success criteriaProvide requirements and feature trade-off decisions

Product Planning

As opposed to a Business Analyst functional area that is more externally focused, a Product Planning functional area works with the team on a tactical level, as depicted in the following figure. Product planners take a vision and conceptual solution and drive a delivery strategy.


As discussed, Symbyo software development methodology recommends that solutions be incrementally delivered through versioned releases. A release is a bundling of solution features and capabilities so that it can be shared either internally among the team or externally with stakeholders. A Product Planning functional area coordinates and manages versioned solution releases. A release can encompass one or more teams' efforts. For instance, a release might be made up of new features from some teams and updates from others with previously released features. This functional area coordinates with Product Management from each of the subteams to present an integrated solution version for release.
Product planning entails understanding the requirements of a solution completely, including what the needs of the business are, how customers will use it, what support issues will be, and what alternatives are available. It also entails working with the team to agree upon prioritization of requirements, capabilities, and feature sets; issues; risks; and so forth.
Key Responsibilities
  • Shared project and solution vision
  • Working with the respective teams to deliver a solution version consistent with a solution road map
  • Being the authority on requirements and expectations associated with each release
  • Solution definition and solution definition process
Key Activities
  • Stack-rank requirements and features for a solution and for each release
  • Balance and trade off requirements with project(s) constraints
  • Perform market research, market demand, competitive intelligence/analysis
  • Gather, analyze, and prioritize customer and business requirements
  • Perform release-level requirements and feature trade-off decisions
  • Identify a multiversion release plan


Symbyo Is continuously looking for talented product managers to join our team, if you feel you have the qualification, experience and passion to excel in a product manager role in Symbyo Technologies, Then apply online through our careers section. www.symbyo.com/careers/

Wednesday, June 1, 2011

Applying Agile Techniques to Software Architecture

Introduction
The agile methodologies are getting widely accepted all over the world. However, there is still a lot of discussion and debate on how to apply those methodologies to the architectural space. Most conflicting issues arise between the ‘big design upfront – an approach that is strongly discouraged by the agile approach practitioners and the traditional approach to architectural design. In this post you will read on how you can achieve technical excellence, streamlined development practices, and a constant and ever-increasing flow of business by integrating the agile approach in to your software architecture. This can be achieved with a set of team dynamics, conceptual practices, and specific technologies that are proposed herein.

Architectural dynamic utilized in Agile teams
One of the 12 principles of the Agile Manifesto states that “the best architectures, requirements, and designs emerge from self-organizing teams.” This is something that is considered as a foundation here, especially with regard to the shared specialization.
The architecture is an activity that is historically performed with emphasis on the early stages of a project. The agile development on the other hand, lays its focus on emergent design and iterative production. Thereby, it creates a series of interesting challenges down the road.
The basic characteristic of the agile approach is that it believes in shared responsibility. Unlike the traditional approach wherein a software architect was considered wholly responsible for creating the software architecture and higher-level design, in case of the agile approach this responsibility of the software architect is diluted. In this approach, the software architecture is developed by the whole team. Hence, it helps in preserving its multi disciplinary nature. Now, that doesn’t mean the role of software architect is no longer considered important. It goes without saying that the software architect will still remain the person who will conceptualize the idea of the software architecture however, he will explain the design to the team members and they all will contribute in its development. The benefit here is that the entire team participates in understanding the implications of the design and continuously evaluates them.
It is a fact that key considerations such as the modularity strategy, how communication is handled within and outside the application, and how data and services are accessed and abstracted are better analyzed when a team sits and discusses about them rather than an individual handling them all simultaneously. In this way, the team members contribute their suggestions, their fears and concerns. Hence, the probability of failure is reduced to a great extent.
These challenges are usually tackled by holding regular meeting of the team members for architectural discussion and revision. These review and design meetings comprise a lot of white boarding and open talk. Also, it helps to have the most important guidelines permanently exposed in the meeting area. These could include diagrams, checklists or reference charts around the walls, and semi-permanent flip charts that can be used as posters.

Patterns and practices followed in Agile architecture
The big design approach leaves us with several inconveniences. To avoid this one of the most common approach suggested it “sashimi” approach. Here separate design for each part is not developed instead, small codes are developed with the intent to connect all the pieces and then the main functionality is constructed. This will give you the same end to end set up that you wanted. The objective is to do away with complexities of big building architectural components. Since there are repetitions of some of the processes become unnecessarily big and unmanageable.
However one challenge that is faced with to replace this support system with architectural pieces is to define a decoupled API. At the outset developing the API becomes the most critical thing to do. For similar reasons it is advised to star with absolutely no implementation. Even if you use a third party component it is advised that you follow a similar practice.
Architectural Pattern
Concentric approach has also emerged as a most common approach for agile development of software for architecture. The first step is to analyze and develop technical vision of the desired solution. This technical vision enables you not only to compare your own progress but also to guide you as to what your subsequent action should be. Thus it is important to establish a logical continuity in your entire planning. The second step would be to decompose the entire step into as many small manageable steps as possible. This not only makes the job easier in terms of division of responsibility but also to check progress and to check whether the person to whom the responsibility was given has lived up to it or not. This also helps in adding up new functionality if needed. This helps us do away with the requirement of having to redo the entire program all over again.
The next step is to describe each such decomposition in terms of architectural styles. This helps us make this decomposition more understandable to people who are not directly linked with the project. The trickiest part is to define the layers. The layers have to be so defined that they represent the decomposed components of the project. If they are clearly defined then it becomes easier for the person to whom the responsibility is entrusted to understand and execute the work better. This also makes it easier to distribute the work among teams so that development of each part can be closely monitored and handled. This also helps understand which a particular component is lagging.
The next level is the packaging of the software to turn them into independent saleable software packages. This helps to turn them into independently recognizable software packages.
The next step is to finally develop the program languages and introduce the same to the stake holders.
However one should keep in their mind that all these different steps in the architecture can be undertaken in an independent basis as well. The latter would be in congruence with the needs and goals of the project!
Quality Attributes required in architecture
It is a common aspect in the world of architecture of what are the aspects which one should consider in a system design. There are several qualities and attributes which are essential. In perspective of agility one should keep in mind the attributes which must be managed in view of the backlog of the product. The implementation should be done on an incremental basis. In specific terms it means the management of a mix of needs, both the quality attribute requirements as well as features. Interestingly, the several qualities attribute lead to a trade off decisions and analysis where the usual prioritization might not prove to be enough!
The authors suggest that in order to manage quality attribute in an effective manner, one need to consider the latter as a goal whereas the requirements as a support system and user stories to the goal. It is important for the stories to have some normal acceptance criterion which re defined clearly. This is vital such that the tests that are implements can be neatly written out. For instance, some of the requirements are performance which need the resource usage and response time.
Validation of the architecture
The validation and testing of the architecture are the last stage of this section. From the authors point of view there are automated quality-attribute requirements testing, test-driven development, environment-configuration management, automated integration testing, and application-configuration management and automated deployment.
The authors are of the belief that interfaces should be defined as in the first section. Unit tests which can be executed should be used in the definitions. These specifications will have a dual role. Firstly they will safeguard for multi component and local refactoring and secondly they will be the point of entry for identifying defects in the reporting of the incident. The basic idea is that the implementation needs to be correct or changed in sync with the defect! However one should bear in mind that there are several changes in the architecture that will not be noticeable in unit tests!
In order to have a good management of the changes which should exceed the contracts of unit tests, one needs automated tests. The latter is a must for quality attributes and integration. While automated tests are difficult to create, their results are superior. These tests need to be such that they have a lower frequency which is a result of their resource usage.
Some of the examples include the following:
· Scalability: There is an acceptable amount of response time in the event of increase in system load. There is a planned capacity along with tool support which is a must for these tests. In this case both the server and client site needs to be kept in mind. The deployment also needs to be automated in the testing environment.
· Flexibility: The layers pattern needs to be instantiated. The tests need to be configured such that the acceptance needs to layer by layer, starting from the top layer only!
·
For the above to come true, one need to manage the configuration in two levels, one which is dependent on the environment and one is not. The automated deployment will be enabled in case of environment dependent configuration and focuses on the local and physical resource configuration! For the remaining configuration, there will be an issue that is the variability of the available functionality!
Technologies and techniques
It is vital to use the appropriate techniques and technologies in order to achieve the needed discipline through automation.
The agile world is one which has given more importance to human and their interactions rather than to tools and processes. in lieu of the above a helpful set of tools have been devised which make tedious and manual jobs away from individuals and make the execution frequent and fast. The latter is simple use to the constant feedback which is provided making it easier for human beings to act.
In order to attain the first level of technology, it usually includes frameworks and regular testing tools. Some of the unit testing tools includes xUnit to Cucumber apart from others. There are others like Selenium which is functional testing tools apart from several others which have a host of technologies needed for stress and performance testing. All of these run successfully on a built server as well individually at varying frequencies.
In a nutshell, while the basic development proactive is undertaken, it is supplemented with a specific unit test, stress level and acceptance to validate the architecture. There are style analysis, afferent and efferent coupling, cyclomatic complexity, code coverage statistics, lined of code per module and other such checks which were introduced in the second level. These tools are used in NDepend, StyleCop, FXCop, CheckStyle, JDepend, and Lattix among others. In the area of dynamic languages like Python, JavaScript and Ruby, there in an inherent problem in the implementation. However this should be filled up soon!
The third step is about metrics involving maintainability and flexibility regarding the project life cycle. In this arena, Visual Studio Team System has made immense progress.
It has been seen that a model needs to be in place for validation of a model of architecture. The important factor is for the automation of the process for the extraction of the required Meta data which is needed to validate the references, module composition and code. In addition, the distinguishing aspect of the module or code view of the system, starting from the runtime view in the evaluation period is vital! Lastly, learning about the performance of levels of reverse engineering is also done. The final step in the process involves the configuration and deployment in the varying staging
It is essential to have the project relevant and appropriate techniques in each fold and step of the main plan. The latter ensures that the controls are planted in the proper places with commencement of the project.
Conclusion
Symbyo Technologies strongly belief that the consideration of the architecture is the most fundamental aspect which creates value to the software projects. Additionally, the agile teams have immense techniques, tools and mechanics which are on offering for the software architecture society. Interestingly, these contributions have been considered one of the best in its area. It provides immense benefits to the users and enhances one’s results and project value!


,, ,