Admios Basics - 101
Admios Basics
Admios Basics - Admios Basics - 101
Admios Basics Course
Welcome
Welcome to Admios! During the next few weeks you’ll become acquainted with our team, philosophy, and process. Before we start we need to make sure you have a few basics covered:
- You should have access to an @admios or @admios-sa email address
- You should have a personal account in Github for source control
- You should have a Slack account
- You should have a Zoho People account
- You should have a 1Password account
If you are missing any of those please email anybody at the OPS team now. Your training will occur in three phases:
- Phase 1 Admios Basics
- Phase 2 Technical Training
- Developer Basics - Everyone completes this track
- Client-Specific - Dependent on the client and tech stack they employ
- Phase 3 Client Work
During Phase 1 you’ll spend time reading and completing some assignments. We’ll treat your training like a project and track hours using Zoho Time Tracker. You scrum daily with Ricardo, set goals, track your time and present your work just like you would with an actual client.
During Phase 2 you’ll focus on fine-tuning your development skills. You complete a series of development training to make you a better all around developer. You’ll then focus on a specific technology stack and become a member (or leader) of that team.
During Phase 3 you’ll test your technical skills on either an internal project or with a real client. If this is an internal project, it will be run like a client project with daily meetings and weekly sprints. If the work is for a live client, they’ll be aware that you are in training and we’ll actively solicit their feedback on your work. Once you achieve a development quality and velocity that we are happy with, you’ll be assigned to a billable client account.
Expectations
During the course of this training you’ll be asked to independently complete a great deal of reading and coding. When you are asked to read an article, we expect that by the time you mark that task complete, you have actually read, processed and understood the material in the article. If you’re reading about dynamic versus static languages, expect that we’ll ask you about the merits of each in the morning scrums. We’ll want to hear examples, your experiences, and opinions. If you don’t like an article we’ve selected, suggest another, or better yet write one.
If you’re a junior dev, this is a chance for you to build a firm foundation on which to grow your development skills.
If you’re a more experienced developer, this a great chance to refresh your knowledge of some basic topics and contribute opinions so we can improve the training.
At the end of the day, this should be interesting and exciting. You’re getting a chance to take some time and learn. Learning isn’t optional at Admios, it’s required.
Hopefully, this is one of the reasons you’ve chosen to work here. Enjoy!
Where to find Materials
eBooks and other materials
The books referenced in the tasks can be found in the eBooks collection or our Kindle Reader. If you need access to Kindle, please contact the OPS team now.
Admios Intro
Roles and Responsibilities
In order for Admios to be successful as a company, we must all work as a team. As part of this team, we each have a role and responsibilities to ourselves and to one another. Please review the following responsibilities and take them to heart.
Developers
Create code that the company and they can be proud of. Openly and honestly communicate any concerns about the company or a project. Provide timely and accurate estimates. Look for ways to improve their skills. Strive to be better, convert problems into opportunities. Managers
Work to provide their clients with predictable iterations that lead to valuable software that provides business value. Challenge their team members with increasing levels of responsibility, set them up for success. Create a company atmosphere based on trust, open communication, and positive reinforcement. Look for ways to improve the company culture and take personal responsibility for executing on them. Model the behavior you want to see reflected in your team and company. Lead by example. Founders
Discover and hire the best developers possible. Provide comfortable infrastructure including current, efficient, and challenging training. Find interesting and challenging projects for the team. Keep the company on a stable path to growth in order to provide career opportunities for all members of the team.
Software Process Overview
One of the key differentiators between Admios and other services firms is how we manage our projects. A firm understanding of how projects are organized and delivered will better enable you to contribute to any effort, regardless of process and management styles. Become familiar with basic SDLC (Systems Development Life Cycle) history and the different methodologies that have been tried over the years. We’ve encapsulated our favorite Agile best practices on this site. We rely heavily on concepts borrowed from eXtreme Programming, SCRUM, and others.
Agile Process At Admios
All Admios customers use some form of Agile best practices. With variation based on experience, team size, history, client preferences, etc. Tools for tracking stories/requirements vary greatly also.
The Agile development approach had been used for years, unnamed, and on rare client projects. Then a group of now well-known engineers tried to formalize an approach to something everyone had been doing for years. By formalizing it, the “process” came to have more structure and formed the basis of what we use today. It all started with this declaration: The Agile Manifesto
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
Since that time and once given a name and a structure, preferences, principles, and tools followed. Approaches like XP, Scrum, LEAN, etc., along with toolsets to support them.
At Admios it is important we always adapt to our client environments to be successful. All clients are using some form of Agile best practices, some very strict, some very loose. There will be variation, as always, based on experience, team size, client history, management preferences, etc. This section is about BEST PRACTICES. By learning the Agile approach you should be able to:
- Adapt and cooperate effectively in any Admios team and client environment.
- Reduce project risk. Agile guides your contribution, continually lowering project risk for clients.
Agile is now more a blanket term for a development approach that favors frequent releases, in cooperation with and visible to clients and users, in incremental steps. This is in contrast to traditional “waterfall” development where a 6-month project is delivered in essentially one massive development effort and revealed to clients at the very end. Read more about Waterfall development here. In particular pay attention to the “Criticism” section. Understand what the author means when they say
“Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. In this case, it is better to revise the design than persist in a design based on faulty predictions, and that does not account for the newly discovered problems.”
In Agile, a conceptualized 6-month project would be broken into 12 or more small mini releases, called an iteration or sprint. Each one adapting and building upon the last, as the stakeholders, requirements, and solution evolve. The heart of Agile is breaking up an effort and getting features out the door, addressing implementation risk head-on rather than make predictions, so that there is always working code that drives project direction.
Read the entire Wikipedia entry here on Agile Process.
At Admios most of our best practices have evolved from the eXtreme Programming (XP), Scrum, and Kanban methods.
Agile Basics
Now that you know more about where Agile came from, why people use it, and why it’s good, you need to know some basics about how to contribute as a developer. This isn’t everything you need to know, only the basics.
Communication on Projects
Every project is different but expect a continual dialog and meeting schedule to drive an Agile project. Projects are organized around stories, so much of your communication will be shepherding these stories through the software development lifecycle. Constant communication, feedback, and cooperative understanding drive every project. If you aren’t talking and working with others, chances are you are the weak link on the project. In this regard, there are usually 4 basic meeting types you will be involved with:
- Planning Meetings. Before every iteration, there is a meeting that reflects the “planning game”. An agile concept where business users and project managers line up the next iteration’s stories on the basis of priority for iterations and releases. All the information you have shared on a story is used to determine whether a story is part of the next iteration. Read more about the planning game on this site.
- Scrums. There is usually a meeting every day in the AM, usually referred to as a “scrum” or “morning standup”. The purpose is to kick off the day’s work as a team. It is a forum to ask questions of your teammates, let everyone know the status of your work, and commit to what you will get done that day that reflects the tasks associated with your work.
- Interday Slack. You will use Slack all day long with teammates to help everyone stay on track. Problems, concerns, new ideas should be processed in real time as best as possible.
- Review Meetings. At the end of each iteration, a meeting is organized to click through the deliverable and gain customer acceptance before the iteration is pushed to staging (for performance testing) or production.
What is a story?
A user story is a requirement. All development work and code relates back to a story. It is written as one or more sentences in the everyday or business language of the end user of the system that captures what a user does or needs to do as part of his or her job function.
A good story is written in the following format: “As a (role), I want (goal/desire), so that (benefit)”
Example: As a system administrator, I want the ability to add users to the system and assign them access permissions as a user, developer, technical lead, or admin, so that users have appropriate access to various functions within the application.
What do you do with a story as a developer?
All stories have a lifecycle that both developers and clients are responsible for. As a developer you are generally responsible for:
- Understanding a story assigned to you (and asking enough questions to know that you do).
- Estimate a story by breaking it into tasks.
- Writing a test, developing the code, testing, then delivering clean code for the story.
- Honestly communicating progress, setbacks, discovery, throughout the effort.
- Sharing story experience with teammates (did you discover something that is helpful to everyone?).
Basic Story Lifecycle
On teams, there are 2 basic stakeholders representing the business side or implementation team. Sometimes there are project managers, designers, CEO’s, etc., that are involved in the various client environments. But in general, there are two roles: business and developers. When we think about those two roles, they have different responsibilities towards seeing a story through, from an idea to a working feature in production.
| Stage | Business | Developer |
|---|---|---|
| Before Development | Writing story and acceptance criteria | Understanding story meaning, break into dev tasks, estimate the story in (points/hours) |
| Iteration Planning | Assign priority of which stories based on preference, estimates, risks | Helping business understand trade-offs and compromises |
| During Development | Being part of meetings to guide dev choices and evaluating compromises | Developing code. Communicating progress, setbacks, blockers, compromises. All code passes acceptance criteria and tests. |
| After Development | Testing and accepting features | Helping with deployment, completing comments, committing final drafts and comments into the system |
What is an Iteration or Sprint?
An Iteration or Sprint, as words, are often used interchangeably by the team to define the next increment of work in a project. Over the course of a project, there are usually multiple releases comprised of several iterations each. Each iteration taking a subset of the overall production goal and delivering working code incrementally. Fundamentally, an iteration is a measure of time (usually 1 or 2 weeks) that is used to bookend a collection of stories and development effort. Since in Agile we are always delivering, the start and end dates of the iteration are usually defined before determining which of the priority stories are chosen to fill it (usually in a planning meeting). If there are 12 stories in an iteration, and only 10 are complete, the iteration still completes. Those 10 stories are reviewed and released and the remaining two are usually pushed into the next iteration.
In some client situations, you will be part of those iteration planning meetings, and the team will determine which stories are in it and to whom they are assigned as a group effort. In other client situations, usually when you are more Junior, your estimates will be taken to that meeting but you will not participate, and the estimates are used to represent your interests. It’s why estimation is so important. How much capacity for development is within that Iteration will vary from team to team based on a lot of factors, number of team members, skills, individual and aggregate performance, etc. In Agile, there is a term used to describe this capacity, called “velocity”. It is usually determined by looking at the track record of the team and how much work does the team get done over a similar amount of time and complexity. We’ll save that subject for another time, but you can read more about how you might calculate it here.
SDLC Reading
- Read about how complex SDLC can be here
- Read what we tell our clients on the Admios.com website
Development Rituals
Work Schedule
Vacations
Holidays
Time Tracking
Meeting Etiquette
Social Media Guidelines
Best Practices
How to Request Time Off
At Admios we use a system called Replicon to manage time off requests. Employees accrue time off at a rate of .42 days per week (22 days a year). The replicon system allows employees to request time off, which is then approved by their manager and also by the head of the office. This approvals are necessary to ensure that there are no unnecessary disruptions to client work. The following steps explain how to use the system:
To request time off:
- Log in to Zoho, go to LeaveTracker
- Click on a date in the future
- Click on book time
- Complete form and submit
- You will receive an email when you request is approved
To approve time off (for Managers only):
- Login to Zoho, go to LeaveTracker
- Click on Leave Applications
- Fill out the comments (optional) and approve it
Travel Prep
- Make sure you have a current passport
- Make sure you have a current visa for travel to USA and Panama. If you don’t, talk to The OPS Team now.
The OPS Team
If you have any concerns, please talk to anyone at the OPS team: Ricardo, Vanessa or Nicole.