Kanban for scrummers
•Download as PPTX, PDF•
1 like•1,197 views
The document discusses whether organizations need to change and considers applying Kanban principles. It outlines some Kanban concepts like limiting work in progress, continuous flow, and continuous improvement. It acknowledges that change may not always be needed but suggests using Kanban when issues like long lead times, quality problems, or unpredictable demand exist. Kanban is presented as a potential solution for organizations not suited for Scrum or with chaotic requirements. The document advocates trying Kanban principles before concluding that change is not possible.
Report
Share
Kanban for scrummers
- 2. Do we really need to change?
- 3. Ilan Kirschenbaum Agile coach at Practical Agile Find me at: http://practical-agile.com http://fostnope.com at Wordpress.com Twitter: kirschi_ Facebook: Ilan Kirschenbaum
- 17. Now tell us something we don’t know
- 24. Quality, Cost, Lead Time, Morale, Safety Respect for People In-station Just In Time Continuous Quality Pull, Flow Improvement (Kaizen) (Jidoka) Reduce Waste Stability, Standardization, Leveling (heijunka)
- 25. Choose the project Map your current process Find and reduce waste Identify and respect WIP limits Maintain Flow by Pulling work Continuously Improve
- 26. Lead Time Costs Value adding and essential waste Non-essential waste
- 29. Waste = Investing in efforts that do not contribute to value Partially done work Extra features Rework Redundant handoffs Delays Context switching Defects Ignoring creativity
- 30. Value adding work Activities that directly contribute to working product Essential waste Activities that the customer will not pay for, but are unavoidable Non essential waste Activities that the customer will not pay for, and can be eliminated or reduced
- 32. Which Side of This Road Would You Rather Drive?
- 35. Redefining the daily meeting Does the Kanban reflect our activity? Is there anything blocking us? Are we blocking anyone?
- 36. Yes – if you need it Define your Cadence, and create the rhythm of Planning Reviewing Retrospection
- 37. Where does it hurt? What would you discuss in your Kaizen? Time to Market? Try CFD and Cycle Time Quality? Try Code Coverage or Defects rate Match your measure to your goals
- 38. Backlog WIP Avg Cycle Time Avg Lead Time Source: Target Process
- 41. Source: Sonar
- 42. What’s Next?
- 46. So, Do we really need to change?
- 48. If it ain’t broken – don’t fix it If it is broken, use what you already know to fix it If it doesn’t fit – see if Kanban fits Daily releases – e.g. support, short SLA Chaotic requirements changes – e.g. Start- up Not SCRUM-able – e.g. large complex team
- 50. Salmon: http://www.flickr.com/photos/66143381@N07/6106820290/ Ruins: http://www.flickr.com/photos/blathlean/5424392859/ Daily SCRUM http://www.flickr.com/photos/improveit/1470213411/ Yawn http://www.flickr.com/photos/melissadion/4480984908/ Kanban – Karl Scotland http://agile.dzone.com/news/introducing-kanban-flow-and Toyota http://www.flickr.com/photos/katerha/5581762999/ Piggly Wiggly http://www.flickr.com/photos/pixelpackr/91923434/ JIT – Dilbert, Scott Adams. Found at http://www.witiger.com/internationalbusiness/JIT.htm Customer service http://www.socialsellingu.com/blog/5-reasons-add-customer-satisfaction-survey Value Stream Mapping – Courtesy of Amdocs WIP – Henrik Kniberg CFD – Target Process http://www.targetprocess.com/blog/2010/02/cumulative-flow-chart-in-kanban-real-usage- example.html Cycle time – Target Process http://www.targetprocess.com/userguides/userguide.html Defects – created vs. resolved: Atlassian https://confluence.atlassian.com/display/JIRA/Created+vs+Resolved+Issues+Report Code coverage: Sonar http://www.sonarsource.org/sonar-to-manage-unit-tests-and-improve-code-coverage/ Kanban big to small – Joseph Wilk http://agilepractitioners2012.com/wp-content/uploads/2011/11/Joe-Wilk- Testing-In-the-land-of-Startups.pdf Toyota Production System http://en.wikipedia.org/wiki/Toyota_Production_System The Toyota Way http://en.wikipedia.org/wiki/The_Toyota_Way The Machine That Changed the World by by James P. Womack, Daniel T. Jones (scientist), and Daniel Roos Stopwatch http://www.flickr.com/photos/rsdio/3642425935/ Dollar http://www.flickr.com/photos/8011986@N02/2965137520/ Traffic http://www.flickr.com/photos/stevenworster/6122957783/
Editor's Notes
- שלום לכולםאם אתם כאן אני מניח שכבר יש לכם מושג סביר מה זה סקראם. גם אם לא, אתם מוזמנים להישאר. אם יש משהו שאתם ממש לא מכירים אתם מוזמנים לשאול. לגבי שאלות אחרות, אני אשאיר זמן בסוףטוב, השאלה הראשונה לאלו שכבר עושים סקראם, ורוצים לעבור לקאנבאן, היא – האם יש לנו סיבה מספיק טובה לעבור למשהו אחראבל רגע לפני כן, כמה מלים על מי אני בכלל
- שמי אילן, ואני agile coach בחברת פרקטיקלאג'ייל. אני מגיע מרקע של הנדסת תוכנה, כאשר לפני מספר שנים נפל לי האסימון של למה לעזאזל שיטת המפל לא עובדת, ומאז אני מפיק הנאה מרובה מלעזור להפיל את האסימון הזה אצל הלקוחות שלנו
- ולענייננו.אחד היתרונות של סקראם הוא שהוא נותן מסגרת יחסית ברורה לתהליך. אמנם יש מרחב חופש עצום, אבל אפשר די בקלות לומר אם אתם עושים סקראם או לא. ובכל זאת...
- במקריםמסויימים, גם אם עושים את כל הדברים הנכונים לכאורה, זה מרגיש שאתם לא קוצרים את הפירות שהבטיחו לכם או שדמיינתם לעצמכם כשהתחלתם עם סקראם
- בתור התחלה, סקראם מניח שיש רשימת תכולה יציבה פחות או יותר מתחילת הספרינט לכל אורכו. נכון, יש ספייקים, אבל סקראם בעצמו מדגיש את המרחב המוגן של הצוות, ושספייקים צריכים להיות המקרה החריג, ולא הכלל.
- אבל מה אם ברוב הספרינטים אותה רשימת התכולה, הבקלוג, הופכת להיות עיי חרבות זמן קצר אחרי שהספרינט מתחיל? זה יכול לקרות מסיבות שונות ומשונות, אבל לצורך הדיון אני אתמקד בסוג אחד של מקרים:בכל ספרינט יש אחוז מסוים, דומה, של דברים שנשארים קבועים, ושאפשר לקחת עליהם התחייבות לשבועיים. אבל החלק האחר נוטה להשתנות – אם זה בגלל דרישות מהלקוח שהשתנו, או בגלל שאנחנו מוצר חדש שצריך להתכונן בזריזות לפגישות עם לקוחות, או אולי להיפך, שאנחנו מוצר ותיק עם מספר רב של לקוחות ו-SLA קצרואז...
- אם יש דברים דחופים לטפל בהם, כל עוד זה פחות או יותר צפוי, וברמה נמוכה, אז סקראם יסתדר עם זה היטב. מראש נדע ש- X% מהספרינט שמור לבלתמים, ואת ה-פלנינג נעשה לפי זה.אבל...
- מה אם זה הופך להיות בלתי צפוי?כלומר רוב הדברים שתכננו ביום הראשון של הספרינט הופכים להיות לא רלוונטיים ככל שהספרינט מתקדם?השאלה הראשונה שצריך לשאול היא (תופים......) למה זה קורה?יתכן שאת רוב המקרים ניתן לפתור בלי להפריע לצוות. למשל, לשאול למה? למה עכשיו? מה עוד אפשר לעשות?אבל לפעמים באמת הדרישות משתנות באופן שהוא יותר תכוף משבועיים.
- מה יהיו ההשלכות של שינויים תכופים?נתחיל ביכולת שלנו לתכנן. אנחנו משתמשים ב BDC כדי לתקן את עצמנו במהלך הספרינט – אילו החלטות צריך לעשות עכשיו? כדי לעמוד בהתחייבות, כדי לשמור על האיכות, כדי להתכונן לספרינט הבא, כדי לעזור לחבר צוות שנתקע.אבל אם הדרישות משתנות ללא הרף...
- אז הכלי הזה הופך לבלתי שימושי. אילו החלטות אפשר לעשות בעזרת גרף שכזה?
- היבט נוסף של אי-יציבות הבקלוג הוא בדיילי סטנד-אפמוטו בסקראם הוא: סטופ סטרטינגסטרטפינישינג = תתמקדו, כצוות, בפחות דברים לסיים, כדי לסיים יותר דברים.הבעיה היא שכשיש הרבה דברים דחופים, זה הרבה הרבה יותר קשה לביצוע.עוד נדבר על זה בהמשך, אבל בהקשר של הדיילי, עלול להיווצר מצב שמעט חברי צוות עובדים על דרישות משותפותואז...
- הדיילי הופך להיות משעמם.למה שאני אקשיב למה שיש לחבר צוות אחר לדבר על משימה לא שלי, כשאני עובד על משימה שעבורי היא הדחופה ביותר?הדיילי הופך להיות משהו שמפריע להתקדם בדברים הדחופים, במקום מקום לקדם את המשימות המשותפות
- אה, ועוד משהו משמעותי. רעיון מרכזי בסקראם, כפי שכבר דיברנו היום במובלע, הוא קצב קבוע עבור הצוות. כשיש קצב קבוע, אפשר לצפות ליותר דברים שיחזרו על עצמם, ספרינט אחרי ספרינט.עצם החזרה מורידה חרדה, וכשיש פחות חרדה, אפשר לעבוד יותר טוב.
- שחרור תוכנה עובדת במקצבים קבועים זה חלק מהעניין. הצוות, מנהל המוצר, מנהל הפיתוח, הלקוח, כולם רגילים שתוכנה משתחררת לפי מקצב קבוע. התכנון מסתדר לפי המקצב הזה, וזה לא משנה, לצורך הדיון, אם זו תוכנה עובדת באתר לקוח, או תוכנה עובדת לקראת גירסא קרובה. כמובן עדיף שזה יעבוד אצל הלקוח בכל ספרינט.אבל...
- מה אם הדרישה לתוכנה עובדת גם היא לא סדורה?קשה לתכנן, קשה לחזות, ובודאי קשה לבצע
- טוב, עד עכשיו דיברנו על מה בסקראםלאעובד. אז מה כן עובד במצבים האלה?
- מי שקרא את כותרת ההרצאה הזו, לא יופתע שאני הולך לדבר על קנבאן.
- במה קנבאן שונה מסקראם, ואיך הוא יכול לפתור את הבעיות שתיארתי עד עכשיו?רק רגע, לפני שאני צולל לעצם העניין, מספר הודעות חשובות
- הודעה ראשונה. בדרך כלל, את רוב, אם לא כל הבעיות שאירגונים חווים ולא מצליחים לפתור בסקראם, אפשר לפתור גם בסקראם.לא, זו לא טעות. זה רק עניין של להתבונן קודם בבעיות, ולא בפתרונות.קחו למשל את עניין השחרורים התכופים. נגיד, קבוצה פנימית של אינפרא, שמכינה סביבות פיתוח ובדיקות עבור צוותי הפיתוח.יכול להיות שחלק מהדרישות לא יכולות לחכות שבועיים עד לפיתרונן. אבל אם 70% מהדרישות הללו כן יכולות לחכות שבוע, אולי אפשר פשוט לקצר את הספרינט?המעבר לקנבאן, כמו המעבר לסקראם, יביא לשיפורים תהליכיים משמעותיים – אבל הוא יהיה גם תהליך כואב.
- והודעה נוספתההבדל הוא, שכפי שאמרתי בהתחלה, סקראם נותן מסגרת די ברורה לתהליך. התפקידים, הטקסים, הזמנים, התוצרים, הם די ברורים. אפשר די בקלות לומר אם צוות עושה סקראם סביר או לא.בקנבאן זה שונה. מספר ה"כללים" הוא יותר מצומצם, ולכן אפשר למצוא צוות שלמראית עין עושים קנבאן, אבל הלכה למעשה הם רחוקים מכך.ולהיפך, כבר ראיתי צוות שהחליט שבפרויקט מסויים לוח הקנבאן אינו נחוץ להם – ובכל זאת הם התנהלו בתוך ערכים מעולם ה-LEANוהקנבאן. התקורה של הלוח נראתה להם מיותרת, ובפרוייקט הזה, בניגוד לפרוייקטים לפני ואחרי, הם החליטו לעשות את ה"לוח" בתוך מסמך מתגלגל.האם אני הייתי עושה אותו הדבר? לא. אבל עבור אותו הצוות זה עבד טוב, בעיקר מכיוון שהיו להם התנסויות בקאנבאן עוד קודם
- ועוד רגע לפני שצוללים פנימה – קצת על סיפור הרקע. כדי שנבין את ההבדלים, צריך ראשית להבין שסקראםוקאנבאן צמחו ממקומות דומים. השורשים של סקראם מגיעים מהעבודה של טקאוצ'יונונאקה ב-1986 עם The New New Product Development Game, באותן השנים שוומאק ועמיתיו ביצעו את המחקר בטויוטה, שיתפרסם בספר The Machine That Changed The Worldבזמן ששני הממציאים של סקראם, סאט'רלנדוששואבר, ניזונו מהעבודה של טקאוצ'יונונאקה, קאנבאן עשה "סיבוב" דרך טויוטה, ל- LEAN, ודרך מרי פופנדיק לעולם התוכנה.
- הרעיונות המקוריים גם הם עשו סיבוב בסיפור המעשה. מספרים שכאשר מנהיגי טויוטה, טויודה, אונו, ושינגו, נסעו לארצות הברית ב-1948, הם ביקרו, בין השאר במפעל של פורד. בהמשך לביקור קודם בשנות ה-30, הם מצאו שתעשיית הרכב לא התקדמה הרבה. שיטות הייצור, ובעיקר תהליך הייצור הסדרתי, עדיין עבדו באופן דומה. אבל כאשר הם למדו כיצד פועלות רשתות סופרמרקטים, ספציפית פיגליוויגלי, הם מצאו את שיטת חידוש ועיתוד המלאי מאוד רלוונטית.באופן פשטני, במחסן החנות מסתכלים על רמות המלאי, ומחליטים מאילו מוצרים צריך להזמין לפי ההפרש מהמלאי הרצוי. המלאי הרצוי נקבע לפי המכר בחנות. אולי היום זה נשמע בנאלי, אבל השיקול של מלאי עומד באותו הזמן לא היה בעל משמעות גדולה כפי שהוא היום, מכיוון שזו לא נתפסה כבעיה במפעלים של פורד. לאור הרשמים מהביקור הם קראו לזה – Just In Time
- במהלך השנים מ-1948 ועד 1975 השיטה התפתחה והתעדנה, וזכתה לכינוי Toyota Production System או TPS. השיטה פועלת לפי 14 עקרונות שתועדו ע"י דר' ג'פרי לייקר כ- The Toyota Way ב- 2004את העקרונות אפשר לראות ב"בית של טויוטה", והם מתחלקים לפי הרעיונות הבאים:בבסיס הבית נמצאים העקרונות של הייצור – יציבות, סטנדרטים בייצור, אחידות. יהיה מי שיאמר Engineering Practices – והוא יצדק! TDD, Clean Code, נופלים תחת הקטגוריה הזובגג הבית נמצאות התוצאות: איכות, עלויות, זמן הייצור הכולל, מוראל, בטיחות. יהיה מי שיאמר הסיבות למעבר לסקראם, וגם הוא יצדקעמודי התווך של הבית הם שניים: זרימה עקבית של עבודה, ו- JIT. כאן יהיה מי שיאמר At the last responsible moment, ושוב – יצדקעמוד התווך הנוסף הוא לאפשר לעובד לשפר איכות בו במקום, או אוטונומיזציה. יהיה מי שיאמר Self Organized Teams – והפלא ופלא – יצדקבלב הבית נמצא השיפור המתמיד. מתוך כבוד לאנשים, ובשאיפה להפחית בלאי בתהליך, יש לשקוד על שיפור באופן עקבי ומתמיד. יהיה מי שיאמר רטרוספקטיבה, ושומו שמיים – יצדק!!!ומכאן שההבדלים בין סקראם לעקרונות שמאחורי קאנבאן הם לא כל כך גדולים, ונזכיר את שתי ההצהרות שציינתי קודם לכן.ובכל זאת – למה קאנבאן?בואו נדבר על איך מתחילים קאנבאן, ואז תחליטו בעצמכם
- עד כאן שיעור מקוצר בהיסטוריה. עכשיו בואו נראה איך מתחילים לעבוד עם קאנבאן.כדאי לבחור את הפרוייקט המתאים – פרויקט שיש בו מספיק כאב, אבל לא משותק.בשלב הבא ממפים את התהליך שמתחולל בפרוייקט כפי שהוא בשלב ההתחלתי
- זה תהליך פשוט מבחינה טכנית, אבל לא פשוט מבחינת התהליך שעובריםאתם תצטרכו להסתכל במראה ולהבין שיש דברים בפרוייקט שלא תורמים למוצר שלכם, ולהיפך, הם מוסיפים WASTE בתהליך
- באופן טיפוסי זה נראה משהו כזה, כאשר החיצים האדומים מסמלים REWORK – שלבים בתהליך שגורמים ל- WASTEחשוב להבין שככל שיש לכם יותר שלבים בתהליך, יש יותר HANDOFFS ובהכרח גם יותר WASTE מסוגים שונים
- אחרי שעשיתם את המיפוי, אפשר לעשות קאנבאןאיזה יופי! אז גמרנו?זהו, אז שלא, זוהי רק ההתחלה, וזה החלק הכי פחות כואב. שימו לב שלוח הסקראם לא מאוד רחוק מזה, אלא שיש רק שלוש עמודות: בקלוג, בעבודה, גמור. זהואם יש לכם מעט פתקים בעמודת בעבודה, אז אתם בכיוון הנכון. אם יש הרבה, אז כדאי מאוד, בעצם מאוד מאוד, להתמקד.אם נתייחס לזה במונחי קאנבאן, נגיד שאנחנו מחפשים ומצמצמים את ה WASTE
- עכשיו מתחילה העבודה. איפה בתהליך שלנו יש לנו ביזבוז. של משאבים, של זמן, של עבודה מיותרת, של עצירות מיותרות, של איכות לקויה, ועוד ועוד.מי שכבר עושה סקראם יאמר "אבל אנחנו כבר עושים את זה – ברטרוספקטיבה!"בשלב הזה אנחנו כבר יודעים שרעיונית קאנבאןוסקראם לא כל כך רחוקים זה מזה, ולכן מי שיאמר את זה כמובן... יצדק
- כדאי תמיד לזכור שלא כל בזבוז הוא מיותר. יש האומרים שצריך לחסל את ה-WASTE. אני בעד לצמצם. יש בזבוז שלא ניתן להסתדר בלעדיו.למשל, אם הלקוח לא מוכן לשלם על תיעוד, אבל ללא מדריך משתמש לא ניתן למכור את המוצר, אזי אין ברירה אלא ליצור את המסמך.לחליפין הלקוח אולי לא מוכן לשלם על ידידותיות למשתמש – סוג של תכונה עודפת, אבל בטווח הבינוני-ארוך זו תכונה שתחסוך וגם תכניס לאירגון הרבה כסף. וראו אייפון כדוגמא
- בשלב הבא נשתמש במידע שאנחנו מקבלים מהקאנבאן כדי ליצור הגבלות על כמה דברים אנחנו יכולים לעבוד במקביל. זהו שלב שבמקרים רבים בהטמעת קאנבאן לא מגיעים אליו. כאן מתחילים הכאבים הגדולים, אבל גם הרווחים הגדולים.גם בהטמעותסקראם אני מגלה שצוותים ממשיכים למקבל עבודה, ולא מתמסרים לדרך על-ידי הגברת עבודת צוות.למה הדבר דומה?
- כל נהג טרי מבין שהעומס נוצר בגלל אי-יכולת של המערכת (הכביש) לשאת את התכולה (המכוניות). המידע האמפירי מראה בבירור שצריך להפחית את העומס על המערכת כדי לשפר את הזרימה.אם נתרגם את זה לעבודת הצוות – בגלל ריבוי משימות, כל המשימות מתעכבות. ולחליפין, אם נעבוד על פחות משימות יחד, כצוות, הזמן שנדרש להשלמת כל משימה יתקצר.בכל הטמעה של אג'ייל, אני מוצא שזה אחד המכשולים הקשים לעבור אותם.בהטמעה של קאנבאן הופכים את זה לויזואלי על-ידי קביעת מגבלות WIP.
- את עניין ה-WIP אפשר להסביר גם מתמטית וגם באופן הגיוני/רציונאלי
- עכשיו כשכבר יש לנו WIP limits, הדבר הקשה הבא הוא לכבד אותן.כדי שהמערכת תעבוד טוב, צריך לראות מה יוצא מהמערכת. בפקק תנועה, אנחנו נדע כמה מכוניות להכניס לכביש רק לפי מספר המכוניות היוצאות. כמובן שאנחנו ניצור פקק במקום אחר, אשר גם שם נצטרך לעשות פעולה דומה במעלה זרימת התנועה. זהו הרעיון של PULL ו- FLOWבסימולציה הזו אנחנו רואים מה קורה כשנכנסת לנו משימה דחופה לתוך המערכת, וגורמת לחריגה מהמגבלות שלנו.הדבר הנכון לעשות הוא להוציא משהו מהמערכת כדי שיכולת המערכת לא תגרום לעיכובים ולבזבוזים.לא תמיד זה אפשרי, ולכן אפשר לשכלל את הלוח כדי לאפשר באופן "חוקי" (במרכאות) את הדברים הדחופים.הדבר נכון גם לדברים שאינם דחופים ונדחקים החוצה בגלל המשימות ה"רגילות"אפשר לראות את הרעיון בצורה מאוד מוחשית כאן:
- וכל מילה נוספת מיותרת (להתעכב כ-15 שניות עלהסלייד)
- תכל'ס, איך מוודאים שה-PULL עובד?עובדים מימין לשמאל, ושואלים איפה יש גורמים לפקק. אלו הדברים שנצטרך לטפל בהם היום, ולהסיר את המכשולים.בשלבים הראשונים, כשעובדים מימין לשמאל, נשאל האם הלוח שלנו מייצג את המצב האמיתי. כשהאירגון מפנים את ה FLOW, אפשר יהיה לוותר על השאלה הזו. זה יכול לקחת חודש, וזה יכול לקחת עשר שנים, או בכלל לא – תלוי כמה יש התמסרות לשינוי.וכשזה קורה, מרגישים את ה FLOW. הפגישה היומית היא קצרה וממוקדת –עוברים מעיוורון תהליכי לראייה
- מה קורה בין המקצבים (קדנציות) תלוי בצרכים של התהליך.במידה ומשחררים כל יום, גם התכנון והREVIEW צריך להיות כל יום. במידה ויש מקצב לשחרורים, צריך להתאים את המקצב לצרכים של התהליך.כלומר, אין טעם להכריז על מקצב של חודש, אם הלקוח דורש לראות משהו עובד כל שבוע – ולהיפך.ובכל מקרה, גם אם מתכננים באופן יומי, חובה לשמור על מקצב של הרטרוספקטיבה – שהרי זה הבסיס לשיפור המתמיד המיוחל. איך זה עובד בקאנבאן?
- כלי שימושי מאוד הוא ה- OPS Reviewבכל תקופה, נניח שבועיים, תעקבו אחרי הנתונים, ותחליטו החלטות. אחרי מה לעקוב? אחרי מה שכואב כרגע. לדוגמא
- באופן יומי תציינו מהו ה- WIP שלכם בכל שלבהתוצאה – מהי ההשפעה של ה- WIP על ה Cycle Time שלנו, או ה TTM
- באופן דומה, כיצד נראה ה- Cycle Time לאורך זמן. אילו אירועים במהלך התקופה השפיעו עליו? מה אפשר ללמוד מזה?
- אם אנחנו סובלים מענייני איכות הקוד – מה היחס בין באגים נכנסים ליוצאים יש לנו? מה אפשר ללמוד מזה? מה יכול לשנות את היחס?התשובה היא פשוטה להבין, קשה לביצוע: אם נוציא תוכנה בדוקה יותר, אז יהיו לנו פחות באגים. נצטרך לעשות פחות דברים יותר טוב. נצטרך אולי להקטין את ה- WIPגם אם האמת ברורה לנו, כדי ליישם את המסקנות נצטרך לשים את האמת בפרצוף באופן עקבי – עד שזה יכאב לנו מספיק כדי לשנות
- ובאופן דומה, כיסוי הקוד: כמה מהקוד אנחנו בודקים? כמה מתוכן עוברות? האם אנחנו עומדים בסטנדרטים של עצמנו?
- לאן לוקחים את זה מכאן?
- שכלול פופולארי של הקאנבאן הוא על ידי Swimlanes – דוגמת בית-ספר היא על ידי Classes of Serviceזה פתרון אלגנטי לבעיה שראינו קודם, שפתאום נכנסת משימה דחופה – עכשיו אנחנו יכולים לנהל את ה WIP ברמת CLASSלמשל, בכל רגע נתון אנחנו מסכימים לעבוד על עד משימה דחופה אחת.חשוב לדעת שבדרך כלל אפילו משימה דחופה אחת עלולה לגרום לנו לזנוח את ה PULL ולעבור ל PUSH על מנת לעמוד ביעדי זמן דחוקיםאפשרות פופולארית נוספת
- היא לשלב בין סקראםלקאנבאן.כל SWIMLANE יהיה STORY נפרד, ונתאר את התהליך בתוך הפסרינט על-ידי קאנבאן.רעיון נחמד להתחלה, אבל בסופו של דבר אנחנו רוצים שבאמת כל הצוות יעבוד רק על דבר אחד בכל פעם. הפיתרון הזה, בעיני, עוזר לצוות לעשות את ההיפך
- רעיון נוסף הוא שהמעטפת, האקו-סיסטם, יעבוד בקאנבאן, ואילו צוותי הפיתוח הצמם יעבדו בסקראם מסורתי.זה רעיון לא רע ל- SCALINGבפרוייקטים מורכבים.אבל הוא סובל מאותן הבעיות של המודל הקודם – אם הפרוייקט הוא מורכב ומסובך, פיתרון כזה עלול לעזור לו להישאר מורכב ומסובך
- הנה דוגמא לקאנבאן שעשו בחברת SongKick, סטארט אפ עם כ-60 עובדים.תיראו איפה הם התחילו את הקאנבאן, ולאן הוא התפתח
- שימו לב לשמות העמודות, שאי אפשר לטעות בהגדרה שלהן.אם אתה עובד כאן, ואתה לא Making Something, תחשוב שוב מה אתה רוצה לעשותאם אתה מעביר משהו ל- DONE, שים לב שהוא אמור להביא רווח לחברה
- טוב, סגרנו מעגל. אחרי שלמדנו על קצה המזלג מה זה קאנבאן, ואיך הוא דומה ושונה מסקראם, אני חוזר למה שתפחתי בו:אם סקראם עובד לכם טוב, או פחות או יותר טוב – תמשיכו, ואל תשנו.יש סיכוי יותר מסביר שסקראם מספיק טוב בשבילכם – אבל תצטרכו לשלם מחיר כדי להגיע לשם. למשל, לדבר עם הלקוח, ולבדוק אם SLA של שבוע מספיק טוב לצרכים שלו, ולשנות את אורך הספרינט בהתאם.זוכרים כשהתחלתם עם סקראם? זה היה קל? אולי בספרינט הראשון, כשעוד התלהבתם, אבל אחרי שניים שלושה ספרינטים, כשהבנתם זה לתמיד, התחילו לצוץ הבעיות. נכון?מתאים לכם להתחיל הכל מחדש?אם הכאבים מצדיקים את זה – סבבה – קאנבאן זה בעיני בליגה של הגדולים, יחסית לסקראם.בשני המקרים – כשתעברו את החסמים של להפוך לאירגון לומד, או אז יתחילו הרווחים האמיתיים.ולכן הכי חשוב שתעיזו לנסות. אולי תיכשלו, אבל לפחות תלמדו מזה משהותודה רבה