Process Planning - CL2 Flashcards
Lean software development concept
Lean Software Development (LSD) is an agile framework based on optimizing development time and resources, eliminating waste, and ultimately delivering only what the product needs. The Lean approach is also often referred to as the Minimum Viable Product (MVP) strategy, in which a team releases a bare-minimum version of its product to the market, learns from users what they like, don’t like and want to be added, and then iterates based on this feedback.
Link:
https://www.productplan.com/glossary/lean-software-development/
Extreme programming
Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development,[1][2][3] it advocates frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
Other elements of extreme programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, code simplicity and clarity, expecting changes in the customer’s requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers.[2][3][4] The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to “extreme” levels. As an example, code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously, i.e. the practice of pair programming.
Link:
https://en.wikipedia.org/wiki/Extreme_programming
Scrum vs Kanban: applicability
DIFFERENCES BETWEEN SCRUM AND KANBAN
Scrum and Kanban are two terms that are often (incorrectly) used interchangeably or thought to be two sides of the same coin. In reality, there are significant differences between these two Agile methodologies. Understanding these differences is key to choosing the path that will work best for your environment. In a nutshell, what is Scrum? Without getting too detailed, Scrum is a tool used to organize work into small, manageable pieces that can be completed by a cross-functional team within a prescribed time period (called a sprint, generally 2-4 weeks long). To plan, organize, administer, and optimize this process, Scrum relies on at least three prescribed roles: the Product Owner (responsible for initial planning, prioritizing, and communication with the rest of the company), the Scrum Master (responsible for overseeing the process during each sprint), and the Team Members (responsible to carry out the purpose of each sprint, such as producing software code.) Another common tool used by scrum teams is the Scrum Board – a visual representation of the work flow, broken down into manageable chunks called “stories”, with each story moved along the board from the “backlog” (the to-do list), into work-in-progress (WIP), and on to completion.
In a nutshell, what is Kanban?
Again, scratching the surface, Kanban is also a tool used to organize work for the sake of efficiency. Like Scrum, Kanban encourages work to be broken down into manageable chunks and uses a Kanban Board (very similar to the Scrum Board) to visualize that work as it progresses through the work flow. Where Scrum limits the amount of time allowed to accomplish a particular amount of work (by means of sprints), Kanban limits the amount of work allowed in any one condition (only so many tasks can be ongoing, only so many can be on the to-do list.)
How are Scrum and Kanban the same?
Both Scrum and Kanban allow for large and complex tasks to be broken down and completed efficiently. Both place a high value on continual improvement, optimization of the work and the process. And both share the very similar focus on a highly visible work flow that keeps all team members in the loop on WIP and what’s to come.
How are Scrum and Kanban different?
As alluded to above, there are a number of differences in both the philosophy behind and the practical application of Scrum and Kanban. While the individual differences are many, they can be grouped into the following three buckets:
Scheduling, iteration, and cadence
Scrum processes place heavy emphasis on schedule. The scrum team is provided with a prioritized list of story points that need to be completed to deliver a shippable product. The team must decide how many of the points they feel can be completed within one sprint. Anything outside the scope they commit to must wait for the next sprint. Optimally, an efficient scrum team will quickly learn their capabilities over the course of several sprints and their estimates will improve and be optimized as time goes on. Then, every two weeks (or however long their sprint is) the team produces a shippable product, carries out a retrospective to discuss optimizing the process, and moves into the next sprint. This iterative process is designed to allow for accurate estimations of work flow and effective management of multiple projects. On a Kanban team, there are no required time boxes or iterations. While the Kanban method is iterative in nature, the continual improvement is expected to occur in an evolutionary fashion as work is continually completed. The limitations placed on various conditions in the work flow will be regulated early in a team’s (or organization’s) use of Kanban until an optimal set of limits is arrived at to keep the flow steady and efficient.
Roles and responsibilities
On scrum teams, there are at least three roles that must be assigned in order to effectively process the work: the Product Owner, Scrum Master, and Team Members. Each role has its own set of responsibilities, and they must work together to achieve an orderly and efficient balance. The scrum team itself also must be cross-functional, which is to say that one team must have all the resources necessary to complete the entire sprint’s work. Under Kanban, no set roles are prescribed. Practically speaking, it makes sense for someone to serve as a project manager or supervisor, especially for larger more complex Kanban projects, but the roles should theoretically evolve with the needs of the project and the organization. A Kanban team is not required to be cross-functional since the Kanban work flow is intended to be used by any and all teams involved in the project. Therefore, a team of specialists and a separate team of generalists may be working on different aspects of the same Kanban project from the same board, and that’s ok.
The board itself
While very similar, the Scrum Board and Kanban Board are different animals. On a Scrum board, the columns are labeled to reflect periods in the work flow beginning with the sprint backlog and ending with whatever fulfills the team’s definition of done. All the stories added to the board at the beginning of each sprint should be found in the final column at the end of that sprint or the sprint was unsuccessful. After the sprint retrospective, the board is cleared and prepped for the next sprint. On a Kanban board, the columns are likewise labeled to show work flow states, but with one vital difference: they also publish the maximum number of stories allowed in each column at any one time. This enforces the team-determined limitations Kanban prescribes for each condition. Since each column has a limited number of allowed stories and there are no required time boxes (such as sprint length), there is no reason to reset the Kanban board as work progresses. It will continue to flow for as long as the project continues, with new stories being added as the need arises, and completed stories being re-evaluated should it be necessary.
Which is better for your needs?
There’s really no way to answer that question for you in this article. Both Scrum and Kanban are powerful, proven process tools that can vastly improve your project management. The best option is to become familiar with both of them and experiment with various aspects of both in your production environment. Creating a hybrid of both is perfectly acceptable if that works best for you. For more information about Scrum and Kanban, take a peek inside this webinar and learn how to incorporate these approaches into your overall strategy.
Links:
https: //leankit.com/learn/kanban/kanban-vs-scrum/
https: //www.cprime.com/2015/02/3-differences-between-scrum-and-kanban-you-need-to-know/
Distributed teams coordination and collaboration
Distributed Teams
Communications
Your distributed team will need communication tools and techniques to replace the in-person chatter of a co-located team.
Skip the conference call
Do not try to manage your distributed project with daily conference calls. People hate it. Think about a project where you participated in a lot of long conference calls. Did you enjoy it? Was it a satisfying, successful project? I have asked hundreds of people this question and they have never recalled a case of a good project with a lot of conference call time. I find that conference calls are a good indicator of failing projects. They make the boss feel better by allowing him or her to share his or her problems. They don’t solve problems for team members. They eat time that could be used to fix problems. They come at awkward times of the day. I laugh when I hear about how the boss has to get up in the middle of the night to inflict a conference call on his Asian team. Calls demand attention, and attention is a very scarce commodity.
Synchronous versus asynchronous
“Synchronous” communications happen between two or more people at the same time. Face-to-face conversations are synchronous. Telephone calls are synchronous. In “asynchronous” communications, people can respond at different times, at their convenience. Emails and text messages are asynchronous communications.
A naive manager will try to replace his co-located conversations with equivalent, high-bandwidth, synchronous communications. This leads to a lot of conference calls, some of them late at night. It also leads to a vision of the future where everyone is in front of a camera, video-conferencing with colleagues as if they were at the next desk or in front of the proverbial water cooler.
However, many hard-working people prefer asynchronous communication. Even if they are sitting at the next desk, you will see that they often email each other and respond at leisure. This trend is particularly strong among young people who prefer to receive text messages rather than voice calls.
Why do they prefer short and seemingly unsatisfying text messages over real conversations with friends and colleagues? There are two reasons. First, they don’t want to be interrupted. They want to pay attention to the thing in front of them, which is often computerized. Second, they are multitasking, having many different conversations at one time. At the same time that you are trying to talk to them about a weekly plan (bla bla bla) they are discussing an engineering point they care about, and arranging for beers with friends.
As we become more productive, and as the competition for our attention intensifies, we come to prefer asynchronous communications. Also, we get annoyed by people who demand our attention for synchronous meetings.
Ticket and issue tracking systems
Write your ideas, requests, bug reports, and comments in an online ticket system. They will be visible to the entire team, and you have a running, long-term record of contributions.
If you are writing feature requests, learn to present complete “stories.” That makes the implementation work easier, and you will get better results. We describe the elements of a good story in the Product Management chapter.
Your team will have a default view of the Work in Progress tasks which shows the status of each task, and shows who is working on it, or where it is waiting. Agile teams call this an “information radiator.” You can always go to this view to find something to work on.
A good online ticketing system with comments and attachments is a requirement for a distributed team.
Email
I live on email. I type thousands of words per day in email. However, it’s a dangerous addiction. You should avoid using email for team communications. Information in an email thread is invisible for other team members. This creates work for you when you have to relay the information. When people email you details that are not important, they waste your time. When they email you information that is important, you need to repost it for the team, which wastes your time. Avoid becoming a human router. I recommend using email only if you are asking a personal question. If people send you information by email that they should be sharing, just ignore the information until they post it properly.
Chat
Every distributed team should have a chat running. People like chat because it can be synchronous when they want to have a real conversation, and asynchronous when they want to come back to it later. You want a persistent chat that team members can come back to at any time. You probably also want a searchable history so that you can find that URL someone posted last week. We use Skype. You can now get chat systems designed for programming teams.
Wiki and message boards
You will want to post your documentation and instructions on a Wiki. If you are inviting new people to join the project, you should take some time to document the setup and other instructions. Later you will want to document test, build, and deploy procedures.
You will want to post status reports, meeting summaries, and major questions on a message board. These tools aren’t absolutely required, but they are helpful and they help move communication out of email and into more visible formats.
Other communications tools
Other useful communication and collaboration tools include:
Online standup reports. Your team can post “What I did” and “What I will do today” and “What I need” on a form. We built this form into Assembla. It only takes about one minute to post a daily report this way, so it saves a lot of time compared with other types of reporting. After that you can get on the team chat to discuss any questions or needs. It’s very useful to read the “What I will do today” reports, because you will often see that people are working on things that are not very important. By asking them to work on higher priority items, you can blast through project obstacles.
@mentions. In some ticketing and collaboration systems, you can @mention teammates to draw their attention to your comment or question. They will get a link on their dashboard that goes directly to the discussion. This is a great way to collaborate and build a visible discussion.
Communicating with code
An effective distributed programming team communicates with code. In fact, many of the most successful distributed projects are open source projects that communicate almost entirely through the exchange and review of code.
Distributed teams should have either a daily build or a continuous build of code. This shared build communicates a lot about the state of the project, and it gives everyone, even non-programmers, a way to see current code and comment about it. If you want your distributed group to work together as a team, then you want everyone to be working on the same thing - the shared build.
Programming teams exchange code through their version control systems. Code management workflows can facilitate many types of communication:
Comments on individual lines of code.
Comments attached to merge requests, change requests, changelists, and other types of code contributions.
Instructions about standards for style, documentation and test coverage.
Voting and consensus-building around feature and architecture questions.
Discussions among product managers, users and non-technical participants about contributions accepted and deployed in the shared build.
An important function of a project manager is to improve communications between team members. If your team communicates mostly with code, then a non-technical project manager will not be able to participate. That is why modern continuous projects use tech leads who can understand code.
About those calls …
I like to do big full-team calls to kick off a project. This ensures that everyone on the team hears the same plan and the same goals. Your team will form around the goal. After that, I do calls that include only the correct people, the people that need to be on the call. They will appreciate the call if it is for them.
Some teams are getting good results with Google Hangouts, which is a sort of informal, low-fidelity group video conferencing tool. It works better than a formal videoconference that requires a lot of setup and synchronous attention.
Links:
https: //www.atlassian.com/blog/confluence/4-simple-collaboration-strategies-distributed-teams
http: //www.continuousagile.com/unblock/team_communication.html
Test Driven Development
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved so that the tests pass. This is opposed to software development that allows software to be added that is not proven to meet requirements.
American software engineer Kent Beck, who is credited with having developed or “rediscovered”[1] the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.[2]
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,[3] but more recently has created more general interest in its own right.[4]
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.
Link:
https://en.wikipedia.org/wiki/Test-driven_development
Feature Driven Development
Feature-driven development (FDD) is an iterative and incremental software development process. It is a lightweight or Agile method for developing software. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner in accordance with the Principles behind the Agile Manifesto.
Link:
https://en.wikipedia.org/wiki/Feature-driven_development
Evaluating technical feasibility
Demonstrating the Feasibility of the Design
You need to evaluate and prove the effectiveness of the prototype.
Remember that your intent is to understand and establish the
requirements and design recommendations better. The prototype is meant to build confidence and foster a sense of mutual understanding between users, stakeholders, and the developers-before it’s too late.
Go into the prototype phase expecting to find issues with the requirements and design. Do not be afraid to make changes in your assumptions, your design, or your requirements. That is the point. You need to find conflicts between documented requirements and what is practical and feasible. For this reason, spend time evaluating the
effectiveness of your prototype. Consider all of the following contingencies.
1. Missing or poor requirements Did you identify requirements that were incomplete or ambiguous? Were there areas that required additional clarification or use cases?
2. Design challenges What portions of the application will present additional design challenges? Identify areas that will need more focus. Also, consider whether you need to extend the prototype session to complete this effort.
3. Technology recommendations Are there different
recommendations that you would make, based on the prototype? Did your recommendations satisfy everything you had hoped?
4. Level of effort The prototype should help you understand how much effort will be required to build the application. Take a look at what was required for the reference architecture. Now make sure that you have enough time built into the project based on this effort (adjusted for the skills of the team).
5. Usability A good gauge of the prototype is, “Does it seem natural to the users, or do they require training to work with the screens?”
If your prototype leans toward the latter, you need to keep working.
Finally, you need to take what you’ve learned from the prototype and put together a presentation for the stakeholders. This will help communicate formally what you’ve learned and accomplished during the prototype
phase. This demonstration will help the stakeholders make the decision to release funds to move the project to the next level.
Defining unit-testing process
Benefits
Provides quick feedback on implemented functionality.
Allows making big changes to code quickly.
Prevents most of regression and new defects.
Reduces development and testing overhead.
Improves overall code quality.
Minimizes amount of debugging sessions.
Indicators of successful process
- The unit testing policy is defined and documented
- Tests are F.I.R.S.T. (Fast, Isolated, Repeatable, Self-Verifying, Timely) / FAIL (Functionality, Accuracy, Instant, Locator)
- Test smells are avoided and removed from the code base
- Tests are structured with four distinct parts executed in sequence aka “Four-Phase Test” (Setup, Exercise, Verify, Teardown)
All external dependencies are mocked out
Unit tests are named according to defined conventions: Tests Naming patterns: [UnitOfWorkName]_[ScenarioUnderTest]_[ExpectedBehavior] Organization pattern (e.g. AAA/GWT/Context/Specification) Each unit test method performs exactly one logical assertion and checks only one thing at a time
Tests check a unit behavior not implementation details
Test code is separated from production code
Functional defects in code are also covered by tests
Unit tests are separated from integration or other tests by project, folder/namespace, test category, or a combination of these options
Testing is part of the build and CI process
Unit tests do not use file system, database, network, registry, configuration settings, etc. (everything that is outside of a process boundary)
Defects detected at unit testing stage are fixed before moving to the next development phase
Parametrized tests, common methods and test cases are used to avoid code duplication
Unit Testing Techniques
Structural, Functional are Error based Techniques
Structural Techniques: It is a White box testing technique that uses an internal perspective of the system to design test cases based on internal structure. It requires programming skills to identify all paths through the software. The tester chooses test case inputs to exercise paths through the code and determines the appropriate outputs. Major Structural techniques are:
Statement Testing: A test strategy in which each statement of a program is executed at least once.
Branch Testing: Testing in which all branches in the program source code are tested at least once.
Path Testing: Testing in which all paths in the program source code are tested at least once.
Condition Testing: Condition testing allows the programmer to determine the path through a program by selectively executing code based on the comparison of a value
Expression Testing: Testing in which the application is tested for different values of Regular Expression.
Functional testing techniques: These are Black box testing techniques which tests the functionality of the application. Some functionality testing techniques are:
Input domain testing: This testing technique concentrates on size and type of every input object in terms of boundary value analysis and Equivalence class.
Boundary Value: Boundary value analysis is a software testing design technique in which tests are designed to include representatives of boundary values.
Syntax checking: This is a technique which is used to check the Syntax of the application.
Equivalence Partitioning: This is a software testing technique that divides the input data of a software unit into partition of data from which test cases can be derived
Error based Techniques: The best person to know the defects in his code is the person who has designed it.
Few of the Error based techniques are:
Fault seeding techniques can be used so that known defects can be put into the code and tested until they are all found.
Mutation Testing: This is done by mutating certain statements in your source code and checking if your test code is able to find the errors. Mutation testing is very expensive to run, especially on very large applications.
Historical Test data: This technique calculates the priority of each test case using historical information from the previous executions of the test case.
Link:
https://confluence.softserveinc.com/display/SDO/Unit+Testing
Defining code review process
Benefits
The strongly defined code review process allows to avoid functional and non-functional defects appearing, prevents anti-patterns and bad practices in the code, increases maintenance of the product, forces code conventions across the team, and lets the team members share knowledge between each other.
The code review increases responsibility for the code quality by each team member.
Using a code review tool simplifies the code review, when it is needed to involve several reviewers, enables involvement of an observer role, and decouples an author and a reviewer, as the author is not required to wait for the reviewer to start a review. In addition, the reviewer is able to review just updated changes in comparison to failed review changes that simplifies and speeds up the review process.
Indicators of Successful Process
The code review procedure is defined and documented
Code review checklist is used
Code is reviewed against requirements (code and project conventions, specified architecture, functional and non-functional requirements, security guidelines)
Code review is used as learning and knowledge sharing instrument and share typical findings among team members
Code review workflow is using best practices for selected tool
Code review is automated (specialized review tools are used)
All changes are reviewed and validated
Consistent code conventions are enforced through all product parts or modules
Code review process roles are assigned: referee, author, reviewer. One person cannot have more than one role.
Code review is done in small portions: up to 400 lines per review, up to 2 hours per day for reviewer and collect metrics to enforce that practice
A wiki of project best practices are up to date and those practices are enforced on review
Reviews are optimized:
Drop trivial changes review (e. g. some autogenerated files, etc.)
Setup focused review sessions guided by author to speedup (author comments changes and provides context for made decisions)
Involve only necessary reviewers
Author critically reviews own code before requesting a code review
Review statistics is collected and used to optimize review process
Process ensures that identified code review defects or action items are fixed
Feedback cycles are reduced by introducing relevant, intelligent comments
Code review results are reviewed and approved by project leadership team
Code review items are closed along with the story and are part of acceptance criteria
Link:
https://confluence.softserveinc.com/pages/viewpage.action?spaceKey=SDO&title=Code+Review+Process
