Scrum is a subset of Agile and one of the most popular process frameworks for implementing Agile. It is an iterative software development model used to manage complex software and product development. Fixed-length iterations, called sprints lasting one to two weeks long, allow the team to ship software on a regular cadence. At the end of each sprint, stakeholders and team members meet to plan next steps.
Scrum follows a set of roles, responsibilities, and meetings that never change. For example, Scrum calls for four ceremonies that provide structure to each sprint: sprint planning, daily stand-up, sprint demo, and sprint retrospective. During each sprint, the team will use visual artifacts like task boards or burndown charts to show progress and receive incremental feedback.
Jeff Sutherland created the Scrum process in 1993, taking the term “Scrum” from an analogy in a 1986 study by Takeuchi and Nonaka published in the Harvard Business Review. In the study, Takeuchi and Nonaka compare high-performing, cross-functional teams to the Scrum formation used by Rugby teams. The original context for this was manufacturing, but Sutherland, along with John Scumniotales and Jeff McKenna, adapted the model for software development.
Advantages of Scrum
Scrum is a highly prescriptive framework with specific roles and ceremonies. While it can be a lot to learn, these rules have a lot of advantages. The benefits of Scrum include:
- More transparency and project visibility: With daily stand-up meetings, the whole team knows who is doing what, eliminating many misunderstandings and confusion. Issues are identified in advance, allowing the team to resolve them before they get out of hand.
- Increased team accountability: There is no project manager telling the Scrum Team what to do and when. Instead, the team collectively decides what work they can complete in each sprint. They all work together and help each other, improving collaboration and empowering each team member to be independent.
- Easy to accommodate changes: With short sprints and constant feedback, it’s easier to cope with and accommodate changes. For example, if the team discovers a new user story during one sprint, they can easily add that feature to the next sprint during the backlog refinement meeting.
- Increased cost savings: Constant communication ensures the team is aware of all issues and changes as soon as they arise, helping to lower expenses and increase quality. By coding and testing features in smaller chunks, there is continuous feedback and mistakes can be corrected early on, before they get too expensive to fix.
Disadvantages of Scrum
While Scrum offers some concrete benefits, it also has some downsides. Scrum requires a high level of experience and commitment from the team and projects can be at risk of scope creep.
Here are the disadvantages of Scrum:
- Risk of scope creep: Some Scrum projects can experience scope creep due to a lack of specific end date. With no completion date, stakeholders may be tempted to keep requesting additional functionality.
- Team requires experience and commitment: With defined roles and responsibilities, the team needs to be familiar with Scrum principles to succeed. Because there are no defined roles in the Scrum Team (everyone does everything), it requires team members with technical experience. The team also needs to commit to the daily Scrum meetings and to stay on the team for the duration of the project.
- The wrong Scrum Master can ruin everything: The Scrum Master is very different from a project manager. The Scrum Master does not have authority over the team; he or she needs to trust the team they are managing and never tell them what to do. If the Scrum Master tries to control the team, the project will fail.
- Poorly defined tasks can lead to inaccuracies: Project costs and timelines won’t be accurate if tasks are not well defined. If the initial goals are unclear, planning becomes difficult and sprints can take more time than originally estimated.
Roles in Scrum
There are three specific roles in Scrum. They are:
- Product Owner: The Scrum Product Owner has the vision of what he or she wants to build and conveys that vision to the team. The Product Owner focuses on business and market requirements, prioritizing all the work that needs to be done. He or she builds and manages the backlog, provides guidance on which features to ship next, and interacts with the team and other stakeholders to make sure everyone understands the items in the product backlog. The Product Owner is not a project manager. Instead of managing the status and progress, his or her job is to motivate the team with a goal and vision.
- Scrum Master: Often considered the coach for the team, the Scrum Master helps the team do their best possible work. This means organizing meetings, dealing with roadblocks and challenges, and working with the Product Owner to ensure the product backlog is ready for the next sprint. The Scrum Master also makes sure the team follows the Scrum process. He or she doesn’t have authority over the team members, but he or she does have authority over the process. For example, the Scrum Master can’t tell someone what to do, but could propose a new sprint cadence.
- Scrum Team: The Scrum Team is comprised of five to seven members. Everyone on the project works together, helps each other, and shares a deep sense of camaraderie. Unlike traditional development teams, there are not distinct roles like programmer, designer, or tester. Everyone completes the set of work together. The Scrum Team owns the plan for each sprint; they anticipate how much work they can complete in each iteration.
Steps in the Scrum Process
There are a specific, unchanging set of steps in the Scrum flow. They include:
- Product backlog: The Product Owner and Scrum Team meet to prioritize the items on the product backlog (the work on the product backlog comes from user stories and requirements). The product backlog is not a list of things to be completed, but rather it is a list of all the desired features for the product. The development team then pulls work from the product backlog to complete during each sprint.
- Sprint planning: Before each sprint, the Product Owner presents the top items on the backlog to the team in a sprint planning meeting. The team then chooses which work they can complete during the sprint and moves the work from the product backlog to the sprint backlog (which is a list of tasks to complete in the sprint).
- Backlog refinement/grooming: At the end of one sprint, the team and Product Owner meet to make sure the backlog is ready for the next sprint. The team may remove user stories that aren’t relevant, create new stories, reassess the priority of stories, or split user stories into smaller tasks. The purpose of this “grooming” meeting is to ensure the backlog only contains items that are relevant and detailed, and that meet the project’s objectives.
- Daily Scrum meetings: The Daily Scrum is a 15-minute stand-up meeting where each team member talks about their goals and any issues that have come up. The Daily Scrum happens every day during the sprint and helps keep the team on track.
- Sprint review meeting: At the end of each sprint, the team presents the work they have completed at a sprint review meeting. This meeting should feature a live demonstration, not a report or a PowerPoint presentation.
- Sprint retrospective meeting: Also at the end of each sprint, the team reflects on how well Scrum is working for them and talks about any changes that need to be made in the next sprint. The team may talk about what went well during the sprint, what went wrong, and what they could do differently.
Tools, Artifacts, and Methods in Scrum
In addition to roles and ceremonies, Scrum projects also include certain tools and artifacts. For example, the team uses a Scrum board to visualize the backlog or a burndown chart to show outstanding work. The most common artifacts and methods are:
- Scrum board: You can visualize your sprint backlog with a Scrum task board. The board can have different forms; it traditionally involves index cards, Post-It notes, or a whiteboard. The Scrum board is usually divided into three categories: to do, work in progress, and done. The Scrum Team needs to update the board throughout the entire sprint. For example, if someone comes up with a new task, she would write a new card and put it in the appropriate column.
- User stories: A user story describes a software feature from the customer’s perspective. It includes the type of user, what they want, and why they want it. These short stories follow a similar structure: as a <type of user>, I want to <perform some task> so that I can <achieve some goal.> The development team uses these stories to create code that will meet the requirements of the stories.
- Burndown chart: A burndown chart represents all outstanding work. The backlog is usually on the vertical axis, with time along the horizontal axis. The work remaining can be represented by story points, ideal days, team days, or other metrics. A burndown chart can warn the team if things aren’t going according to plan and helps to show the impact of decisions.
- Large-Scale Scrum (LeSS): If you want to scale elements of Scrum to hundreds of developers, the Large-Scale Scrum (LeSS) framework helps extend the rules and guidelines without losing the core of Scrum. The principles are taken directly from Scrum, however focuses on scaling up without adding additional overhead (like adding more roles, artifacts, or processes).
- Timeboxing: A timebox is a set period of time during which a team works towards completing a goal. Instead of letting a team work until the goal is reached, the timebox approach stops work when the time limit is reached. Time-boxed iterations are often used in Scrum and Extreme Programming.
- Icebox: Any user stories that are recorded but not moved to development are stored in the icebox.
The term “icebox” was created by Pivotal Tracker, an Agile project management tool.
- Scrum vs RUP: While both Scrum and Rational Unified Process (RUP) follow the Agile framework, RUP involves more formal definition of scope, major milestones, and specific dates (Scrum uses a project backlog instead of scope). In addition, RUP involves four major phases of the project lifecycle (inception, elaboration, construction, and transition), whereas Scrum dictates that the whole “traditional lifecycle” fits into one iteration.
- Lean vs Scrum: Scrum is a software development framework, while Lean helps optimize that process. Scrum’s primary goal is on the people, while Lean focuses on the process. They are both considered Agile techniques, however Lean introduces two major concepts: eliminating waste and improving flow.
How to Get Started with Scrum
Working with Scrum often means changing the team’s habits. They need to take more responsibility, increase the quality of the code, and boost speed of delivery. This level of commitment acts as a change agent; as the teams commit to sprint goals, they are more and more motivated to get better and faster to deliver a quality product.
A good place to start with Scrum is to talk about the roles. Every project must have a Scrum Master, Product Owner, and Scrum Team. You may want to talk about who should be the Scrum Master and Product Owner, or if these roles are already assigned, you may want to clarify their roles and responsibilities.
Depending on how familiar your team is with Scrum, you may also want to look into training sessions. Certified Scrum Coaches and Trainers and Scrum Alliance Registered Education Providers can help your team learn and embrace Scrum.
Our newest view, Card View, gives Agile teams a more highly-visual way to work, communicate, and collaborate in Smartsheet. Card View enables you to focus attention with rich cards, give perspective with flexible views, and prioritize and adjust work more visually. Display information on cards including custom fields, images, and color coding to better focus your team’s attention. Categorize cards into lanes to organize your work more visually.
See how easy it can be to use Smartsheet Card View during your next Scrum meeting.
Code Simplicity is a companion blog to author Max Kanat-Alexander’s application design book Code Simplicity: The Science of Software Development. Max is a software engineer at Google, and the chief architect of the Bugzilla Project – and his blog draws upon this experience to offer advice on simplifying software design. His mantra is ‘Complexity is stupid. Simplicity is smart’ – and after reading the blog, I’m inclined to agree.
In addition to being a former Microsoft program manager, Joel Spolsky is a co-founder of programming Q&A site StackExchange, the man behind software development company Fog Creek Software, and the awesome little browser-based workflow tool Trello. He’s been blogging since 2000, and his site is a goldmine of insight on software dev, management and business.
3) Scott Berkun
Scott Berkun’s eponymous blog is one of the most multi-faceted on this list, offering advice and insight into creativity, leadership and philosophy – alongside his experiences as a manager at giants Microsoft and WordPress. If you’re tired of reading the same old blog content, Scott’s blog offers a plethora of engaging info, all of which is designed to help you become a better person, as well as a better programmer.
Coding Horror is the outlet of seasoned web application developer (and, like Joel Spolsky above, co-founder of StackExchange) Jeff Atwood. The blog tackles all manner of software development and security topics, but it’s Jeff’s interest in the human component of development that makes the blog stand out. As Jeff himself says:
‘In the art of software development, studying code isn't enough; you have to study the people behind the software, too.’
Scott Hanselman’s blog tackles the full pantheon of software developer interests, covering technology, code, gadgets, dev culture and the web. As a former professor, and current employee of Microsoft, his hands-on advice is clear, concise and helpful. Unlike many of his contemporaries, Scott’s writing is also bursting with personality. If you’re a fan of Scott’s insight, you can also check out his three podcasts and YouTube channel.
Andy Hunt is a prolific author, a co-founder of the Agile Alliance, and part of the team that developed the Agile Manifesto. Andy’s blog tackles a diverse range of development topics, and unsurprisingly, offers some of the most interesting and unique insight into agile development anywhere on the web.
Paul Graham was one-half of the duo behind Viaweb, arguably the very first (started in 1995) software as a service company. Since then, he’s gone on to co-found Y Combinator, a start-up incubator that’s funded the likes of Dropbox, Reddit and Airbnb. Paul Graham’s Essays collates his long-form insights into developing SaaS businesses, and provides developers a wonderful insight into their role within the wider business world.
Federico is a professional mobile and web developer, and regularly blogs around coding (particularly PHP), software architecture and agile development. With a mixture of straight-to-the-point tutorials and, courtesy of his Twitter, a ton of tech news and insight, Frederico’s blog is a great read for any software developer.
10) David Walsh
Ponitkis is a blog of two halves, offering the latest in web technology, business and news, alongside a plethora of how-tos and guides. Author Christos Pontikis offers seriously in-depth instructions on all-manner of languages and frameworks, with his expert insights into PHP, jQuery and MySQL a serious incentive for any knowledge-hungry developers.
12) Six Revisions
13) Web Appers
WebAppers dedicates itself to sourcing and collating free open-source tools and resources, with the professional web dev and web designer in mind. In addition to a pantheon of almost 700 plugins, the blog shares a ton of actionable guidance and helpful advice, with a view to helping web developers use the tools in the most beneficial way possible.
Since its inception in 2005, ProgrammableWeb has been at the forefront of the evolving API economy. It offers a staggering amount of hands-on content, and manages to maintain its quality across an incredible publication schedule ranging as high as 10 posts per day. In addition to its fantastic blog content, ProgrammableWeb has a huge directory of APIs for web and mobile development, and a plethora of whitepapers and research.
16) Martin Fowler
Software developer Martin Fowler is a prolific author (having penned no less than seven programming books), and an even more prolific blogger. He writes primarily around agile, refactoring and project delivery – with a particular focus on the design of software systems, and ways to maximise the productivity of development. Whilst the blog is a great resource for all types of developer, it should have a special interest to those managing a development team.
17) Eric Sink
Eric Sink is a software developer at SourceGear – but prior to his current role, he served as project lead for the browser development team that prototyped a little-known browser called ‘Internet Explorer’. Since then, Eric has been blogging consistently around software development, with his advice, news roundups and opinions stretching all the way back to 2001.
18) The Daily WTF
If you’re looking to break-up the monotony of personal development, The Daily WTF should provide ample relief. The site pairs genuinely helpful development insights with an awesome sense of humour, creating a blog that’s as funny to read as it is useful. The site has a particular focus on how-not-to-guides, and the disastrous development stories its shares will easily consume your lunch break.
19) UIE Brainsparks
User Interface Engineering is a research and training company focused on web and application usability. Its Brainsparks blog is an industry-leading resource, covering all aspects of UI and UX development – with founder Jared Spool offering his expert insight on a weekly basis. In addition to the blog, UIE offer podcasts, long-form articles, event and seminars for devs interested in improving their UI skills.
Programmer turned publisher Dave Thomas blogs and tweets about all manner of development news and advice. Alongside tutorials, guides and opinions, Dave has developed his own Zen-like approach to the art of coding – creating the martial arts inspired CodeKata to help developers change their attitude to coding, and develop an always-learning mindset.
Open development breaks the data center down into its lowest-level components, which fit together by open standards. Still, with less than 2% of enterprise applications designed for horizontal scaling, enterprise IT should avoid lifting legacy apps onto open infrastructure.
Instead, put new workloads on building-block infrastructure, and renegotiate your hardware contracts to get ready for more open-standard hardware and software.
he problem, however, is IT administrators love scripts. They love creating the best scripts, fiddling with scripts that come from colleagues, and leaving little documentation when they move on to another job. IT automation must evolve from scripting to deterministic (defined workloads for tasks) then to heuristic design (automation based on data fed in operations). There are banks today that use heuristic automation because they have all the hardware that you could want, Govekar said. But they lack the ability to automatically place workloads that best at any given moment.
the control plane is abstracted from the hardware, and it's going on with every piece of equipment a data center can buy. Software-defined servers are established, software-defined networking is maturing and software-defined storage won't have much impact until at least 2017, Govekar said.
Don't approach software-defined everything as a cost saving venture, because the real point is agility. Avoid vendor lock-in in this turbulent vendor space, and look for interoperable application programming interfaces that enable data-center-wide abstraction. Also, keep in mind that the legacy data center won't die without a fight.
Big data analysis is used in a number of ways to solve problems today. For example, police departments reduce crime without blanketing the city with patrol cars, by pinpointing likely crime hot spots at a given point in time based on real-time and historical data.
Build new data architectures to handle unstructured data and real-time input, which are disruptive changes today. The biggest inhibitor to enterprise IT adoption of big data analytics, however, isn't the data architecture; it's a lack of big data skills.
Internet of Everything
is IT in charge of the coffee pot? If it has an IP address and connects to the network, it might be.
Internet-connected device proliferation combined with big data analytics means that businesses can automate and refine their operations. It also means security takes on a whole new range of end points. In data center capacity management, Internet of Everything means demand shaping and customer priority tiering, rather than simply buying more hardware.
Build a data center that can change, don't build to last, Govekar said.
For better or worse, business leaders want to know why you can't do what Google, Facebook and Amazon do.
Conventional hardware and software are not built for webscale IT, which means this trend relies on software-defined everything and open philosophies like the Open Compute Project. It also relies on a major attitude adjustment in IT where experimentation and failure are allowed.
our workforce is mobile. Your company's customers are mobile. Bring your own device has morphed into bring your own toys. The IT service desk can't fall behind this trend and risk giving IT a reputation of being out of touch.
Bring data segregation -- personal and business data and applications isolated from each other on the same device -- onto your technology roadmap now.
No one's congratulating IT on keeping the lights on and the servers humming, no matter how difficult it can be. Bimodal IT means maintaining traditional IT practices while simultaneously introducing innovative new processes -- safely.
Take the pace layering concept from application development and apply it to IT's roadmap, and find ways to get close to customers. Bimodal IT will make your team more diverse.
Business value dashboards
By 2017, the majority of infrastructure and operations teams will use dashboards to communicate with the outside world. Govekar made the analogy of the business-value dashboard vs. IT metrics to cruise ship reviews vs. cruise ship boiler calibration reports. They serve different purposes.
All the trends above feed shadow IT, where the business units steer around IT to gain agility.
Some IT teams are trying a new approach; rather than quash all shadow IT operations they find, these companies allow business users to set up shadow IT for projects and track the performance like a proof-of-concept trial. If the deployment succeeds, IT formally folds shadow IT into the organization.
- Definitions ?
DevOps is a new term emerging from the collision of two major related trends. The first was also called “agile system administration” or “agile operations”; it sprang from applying newer Agile and Lean approaches to operations work. The second is a much expanded understanding of the value of collaboration between development and operations staff throughout all stages of the development lifecycle when creating and operating a service, and how important operations has become in our increasingly service-oriented world
One definition Jez Humble explained to me is that DevOps is “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale.”
That’s good and meaty, but it may be a little too esoteric and specific to Internet startup types. I believe that you can define DevOps more practically as DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.
DevOps means a lot of different things to different people because the discussion around it covers a lot of ground. People talk about DevOps being “developer and operations collaboration,” or it’s “treating your code as infrastructure,” or it’s “using automation,” or “using kanban,” or “a toolchain approach,” or “culture,” or a variety of seemingly loosely related items. The best way to define it in depth is to use a parallel method to the definition of a similarly complex term, agile development. Agile development, according to Wikipedia and the agile manifesto, consists of four different “levels” of concern. I’ve added a fifth, the tooling level – talk about agile and devops can get way too obsessed with tools, but pretending they don’t exist is also unhelpful.
- Agile Values – Top level philosophy, usually agreed to be embodied in the Agile Manifesto. These are the core values that inform agile.
- Agile Principles – Generally agreed upon strategic approaches that support these values. The Agile Manifesto cites a dozen of these more specific principles. You don’t have to buy into all of them to be Agile, but if you don’t subscribe to many of them, you’re probably doing something else.
- Agile Methods – More specific process implementations of the principles. XP, Scrum, your own homebrew process – this is where the philosophy gives way to operational playbooks of “how we intend to do this in real life.” None of them are mandatory, just possible implementations.
- Agile Practices – highly specific tactical techniques that tend to be used in conjunction with agile implementations. None are required to be agile but many agile implementations have seen value from adopting them. Standups, planning poker, backlogs, CI, all the specific artifacts a developer uses to perform their work.
- Agile Tools – Specific technical implementations of these practices used by teams to facilitate doing their work according to these methods. JIRA Agile (aka Greenhopper), , et al.
the different parts of DevOps that people are talking about map directly to these same levels.
- DevOps Values – I believe the fundamental DevOps values are effectively captured in the Agile Manifesto – with perhaps one slight emendation to focus on the overall service or software fully delivered to the customer instead of simply “working software.” Some previous definitions of DevOps, like Alex Honor’s “People over Process over Tools,” echo basic Agile Manifesto statements and urge dev+ops collaboration.
- DevOps Principles – There is not a single agreed upon list, but there are several widely accepted attempts – here’s John Willis coining “CAMS” and here’s James Turnbull giving his own definition at this level. “Infrastructure as code” is a commonly cited DevOps principle. I’ve made a cut at “DevOps’ing” the existing Agile manifesto and principles here. I personally believe that DevOps at the conceptual level is mainly just the widening of Agile’s principles to include systems and operations instead of stopping its concerns at code checkin.
- DevOps Methods – Some of the methods here are the same; you can use Scrum with operations, Kanban with operations, etc. (although usually with more focus on integrating ops with dev, QA, and product in the product teams). There are some more distinct methods, like Visible Ops-style change control and using the Incident Command System for incident reponse. The set of these methodologies are growing; a more thoughtful approach to monitoring is an area where common methodologies haven’t been well defined, for example.
- DevOps Practices –Specific techniques used as part of implementing the above concepts and processes. Continuous integration and continuous deployment, “Give your developers a pager and put them on call,” using configuration management, metrics and monitoring schemes, a toolchain approach to tooling… Even using virtualization and cloud computing is a common practice used to accelerate change in the modern infrastructure world.
- DevOps Tools – Tools you’d use in the commission of these principles. In the DevOps world there’s been an explosion of tools in release (jenkins, travis, teamcity), configuration management (puppet, chef, ansible, cfengine), orchestration (zookeeper, noah, mesos), monitoring, virtualization and containerization (AWS, OpenStack, vagrant, docker) and many more. While, as with Agile, it’s incorrect to say a tool is “a DevOps tool” in the sense that it will magically bring you DevOps, there are certainly specific tools being developed with the express goal of facilitating the above principles, methods, and practices, and a holistic understanding of DevOps should incorporate this layer.
Mark Zukerberg's challenge for 2016 was to build a simple AI to run his home -- like Jarvis in Iron Man. His goal was to learn about the state of artificial intelligence -- where we're further along than people realize and where we're still a long ways off. These challenges always lead me to learn more than he expected, and this one also gave me a better sense of all the internal technology Facebook engineers get to use, as well as a thorough overview of home automation.
So far this year, he has built a simple AI that he can talk to on his phone and computer, that can control his home, including lights, temperature, appliances, music and security, that learns his tastes and patterns, that can learn new words and concepts, and that can even entertain Max. It uses several artificial intelligence techniques, including natural language processing, speech recognition, face recognition, and reinforcement learning, written in Python, PHP and Objective C. In this note, he'll explain what he built and what he learned along the way.
- Getting Started: Connecting the Home
In some ways, this challenge was easier than he expected. In fact, my running challenge (I also set out to run 365 miles in 2016) took more total time. But one aspect that was much more complicated than he expected was simply connecting and communicating with all of the different systems in my home.
Before he could build any AI, he first needed to write code to connect these systems, which all speak different languages and protocols. We use a Crestron system with our lights, thermostat and doors, a Sonos system with Spotify for music, a Samsung TV, a Nest cam for Max, and of course my work is connected to Facebook's systems. he had to reverse engineer APIs for some of these to even get to the point where he could issue a command from my computer to turn the lights on or get a song to play.
Further, most appliances aren't even connected to the internet yet. It's possible to control some of these using internet-connected power switches that let you turn the power on and off remotely. But often that isn't enough. For example, one thing he learned is it's hard to find a toaster that will let you push the bread down while it's powered off so you can automatically start toasting when the power goes on. he ended up finding an old toaster from the 1950s and rigging it up with a connected switch. Similarly, he found that connecting a food dispenser for Beast or a grey t-shirt cannon would require hardware modifications to work.
For assistants like Jarvis to be able to control everything in homes for more people, we need more devices to be connected and the industry needs to develop common APIs and standards for the devices to talk to each other
- natural language
This was a two step process: first he made it so he could communicate using text messages, and later he added the ability to speak and have it translate my speech into text for it to read.
It started simple by looking for keywords, like "bedroom", "lights", and "on" to determine he was telling it to turn the lights on in the bedroom. It quickly became clear that it needed to learn synonyms, like that "family room" and "living room" mean the same thing in our home. This meant building a way to teach it new words and concepts.
- Vision and Face Recognition
Even though he think text will be more important for communicating with AIs than people realize, he still think voice will play a very important role too. The most useful aspect of voice is that it's very fast. You don't need to take out your phone, open an app, and start typing -- you just speak.
To enable voice for Jarvis, he needed to build a dedicated Jarvis app that could listen continuously to what he say. The Messenger bot is great for many things, but the friction for using speech is way too much. My dedicated Jarvis app lets me put my phone on a desk and just have it listen. he could also put a number of phones with the Jarvis app around my home so he could talk to Jarvis in any room. That seems similar to Amazon's vision with Echo, but in my experience, it's surprising how frequently he want to communicate with Jarvis when I'm not home, so having the phone be the primary interface rather than a home device seems critical.
- Facebook Engineering Environtment
As the CEO of Facebook, he don't get much time to write code in our internal environment. he has never stopped coding, but these days he mostly build personal projects like Jarvis. he expected he'd learn a lot about the state of AI this year, but he didn't realize he would also learn so much about what it's like to be an engineer at Facebook. And it's impressive.
My experience of ramping up in the Facebook codebase is probably pretty similar to what most new engineers here go through. he was consistently impressed by how well organized our code is, and how easy it was to find what you're looking for -- whether it's related to face recognition, speech recognition, the Messenger Bot Framework [messenger.com/platform] or iOS development. The open source Nuclide [github.com/facebook/nuclide] packages he ve built to work with GitHub's Atom make development much easier. The Buck [buckbuild.com] build system he ve developed to build large projects quickly also saved me a lot of time. Our open source FastText [github.com/facebookresearch/fastTex...] AI text classification tool is also a good one to check out, and if you're interested in AI development, the whole Facebook Research [github.com/facebookresearch] GitHub repo is worth taking a look at.
One of our values is "move fast". That means you should be able to come here and build an app faster than you can anywhere else, including on your own. You should be able to come here and use our infra and AI tools to build things it would take you a long time to build on your own. Building internal tools that make engineering more efficient is important to any technology company, but this is something we take especially seriously. So he want to give a shout out to everyone on our infra and tools teams that make this so good.
Perbedaan QA engineer dan QA tester
Pada beberapa perushaan startup kita kerap kali mendengar istilah QA engineer dan QA tester. Kedua jabatan tersebut sangat penting dalam menjaga kualitas perangkat lunak. Apakah perbedaan antara QA engineer dan QA tester ?
QA engineer lebih fokus pada bagaimana proses pengembangan perangkat lunak dilakukan dengan baik daripada bagaimana hasil akhir perangkat lunak yang dihasilkan. Tugas QA engineer memastikan setiap proses pengembangan perangkat lunak berjalan dengan baik guna menjaga kualitas pengembangan perangkat lunak. Menjaga kualitas proses programming dan build/test menjadi salah satu fokus utama pada pekerjaan QA engineer.
Beberapa tugas QA engineer adalah
- Function – Test planning, Test Design and execution.
- Prepare test plans, develop test cases and execute tests with a focus on coverage.
- Engineers Quality. Good to answer – what is the quality of the product?
- Logical thinkers. Ability to resolve issues using abstraction. Capability in analysis/predictions/improvements.
- Can reconcile conflicting constraints.
- Process and metrics/measurement driven.
- Cost sensitive
- Good for System/functionality testing
- Best to have them involved in complete SDLC Cycle.
Berbeda dengan QA engineer, QA tester lebih berfokus kepada kualitas perangkat lunak yang digunakan. Pengujian-pengujian yang dilakukan oleh QA tester lebih fokus pada metode black-box. QA tester bertugas memastikan perangkat lunak yang di hasilkan sudah sesuai dengan keinginan user.
Beberapa tugas QA tester antara lain
- Function – Strong in test execution.
- Write and execute test cases – may not be coverage driven. Requirements driven testing.
- Determines Quality. Good to answer – did you find any bugs?
- Linear thinkers, low capability of analysis and re-usability of efforts/resources.
- Requires a defined environment. Typically are weak in finding solutions in ambiguous/constrained environments.
- Low process oriented capability.
- May not be cost sensitive (time, effort, monetary, etc.)
- Good for UI Testing
- Typical involvement is in later stage of SDLC
Kesimpulan yang bisa kita ambil, untuk menjaga kualitas perangkat lunak maka dibutuhkan proses QA pada proses pembangunan perangkat lunak/SDLC dan setelah perangkat lunak jadi dan siap rilis. Untuk memenuhi kebutuhan tersebut jabatan QA dibagi menjadi QA engineer dan QA tester. Dimana QA engineer fokus pada proses SDLC dan QA tester fokus pada proses setelah SDLC atau sebelum delivery ke user.
karena QA engineer melakukan test pada setiap proses SDLC dibandingkan dengan QA tester yang hanya berfokus pada testing aplikasi yang sudah jadi. QA engineer memiliki beban kerja yang lebih berat, sehingga salary pun lebih tinggi dari QA tester.
Jadi mau pilih yang mana?, QA engineer atau QA tester?
Software Framework adalah sebuah abstraksi yang digunakan untuk mempermudah pembuatan perangkat lunak. Software Framework menyamakan persepsi setiap pengembang pada abstraksi yang sama. Penyamaan persepsi ini mempermudah pengembang baru untuk mengetahui keseluruhan perangkat lunak dengan lebih cepat. Paradigma yang paling populer digunakan pada software framework adalah MVC. MVC memisahkan aplikasi menjadi 3 bagian fungsionalitsa yaitu model,view, dan controller.
Beberapa software framework yang sering digunakan adalah
- Laravel : full-stack web framework menggunakan paradigma MVC, memiliki fitur yang sangat lengkap dan pemodelan ORM(Object Relational Mapping) pada database
- CodeIgniter: full-stack web framework menggunakan paradigma MVC, memiliki fitur yang umum dan berjalan cepat dibandingkan framework php lainnya
- Lumen : Rest Api web framework dari Laravel. Lumen adalah versi REST API dari Laravel,lumen memiliki fitur yang lebih simpel dibandingkan Laravel
- Yii : full-stack web framework menggunakan paradigma MVC memiliki fitur lengkap dan beberapa scaffolding.
- Flask : minimal web framework, digunakan untuk membangun aplikasi web atau API
- Djanggo : full-stack web framework dengan paradigma MVC digunakan untuk membuat aplikasi web yang utuh
- Ruby on Rails: Pesaing laravel, memiliki kelengkapan fitur seperti laravel dan berjalan menggunakan bahasa ruby, memiliki kelebihan pada syntax nya yang sederhana.
Pemanfaatan teknologi elektronik untuk menyampaikan, mendukung dan meningkatkan pengajaran dan pembelajaran (oleh : Learning Skills Development Agency [LSDA]).
Penggunaan teknologi multimedia dan Internet untuk meningkatkan kualitas pembelajaran dengan memfasilitasi akses ke sumber daya dan layanan serta kolaborasi sesama member (UE)
jika seseorang belajar dengan cara yang menggunakan teknologi informasi dan komunikasi (TIK), dengan menggunakan elearning (oleh : DfES)
Tersedianya fasilitas e-moderating dimana pengajar dan siswa dapat berkomunikasi secara mudah melalui fasilitas internet secara reguler atau kapan saja kegiatan berkomunikasi itu dilakukan tanpa dibatasi oleh jarak, tempat, dan waktu.
Pengajar dan siswa dapat menggunakan bahan ajar yang terstruktur dan terjadwal melalui internet.
Siswa dapat belajar (me-review) bahan ajar setiap saat dan dimana saja apabila diperlukan mengingat bahan ajar tersimpan di komputer.
Bila siswa memerlukan tambahan informasi yang berkaitan dengan bahan yang dipelajarinya, ia dapat melakukan akses di internet.
Baik pengajar maupun siswa dapat melakukan diskusi melalui internet yang dapat diikuti dengan jumlah peserta yang banyak.
Berubahnya peran siswa dari yang pasif menjadi aktif.
Relatif lebih efisien. Misalnya bagi mereka yang tinggal jauh dari Perguruan Tinggi atau sekolah konvensional dapat mengaksesnya.
interaksi antara pengajar dan siswa atau bahkan antara siswa itu sendiri, bisa memperlambat terbentuknya values dalam proses belajar mengajar.
Kecenderungan mengabaikan aspek akademik atau aspek sosial dan sebaliknya mendorong aspek bisnis atau komersial.
Proses belajar dan mengajarnya cenderung ke arah pelatihan dari pada pendidikan.
Berubahnya peran guru dari yang semula menguasai teknik pembelajaran konvensional, kini dituntut untuk menguasai teknik pembelajaran dengan menggunakan ICT (Information Communication Technology).
Siswa yang tidak mempunyai motivasi belajar yang tinggi cenderung gagal.
Tidak semua tempat tersedia fasilitas internet (berkaitan dengan masalah tersedianya listrik, telepon, dan komputer).
Kurangnya mereka yang mengetahui dan memiliki keterampilan tentang internet.
Kurangnya penguasaan bahasa komputer.
Computer Based Training (CBT)
eLearning dengan komunikasi satu arah, merupakanawal kemunculan aplikasi e-learning yang berjalan di PC standalone ataupun dalam kemasan CD-ROOM. Isi berupa materi dalam bentuk tulisan maupun multimedia (video dan audio) dalam format MOV, MPEG-1 atau AVI. Dengan menggunakan tools yang disediakan maka pengguna mempunyai kesempatan untuk mencoba soal-soal latihan tanpa batasan jumlah dan tingkat kesulitannya, Contohnya :
- Toolbox (keluaran perusahaan Asymetrix sekarang bernama Clickllearn)
- Autoware (keluaran Macromedia ).
LMS (LearningManagement System)
Seiring dengan perkembangan teknologi internet di dunia, masyarakat dunia mulai terkoneksi dengan internet. Kebutuhan akan informasi yang cepat diperoleh menjadi mutlak, dan jarak serta lokasi bukanlah halangan lagi. Disinilah muncul sebuah Learning Management System atau biasa disingkat dengan LMS. Perkembangan LMS yang semakin pesat membuat pemikiran baru untuk mengatasi masalah interoperability antar LMS yang ada dengan suatu standard. Standard yang muncul misalnya adalah standard yang dikeluarkan oleh AICC (Airline Industry CBT Committee), IMS, IEEE LOM, ARIADNE, dsb. Contoh aplikasi ini adalah
- Atutor, yang mana aplikasi ini terdapat fasilitas penulisan materi, upload materi, penugasan, pembuatan bank soal, pengujian dan penilaian serta fasilitas komunikasi (chatting, forum dan blog) dan modul lainnya (kalender dan photoalbum).
Aplikasi e-learning berbasis web
Perkembangan LMS menuju ke aplikasi e-learning berbasis Web secara total, baik untuk pembelajar (learner) maupun administrasi belajar mengajarnya. LMS mulai digabungkan dengan situs-situs portal yang pada saat ini boleh dikata menjadi barometer situs-situs informasi, majalah, dan surat kabar dunia. Isi juga semakin kaya dengan berpaduan multimedia, video streaming, serta penampilan interaktif dalam berbagai pilihan format data yang lebih standard, berukuran kecil dan stabil. Contoh aplikasi ini adalah Dokeos. Dokeos merupakan free software yang di release oleh GNU GPL dan pengembangannya didukung oleh dunia internasional. Sistem operasinya bersertifikasi yang bisa digunakan sebagai konten dari sistem managemen untuk pendidikan. Kontennya meliputi distribusi bahan pelajaran, kalender, progres pembelajaran, percakapan melalui text/audio maupun video, administrasi test, dan menyimpan catatan. Tujuan utama dari dokeos adalah menjadi sistem yang userfriendly dan flexibel serta mudah dipakai.
Berikut beberapa tool yang biasa digunakan untuk merancang pemodelan dalam pengembangan perangkat lunak :
- offline :
webSequenceDiagrams > https://www.websequencediagrams.com/
colorcombos > http://www.colorcombos.com/
mockflow > http://share.its.ac.id/app.mockflow.com/
Dalam rekayasa sistem dan rekayasa perangkat lunak, analisis kebutuhan mencakup pekerjaan-pekerjaan penentuan kebutuhan atau kondisi yang harus dipenuhi dalam suatu produk baru atau perubahan produk, yang mempertimbangkan berbagai kebutuhan yang bersinggungan antar berbagai pemangku kepentingan. Kebutuhan dari hasil analisis ini harus dapat dilaksanakan, diukur, diuji, terkait dengan kebutuhan bisnis yang teridentifikasi, serta didefinisikan sampai tingkat detail yang memadai untuk desain sistem.
Analisis kebutuhan merupakan langkah awal untuk menentukan gambaran perangkat yang akan dihasilkan ketika pengembang melaksanakan sebuah proyek pembuatan perangkat lunak. Perangkat lunak yang baik dan sesuai dengan kebutuhan pengguna sangat tergantung pada keberhasilan dalam melakukan analisis kebutuhan. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah aktivitas sistem information engineering dan software project planning.
Analisa kebutuhan yang baik belum tentu menghasilkan perangkat lunak yang baik, tetapi analisa kebutuhan yang tidak tepat menghasilkan perangkat yang tidak berguna. Mengetahui adanya kesalahan pada analisis kebutuhan pada tahap awal memang jauh lebih baik, tapi kesalahan analisis kebutuhan yang diketahui ketika sudah memasuki penulisan kode atau pengujian, bahkan hampir masuk dalam tahap penyelesaian merupakan malapetaka besar bagi pembuat perangkat lunak. Biaya dan waktu yang diperlukan akan menjadi sia sia.
Ada 3 faktor yang harus dipenuhi ketika melakukan analisa kebutuhan ini yaitu : lengkap, detail, dan benar. Lengkap artinya semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisa. Sedangkan detail maksudnya adalah berhasil mengumpulkan informasi yang rinci sampai hal-hal yang kecil. Semua data dari analisa kebutuhan ini haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang difikirkan oleh pihak yang melakukan analisa. Sebuah kutipan anonim yang sering disampaikan mengenai hal ini adalah : “Saya percaya anda sangat mengerti dengan apa yang saya katakan, namun saya tidak yakin bahwa apa yang anda dengar adalah sama dengan apa yang saya maksud”.
Analisa kebutuhan ini terdiri dari lima langkah pokok:
2.Evaluasi dan sintesis
Tujuan analisis kebutuhan
Ada tiga tujuan utama dari proses analasis kebutuhan yang dapat diformulasikan sebagai beriukut :
- Mengelola hasil elistasi kebutuhan untuk menghasilkan dokumen spesifikasi kebutuhan yang isi keseluruhannya sesuai dengan apa yang diinginkan pengguna (Liu and Yen, 1996).
- Mengembangkan persyaratan kualitas yang memadai dan rinci, dimana para manajer dapat membuat pekerjaan proyek yang realistis dan staf teknis dapat melanjutkan dengan perancangan, implementasi dan pengujian (Wiegers, 2003).
- Membangun pemahaman tentang karakteristik ranah permasalahan dan sekumpulan kebutuhan untuk menemukan solusi
Ketiga tujuan tersebut dapat dicapai oleh perekayasa kebutuhan dengan melalui serangkaian tahapan-tahapan aktivitas.
Tahap Analisis Kebutuhan
Domain Understanding, dalam tahap ini perekayasa kebutuhan perangkat lunak harus mengetahui bagaimana organisasi perusahaan beroperasi dan apa yang menjadi permasalahan pada sistem yg sedang berjalan pada saat ini. perekayasaan perlu memfokuskan kepada ‘Apa’ yg menjadi permasalahan. Perekaysaan hendaknya tidak berhenti pada menemukan “gejala” dari permasalahn itu terjadi untuk menemukan akar dari pemasalahan dari sistem yg berjalan tersebut.
Requirements Collection, Tahapan ini merupakan tahapan pengumpulan kebutuhan akan sistem yang akan dibangun.Pada tahapan ini diperlukan adanya intekasi intensif dengan pemangku kepentingan terutama dengan pengguna akhir.
Classification, Pada tahapan sebelumnya kumpulan kebutuhan masih tidak terstruktur.Untuk itu kebutuhan yang saling berkaitan dikelompokan,baik menurut kelas penggunaanya maupun jenis kebutuhananya. Kebutuhan kebutuhan tersebut diorganisasi ke dalam kelompk-kelompok yang koheren.Perekayasaan perlu memisahkan antara kebutuhan dan keinginan dari pengguna.
Conflict resolution, Pada tahapan ini adalah menemukan dan menyelesaikan kebutuhan yang di dalamnya terdapat konflik.
Prioritisation, Pada tahapan dilakukan interaksi dengan pemangku kepentingan untuk mengidentifikasikan kebutuhan-kebutuhan priopritas dari masing-masing kebutuhan agar sumber daya yang tersedia pada organisasi dialokasikan untuk mengimplementasikan kebutuhan yg terutama dari pemangku kepentingan.
Requirements Checking, Menganalisa sekumpulan kebutuhan dari hasil tahapan sebelumnya untuk memverifikasi dan memvalidasi berdasarkan aspek kelengkapan,konsistensi,dan kebutuhan nyata.
Dalam rekayasa kebutuhan, analisa kebutuhan yang baik hedaklah menitik beratkan pada ranah permasalahan dan bukan pada ranah solusi. Tujuan utamanya adalah untuk mencapai pemahaman tetang sifat dari ranah permasalahan dan permasalahan yang ada didalamnya . Pada dasarnya, analisi kebutuhan diawali dengan spesifikasi (layanan, atribut, properti, kualitas, batasan) dari sistem solusi yang hendak dibangun.
Kegunaan analisis adalah untuk memodelkan permasalahan dunia nyata agar dapat dimengerti. Permasalahan dunia nyata harus dimengerti dan dipelajari supaya spesifikasi kebutuhan perangkat lunak dapat diungkapkan. Tujuan aktivitas ini adalah untuk mengetahui ruang lingkup produk (product space) dan pemakai yang akan menggunakannya. Analisis yang baik akan mengungkapkan hal-hal yang penting dari permasalahan, dan mengabaikan yang tidak penting.