a good process will outperform good people with no process every time.“ - Grady Booch, Object Solutions: Managing the Object-Oriented Project. Addison-Wesley, 1996 @simonsinek: A team is not a group of people that work together. A team is a group of people that trust each other. 5 se16b-yagel
of Social Skills in the Labor Market, 2015 • W. Felps, “How, when, and why bad apples spoil the barrel: Negative group members and dysfunctional groups.” • K. Matsudaira, The Paradox of Autonomy and Recognition - Thoughts on trust and merit in software team culture • The Drucker Exercise • J. Spolsky, How to be a program manager • המ םירדתסמ םניא הצובקה ירבחשכ תושעל ? • O'Brien, People the missing ingredient (talk) 6 se16b-yagel
It’s about listening, empathy and having more women“ – http://www.nytimes.com/2015/01/18/opinion/sunday/why-some- teams-are-smarter-than-others.html?_r=0 • "Gender and Tenure Diversity in GitHub Teams", 2015 – “we show that both gender and tenure diversity are positive and significant predictors of productivity” se16b-yagel 8
team 1. Psychological safety: Can we take risks on this team without feeling insecure or embarrassed? 2. Dependability: Can we count on each other to do high quality work on time? 3. Structure & clarity: Are goals, roles, and execution plans on our team clear? 4. Meaning of work: Are we working on something that is personally important for each of us? 5. Impact of work: Do we fundamentally believe that the work we’re doing matters? se16b-yagel 10
capture ideas, relationships, decisions and requirements in a well-defined notation that can be applied to many different domains [Pilone, D., UML 2.0 in a Nutshell, 2005] • תבכרומ תושי לש טשופמ רואיתל שמשמ לדומ – םיטרפל הדירי אלל םיינורקעה םיטרפב דקמתמ לדומ – שרוד לדומ " םוגרת " תיתימאה תושיל – תונוש תויונשרפו םישומימ רשפאל רומא 20 se16b-yagel
[implementation] away; you will, anyhow.” - Fred Brooks, Jr. (1999 Turing Award winner) • Often after build first one, developers learn right way they should have built it 39 (Photo by Carola Lauber of SD&M www.sdm.de. Used by permission under CC-BY-SA-3.0.) se16b-yagel
phase Vision document Init ial use-case model Init ial project glossary Init ial business case Init ial risk assessment . Project plan, phases and it erat ions. Business model, if necessary. One or more prot ot ypes I nc e pt i o n Use-case model Supplement ary requirement s including non-funct ional Analysis model Soft ware archit ect ure Descript ion. Execut able archit ect ural prot ot ype. Preliminary design model Revised risk list Project plan including it erat ion plan adapt ed workflows milest ones t echnical work product s Preliminary user manual Design model Soft ware component s Int egrat ed soft ware increment Test plan and procedure Test cases Support document at ion user manuals inst allat ion manuals descript ion of current increment Delivered soft ware increment Bet a t est report s General user feedback se16b-yagel
דועו 16 םימסרפמ םיליבומ " רשנמ ( " תירבע , יקיו :) 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. • רתוי םיטרופמ תונורקע םיללוכ ( תידגנ תרוקיב , antiagilemanifesto ) 55 se16b-yagel
another attempt to undermine the discipline of software engineering… nothing more than an attempt to legitimize hacker behavior.” – Steven Ratkin, “Manifesto Elicits Cynicism,” IEEE Computer, 2001 • Accepted in 2014 – 2012 study of 66 projects found majority using Agile, even for distributed teams • Is it new? 1974 - Lehman's laws of software evolution: 1. Continuing Change — An E-type system must be continually adapted or it becomes progressively less satisfactory se16b-yagel 62
if followed religiously, works. Each method provides the programmer a way to manage complexity and change so as to delay and moderate the B-L upswing. However, each method has a catch, a fatal flaw, at least one step that is a real pain to do, that people put off. People put off this painful step in their haste to get the software done and shipped out or to do more interesting things, like write more new code. Consequently, the software tends to decay no matter what. The B-L upswing is inevitable.” 69 se16b-yagel
הנכות ? ( Cargo Cult SE ) • רתויב םיאתמה לדומה והמ ? ( “No One Size Fits All”, “No Silver Bullet” ) • םיפסונ םילדומ םנשי ( חותפ דוק לש לשמל , רוד 5 ? ) – http://theleanstartup.com/ Build-Measure-Learn • טקיורפב ? • דב םילוכי ךשמהב דמלנש םיקלחה " אלל בלתשהל כ לדומל רשק רחבנש יפיצפסה חותיפה ? 72 Constantine: If you don’t know what you’re going to do before you do it, you don’t know what you’re doing. If you spend all your time figuring out what you’re doing, you’re doing nothing. se16b-yagel
robiy
terasawat
gishi_yama
camel_404
matleenalaakso
doratex
stevekinney
bvr7352
kzkmaeda
frievea
matsu0228
pawan_pharm
juanmartin2026
nonsquared
varn
mza
frankvandijk
codingconduct
irinanazarova
lynnandtonic
chriscoyier
tammyeverts
lemiorhan
mojombo
![םימה לפמ • ל סחוימ - Royce [ 1970 ]](https://files.speakerdeck.com/presentations/e35be13226d14f0681f8d2ceb85cc0b8/slide_34.jpg){kind=link}
![“The Inevitable Pain of Software Development” [Berry] • “Each method,](https://files.speakerdeck.com/presentations/e35be13226d14f0681f8d2ceb85cc0b8/slide_68.jpg){kind=link}
