Things To Unlearn In Software Development

893 views

Published on

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

Published in: Business, Technology
1 Comment
5 Likes
Statistics
Notes
No Downloads
Views
Total views
893
On SlideShare
0
From Embeds
0
Number of Embeds
154
Actions
Shares
0
Downloads
0
Comments
1
Likes
5
Embeds 0
No embeds

No notes for slide

Things To Unlearn In Software Development

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

×