5. A study by the Standish Group indicates how often
features are used in a typical application
Source: Jim Johnson of the
Standish Group,
Keynote Speech XP 2002
14. Daily Scrum Meeting (Daily Standup)
Morning Huddle Meeting
The Daily Scrum is the team’s chance to get together.
define a plan for the day’s work, and identify any
blockers.
● What did you do yesterday?
● What will you do today?
● Are there any impediments in the way?
16. Sprint Restrospective
During the Sprint Retrospective, the team discusses:
● What went well in the Sprint.
● What went well in the Sprint.
● What could be improved.
What Happens in Retrospective
Stays in Retrospective
What Happens in Retrospective
Stays in Retrospective
https://www.pointingpoker.com/
17. Backlog Grooming/Refinement
● Removing user stories that no longer appear relevant.
● creating new user stories in response to newly discovered needs.
● Re-assessing the relative priority of stories.
● correcting estimates in light of newly discovered information.
● Splitting user stories which are high priority but too coarse grained to
fit in an upcoming iteration.
19. Sprint Artifacts
Scrum Artifacts provide key information that the
Scrum Team and the stakeholders need to be aware of
for understanding the product under development, the
activities being planned, and the activities done in
the project. The following artifacts are defined in
Scrum Process Framework.
23. Testing In Agile Team
“Core features should never be negatively impacted
by new features or deployed updates.”.
Dalam agile practice, delivery bisa jadi dilakukan per-
feature, per-sprint atau perbeberapa sprint. Intensitas
deployment ditambah adanya otomatisasi continues
deployment. Dengan kondisi seperti ini maka melakukan
regression test secara manual tidak mungkin dilakukan.
24. ● Pentingnya testing supaya mengetahui apakah fitur baru mengganggu fitur2
lama.
● KIta bisa agile kalo setiap perubahan yang kita lakukan bisa diketahui
impactnya dimana dan apa saja.
https://medium.com/ppl-sutopo/agile-manifesto-a6c2cd69ff67
1. Individuals and Interactions Over Processes and Tools
Individu dan interkasi antar individu pelaku development lebih diutamakan dibandingkan prosesnya.
Jika disetir oleh proses, bisa jadi komunikasi antar anggota harus terstruktur, terjadwal, dan kontennya spesifik (Harus fleksibel dan bisa diatur kemudian asal terukur tidak menggangu sprint goal).
Pentingnya interaksi juga menandakan bahwa developer tidak boleh “masa bodoh” dengan pekerjaan developer lain (Bukan cuma sekedar melempar bola panas).
2. Working Software Over Comprehensive Documentation
Pada agile, lebih diutamakan working produk yang terdeliver ke klien dengan cepat, hal-hal terkait dokumentasi tersebut dikurangi.
Agile tetap memperhatikan dokumentasi meskipun working software lebih diutamakan.
Dokumentasi requirement diwujudkan sebagai user stories, dan itu sudah cukup untuk developer untuk memulai.
3. Customer Collaboration Over Contract Negotiation
Waterfall, klien bernegosiasi dengan development terkait requirement produk secara detail sebelum development dimulai (lempar-lemparan antara tembok).
Iterasi yang dilengkapi dengan kolaborasi dengan klien akan lebih efektif untuk development.
Developer diuntungkan karena spesifikasi produk menjadi lebih jelas dan mengeliminasi adanya fitur yang kurang feasible.
klien juga diuntungkan karena mendapatkan produk yang lebih sesuai dengan keinginannya.
4. Responding to Change Over Following a Plan
Waterfall tidak fleksibel terhadap perubahan, sehingga sekarang banyak dihindari.
Pada Agile, development lebih fleksibel terhadap perubahan. Agile menggunakan iterasi yang pendek dan fitur baru dapat ditambahkan pada iterasi berikutnya.
Menurut Agile, fleksibilitas terhadap perubahan dapat meningkatkan kualitas project.
Small Working Team
http://disciplinedagiledelivery.com/agility-at-scale/large-agile-teams/
Team Picture https://i0.wp.com/disciplinedagiledelivery.com/wp-content/uploads/2014/12/Team-Product-Delivery.png?w=794
Embrace Changing Requirement
https://www.scrum.org/forum/scrum-forum/12885/change-during-sprint-initiated-product-owner
1. The change should not violate the sprint goal.
2. The development team 'owns' the sprint backlog. Changes should be negotiated with the dev team.
Deliver FInished Work Properly and Release Product Whenever Required
https://www.knowledgehut.com/tutorials/scrum-tutorial/release-planning
Release Picture https://d14b9ctw0m6fid.cloudfront.net/tutorials/topics/images/1532059486410-image3.jpg
A Scrum Team is a collection of individuals (typically between five and nine members) working together to deliver the required product increments. The Scrum framework encourages a high level of communication among team members, so that the team can:
Follow a common goal
adhere the same norms and rules
show respect to each other
-----------------------------------------------------------------------------------------------------
Small Working Team
http://disciplinedagiledelivery.com/agility-at-scale/large-agile-teams/
Team Picture https://i0.wp.com/disciplinedagiledelivery.com/wp-content/uploads/2014/12/Team-Product-Delivery.png?w=794
Embrace Changing Requirement
https://www.scrum.org/forum/scrum-forum/12885/change-during-sprint-initiated-product-owner
1. The change should not violate the sprint goal.
2. The development team 'owns' the sprint backlog. Changes should be negotiated with the dev team.
Deliver FInished Work Properly and Release Product Whenever Required
https://www.knowledgehut.com/tutorials/scrum-tutorial/release-planning
Release Picture https://d14b9ctw0m6fid.cloudfront.net/tutorials/topics/images/1532059486410-image3.jpg
The Product Owner is the Team member who knows what the customer wants and the relative business value of those wants. He or she can then translate the customer’s wants and values back to the Scrum team. The Product Owner must know the business case for the product and what features the customers’ wants. He must be available to consult with the team to make sure they are correctly implementing the product vision. Most importantly, he must have the authority to make all decisions necessary to complete the project, in other words, the Product Owner is responsible for Managing the Product Backlog which includes:
Expressing Product Backlog items clearly.
Ordering the Product Backlog items to best achieve goals and missions.
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Team will work on further.
Ensuring that the Team understands items in the Product Backlog to the level needed.
Scrum Master
The scrum master help to keep the team accountable to their commitments to the business.
Remove any roadblocks that might impede the team’s productivity.
The role of a scrum master is to coach and motivate team member, not enforce rules to them.
The role of a scrum master includes:
Ensure the process run smoothly.
Remove obstacles that impact productivity (Communication, Personal conflict).
Organize the critical events and meeting.
A Scrum Delivery Team is a collection of individuals working together to deliver the requested and committed product increments. It comprises of cross-functional members who are capable of achieving the sprint goals.
This could include:
software engineers
architects
programmers
analysts
system admins
QA experts
testers
UI designers, etc.
A stakeholder is anyone that is potentially affected by the outcome of the project. The term is usually used to name the management or the customers.
The product owner is a stakeholder by defintion (just like the developers in fact), but is generally the person that represents the stakeholders (given the general usage described before).
Sprint Planning is the scrum ceremony designed to make sure the team is prepared to get the right things done every sprint.
The team plans what user stories (backlogs) it will execute during the Sprint and breaks them into tasks. The team commits to completing those during the Sprint according to the Definition of Done (DoD).
Menentukan sprint backlog.
Menentukan velocity / story points dengan https://firepoker.io (velocity).
Brakdown task yang terlalu besar (Bila task teralu besar maka breakdown, perhatikan psikologis yang ngerjain.)
Menentukan siapa yang mengerjakan apa.
Konfirmasi availability team (cuti dll).
When team add a story point to the task
https://pm.stackexchange.com/questions/25346/when-does-a-scrum-team-assign-story-points-to-the-stories-in-the-scrum-methodolo
time-boxed event of 8 hours, or less,
The Daily Scrum is the team’s chance to get together. define a plan for the day’s work, and identify any blockers.
What did you do yesterday?
What will you do today?
Are there any impediments in the way?
During a Scrum, regular sprint review meeting is schedule to demo and determine the product usability. Teams are expected to deliver a shippable product during each increment or Sprint.
To ensure their success, sprint review meeting is held at the end of each sprint. During the review, the Scrum team shows to the stakeholders what they have accomplished by demonstrating the newly designed features.
Myth: The Sprint Review is a Demo
“Too many Scrum Teams approach the Sprint Review as their moment to show progress, to give a ‘product update’, to sell what was built to stakeholders or to talk about what *they* did.“
Seharusnya dua arah.
The Scrum Guide describes the Sprint Review as an event that “is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed”.
“the collaboration between the Scrum Team and its stakeholders is key during the Sprint Review”
time-boxed event of 4 hours, or less,
Tools
https://www.pointingpoker.com/
time-boxed event of 3 hours, or less.
What is a Sprint Goals?
Sprint goal is a high-level summary of the goal the product owner would like to accomplish during a sprint, frequently elaborated through a specific set of product backlog items.
Product Backlog
The Product Backlog is a sorted list of all the products you need and the only source of product demand changes. The product owner is responsible for the content, availability, and priority of the product to-do list called Product Backlog.
Sprint Backlog
Sprint Backlog is a set of Product Backlog items selected for the current Sprint, plus plans for delivering product increments for achieving Sprint goals. Sprint Backlog is a set of Product Backlog items selected for the current Sprint, plus plans for delivering product increments for achieving Sprint goals.
Definistion of Done
Definition of Done (DoD) is a list of requirements that a user story must adhere to for the team to call it complete. While the Acceptance Criteria of a User Story consist of set of Test Scenarios that are to be met to confirm that the software is working as expected.
Testing is a core part of agile software development. Unlike in previous software methodologies, where testing was a separate stage that occurred after development was complete, in an agile methodology testing begins at the very start of the project, even before development has started. Agile testing is continuous testing, which goes hand in hand with development work and provides an ongoing feedback loop into the development process.
Common Categories Of Software Errors:
1. Functionality Errors (Tidak berfungsi).
2. Communication Errors (Tidak tau harus ngapain).
3. Missing command errors (Ada fungsi yang hilang).
4. Syntactic Error (typo) (Salah tulis).
5. Error handling errors (Menghandle error dengan cara yang salah).
6. Calculation Errors (Salah hitung).
7. Control flow errors (Aksi selanjutnya tidak sesuai harapan).
https://www.softwaretestinghelp.com/types-of-software-errors/
Regression Testing atau pengujian regresi adalah jenis pengujian aplikasi software yang sudah ada untuk memastikan bahwa perubahan atau penambahan belum melanggar fungsi software sebelumnya. Tujuan utamanya yaitu untuk mengetahui dan menangkap bug yang mungkin secara tak sengaja menyebar ke dalam perangkat lunak.
Catatan
Bila developmentnya Agile maka harus diimbangi dengan testing dan deployment yang agile juga, bila tidak maka akan terjadi Bottleneck.
Tanpa test tidak diketahui perubahan kita akan menimbulkan defect ditempat lain. Mengurangi kepercayaan diri saat melakukan suatu perubahan (Misal pindah server, menghapus fitur yang tidak terpakai, penambahan dll).
KIta bisa agile kalo setiap perubahan yang kita lakukan bisa diketahui impactnya disebelah mana saja.
Pentingnya testing supaya mengetahui apakah fitur baru mengganggu fitur2 lama.
KIta bisa agile kalo setiap perubahan yang kita lakukan bisa diketahui impactnya dimana dan apa saja.
https://hiptest.com/docs/writing-scenarios-with-gherkin-syntax/
Programmer fokus membuat fitur bukan menganalisa kebutuhan client, saat menjadi story di Jira seharusnya story/issue/task itu sudah clear dan memiliki acceptance kriteria yang terukur.
Komunikasi
Saat ada perubahan status sebaiknya mention developer, QA dan team member terkait untuk memberikan penjelasan singkat dikomentar, bila malas buat comment maka berikan saja snapshot yang relevan.
Di Agile kita tidak membuat dokumentasi khusus yang sangat detail dan komprehensif jadi pastikan Jira issue ini mudah dipahami dan komunikatif.