Your SlideShare is downloading. ×
Things To Unlearn In Software Development
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Things To Unlearn In Software Development

697
views

Published on

"От чего нам стоит утучиться в индустрии разработки ПО". Доклад с ITJam.

"От чего нам стоит утучиться в индустрии разработки ПО". Доклад с ITJam.

Published in: Business, Technology

1 Comment
5 Likes
Statistics
Notes
No Downloads
Views
Total Views
697
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
1
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Things to unlearn in software development
    #itjam #unl
  • 2. История Васа
  • 3. История Васа
  • 4. История Васа
  • 5. История Васа
  • 6. Причины трагедии
    Очень важный заказчик
    Нереальные планы
    Увеличивающийся объем работ
    Высокие технологические риски
    Архитектурные просчеты
    Провалились приемочные тесты
    Сменился ведущий архитектор
    Выдавание желаемого за действительное
    Неверные приоритеты разработки
    Ошибки внедрения
  • 7. Прошло 350 лет
    Кораблестроение многому научилось
    Развиваются новые индустрии
    Проектный менеджментстал наукой
    Почему спустя 350 лет мы совершаем одни и те же ошибки?
  • 8. 1
  • 9. ДИЛЕММА ВАЖНОСТИ И ПРАВОТЫ ЗАКАЗЧИКА
    Гарри Гордон Селфридж сказал «Заказчик всегда прав»
    Но что, если важный заказчик не прав?
  • 10. Безоговорочное согласие приводит к ухудшению качества обслуживания
    Пренебрежение мнением сотрудников
    Демотивация
    Снижение качества услуг
  • 11. Безоговорочное согласие приводит к проектным неудачам
    Принимаем нереальные сроки
    Соглашаемся с неоптимальными решениями
    Позволяем диктовать технические требования
    Боимся сказать возразить или признать провал
    На продукте будет «висеть» наша бирка
  • 12. UnlearnБЫТЬ БЕЗОТКАЗНЫМ
    Your 'yes' has no power
    if you do not know how to say 'no'
  • 13. LearnВЗАИМОДЕЙСТВОВАТЬ
    Говорить «нет» неприемлемым решениям
    Вести конструктивные диалоги для поиска лучших решений
    Реалистичных
    Профессиональных
  • 14. 2
  • 15. ДИЛЕММА ЖЕСТКОГО ПЛАНА И ПОСТОЯННЫХ ИЗМЕНЕНИЙ
    Изменения приходят неизбежно
  • 16. Объем проекта изменяется
    1) Дополнительные исследования
    «дьявол в деталях»
  • 17. Объем проекта изменяется
    Мы даем обещания, когда знаем ещё слишком мало
  • 18. Объем проекта изменяется
    2) Неверные трактовки
    требований
  • 19. Объем проекта изменяется
    3) Новые пожелания заказчика
  • 20. Unlearn ФИКСИРОВАТЬ ОБЪЕМ ПРОЕКТА
    [SCOPE] x [TIME] x BUDGET x QUALITY
    [SCOPE] x [TIME] x [BUDGET] x [QUALITY]
    [SCOPE] x [TIME] x [BUDGET] x [QUALITY]
    В проигрыше оказываются все:
    сценарий «Lose-lose»
  • 21. LearnУПРАВЛЯТЬ ОБЪЕМОМ ПРОЕКТА
    1) Разбивать проект на под-проекты
    Детализировать и подписывать требования только текущего под-проекта
    Планировать работу над следующим проектом, основываясь на опыте предыдущего
  • 22. LearnУПРАВЛЯТЬ ОБЪЕМОМ ПРОЕКТА
    2) Фокусироваться на приоритетах бизнеса
    Регулярно поставлять наиболее важную для бизнеса функциональность
    Принимая важные изменения, позволить бизнесу учиться и создавать конкурентные преимущества
  • 23. 3
  • 24. ПРОБЛЕМА OVER-ENGENEERING’А
    Стремясь «упредить» изменения мыразрабатываем универсальные решения
    Big Requirement Up Front (BRUF)
    Big Design Up Front (BDUF)
  • 25. Unlearn СТРОИТЬ УНИВЕРСАЛЬНУЮ АРХИТЕКТУРУ
    Предусмотреть все невозможно
  • 26. LearnБЕЗОПАСНО И ДЕШЕВО ВНОСИТЬ ИЗМЕНЕНИЯ
    Дешево:
    - Простой дизайн
    Безопасно
    - Автоматические тесты
    Без ограничений
    - Рефакторинг
    Архитектура растет
    вместе со знаниями о продукте
  • 27. Вы используете?
    Test-Driven Development
    Refactoring
    Continuous Integration
  • 28. Бытуют мнения
    «Мне не нужны юнит-тесты, я без них пишу качественно»
    «У меня нет времени на рефакторинг, поэтому я пишу качественно сразу»
    «Legacy код пишется в Индии и Китае»
  • 29. 4
  • 30. ПРОБЛЕМА ПРОФЕССИОНАЛЬНОЙ НЕБРЕЖНОСТИ
    Не думать
    О том, что будет с нашим кодом через полгода-год
    О том, что будет с нашим кодом, после того, как мы перейдем на другой проект
    О тех людях, которые будут его поддерживать
  • 31. UnlearnПРОФЕССИОНАЛИЗМ = ХРАБРОСТЬ
  • 32. LearnПРОФЕССИОНАЛИЗМ = БЕЗОПАСНОСТЬ
  • 33. LearnПРОФЕССИОНАЛИЗМ = БЕЗОПАСНОСТЬ
    ЗАБОТА О СЕБЕ
    - TDD
    - Refactoring- Continuous Integration
    Пишите код так, что бы позже, при его поддержке Вам было за что себя поблагодарить
  • 34. Что делают программисты?
    Читают код
    Пишут код
  • 35. Что делают программисты?
    Читают код
    90%
    Пишут код
    10%
  • 36. LearnПРОФЕССИОНАЛИЗМ = БЕЗОПАСНОСТЬ
    ЗАБОТА О ДРУГИХ
    - TDD
    • Refactoring- Continuous Integration
    Пишите код так, будто тот, кто будет его поддерживать - маньяк, который знает Ваш адрес
  • 37. 5
  • 38. ПРОБЛЕМА СТАНДАРТИЗАЦИИ ПРОЦЕССОВ
    Выбор методологии происходит в начале проекта
  • 39. ПРОБЛЕМА СТАНДАРТИЗАЦИИ ПРОЦЕССОВ
    The danger of standard process is that peoplewill miss chances to take important shortcuts
    T. DeMarco,T. Lister
  • 40. UnlearnПОЛАГАТЬСЯ НА СТАНДАРТНЫЙ ПОДХОД, который решит все возможные проблемы
    На «рынке» много предложений: CMM,RUP,XP,SCRUM …
  • 41. LearnСТРОИТЬ МЕТА-ПРОЦЕССзамыкающий цепочки обратной связи
    Выстраивать обратную связь между компонентами процесса:
    • Заказчиками и исполнителями
    • 42. Требованиями и их реализацией
    • 43. Версиями продукта и рыночными условиями
  • LearnСТРОИТЬ МЕТА-ПРОЦЕССзамыкающий цепочки обратной связи
    Положить непрерывнуюадаптацию в основу мета-процесса
  • 44. LearnСТРОИТЬ МЕТА-ПРОЦЕССзамыкающий цепочки обратной связи
    Строить свой собственныйпроцесс и адаптировать его под изменяющиеся условия
  • 45. LearnСТРОИТЬ МЕТА-ПРОЦЕССзамыкающий цепочки обратной связи
    Best practices
    Good practices
  • 46. Unlearns
    БЫТЬ БЕЗОТКАЗНЫМ
    ФИКСИРОВАТЬ ОБЪЕМ ПРОЕКТА
    СТРОИТЬ УНИВЕРСАЛЬНУЮ АРХИТЕКТУРУ
    ПУТАТЬ ПРОФЕССИОНАЛИЗМ И ХРАБРОСТЬ
    ПОЛАГАТЬСЯ НА СТАНДАРТНЫЙ ПОДХОД
    #itjam #unl
  • 47. Хорошего плавания!
    S C R U M g u i d e s